PMsoop: Глава №5: МП знакомится с Заказчиком

в 3х частях

В ролях – Заказчик, Менеджер Проекта, может быть Бизенс Аналитик

Артефакты – ПОЗП, предложение на разработку, Контракт

Суть – Менеджер Проекта начинает общение с Заказчиком проекта

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

Собственно, познакомиться с Заказчиком МП мог и ранее – в зависимости от принятого процесса и сложившихся обстоятельств. Суть данной главы в том, что Менеджер Проекта должен, просто обязан, до начала планирования работ и до объяснения задач проекта команде проекта синхронизировать своё понимание/видение данного проекта с Заказчиком. Ибо, как я уже отмечал ранее, синхронность/одинаковость понимания сути проекта, его задач и приоритетов этих задач между Менеджером Проекта и Заказчиком является фактически ключевым аспектом успешности проекта. Неправильное понимание МП задач проекта или их приоритетов приводит к ошибкам при постановке конкретных задач по реализации функционала разработчикам проекта, и в результате элементарным образом получается не то, что было нужно, не тогда, когда нужно, не так как нужно или что-то вообще ненужное. Теперь переходим к рассмотрению действий по существу.

Часть 1. Про общение.

Как именно знакомиться с Заказчиком? Можно начать например таким письмом:

“Здравствуйте Иван Иванович,

Меня зовут Вася Пупкин, я менеджер проектов в компании ХХХ и мне поручено руководство вашим проектом “создание новой мега-системы”. Сообщите пожалуйста, когда вам будет удобно ответить на несколько вопросов.

С надеждой на заимовыгодное сотрудничество,

Вася Пупкин”

Можно позвонить, можно написать Закзачику в скайп или аську – всё зависит от способов общения, предпочитаемых Заказчиком (которые можно выяснить у сейлза, например), возможностей (в аутсорсинге личные встречи не всегда получаются) и фантазии Менеджера Проектов. Общая рекомендация – чем ближе общение к “живому”, тем легче и быстрее оно происходит. Способы общения по приоритетам:

1. Встреча вживую с использованием наглядных материалов (доска + маркеры = гениальное изобретение)
2. Встреча вживую
3. Видеоконференция
4. Аудиоконференция (звонок по телефону или скайпу, скайп лучше т.к. простым образом записывает разговоры)
5. Чат
6. Переписка по email

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

1. При личных встречах – если обе стороны не против желательно использовать диктофон.
2. Исользовали ли вы диктофон или нет – по завершению встречи крайне рекомендуется написать “meeting minutes” и разослать всем участникам. Что такое meeting minutes хорошо знает гугл.
3. При видеоконференциях – есть масса ПО для захвата и запси видеопотока. Meeting minutes тоже никто не отменял.
4. Аудиоконференции – аналогично. И снова – meeting minutes наше все!
5. Чаты – храним историю переписки!
6. Email – достаточно не удалять письма до окончания проекта (а лучше и после – сложить в архив и пусть живет, а то вдруг продолжение или переделки)

Все таки раскрою краткую суть meeting minutes: это некоторый текст, обычно электрическое письмо типа email, в котором перечислены участники встречи, основные темы которые обсуждались, принятые решения (ключевая часть!) и намеченные задачи на будущее. Meeting minutes следует писать “по горячим следам”, и отправлять решительно всем участникам встречи. Часто ответственным за написание meeting minutes в ходе проекта является Менеджер Проекта, и этой ответственность ни в коем случае не стоит пренебрегать.

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

Часть 2. Про выяснение требований, или “Необходимо”

Отступление: В идеальном проекте всю работу по выяснению и уточнению требований выполяет отдельная роль – Бизнес Аналитик, задачей которого является формирование полного и ясного ТЗ. В реальности идеальных полных и ясных ТЗ не встречается (если у кого есть – присылайте ), и часто Менеджер Проекта, даже при наличии в проекте бизнес аналитика, все равно выполняет некоторые задачи анализа будучи вынужденым уточнять требования по ходу проекта. Кроме того, в заказной (а тем более аутсорсинговой) разработке для проектов небольшого (определяется в разных компания по-разному) масштаба выделение бизнес аналитика на проект может являеться нежелательной тратой ограниченных ресурсов, так что все задачи анализа выполняются МП.

Идем дальше. Сначала задаём самые важные вопросы. По мере получения ответов – заодно понимаем насколько понимание наиболее значимого функционала соответствует пониманию Заказчика. В некоторых случаях Менеджера Проекта могут ожидать удивительные открытия.

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

Чёткие рекомендации по определению важности предоставить трудно, главное о чем следует помнить – Заказчик обычно склонен мыслить на уровне бизнес-идей, и “спуск” на технические уровни Заказчика может весьма утомить, либо наоборот, вызвать прилив не очень желательного энтузиазма. Многие начинающие Заказчики любят лично расставлять кнопочки и определять их цвета, обращая на это чуть ли не больше внимания чем на основной функционал. Задача Менеджера Проектов – “удержать” Заказчика на уровне его компетентности и при этом выяснить все действительно важные аспекты проекта.

При выяснении вопросов у Заказчика рекомендуется группировать вопросы сообразно тематике и задачам проекта, которых они касаются. Последовательное “забрасывание” заказчика разными вопросами, касающимися разных задач проекта, быстро утомляет как Заказчика, так и вопросителя, а также усложняет разбор полученных ответов. Лучше заранее подготовить несколько серйи вопросов, и задавать их отдельными блоками (тем более часто бывает что несколько вопросов могут быть взаимосвязаны). Между сериями вопросов следует делать перерывы (размер перерыва зависит от времени которое можно потратить на обсуждение вопросов вообще, и времени которое занимает обсуждение одной серии вопросов) – в время таких перерывов информация “укладывается в головах”, и могут возникать новые мысли касательно уже состоявшегося обсуждения.

Пожалуй, на этом краткий обзор начала общения Менеджера Проекта с Заказчиком и рекомендации “что делать” пока закончу. Любознательный читатель для получения более полной информации может обратиться к источникам по Бизнес Анализу и Requirements Facilitation.

По результату всех описанных действий (кто бы их не выполнял – МП или бизнес-аналитик) Менеджер Проекта должен обрести уверенность в том, что его понимание задач проекта и их приоритетов аналогично пониманию Заказчика. Еще раз повторюсь – “одинаковость” понимания задач (бизнес-идеи) проекта между МП и Заказчиком это ключевой фактор успешности проекта. Наличие в проекте бизнес аналитика обычно помогает достижению “одинаковости”, но его не гарантирует. Менеджер Проекта должен  уделить особое внимание этому вопросу самостоятельно, используя все доступные средства, в том числе и бизнес аналитика (если он есть).

Часть 3. Про сроки, или “Достаточно”

Бывает, что время на обсуждение и выяснение вопросов ограничено. Например, есть установленный срок сдачи первой версии проекта, и руководство “давит” чтобы начать разработку как можно раньше. Бывает, что Заказчик устал от вопросов, или через 2 дня срочно уезжает в командировку. Вообще, часто бывает что выяснить все важные вопросы до старта собственно разработки не представляется возможным. Это, в общем, нормально.

В таких случаях необходимо до старта разработки выяснить всего два основных момента.

Первым моментом является понимание бизнес-идеи проекта. Без чёткого понимания каким образом Заказчик получит выгоду от реализации данного проекта стартовать разработку категорически не рекомендуется.

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

Как известно, в подавляющем большинстве случаев функционал проекта реализуется не весь и сразу, а в некоторой последовательности, определенной планом проекта. С точки зрения требований (ТЗ), отдельные элементы функционала определяются отдельными задачами проекта, которые в свою очередь определяются общей бизнес-идеей проекта. При планировании реализации функционала логично и рационально в первую очередь реализовать функционал, воплощающий наиболее важную задачу проекта. Потому что чем раньше Заказчик сможет “потрогать” основной “механизм” своей идеи – тем раньше Разработчик получит либо утверждение, либо изменения основного функционала. Переделки основного функционала в конце проекта штука очень неприятная, поэтому лучше основной функционал реализовать и утвердить в первую очередь.

Таким образом, для реализации второго момента нужно понять, что именно (какой ключевой функционал) возможно воплотить в первую очередь и затем проверить, и договориться об этом с Закзачиком. Говоря другими словами – определить и прояснить, а затем утвердить скоуп первой итерации проекта. При этом принимается, что вопросы касательно прочего функциоанала можно будет выяснить во время разработки первой итерации.

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