Любая проектная задача проходит начальные фазы обзора, так называемый пресейл (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 проекте — это некий шаблон, но зачастую, один специалист выполняет несколько ролей и задач. В зависимости от масштаба проекта, бывает разный набор ролей, а также, отличаются исполняемые функции. Например, в некоторых случаях распределение ролей команды может меняться и быть гибче.

Продолжение следует.