Продолжаем улучшать коммуникацию со стейкхолдерами

В начале февраля мы делились с вами статьей Александра Плескова, руководителя проектов в Ауриге. В ней были рассмотрены стратегии организации взаимодействия со стейкхолдерами на разных этапах заказной разработки ПО.

Продолжаем улучшать коммуникацию со стейкхолдерами

Александр выпустил новую статью, посвященную важности правильного взаимодействия между подрядчиком и заказчиком в самом начале проекта. Он затронул такие темы как выбор модели разработки, выбор финансовой модели взаимодействия, определение требований к будущему программному продукту.

Некоторые подходы к разработке, такие как Agile, акцентируют внимание на тесном взаимодействии с заказчиком и постоянной обратной связи, в то время как другие модели, например, Waterfall, предполагают более ограниченное взаимодействие. Ошибочный выбор модели разработки может привести к недостаточной прозрачности ведения проекта и ограниченной обратной связи между командой разработки и заказчиком.

Александр Плесков, менеджер проектов

Аурига в своей работе использует несколько типовых подходов к взаимодействию:

1. Анализ и уточнение требований

Этот подход заключается в проведении на предварительном этапе дополнительного анализа и уточнения требований, особенно если исходные бизнес-требования недостаточно детализированы. На этом этапе системный аналитик Ауриги совместно с ключевыми стейкхолдерами разрабатывает частное техническое задание (ЧТЗ).

Продолжаем улучшать коммуникацию со стейкхолдерами

2. Итерационный Agile Подход

Подход основывается на разработке ТКП на основе верхне-уровневого описания бизнес-требований (CRS), предоставленного заказчиком. Здесь предлагается выполнять проект итерационно с использованием Agile методологии, такой как Scrum или Kanban, и финансовой модели Time & Material.

3. Разработка Бизнес-Требований «С Нуля»

Согласно этому подходу представитель компании (менеджер продуктов или бизнес-аналитик) общается с ключевыми стейкхолдерами, выявляет их боли, проблемы и задачи, и разрабатывает начальную версию CRS (customer requirement specification). Этот документ затем подвергается нескольким итерациям ревью со всеми заинтересованными сторонами, и после согласования используется для разработки ЧТЗ.

Начать дискуссию