Введение
В эру, когда технологии развиваются с беспрецедентной скоростью и рыночная конкуренция достигает своего апогея, заказная разработка проектов превращается в поле битвы, где каждый стремится к доминированию. Многие компании, однако, совершают фатальную ошибку, пренебрегая критически важным аспектом: учетом интересов всех стейкхолдеров. Отказ от учёта мнений всех заинтересованных сторон – от заказчиков до конечных пользователей – это не просто упущение, это стратегическая ошибка, способная обернуться катастрофой для проекта. Да, уравновешивание разнообразных и часто конфликтующих требований и ожиданий – задача не из лёгких. Но именно этот вызов определяет, будет ли проект заказной разработки триумфом инноваций и клиентоориентированности или провалом, обусловленным узким взглядом и игнорированием широкого круга влияний. В данной статье мы анализируем, почему безоговорочное внимание к интересам всех стейкхолдеров – это не просто хорошая практика, а необходимость для гарантии успеха любого проекта заказной разработки. И начнем мы с разбора одной из типичных ситуаций на проекте, с которыми сталкиваются подрядчики.
Дисклеймер: кто такие стейкхолдеры?
Прежде всего, давайте уточним, кто такие стейкхолдеры в контексте нашего проекта. Стейкхолдеры – это лица или группы людей, формирующие бизнес-цели проекта, заинтересованные в его результатах, влияющие на его ход и итоги, а также конечные пользователи и те, кто будет заниматься сопровождением разработанного ПО: заказчик или владелец продукта, руководители заказчика, эксперты по информационной безопасности, владельцы бюджета или акционеры, партнеры. пользователи или клиенты.
История одного неуспеха: «типичный» сценарий
Рассмотрим на примере достаточного типового сценария, как может развиваться проект и к каким результатам в итоге это может привести в случаях, когда не учитываются интересы части ключевых стейкхолдеров.
Изначально владелец продукта утверждает бизнес-требования для разрабатываемого программного обеспечения, и аналитик подрядчика создаёт частное техническое задание (ЧТЗ), удовлетворяющее этим требованиям. Этот документ, одобренный со стороны заказчика, лежит в основе подписанного договора на разработку ПО. Работа начинается, команда сформирована И разработка проекта идет успешно в соответствии с утвержденным планом-графиком в течение нескольких месяцев.
Проблемы начинаются, когда один из конечных пользователей, не участвовавший в процессе утверждения, высказывает своё недовольство результатами первого этапа. Его возражения привлекают внимание финансового контролера, который начинает подробно разбирать, что было сделано и на каких условиях. Он ясно дает понять, что дополнительные средства и время на расширение функционала ПО не предоставятся.
Ситуация усложняется, когда выясняется, что руководитель проекта со стороны заказчика не имеет полномочий на изменение условий работ. Это вынуждает заказчика прекратить выплаты за уже выполненные работы и назначить нового руководителя, который отказывается от предыдущих договоренностей. К тому же запросы конечных пользователей из разных департаментов начинают противоречить друг другу, усугубляя конфликт между заказчиком и подрядчиком.
Когда ситуация достигает критической точки, в неё вмешивается генеральный директор заказчика, а затем и служба безопасности, которая начинает вводить ограничения, делая работу ПО фактически невозможной. В итоге, управляющий комитет, включающий всех ключевых стейкхолдеров, принимает решение остановить проект из-за недостаточной координации и внимания к деталям со стороны всех участников. Это приводит к остановке проекта и отказу заказчика оплачивать уже понесенные подрядчиком затраты, несмотря на ранее утвержденные документы.
Разбор полетов: что пошло не так
Эта история закончилась разочарованием: заказчик пришел к выводу, что подрядчики и заказная разработка не подходят для его продукта, в то время как компания-разработчик снова столкнулась с проблемой, когда заказчики не имеют четкого представления о своих желаниях. Давайте попробуем разобраться в корнях возникших проблем в описанной выше ситуации.
Перед стартом проекта
- Неполное участие ключевых стейкхолдеров: В процессе обсуждения бизнес-требований и разработки ЧТЗ не участвовали все ключевые стейкхолдеры, такие как конечные пользователи, владельцы бюджета и инженеры compliance. Это привело к формированию неполного ЧТЗ, в котором отсутствовали важные требования пользователей и стандарты безопасности.
- Формальное согласование ЧТЗ и договора: Стейкхолдеры подписали ЧТЗ и договор на разработку без должного внимания к деталям, не предоставляя обратной связи и не анализируя суть требований.
- Неопределенность полномочий руководителя проекта: В начале проекта не были ясно обговорены и согласованы полномочия и области ответственности руководителя проекта со стороны заказчика.
- Расхождение мнений среди конечных пользователей: Конечные пользователи не имели единого мнения о функциональных возможностях разрабатываемого ПО и не могли прийти к общему соглашению.
В ходе выполнения проекта
- Исключение ключевых стейкхолдеров из процесса коммуникации: Важные стейкхолдеры, включая конечных пользователей и владельцев бюджета, не были вовлечены в коммуникационный процесс проекта. Они не участвовали в проектных митингах, не получали отчетов о ходе и результатах проекта и не давали обратную связь.
- Недостаточная передача информации руководству: Владелец продукта и руководитель проекта со стороны заказчика не обеспечивали своевременное, точное и полное информирование вышестоящего руководства и владельцев бюджета о проблемах и ходе проекта, что приводило к утаиванию или искажению информации.
- озднее подключение владельца бюджета: Владелец бюджета включился в процесс коммуникаций только после того, как конечные пользователи выразили недовольство результатами проекта.
- Запоздалое вмешательство высшего руководства: Генеральный директор и отдел compliance начали активно участвовать в решении проблем и оказывать влияние на проект только после того, как ситуация стала критической.
Ключевые стратегии: как предотвратить кризис
Давайте обсудим ключевые рекомендации для эффективного вовлечения стейкхолдеров в процесс разработки, начиная с определения бизнес-требований и до передачи готового или промежуточного продукта заказчику:
Анализ потенциальных стейкхолдеров: определите и вовлеките в проект наиболее важных стейкхолдеров, включая тех, кто принимает ключевые решения и влияет на результаты проекта.
Понимание интересов стейкхолдеров: выясните потребности, ожидания и приоритеты стейкхолдеров для более точного планирования и разработки проекта.
Включение стейкхолдеров в планирование: обеспечьте участие представителей разных групп интересов на начальном этапе планирования для формирования полных бизнес-требований и технического задания.
Активное использование коммуникаций: наладьте открытую коммуникацию со всеми ключевыми стейкхолдерами, включая проведение опросов и собраний, чтобы учитывать их мнения и предложения.
Процессы и инструменты для учёта интересов стейкхолдеров: разработайте процессы ревью и согласования ТЗ, проведите совместные планирования и регулярные демонстрации с участием всех ключевых стейкхолдеров.
Обучение и информирование стейкхолдеров: повышайте осведомленность заказчиков и других ключевых участников о важности учета интересов всех стейкхолдеров.
Совместное принятие решений: включайте стейкхолдеров в процесс принятия решений на всех этапах разработки, документируя и предоставляя согласованные договоренности.
Управление ожиданиями стейкхолдеров: оценивайте возможности проекта реалистично и устанавливайте четкие ожидания, информируя о рисках и управлении ими, а также согласовывайте приоритеты, сроки и цели проекта.
Заключение
В этой статье мы исследовали типичные проблемы проектов по заказной разработке ПО, возникающие, когда не все заинтересованные стейкхолдеры своевременно включены в проект. Мы обсудили, как это влияет на планирование, ход и результаты проекта, и предложили ключевые рекомендации для работы со стейкхолдерами, направленные на минимизацию рисков и проблем. В следующей статье мы рассмотрим типичные подходы Ауриги к организации и управлению проектами, которые мы предлагаем нашим клиентам. В заключение хочется акцентировать, что внимание к интересам ключевых стейкхолдеров и их постоянное вовлечение имеет решающее значение для успеха управления проектами, по следующим причинам:
- Удовлетворение потребностей клиента: Учет интересов всех стейкхолдеров обеспечивает соответствие ПО ожиданиям и требованиям клиента, выявляя ключевые потребности и цели.
- Предотвращение конфликтов: Учёт разных интересов помогает избежать конфликтов, находя компромиссные решения и учитывая различные точки зрения.
- Улучшение качества продукта: Разнообразие мнений стейкхолдеров способствует созданию ПО, удовлетворяющего разные группы пользователей, что улучшает качество и функциональность продукта.
- Успешная реализация проекта: Учет интересов всех стейкхолдеров способствует реалистичному планированию и вкладу каждой стороны в разработку, что обеспечивает эффективное выполнение проекта в рамках установленных сроков и бюджета.