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