Сегодня мы поговорим о роли системного аналитика в процессе разработки продукта. Данную тему я постараюсь раскрыть за 3 простых шага:
- Взгляд заказчика на разработку ПО
- Процесс разработки небольшой командой
- Процесс разработки решений в крупных компаниях
Магия для заказчика
Представим, что есть заказчик, который много размышляет над тем, как ему улучшить рост бизнеса и, например, повысить продажи, оптимизировать процессы внутри компании или запустить свой стартап.
В какой-то момент заказчик придумывает идею, которая предполагает разработку программного продукта. Далеко не все люди знают программирование и могут позволить себе самостоятельно запустить хотя бы минимальную версию продукта, чтобы выйти на рынок. Что же делать тем, кто решил разработать продукт, но не знает как это сделать?
Заказчик решает обратиться в IT-компанию или найти команду фрилансеров, которые будут готовы реализовать его задачу. Он обращается к менеджеру со стороны IT и на глазах заказчика происходит непонятная магия и продукт уже готов...
Реальность не такая загадочная
Мы разобрались, как заказчик видит процесс разработки продукта. Теперь самое время посмотреть на этот процесс изнутри.
На самом деле под магией лежит команда профессионалов, которые занимаются той самой разработкой программного продукта. Вариантов распределения ролей внутри команды огромное множество. Состав команды очень сильно зависит от того, в какой компании происходит разработка и того, какой продукт разрабатывает команда. Давайте рассмотрим упрощенный состав команды, чего должно быть достаточно для понимания.
В нашей вымышленной команде есть архитектор, разработчики, тестировщики и сопровождение. Именно эти ребята в нашем случае переваривают информацию, которую доставил им менеджер, и готовят программный продукт.
Архитектор, это тот человек, который получает требования к программному продукту от менеджера, переваривает их и готовит описание архитектуры решения поставленной задачи. Архитектура программного продукта – это список технологий, которые должна использовать команда разработки, описание модулей, которые необходимо разработать, описанные взаимодействия между модулями и другие ограничения к продукту.
Разработчик, это тот человек, который получает требования от менеджера и результаты работы архитектора, и на основе полученных данных пишет код и разрабатывает сам продукт.
После того, как продукт разработан в дело вступает тестировщик, который проверяет качество разработанной системы и ищет ошибки, требующие исправления.
Когда продукт разработан и протестирован, его можно запускать и передавать заказчику. Чтобы это сделать к процессу подключается сопровождение. Эти ребята, кроме внедрения, осуществляют и поддержку продукта, а именно решение проблем, возникающих в ходе эксплуатации продукта.
Зачем нам еще кто-то?
У читателя скорее всего возникает вопрос: "Вроде же все очень просто и зачем в этом процессе аналитик?"
Действительно, если говорить про схему разработки стартапа или маленького продукта в простых условиях, то даже приведенную схему можно упростить до 2х-3х человек. Но давайте предположим, что заказчик работает в крупной компании и количество заинтересованных сторон в несколько раз больше:
- Заказчик не один, а это целый отдел сотрудников, у каждого из которых свое видение продукта
- В компании есть служба безопасности, которая следит за данными, передаваемыми в системах, за безопасностью инфраструктуры и других частей производственного процесса
- Существуют также смежные команды, которые разрабатывают свои продукты для компании, которые так или иначе могут влиять на функциональность вашего продукта
- Множество других носителей требований, которые необходимо учесть в ходе процесса разработки
Что делать менеджеру в данной ситуации? Логичный, но не всегда очевидный для всех тезис: "не каждый менеджер глубоко разбирается в ИТ и в бизнес составляющей продукта". НО даже если наш менеджер такой молодец и глубоко знает ИТ и бизнес составляющую продукта, у него есть свой набор задач: планирование ресурсов, участие в построении стратегии подразделения, приоритезация задач проекта и другие. Получается, что разобраться во всех технических нюансах проекта, качественно собрать требования со всех заинтересованных лиц и донести до команды менеджер не может при всем желании из-за недостатка времени. Менеджеру очень сложно успеть сделать всю работу за всех и при этом достаточно качественно.
В этот момент в нашем проекте появляется аналитик:
Это именно тот человек, который станет драйвером нашего продукта и будет общаться со всеми заинтересованными сторонами, собирать требования, обсуждать и прорабатывать решения.
После того, как аналитик собрал требования он готовит техническое задание, которое запускает процесс работы команды, менеджер получает продукт и передает его заказчику.
Вывод
Сегодня мы верхнеуровнево ознакомились с ролями процесса разработки программного продукта и с местом аналитика в команде. В следующей статье я расскажу свое видение обязанностей и навыков, которые должен подтягивать аналитик для качественного выполнения своих задач.