Зачем нужна предварительная аналитика при разработке IT-продукта

Любая строительная компания тут же вас остановит. Ведь перед тем, как строить дом, нужно создать проект, чертежи, просчитать все параметры, определиться, из какого материала он будет, сколько планируется комнат, окон, входов и так далее. Если пропустить этот этап, то дом в итоге получится далеко не таким, как вы его себе представляли.
Аналогичная модель применима и к IT-разработке. Её начальный этап — сбор аналитики. Некоторые заказчики недооценивают исследовательские работы, полагая, что в этот момент ничего не происходит — ведь сам продукт не разрабатывается, и их время будто бы тратится впустую. Но именно от этого этапа во многом зависит не только качество итогового продукта, но и сроки завершения работы над ним, а также его итоговая стоимость. Что же включает в себя этап аналитики? — специалисты RedLab расскажут далее в материале.

Что же представляют из себя эти исследовательские работы?

Аналитика начинается со сбора данных о будущем продукте — бизнес-задачи, пользовательские требования, бизнес-процессы, сущности системы. Иногда заказчик уверен, что он точно знает, какой продукт хочет получить. Но в разговоре оказывается, что не все нюансы учтены. Причем, о некоторых из них клиент может и не подозревать. Работа аналитика как раз и заключается в том, чтобы собрать все данные, осветить все нюансы и предложить варианты оптимизации процессов. После этого собранные данные анализируются, и на их основе синтезируется решение в виде модели продукта и функциональных требований.

Т.е. результатом этапа анализа является логическая и функциональная модель системы, которая одинаково понятна всем участникам процесса: заказчику, разработчику, тестировщику. И вот на основе этой модели и ведется разработка. Процесс аналитики достаточно цикличный, поскольку требования могут со временем меняться и трансформироваться. Более того, иногда могут находиться даже новые зависимости.

Обычно этап анализа занимает 10-20% от стоимости всей разработки. При этом, подробная аналитика позволяет на раннем этапе выявлять ошибки проектирования и снижать на 80% и более стоимость изменений. Т. е. если разрабатывать продукт без этапа анализа, то суммарные затраты на разработку, дизайн, тестирование и менеджмент можно смело умножать минимум на два.

Основные этапы процесса аналитики:

1. Анализ предметной области: определение целей, заинтересованных лиц, их влияния на проект и возможности в системе, границ системы, бизнес требований.
2. Формализация бизнес процессов: кто, где и как взаимодействует с системой.
3. Моделирование предметной области: определение основных сущностей, их свойств и взаимоотношений. На основе этой модели в последствии проектируется база данных и функциональные требования.
4. Формализация нефункциональных системных требований: к серверам и нагрузке, к тестированию, локализации, дизайну, пользователям и прочее.
5. Описание функциональных требований и сценариев использования для каждой роли в системе. До разработки каждый сценарий согласуется с заказчиком и разработчиками.

Какие существуют риски разработки продукта без этапа анализа:

1. Результат может получиться совсем не тот, который ожидался. Возможно, цели были ошибочно определены или участники команды их по-разному интерпретировали.
2. Ошибка в построении IT-инфраструктуры и системной архитектуры, поскольку не были выявлены критичные требования. Переделка может дорого обойтись, а таких изменений может быть несколько за проект.
3. Bus-factor. При смене разработчика на проекте вся информация уйдет вместе с ним, придется тратить дополнительное время на погружение нового специалиста.
4. Риски штрафов. Можно упустить влияние нормативных актов, вроде GDPR или 152-ФЗ, и, как следствие, получить штрафы на приличную сумму.

Что получает заказчик, согласившийся на начальный этап анализа:

1. Уверенность в том, что его видение целей и задач системы и логики взаимодействия с ней пользователей разделяется разработчиками в полной мере.
2. Ранний просчет возможных «узких мест» и возможность сэкономить на будущих убытках.
3. Снижение сроков и стоимости разработки — иногда более, чем в два раза.
4. Полную документацию по проекту, которую можно использовать в дальнейшем, если заказчик решит сменить разработчика.

Обычно в команде выделяется отдельная роль — системного и бизнес-аналитика, который отвечает за этап анализа. Но все зависит от специфики проекта. Иногда в этой роли могут выступать product owner, project manager, team lead или архитектор, ux-дизайнер: разные части этого процесса могут быть распределены между всеми участниками команды.

Существует вариант, когда аналитику проводит сам заказчик — если у него в команде есть соответствующие специалисты. В любом случае аналитика должна стать обязательным этапом проекта. Такой подход поможет в будущем сэкономить не только время и деньги, но и получить желаемый результат. Кроме того, сам проект, который разрабатывается в результате аналитики (например, его концепция) является самостоятельным документом, который можно использовать и в дальнейшем, если вам придется сменить разработчика.