Организация команды. Устав проекта как средство разрешения конфликтов, часть 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. Практика

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

  1. Yuri Shilyaev

    Честно говоря, мне про практику самому интересно почитать. 🙂
    Хотя я и в гуще событий нахожусь.

    Reply
  2. Juras Vetrau

    Вся практика как раз взята из вчерашнего письма, только что с купюрами 🙂 Ну и плюс чуток пересмотрел для более литературного вида 🙂

    Reply
  3. Pingback: Организация команды. Устав проекта как средство разрешения конфликÑ

  4. Pingback: Организация команды. Устав проекта как средство разрешения конфликÑ

  5. Pingback: Итерационная разработка. РазбиенÐÂ

  6. Pingback: Итерационная разработка. РазбиенÐÂ

  7. Pingback: Проектирование пользовательских интерфейсов. Краткий обзор процес

  8. Pingback: Проектирование пользовательских интерфейсов. Краткий обзор процес

  9. Pingback: Проектирование в agile-процессе. График работы команд разработки и аналÐ

  10. Pingback: Проектирование в agile-процессе. График работы команд разработки и аналÐ

  11. Aleksey Kim

    Добрый день!

    Уж больно подробный устав… Для средних и крупных проектов, мне кажется не подойдет, т.к. в начале проекта, когда подписывается устав, еще многое не очевидно (например, п.4-8). Мы, обычно, устав делаем кратким, а далее в других документах расписываем все приведенные пункты…

    С уважением,
    Алексей

    Reply
  12. Juras Vetrau

    @Aleksey Kim
    Обычно поступаем также (изначально есть очень краткий формат устава, который по ходу работ расширяется), но тут проект прошел уже достаточно далеко, команда и формат работы устоялись, можно было описать все более детально.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *