Организация команды. Устав проекта как средство разрешения конфликтов, часть 1. Теория

До сдачи бета-версии одного из текущих проектов остается несколько недель, так что работа кипит особенно бурно. В процессе тестирования и доводки функциональности есть ряд сложных моментов. Появляется необходимость небольших расширений функций, есть задержки со стороны поставщиков информации — используются сторонние базы данных, местами не хватает ресурсов. Неприятно, но не смертельно — вполне типичные для долгих разработок рабочие ситуации. И все-таки возникают локальные конфликты — за время работы команда проекта расширилась, сменился менеджер проекта. И хотя приоритеты и полномочия не раз расписывались и оговаривались, в процессе всех изменений успели размыться. Самое время освежить их в памяти.

Одно из лучших средств в таком случае — устав проекта. Этот документ должен описать, что, зачем, для кого, как, когда, кто и в каких условиях делает для создания системы. Все это у нас, в общем-то, было. Правда, в виде отдельных документов, писем и результатов обсуждений. Так что со временем картинка размылась.

Существует множество документов для каждой из ключевых фаз проекта. Правда, часто документация превращается из полезного путеводителя в редко используемый бюрократический геморрой. А процесс ее ведения отнимает больше времени, чем экономится на разрешении неясностей с помощью полученных документов. Так что в каждом случае нужно определиться, следовать стандартам дословно или взять из них основную суть.

Устав проекта во многом связан с общим видением проекта (документ Vision). В последнем также описываются цели создания проекта, заинтересованные стороны, рынок и конкуренты, а также другие детали, которые помогают понять, что именно делается. Другое дело что в уставе нам важнее практическое значение этих деталей. Так что исходя из основной для нас задачи устава — зафиксировать процесс работы над проектом — я составил для себя такую схему документа:

1. Краткая вводная. Она должна рассказать:
   1. для чего и кого предназначен этот проект;
   2. кто был инициатором проекта;
   3. какие основные требования выдвигаются к проекту.
2. Цели создания проекта. Что он принесет:
   1. бизнесу заказчика;
   2. конечному потребителю;
   3. компании-подрядчику;
   4. проектной команде.
3. Ключевые задачи. Какие работы необходимо сделать для реализации проекта;
4. Основные этапы работ. Каждый этап должен:
   1. выдать по окончанию достаточный для одной из групп заинтересованных лиц результат;
   2. быть сконцентрированным на определенном круге задач;
   3. обеспечить одно или несколько качеств проекта как минимум на приемлемом уровне;
   4. закончиться в определенный срок.
5. Перечисление участников проекта. В их число входит команда разработки и заинтересованные лица со стороны заказчика. Каждый из них имеет свои:
   1. сферу ответственности;
   2. задачи и обязанности;
   3. полномочия.
6. Постановка и сбор требований. Для каждой из сфер ответственности важно знать, кто:
   1. выдвигает требования;
   2. влияет на принятие этих требований;
   3. планирует и контролирует реализацию этих требований.
7. Процесс ведения проекта. Необходимо определить, какие:
   1. ключевые фазы проходит проект;
   2. методики используются при управлении проектом — гибкие, водопадные, смешанные;
   3. особенности у выбранной методики в проекте.
8. Принятие решений. Стоит описать:
   1. в каких случаях решения принимаются единолично, а в каких необходимо коллективное обсуждение;
   2. какие качества продукта важны для успеха проекта более , а какие — в меньшей степени;
   3. какими могут быть результаты решений.
9. Потенциальные и существующие сложности. Полный список рисков лучше привести в отдельном документе. Но ключевые из этих “погодных условий” полезно видеть и тут:
   1. какие сложности существуют на протяжении всего проекта или ключевых его частей;
   2. кто и какие действия должен предпринять для того чтобы осложнения влияли не так сильно;

Стандарты просят описывать еще и бюджет проекта, его обоснование, порядок отчетности плюс серию других моментов. В нашем проекте устав нужен для разруливания отношений внутри команды, так что их можно смело опустить. Для этого важно знать о приоритетах, ключевых задачах, ограничениях, сферах ответственности, процессе принятия решений.

Кстати, описание проекта можно по вкусу разделить между различными документами — видением проекта, техническим заданием, описанием объема работ (Scope), календарным планом и другими спецификациями. Следовать ли тут своду управленческих правил PMBoK и прочим наборам правил — дело вкуса и требований организации.

1. Организация команды. Устав проекта как средство разрешения конфликтов, часть 1. Теория
2. Организация команды. Устав проекта как средство разрешения конфликтов, часть 2. Практика