Каждый заказчик хочет получить готовый продукт как можно скорее. Но представьте, что вы заказываете не IT-продукт, а, например, строительство дома. Приходите в строительную компанию, вносите предоплату и хотите, чтобы рабочие тут же вышли на площадку для возведения постройки. Любая строительная компания тут же вас остановит. Ведь перед тем, как строить дом, нужно создать проект, чертежи, просчитать все параметры, определиться, из какого материала он будет, сколько планируется комнат, окон, входов и так далее. Если пропустить этот этап, то дом в итоге получится далеко не таким, как вы его себе представляли. Похожая модель применима и в разработке IT-проекта.
Разработка любой системы или продукта начинается с этапа аналитики. Некоторые компании недооценивают исследовательские работы, ошибочно полагая, что в этот момент ничего не происходит. Аналитики собирают данные, но кажется, что продукт-то не разрабатывается. Но именно от этого этапа во многом зависит не только конечный результат, но и сроки проекта, а также его стоимость.
Что же представляют из себя эти исследовательские работы?
Аналитика начинается со сбора данных о будущем продукте — бизнес-задачи, пользовательские требования, бизнес-процессы, сущности системы. Иногда заказчик уверен, что он точно знает, какой продукт хочет получить. Но в разговоре оказывается, что не все нюансы учтены. Причем, о некоторых из них клиент может и не подозревать. Работа аналитика как раз и заключается в том, чтобы собрать все данные, осветить все нюансы и предложить варианты оптимизации процессов. После этого собранные данные анализируются, и на их основе синтезируется решение в виде модели продукта и функциональных требований.
Т.е. результатом этапа анализа является логическая и функциональная модель системы, которая одинаково понятна всем участникам процесса: заказчику, разработчику, тестировщику. И вот на основе этой модели и ведется разработка. Процесс аналитики достаточно цикличный, поскольку требования могут со временем меняться и трансформироваться. Более того, иногда могут находиться даже новые зависимости.
Обычно этап анализа занимает 10–20% от стоимости всей разработки. При этом, подробная аналитика позволяет на раннем этапе выявлять ошибки проектирования и снижать на 80% и более стоимость изменений. Т. е. если разрабатывать продукт без этапа анализа, то суммарные затраты на разработку, дизайн, тестирование и менеджмент можно смело умножать минимум на два.
Зависимость стоимости исправления ошибок от момента их выявления хорошо показана на графике:
Основные этапы процесса аналитики:
- Анализ предметной области: определение целей, заинтересованных лиц, их влияния на проект и возможности в системе, границ системы, бизнес требований.
- Формализация бизнес процессов: кто, где и как взаимодействует с системой.
- Моделирование предметной области: определение основных сущностей, их свойств и взаимоотношений. На основе этой модели в последствии проектируется база данных и функциональные требования.
- Формализация нефункциональных системных требований: к серверам и нагрузке, к тестированию, локализации, дизайну, пользователям и прочее.
- Описание функциональных требований и сценариев использования для каждой роли в системе. До разработки каждый сценарий согласуется с заказчиком и разработчиками.
Какие существуют риски разработки продукта без этапа анализа:
- Результат может получиться совсем не тот, который ожидался. Возможно, цели были ошибочно определены или участники команды их по-разному интерпретировали.
- Ошибка в построении IT-инфраструктуры и системной архитектуры, поскольку не были выявлены критичные требования. Переделка может дорого обойтись, а таких изменений может быть несколько за проект.
- Bus-factor. При смене разработчика на проекте вся информация уйдет вместе с ним, придется тратить дополнительное время на погружение нового специалиста.
- Риски штрафов. Можно упустить влияние нормативных актов, вроде GDPR или 152-ФЗ, и, как следствие, получить штрафы на приличную сумму.
Что дает этап анализа:
- Четкое понимание всеми участниками процесса целей и задач, которые ставятся перед системой логики взаимодействия пользователя с системой.
- Моделирование системы.
- Снижение сроков и стоимости разработки в два и более раз.
- Документирование системы.
Обычно в команде выделяется отдельная роль — системного и бизнес-аналитика, который отвечает за этап анализа. Но все зависит от специфики проекта. Иногда в этой роли могут выступать product owner, project manager, team lead или архитектор, ux-дизайнер: разные части этого процесса могут быть распределены между всеми участниками команды.
Существует вариант, когда аналитику проводит сам заказчик — если у него в команде есть соответствующие специалисты. В любом случае аналитика должна стать обязательным этапом проекта. Такой подход поможет в будущем сэкономить не только время и деньги, но и получить желаемый результат. Кроме того, сам проект, который разрабатывается в результате аналитики (например, его концепция) является самостоятельным документом, который можно использовать и в дальнейшем, если вам придется сменить разработчика.