Юрий Ветров об интерфейсах
  • Главная
  • Статьи
  • Дайджест
  • Конференции
  • Дизайн-менеджмент
  • Дизайн-системы
  • Заметки
  • О блоге
Юрий Ветров об интерфейсах
Юрий Ветров об интерфейсах
  • Главная
  • Статьи
  • Дайджест
  • Конференции
  • Дизайн-менеджмент
  • Дизайн-системы
  • Заметки
  • О блоге

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

  • 6 ноября 2007

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

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

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

Устав проекта во многом связан с общим видением проекта (документ 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. Практика
Юрий Ветров

Директор по бренду и дизайну (ex-Muse Group (Ultimate Guitar, MuseScore, Audacity и другие), Райффайзен Банк и Mail.ru Group). Я руковожу командами, которые отвечают за дизайн, исследования и редактуру бренда и интерфейсов, а также дизайн-систему в коде. Автор книги и курса «Паттерны дизайн-менеджмента» и «Дайджеста продуктового дизайна». Со-организовывал Fintech Design Conf, Mail Design Conf и московский Dribbble Meetup, а также Russian Design Cup. Читал лекции в Британке, курировал курс Future London Academy в Лондоне. Мои публикации есть на Smashing Magazine, UXmatters и UX Collective. Подробнее обо мне.

Другие статьи по теме
View Post
  • Дизайн-системы

Тёмная тема оформления

  • Юрий Ветров
  • 17 мая 2020
View Post
  • Дизайн-менеджмент
  • Статьи
  • Тренды

DesignOps, стремительно ворвавшийся в тренд

  • Юрий Ветров
  • 23 июля 2018
View Post
  • Дизайн-системы
  • Рецензии

Книги о дизайн-системах

  • Юрий Ветров
  • 26 апреля 2018
View Post
  • Дизайн-менеджмент
  • Статьи

UX-стратегия. Часть 6 — Внедрение

  • Юрий Ветров
  • 30 мая 2017
View Post
  • Дизайн-менеджмент
  • Статьи

UX-стратегия. Часть 5 — Дизайн с выхлопом

  • Юрий Ветров
  • 12 апреля 2017
View Post
  • Статьи
  • Тренды

Куда идёт UX в 2016 году

  • Юрий Ветров
  • 14 сентября 2016
View Post
  • Дизайн-менеджмент
  • Статьи

UX-стратегия на практике. Часть 4 —
От дизайн-команды к дизайн-культуре

  • Юрий Ветров
  • 12 сентября 2016
View Post
  • Методы и практики
  • Статьи
  • Тренды

Алгоритмический дизайн

  • Юрий Ветров
  • 27 июня 2016
12 comments
  1. Yuri Shilyaev:
    6 ноября 2007 в 19:03

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

    Ответить
  2. Juras Vetrau:
    6 ноября 2007 в 19:06

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

    Ответить
  3. Уведомление: Организация команды. Устав проекта как средство разрешения конфликÑ
  4. Уведомление: Организация команды. Устав проекта как средство разрешения конфликÑ
  5. Уведомление: Итерационная разработка. РазбиенÐÂ
  6. Уведомление: Итерационная разработка. РазбиенÐÂ
  7. Уведомление: Проектирование пользовательских интерфейсов. Краткий обзор процес
  8. Уведомление: Проектирование пользовательских интерфейсов. Краткий обзор процес
  9. Уведомление: Проектирование в agile-процессе. График работы команд разработки и аналÐ
  10. Уведомление: Проектирование в agile-процессе. График работы команд разработки и аналÐ
  11. Aleksey Kim:
    7 мая 2010 в 18:05

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

    Ответить
  12. Juras Vetrau:
    10 августа 2010 в 17:55

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

    Ответить

Добавить комментарий Отменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Юрий Ветров об интерфейсах
Дизайн-менеджмент цифровых продуктов, © 2007-2018

Input your search keywords and press Enter.