Книга: Проектное управление
Назад: Глава 16. Пентабазис. КТО и ЧЕМ? Руководители и исполнители
Дальше: Глава 18. Формирование требований к продукту проекта

ГЛАВА 17

Детальная проработка Пентабазиса

Любые, даже самые смелые планы должны опираться на реальные возможности.

Георгий Жуков, Маршал Советского Союза

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

Посмотрим, насколько может быть «глубока кроличья нора» (рис. 17.1).

Рис. 17.1. Глубина проработки Пентабазиса

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

Для вопроса ЧТО в одностраничнике мы формулируем ключевые продукты и эффекты. Но можно пойти глубже — сделать презентацию с более детальным описанием продукта и оценкой эффектов. А могут и потребовать полноценное техническое задание с детальной моделью расчета эффектов.

Для вопроса КАК можно обойтись ключевыми этапами и шагами. Или приготовить высокоуровневую дорожную карту, в которой более подробно расписать стратегию проекта. А можно и вообще сделать детальный план из сотен работ.

Для вопроса КТО вообще в начале проекта нужно определить только ключевые роли: куратора, заказчика, руководителя проекта. Может быть еще несколько ключевых участников. А можно потребовать поименный состав команды. Или даже ресурсный план по ней с указанием, какой процент времени каждый участник будет каждый месяц работать на проекте.

Для вопроса ЧЕМ можно перечислить только ключевые ресурсы. Или подготовить модель с расчетом объема ресурсов. Или сделать детальный ресурсный план.

Аналогично для УСЛОВИЙ реализации проекта глубина их описания может варьироваться в широких пределах.

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

Вот вам пример известного провала — «Карта российской науки».

Грандиозный проект, запущенный в декабре 2012 года как инструмент для мониторинга сектора исследований и разработок, включая институты РАН, государственные научные организации и высшие учебные заведения. Должен был представлять собой «уникальную по охвату базу, обеспечивающую наиболее полное возможное покрытие результатов научно-исследовательской деятельности российских ученых». В презентации проекта было написано, что он «…превзойдет российские аналоги по функционалу, охвату работ российских ученых и качеству данных».

Суть проекта была проста: собрать все, что публикуется российскими учеными, в одну базу данных. Конкурс выиграла PwC с бюджетом 90 млн рублей и сроком 90 дней (март 2013-го). Потом перенесли на декабрь 2013-го. В итоге проект был тихо закрыт.

Причины из предметной области:

 

Как вы можете видеть, были сделаны драматические ошибки в ответах на вопросы КАК, КТО и ЧЕМ. Вот здесь пилотный проект явно не помешал бы! Вообще, для таких проектов очень полезны три «листа сыра»: четкие метрики, пилоты и поэтапная проработка с гейтами.

Итак, вопрос: как глубоко уходить в проработку проекта? С какого момента можно все-таки запускать его? Достаточно ли первого слоя, зафиксированного в описании, или нужно идти все глубже?

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

Покажу на примере жизненного цикла ТНК-ВР, который мы рассматривали выше (рис. 17.2).

Рис. 17.2. Выбор и планирование

По оси Y мы отмеряем некую абстрактную ценность проекта; это могут быть материальные доллары, рубли и евро или просто некие неэкономические показатели. Итак, зеленая линия показывает вариант, когда мы на первом этапе «Оценка» выбрали верный / оптимальный проект.

Далее, на этапе «Выбор», мы взяли оптимальный вариант его реализации, на этапе «Определение» составили наилучший план, успешно его реализовали и правильно эксплуатируем. Мы получили максимальную ценность. Если же мы выберем правильный проект, но реализуем его не оптимально (плохо отработают менеджер проекта и проектная команда), то полученная ценность будет гораздо ниже.

Но если мы выберем НЕПРАВИЛЬНЫЙ / НЕОПТИМАЛЬНЫЙ проект, то даже при условии его отличного выполнения ценность, полученная в результате, будет невысока. Не говоря уже о случае, когда мы неоптимальный проект еще и реализуем неоптимально.

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

Мы дальше будем использовать вариант «миниморум». Это простейший жизненный цикл: предпроектный этап, подготовка, выполнение, завершение. На предпроектном этапе готовится краткое описание проекта. На этапе подготовки оно прорабатывается по различным аспектам; результатом будет сводный план. На этапе выполнения он реализуется. И это все мы с вами детально в рамках книги вместе пройдем. Стоит помнить, что для своего проекта вы можете выбрать более сложный жизненный цикл, включающий больше этапов.

Однако последовательная поэтапная проработка не всегда достаточна. Помните, как мы разбирали модель «Киневин» и работу в запутанном домене (рис. 17.3)?

Рис. 17.3. Объекты внимания в разных доменах

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

Две базовые практики, которые используются в этом случае, — MVP и HADI-цикл.

Что же такое MVP (Minimal Valiable Product), по-русски «минимально жизнеспособный продукт» (сокращение МЖП, по пока не до конца изученным причинам, в России не прижилось, все говорят MVP)?

MVP, минимально жизнеспособный продукт, — продукт, обладающий минимальными, но достаточными для удовлетворения первых потребителей функциями. Основная задача — получение обратной связи для формирования гипотез дальнейшего развития продукта (Wikipedia).

Другими словами, это продукт, который не содержит множества интересных «рюшечек» и красивого интерфейса. Он просто делает то, что позволяет нам понять: мы движемся в правильном направлении.

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

Посмотрите на известную картинку Фреда Воорхорста, иллюстрирующую идею MVP, и скажите, какой из пунктов — «правильный» MVP: А, Б или В (рис. 17.4)?

Рис. 17.4. Три варианта MVP

Правильный ответ… В. Вариант А не подходит потому, что долго и нет обратной связи (от очень одинокого колеса пользователю никакой пользы нет). Вариант Б — потому, что слишком дорого (на каждом шаге выбрасывается то, что делалось на предыдущем) и разные сегменты (пользователь самоката — это другая целевая аудитория, не та, что ездит на автомобилях).

Для проекта «Кварка» по внедрению CRM MVP может быть небольшое пилотное внедрение части функционала новой системы, чтобы убедиться, что решение вообще компании подходит.

Для проекта «Карта российской науки» MVP было бы создание базы по какой-то одной научной области.

Поэтому если вы не уверены в каких-то предположениях Пентабазиса, попробуйте придумать MVP для проверки.

Второе понятие — HADI-цикл. HADI представляет собой простейший алгоритм — от гипотезы через действие к данным и выводам.

Рис. 17.5. HADI-цикл

Гипотеза (hypothesis). На данном шаге выделяются ключевые неясные моменты проекта, формулируются гипотезы по их проверке и идеи, как эти гипотезы проверить, какие эксперименты поставить.

Действие (action). На этом шаге проводятся эксперименты.

Данные (data). На этом шаге происходит сбор данных за заданный период. Анализируются различия между исходными показателями и новыми измерениями.

Выводы (insights). Получили результат — можно увидеть, насколько успешна гипотеза.

После подведения итогов можно повторить цикл заново. И так до тех пор, пока вы не снимете неопределенность.

Есть очень хорошая книжка Дэвида Бленда и Алекса Остервальдера, которая учит, как формулировать и проверять гипотезы: «Тестирование бизнес-идей». В ней много практических советов и инструментов. Я предлагаю вам воспользоваться одним из них — карточкой тестирования (рис. 17.6).

Рис. 17.6. Карточка тестирования

Сформулируйте свою неопределенность так, как рекомендуют авторы книги.

Итого у вас может получиться полная фраза: «Мы считаем, что… Чтобы подтвердить это, мы… Мы оцениваем… Мы правы, если…».

Например, в проекте открытия филиала неясно, сможем ли мы набрать опытный персонал в офис. Возможна такая гипотеза: Мы считаем, что на рынке труда ДФО есть специалисты с необходимым нам стажем. Чтобы проверить это, подключимся к базе HeadHunter по ДФО и проведем анализ резюме соискателей по ключевым словам. Мы оцениваем количество резюме, которые будут содержать ключевые слова. Мы правы, если оно выше 20 (нам больше и не надо).

Таким образом, если вы видите, что какие-то из вопросов Пентабазиса содержат высокую степень неопределенности, то включите в работы этапа «Подготовка» создание MVP, который поможет понять истину, и (или) запланируйте комплекс экспериментов по снятию этой неопределенности.

КРАТКОЕ РЕЗЮМЕ ДЛЯ СЛОНОВЩИКА

Ответы на вопросы Пентабазиса не всегда могут ограничиться первичной проработкой — краткими ответами на вопросы. Может понадобиться более глубокая проработка по всем или отдельным аспектам.

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

Для отдельных аспектов, попавших в запутанный домен «Киневин», поэтапная проработка неприменима. Тогда стоит использовать практики MVP и HADI-цикл из agile. Например, включить в этап «Подготовка» создание минимально жизнеспособного продукта (MVP), который поможет снять неопределенность и (или) запланировать комплекс гипотез и экспериментов по ее снятию.

Назад: Глава 16. Пентабазис. КТО и ЧЕМ? Руководители и исполнители
Дальше: Глава 18. Формирование требований к продукту проекта