Ведь перед тем, как строить дом, нужно создать проект, чертежи, просчитать все параметры, определиться, из какого материала он будет, сколько планируется комнат, окон, входов и так далее. Если пропустить этот этап, то дом в итоге получится далеко не таким, как вы его себе представляли. 

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

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

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

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

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

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

• Анализ предметной области: определение целей, заинтересованных лиц, их влияния на проект и возможности в системе, границ системы, бизнес требований.
   

• Формализация бизнес процессов: кто, где и как взаимодействует с системой.
   

• Моделирование предметной области: определение основных сущностей, их свойств и взаимоотношений. На основе этой модели в последствии проектируется база данных и функциональные требования.
   

• Формализация нефункциональных системных требований: к серверам и нагрузке, к тестированию, локализации, дизайну, пользователям и прочее.
   

• Описание функциональных требований и сценариев использования для каждой роли в системе. До разработки каждый сценарий согласуется с заказчиком и разработчиками.

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

• Результат может получиться совсем не тот, который ожидался. Возможно, цели были ошибочно определены или участники команды их по-разному интерпретировали.

• Ошибка в построении IT-инфраструктуры и системной архитектуры, поскольку не были выявлены критичные требования. Переделка может дорого обойтись, а таких изменений может быть несколько за проект.

• Bus-factor. При смене разработчика на проекте вся информация уйдет вместе с ним, придется тратить дополнительное время на погружение нового специалиста.

• Риски штрафов. Можно упустить влияние нормативных актов, вроде GDPR или 152-ФЗ, и, как следствие, получить штрафы на приличную сумму.

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

• Уверенность в том, что его видение целей и задач системы и логики взаимодействия с ней пользователей разделяется разработчиками в полной мере.

• Ранний просчет возможных «узких мест» и возможность сэкономить на будущих убытках.

• Снижение сроков и стоимости разработки – иногда более, чем в два раза.

• Полную документацию по проекту, которую можно использовать в дальнейшем, если заказчик решит сменить разработчика.

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

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