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

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

Подробнее об особенностях проекта смогу написать только после его запуска. А вот остальные пункты вырисовались примерно следующим образом (хотя и их привожу с белыми пятнами):

1. Ключевые задачи. Необходимо создать продукт от начала до конца, а именно:
   1. Проработать концепцию продукта практически с нуля при минимальных вводных данных.
   2. Спроектировать и создать интерактивный прототип продукта для того чтобы проработать и утвердить его концепцию.
   3. Разработать и запустить продукт в эксплуатацию.
2. Основные этапы работ. Работы разбиваются на три этапа:
   1. Разработка системы с базовой функциональностью. По окончанию проект запускается в режиме закрытого бета-тестирования. Задачи:
      1. Разработка ядра системы и базовой функциональности.
      2. Создание back-office для редакции проекта.
      3. Отладка функциональности и внешнего вида системы.
   2. Развитие системы до состояния продукта. По окончанию проект запускается в виде публичного релиза. Задачи:
      1. Сбор отзывов о системе и ее совершенствование на их основе.
      2. Наполнение системы информацией.
      3. Причесывание интерфейса и дизайна системы.
      4. Оптимизация интерфейса back-office системы.
      5. Добавление новой функциональности.
   3. Развитие продукта. Четкие границы этапа пока не задаются. Задачи:
      1. Поддержка продукта.
      2. Добавление новой функциональности.
      3. Исследование статистики использования продукта и планирование путей его развития.
3. Принятие решений. Все требования проходят через призму общей концепции продукта. Технические требования от заинтересованных лиц собирают и анализируют ведущий разработчик и менеджер проекта, функциональные и бизнес-требования – бизнес-аналитик. За реализацию требований в системе отвечает менеджер проекта – он назначает необходимые задачи. В случае конфликта требований проводится их общее обсуждение. Требования могут быть скорректированы и отклонены, либо повлечь корректировку или отмену других требований. Важность требований определяется списком приоритетов для проекта (в порядке убывания):
   1. построение успешного продукта;
   2. соответствие концепции;
   3. целостность системы как продукта, наличие необходимой для этого функциональности;
   4. приемлемый уровень качества системы;
   5. сдача проекта в установленные сроки;
   6. возможность развития системы.
4. Участники и ответственность:
   1. Управление проектом. Задачи:
      1. постановка и контроль выполнения задач;
      2. сбор требований от заинтересованных лиц, определение их приоритетности и соответствия требуемым на данном этапе качествам системы, реализация этих требований;
      3. предусмотрение и разрешение проблемных ситуаций;
      4. обеспечение команды разработки необходимыми материалами и информацией;
      5. поиск серверной площадки;
      6. проведение еженедельных планерок;
      7. составление еженедельных отчетов о ходе проекта.
   2. Команда разработки. Задачи:
      1. реализация проекта;
      2. выставление технических требований;
      3. распределение задач по реализации проекта внутри команды;
      4. обеспечение качества проекта.
   3. Заинтересованные лица. Задачи:
      1. выставление функциональных и бизнес-требований;
      2. предоставление информационного наполнения;
      3. выстраивание редакционной политики;
      4. приемка работ;
      5. закупка серверного оборудования.
   4. Выработка концепции и аналитика. Концепцию выдвигает компания-подрядчик, утверждает и корректирует заказчик. Задачи:
      1. проработка общего видения проекта;
      2. анализ рынка и аудитории проекта;
      3. выставление функциональных и бизнес-требований;
      4. планирование развития проекта.
   5. Проектирование пользовательского интерфейса front-office и back-office, визуальный дизайн. Проектированием занимается бизнес-аналитик. Концепция дизайна утверждается заказчиком, дизайн отдельных страниц — бизнес-аналитиком и арт-директором. Задачи:
      1. проектирование интерфейса;
      2. приемка визуального дизайна системы.
   6. Системная администрация. Задачи:
      1. настройка серверов проекта;
      2. установка необходимого ПО.
   7. Промоушен проекта. Продвижением проекта полностью занимается заказчик.
   8. Рекламная политика. Рекламные площадки просчитывает и продумывает рекламный отдел компании-подрядчика. Также необходимо обсуждение рекламной политики с ответственными за общую концепцию проекта. Задачи:
      1. расчет посещаемости системы;
      2. расстановка рекламных мест;
      3. расчет финансовой отдачи от размещения рекламы;
      4. привлечение рекламодателей.
   9. Сбор проектной команды. Задачи:
      1. поиск и интеграция специалистов в команду;
      2. мотивация проектной команды;
      3. кураторство процесса ведения проекта.
5. Постоянно действующие сложности и ограничения. Их могут вызвать следующие особенности проекта:
   1. Неясность концепции. Заказчик отдал этот вопрос нам на откуп, поэтому не всегда возможно достоверно знать, все ли делается как нужно. Из-за этого отдельные моменты интерфейса системы не до конца доработаны. Выходы:
      1. Гибкая концепция, облегчающая изменения.
      2. Планирование изменений в концепции – масштабные правки относятся на второй этап, незначительные делаются на первом.
   2. Отсутствие постоянно доступных ресурсов на дизайн и проектирование. Проектная команда полностью укомплектована менеджментом, разработчиками и тестировщиками, но не имеет на 100% занятых в проекте аналитика и дизайнера. В связи с этим могут происходить задержки в предоставлении материалов по интерфейсу. Еще одна проблема – в процессе изменений концепции не осталось эталонного образца дизайна – все разбросано по дизайну, прототипу и альфа-версии. Выходы:
      1. Постановка задач по интерфейсу большими пакетами, так чтобы их суммарный объем был не менее 4 часов.
      2. Дизайн внедряется в два этапа, в соответствии с этапами проекта. На первом внедряется изначально отрисованный дизайн, все необходимые изменения отрисовывает технический дизайнер. Также готовятся несколько ключевых эталонных страниц. На втором этапе проводится ревью дизайна. На текущем этапе такое ревью не имеет смысла – концепция еще не до конца утрясена, очень вероятно что снова пойдет расхождение между эталонным дизайном и реализацией.
   3. Проблемы с поставкой информации от третьих сторон. Так было, например, при работе с первой БД, когда сперва была долгая задержка с первоначальной поставкой базы данных, а после поставки обнаружилось, что она имеет низкокачественный контент. Сейчас будет проходить интеграция с источниками биржевой информации. И хотя этот поставщик куда более адекватен и профессионален, лучше подстраховаться. Выходы:
      1. Предоставление информации третьих сторон – обязанность заказчика. Необходимо обсуждать сдвиг сроков сдачи в случае серьезных задержек с поставками.
   4. Серверное решение. Не считая возможных задержек с появлением доступа к релизным серверам, вполне вероятно возникновение проблем при установке туда системы. Кроме того, чтобы не разрывать редакционный процесс возможными сбоями при переносе информации с одного сервера на другой, крайне желательно закрыть этот вопрос до сдачи бета-версии. Выходы:
      1. Держать вопрос на постоянном контроле.
      2. Переход на более устойчивый и быстрый демо-сервер. В случае если серверный вопрос не будет решен до сдачи первого этапа, работа с продуктом может начаться на демо-сервере.

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

Все части материала:

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