Сегодня мы поговорим о важном аспекте работы с проектами — сборе требований. Сбор требований является критически важным этапом в любом проекте, так как он закладывает фундамент для дальнейшей разработки и внедрения решения. От правильного сбора требований зависит успех всего проекта, поэтому важно следовать определённым рекомендациям и методологиям.
Microsoft for Learning Material для экзаменации на уровень эксперта предоставляет ценные рекомендации по этому процессу, которые помогут собрать точные и чёткие требования, избежать конфликтов и обеспечить успешное завершение проекта. Мы поделимся с вами этими рекомендациями, так как они будут полезны для Solution Architect и Customer Success Manager (CSM). В частности, мы рассмотрим, как проводить сессии для сбора требований, как формулировать функциональные и нефункциональные требования, и как управлять приоритетами и участниками этих процессов.
Узнать больше о сборе требований можно в нашем видео:
Рекомендации от Microsoft
Проведение сессий для сбора требований
На начальных этапах проекта важно проводить дизайн-сессии, чтобы понять бизнес-процессы клиента. Цель этих сессий заключается в преобразовании высокоуровневых требований в более конкретные, которые можно передать команде разработчиков. Если архитектор или CSM был вовлечен на этапе предпродажной подготовки, это дает преимущество, так как они уже понимают потребности клиента и критерии успеха. В противном случае, архитектор должен убедиться, что он получил всю необходимую информацию и изучил индустрию и пожелания клиента.
Формулировка требований
Требования должны отвечать на вопросы: кто, что, почему и как. Это помогает лучше понять потребности клиента. Хорошие требования учитывают такие факторы, как кому они нужны, что именно нужно клиенту и почему клиент действует определенным образом. Часто требования могут быть построены на основе пожеланий, которые не соответствуют бизнес-процессу, и это нужно учитывать, исправлять и адаптировать под систему, которую мы разрабатываем.
Приоритетность
Проекты имеют ограниченные ресурсы и время, поэтому важно определить приоритетность требований. Архитектор и CSM, вместе с командой, должны расставить приоритеты и сформировать бэклог. Проекты могут делиться на фазы, и идти путем прототипирования до MVP продукта (Minimum Viable Product) является хорошей практикой. Архитектор должен использовать ключевые цели клиента для оценки требований и приоритет отдавать тем, которые помогают достичь этих целей.
Реализуемость (Feasibility)
Архитектор должен оценивать требования на предмет их осуществимости. Важно анализировать, может ли наша система реализовать эти требования. Факторы, которые могут влиять на реализуемость, включают доступные данные и интеграции с другими системами. Нужно задавать себе вопросы, есть ли что-то, что могло бы помешать выполнить эти требования.
Управление участниками сессий
Необходимо обеспечить присутствие правильных людей на сессиях. Несколько коротких сессий могут быть более продуктивными, чем одна длинная. Важно привлекать людей с соответствующим опытом, особенно из отдела продаж, если идет дизайн sales-модуля. Приглашение руководства может быть полезным, но нужно учитывать, что их присутствие может снизить активность менеджеров.
Подготовка к сессиям
Перед каждой сессией нужно проводить подготовительную работу: собирать информацию о текущих решениях, системах, процессах компании, количестве пользователей, индустрии. Это поможет избежать необходимости заставлять клиентов повторять все то, что было на предпродажном звонке.
Четкость требований
Все требования должны быть четкими, чтобы избежать неожиданностей. Часто начальное требование является лишь пожеланием, и архитекторы и CSM должны провести исследовательскую работу, чтобы дойти до истинного требования. Важно задавать вопросы, которые помогают понять настоящую потребность клиента.
Разрешение конфликтных требований
Необходимо иметь Product Owner, который принимает окончательные решения по требованиям. Важно выявлять и разрешать конфликтные требования, получая одобрение от владельца продукта.
Отстаивание своей точки зрения
Архитекторы должны уметь отстаивать свою точку зрения и убеждать клиентов в целесообразности своих рекомендаций, делая это так, чтобы клиент не чувствовал пренебрежения к своим идеям.
Функциональные требования
Функциональные требования описывают, что должно делать решение и его поведение. Они фиксируют, кто будет использовать функциональность, что именно должна делать система и почему это нужно. Если требование слишком большое, его стоит разделить на меньшие части для более детальной разработки. Например, менеджеру нужно иметь возможность утверждать возможности (opportunity), или же пользователю, который создает возможности в системе, нужно предотвратить сохранение записи при переходе на следующую стадию, если не заполнены определенные поля.
При составлении функциональных требований полезно использовать User Stories, которые описывают процесс от начала до конца. Эти истории можно визуализировать в виде диаграммы, которая позже станет основой для функциональных требований.
Acceptance Criteria
Для каждого требования важно иметь четкое понимание того, как оно будет считаться удовлетворенным. Это позволяет избежать недоразумений и обеспечить соответствие конечного результата ожиданиям клиента.
Capture Exceptions
На дизайн-сессиях пользователи часто описывают, как должна работать система в нормальных условиях, но редко учитывают возможные ошибки или исключительные ситуации. Архитектор и CSM должны продумать все возможные исключения и предлагать их клиентам для обсуждения и утверждения.
Avoid Scope Creep
Разрастание требований (scope creep) может привести к затягиванию проекта и увеличению затрат. Важно документировать все требования и избегать постоянных изменений, которые могут отдалить проект от начальных целей. Тщательная документация помогает держать проект в рамках определенных сроков и ресурсов.
Нефункциональные требования
Нефункциональные требования охватывают аспекты, которые напрямую не интересуют пользователей, но они важны для поддержки архитектуры решения и его жизнеспособности. К ним относятся:
Производительность
Производительность компонентов, таких как скрипты, контролы, веб-ресурсы. Это включает оптимизацию кода и обеспечение быстрой работы системы. Например, время загрузки страниц может не зависеть от нас при работе с Power Apps, но мы должны обеспечить высокую производительность наших компонентов.
Вместимость
Ограничения по объему данных и количеству пользователей. Microsoft не выделяет много места, поэтому за ним нужно следить. Большое количество записей или пользователей может повлиять на производительность системы.
Политика хранения данных
Политика хранения данных, включающая очистку логов, аудитов и электронных писем. Это необходимо для поддержания производительности и эффективного использования ресурсов.
Ограничения полей
Ограничения по количеству и размеру полей. Например, максимальное количество полей в таблице или максимальный размер поля.
Доступность системы
Надежность системы, обеспечивающая её доступность 99,9% времени, как это гарантирует Microsoft. Это важно для обеспечения бесперебойной работы системы.
Безопасность
Обеспечение безопасности данных и защита от несанкционированного доступа. Это включает шифрование данных, аутентификацию пользователей и контроль доступа.
Масштабируемость
Возможность масштабирования системы для поддержки растущего количества пользователей и данных. Это важно для обеспечения бесперебойной работы системы при увеличении нагрузки.
Удобство использования
Удобство использования системы для конечных пользователей. Это включает интуитивный интерфейс и простоту в навигации.
Поддерживаемость
Возможность поддержки и обновления системы без значительных усилий. Это важно для обеспечения долгосрочной жизнеспособности решения.
Соответствие требованиям
Соответствие требованиям регуляторов и стандартов. Это включает соблюдение законодательства о защите данных и других регуляторных требований.
На финальной стадии, после завершения сбора требований для этого спринта или в целом для проекта, архитектор должен пересмотреть все заметки, которые были записаны на звонках, сформировать финальные требования, отправить их на утверждение и ожидать подтверждения и корректировки.
Заключение
Сбор требований — это фундаментальный этап в процессе разработки проектов, от которого зависит успех всего дальнейшего цикла разработки. Выполняя рекомендации от Microsoft, мы можем значительно улучшить этот процесс, сделать его более структурированным и эффективным. Рассмотрим ключевые аспекты еще раз.
Во-первых, проведение дизайн-сессий на начальных этапах помогает понять бизнес-процессы клиента и преобразовать высокоуровневые требования в конкретные задачи для разработчиков. Это позволяет избежать многих проблем и недоразумений на последующих этапах проекта.
Во-вторых, правильное формулирование требований с учетом всех деталей (кто, что, почему и как) обеспечивает четкое понимание того, что именно нужно клиенту. Это помогает предотвратить неожиданные изменения и дополнительные затраты.
Приоритизация требований и управление участниками сессий позволяют эффективно использовать ограниченные ресурсы проекта, обеспечивая выполнение наиболее критических задач в установленные сроки. Это особенно важно для крупных проектов с большим количеством участников и переменных факторов.
Подготовительная работа перед каждой сессией, а также ясность и точность требований помогают избежать ненужных повторений и обеспечивают высокое качество конечного результата. В этом контексте важно также уметь решать конфликтные требования и отстаивать свою точку зрения, убеждая клиента в целесообразности предлагаемых решений.
Функциональные и нефункциональные требования являются двумя сторонами одной медали. Если первые описывают, что должно делать решение, то вторые определяют его технические характеристики и ограничения, обеспечивая надежность и стабильность работы системы. Учет обоих типов требований критически важен для успешной реализации проекта.
В итоге, соблюдение этих рекомендаций поможет нам создать более эффективные, стабильные и соответствующие ожиданиям клиентов решения. Мы сможем избежать многих типичных проблем, сэкономить время и ресурсы, а также обеспечить высокое качество конечного продукта. Надеемся, что эти советы будут вам полезны и помогут добиться успеха в ваших проектах.
Comments