Без проработки требований — и достаточно глубокой — можно ошибиться в порядке стоимости проекта, потому что первые версии технического задания часто скрывают подводную часть айсберга. Изначально проект может казаться простым, но стоит начать его делать, как выясняется, что для того, чтобы ПО действительно решало задачу, ради которой было задумано, придется делать значительно больше, чем планировалось.
Существует и обратный риск: переоценить проект, заложив ненужные требования, от которых можно отказаться после анализа приоритетов. Проработка требований позволяет существенно повысить точность оценки.
- Исходная концепция
- Согласованное определение продукта
- Завершение требований
- Завершение проектирования пользовательского интерфейса
- Завершение детального проектирования
- Готовый программный продукт
В ситуации большой неопределенности в стоимость проекта исполнителем закладываются возможные риски и неблагоприятные варианты развития событий. С помощью подробной аналитики на начальном этапе можно проработать элементы, вызывающие вопросы, снизив таким образом и риски, и оценку работ.
Стоимость рисков, которую закладывает подрядчик, существенно выше, чем дополнительные затраты на аналитику на начальном этапе.
Например, в проекте из 10 модулей на каждый из них закладывается определенный процент риска, что в сумме существенно увеличивает общую стоимость.
- Первичная оценка с учетом рисков
- Стоимость после анализа требований
- Первичная оценка с учетом рисков
- Стоимость после анализа требований
Фиксирование требований проводится по неизменной в ходе проекта методологии и позволяет сохранять знания в максимально полном и структурированном виде. Таким образом, все наработки будут доступны для последующего использования новыми участниками и через любые промежутки времени.
Эта задача особенно важна для корпоративных систем, в которых планируется последующее развитие и переход на внутреннюю поддержку.
Чтобы решение могло поддерживать требования к масштабируемости и производительности, необходимые в среднесрочной и долгосрочной перспективе, нужно заранее продумать техническую реализацию, предусматривающую развитие системы.
Если начать разработку без анализа требований, то можно попасть в ситуацию, когда развитие продукта дальше будет невозможно, и затраты на коррекцию решений будут значительно выше, чем на этапе планирования.
- Спецификация требований и проектирование продукта
- Разработка кода продукта
- Тестирование продукта
Аналитика позволяет привести всех участников процесса к единому пониманию требований и содержания проекта, зафиксировать конечную цель, согласовать план работ и контролировать продвижение по нему.
Наша практика показывает, что после старта проекта практически всегда возникают запросы на изменения, поэтому работа над требованиями обычно ведется на протяжении всего проекта и позволяет сохранять управляемость на всех этапах его жизненного цикла.
- Что нужно клиенту
- Что создал разработчик
- Точка контакта с клиентом
- Разрыв ожиданий при участии клиента
- Разрыв ожиданий при невмешательстве клиента
Чем более точная оценка необходима, тем более подробно должны быть проработаны все части технического задания. В зависимости от потребностей вашего бизнеса и специфики проекта определяется набор необходимой проектной документации.
Документы, необходимые для любого проекта. Без проработки этих пунктов шансы на успех проекта резко снижаются.
Верхнеуровневое описание проекта (цели, задачи, границы, заинтересованные стороны, роли пользователей, ключевые процессы и т.п.)
Визуализация системы и окружения, в котором она будет работать, а также потоков данных между ними
Визуальное представление основных функций системы без привязки к ролям и компонентам
Описание ключевых технических рисков, влияющих на возможность реализации системы, и предложения по их устранению
Описание требований к производительности, отказоустойчивости, безопасности, масштабируемости и другим параметрам системы
Чем больше в проекте различных автономных частей, интеграций с внешними системами, команд разработки, тем детальнее нужно будет описать протоколы взаимодействия между частями системы.
Верхнеуровневое описание компонентов системы и схем взаимодействия между ними
Описание протоколов взаимодействия (REST, gRPC и т.п.) между компонентами системы и между системой и внешней средой
Для систем с повышенными требования к надежности требуется тщательная проработка процесса поставки обновлений и плана действий при возникновении форс-мажорных ситуаций.
Чем выше требования к регламентированию процессов, и чем сложнее их автоматизация, тем полнее должны быть описаны варианты взаимодействия пользователя с системой.
Описание решаемых задач и критерии приемки для всех функций проектируемой системы.
Полное описание всех сценариев взаимодействия пользователей и системы, а также автоматических сценариев работы системы.
Для сложных сценариев с несколькими участниками или множеством шагов и ветвлений дополнительно делается визуализация с помощью наиболее подходящих диаграмм (swimlane, sequence и т.п.).
Для эффективной работы после запуска в эксплуатацию необходимо обеспечить пользователей понятными инструкциями для работы и протоколами на случай нештатных ситуаций.
Чем шире круг пользователей приложения, больше конкурирующих приложений или важнее удобство пользователя, тем подробнее нужно проработать структуру приложений, навигацию по экранам и состав каждого экрана.
Визуальное представление основных шагов пользователей в системе
Макеты экранов пользовательского интерфейса и карта основных переходов между ними. Подробные макеты со всеми основными функциональными элементами и карта экранов помогут создать представление о том, что смогут делать пользователи в системе и как эти функции будут распределены по экранам без затрат на детальную прорисовку дизайна и всех состояний системы. Также наличие wireflow позволяет дать более точную оценку стоимости реализации.
Набор экранов, позволяющий эмулировать использование продукта в основных пользовательских сценариях, чтобы анализировать его с точки зрения удобства, простоты и визуального соответствия концепции продукта. Может быть выполнен схематически на базе Wireflow, либо на базе готового дизайна.
Чем больше вовлеченных в проект людей на стороне заказчика, тем подробнее нужно проработать дизайн каждого экрана, чтобы, на как можно более ранних этапах, минимизировать разрыв ожиданий всех участников.
Стиль основных элементов (кнопки, таблицы, выпадающие меню и т.п.) пользовательских интерфейсов проекта
Полностью прорисованные все экраны интерфейсов. При подробной проработке дизайна заказчик сможет показать дизайн потенциальным пользователям, чтобы получить от них обратную связь по понятности интерфейса и общему впечатлению от продукта. После этого можно будет внести правки и максимизировать удовлетворенность пользователей без затрат на кодирование и переписывание кода продукта.
Если внутри компании недостаточно технических компетенций, чтобы оценить полученный от разработчика план реализации, то наличие проектной документации дает возможность обратиться к стороннему эксперту, который сможет дать независимую оценку. Это позволит снизить риск переоценки или недооценки проекта и убедиться в реализуемости требований.
Процесс планирования системы и разработки требований может проходить множественные итерации и на длительных промежутках времени сталкиваться с изменениями приоритетов и состава участников.
Без проработки, структурирования и формализации требований будет невозможно восстановить оригинальные смыслы и целеполагания, важные элементы могут потерять приоритет или и вовсе быть упущены.
Сравнивая предварительные оценки, полученные от нескольких потенциальных исполнителей, нужно иметь в виду, что каждый из них может по-своему интерпретировать ваш запрос и выставить оценку на разный функционал. При создании проектной документации требования фиксируются в детальном и сформулированном виде, что позволяет минимизировать неоднозначность при интерпретации разными исполнителями и получить оценки на разработку, которые можно сравнивать между собой.
Проектная документация позволяет минимизировать потребность в консультации разработчиков или сопровождавщих разработку сотрудников после запуска системы в работу. На основе аналитики функциональных требований создается подробная пользовательская документация, которая делает возможным полноценное использование системы без привязки к конкретным лицам.
