Любая проектная задача проходит начальные фазы обзора, так называемый пресейл (presale):
- Прогнозирование продукта на выходе;
- Предполагаемый бюджет на проект;
- Необходимые сроки для реализации проекта.
На этапе пресейла (presale), с огромной погрешностью в 200-500%, происходят:
- экспертиза;
- анализ команды;
- предварительная оценка проекта.
Далее, стоит задача исключить погрешность до минимума. Для этого, подключаются специалисты, которые выполняют свои определенные роли. Очень важно, чтобы роли были грамотно и правильно распределены между командой проекта. Каждый IT проект состоит из определённых упорядоченных ступеней в лице ответственных участников.
В классических проектах, как правило, в команде присутствуют специалисты:
- Product Owner;
- Business Analytic;
- Software Architect;
- Team Lead;
- Project Manager;
- Software Developers;
- Dev-Ops.
На начальном этапе формируются бизнес требования (БТ) проекта. Для того, чтобы было понимание, из чего будет состоять ресурс, как будут расписаны задачи нужны архитектура и бизнес аналитика. Следует отметить, что успех проекта также зависит от того, насколько вовлечён в процесс и сам заказчик. Очень важны его комментарии, обратная связь, пользовательское тестирование и интерес в реализации проекта.
Product Owner — это уполномоченное лицо, у которого есть не только видение самого продукта и он принимает по нему решения, но и отвечает за финансовый результат продукта. В том числе, этот специалист может менять ход разработки продукта в течение всего процесса, если возникает такая необходимость. Ему необходимо понимать потребности заказчика и последовательность этапов. То есть, в конечном итоге, Product Owner должен быть уверен не только в реализации проекта, но и в том, что на нем начали зарабатывать деньги.
Business Analytic работает в связке с Product Owner и пишет требования для разработчиков. Он расписывает пошагово алгоритм, как прийти к результату проекта. Бизнес аналитику необходимо систематизировать все этапы видения процесса, выдвигаемые Product Owner, последовательно изложить все решения, привести весь процесс к автоматизации и логике. Затем, эта структурированная пошаговая логика проекта уходит на, так называемый, системный анализ.
Системным анализом занимается уже системный аналитик ( System Analytic), как правило, на больших корпоративных проектах. В других случаях, эту роль выполняет также Тимлид (Team Lead) и, частично, разработчики.
Project manager — это человек, который ответственен за выполнение задач, по классической схеме, чтобы проект вписался в сроки, в бюджет и в качество. На практике, не всегда проект выполняется в срок, соответственно, увеличивается бюджет, чем не доволен заказчик проекта. Основными инструментами у проектного менеджера является план проекта, ежедневный митинг и готовая архитектура. У проектного менеджера есть несколько важных функций, в том числе, и функция управления ожиданиями заказчика. То есть, этот специалист, в основном, занимается коммуникацией с заказчиком и командой, улаживанием каких-то конфликтов. Эта роль подразумевает под собой и психолога, и коммуникатора, и человека, который выявляет потребности всех участников команды, отвечает за сроки и качество.
Software Architect – это человек, который занимается непосредственно самим проектированием всего проекта в целом. Он изначально выдвигает ключевое представление по технологическому внутреннему устройству проекта, с точки зрения определения архитектурной парадигмы. После того, как готова архитектура, ее необходимо разложить на определенную последовательность технических шагов и распределить между разработчиками. Это делает Техлид (Techical Lead) или Тимлид (Team Lead) и системный аналитик (System Analytic).
На каждом проекте есть все предполагаемые роли, но количество людей сильно отличается. Чем меньше людей, тем больше обязанностей и функций имеет каждый специалист. Если взять максимальную матрицу возможных ролей, сравнить большой и маленький проект, то не всегда будет моментальный ответ, кто выполняет ту или иную роль. Внешние обстоятельства постоянно изменяются, соответственно, к этому вопросу лучше подходить гибко. Чем гибче распределение ролей в команде, тем меньше каких-то трений.
Роль в it проекте — это некий шаблон, но зачастую, один специалист выполняет несколько ролей и задач. В зависимости от масштаба проекта, бывает разный набор ролей, а также, отличаются исполняемые функции. Например, в некоторых случаях распределение ролей команды может меняться и быть гибче.
Продолжение следует.