Основная идея этой главы в том, что существуют неочевидные причины, почему часто не удается успешно реализовать проекты. Упуская их, и бизнес, и специалисты, работающие над цифровыми продуктами, пытаются устранить последствия, а не причину проблем. Причина кроется в самой природе проектной работы, основное свойство которой – высокий уровень неопределенности.
Неопределенность – основная причина, почему бывает сложно, а порой и просто невозможно спрогнозировать параметры будущего проекта, рассчитать бюджет и оценить сроки. Не учитывая это, компании терпят убытки и винят исполнителей, а те, в свою очередь, апеллируют к недостатку информации для качественного выполнения работ. Даже отказавшись от ответственности сторон с заявлением, что проект «будет готов тогда, когда будет готов», бизнес все равно столкнется с проблемами качества получаемых результатов и непредсказуемыми затратами на создание цифровых продуктов.
Напротив, если принять неопределенность как неотъемлемую часть проектной работы, то логично задаться целью обрести инструменты ее контроля. Эту цель преследует «Метод параноика». Описанию способов ее достижения и будет посвящена оставшаяся часть книги.
Глава 4Принцип контроля неопределенности
Структура главы:
• «Метод параноика» и продюсирование проектов
• Как взять неопределенность под контроль
• Концепция воронки неопределенности
• Принципы метода
«Метод параноика» и продюсирование проектов
Наверное, вы замечали, как в начале проекта все воодушевлены и предвкушают будущий успех. Радостно открывают шампанское и забывают, что день, потерянный в начале проекта, равен дню, потерянному в конце. Но, как ни странно, классические подходы к ведению проектов учат именно такому, иррациональному, с моей точки зрения, отношению к организации работы. В основе лежит концепция управления рисками, которая говорит, что по ходу работы над проектом периодически могут возникать неожиданные проблемы. Умелый менеджер проекта должен знать об этом и своевременно их устранять. Подразумевается, что в остальное время в проекте все идет хорошо.
Но работа над проектом не похожа на лодку, которую вы толкнули от берега, и дальше она плывет сама по себе. Если так думать, то вам остается периодически проверять, нет ли в ней течей, которые могут ее потопить. Так якобы и в проекте: он идет, и вам нужно только следить за тем, чтобы возникающие риски были вовремя замечены и устранены. Коварство такого подхода в том, что проект не выполняется сам по себе и работа над цифровым продуктом требует постоянных усилий.
В большей степени это похоже на игру в шахматы, где для выигрыша вам необходимо все время быть вовлеченным в процесс и думать над каждым шагом. Как только вы перестаете это делать или принимаете неверное решение, ваши шансы на выигрыш уменьшаются, а в какой-то момент игра просто останавливается, и вы теряете все, что с таким трудом было достигнуто. Именно поэтому подход, описанный в этой книге, называется «Методом параноика». От того, насколько вы сосредоточены на игре и всех деталях процесса, зависит результат проекта.
Кто же тот противник, который способен нарушить все ваши планы? Это неопределенность, о которой было так много сказано. Именно она главный оппонент, скрывающийся за нечеткими требованиями, отсутствием целей проекта, игнорированием важности выбора его типа и соответствующей команды специалистов, недостаточным проектированием и концептуальным взглядом на задачи. В конечном счете и бизнес, и профессионалы, создающие цифровые продукты, оказываются на одной стороне шахматной доски. Но они не понимают этого и принимают друг друга за соперников, а не партнеров. Так они лишь усложняют ситуацию, пока борются между собой, и не оставляют проекту ни одного шанса на успех.
Первые три главы книги были анализом того, в чем, собственно, состоит цель игры, ее основных участников и текущей практики работы. Все это можно кратко суммировать так: любой бизнес, независимо от размера и сложности, работает в рамках определенной модели. Бизнес-модель опирается на инструменты, дающие возможность ее реализовать. Вместе они представляют симбиоз, и рассматривать их по отдельности не имеет смысла.
Для успешного ведения деятельности нужны инструменты, в том числе цифровые, которые ставят бизнес в более выгодное положение по сравнению с конкурентами. Созданием цифровых инструментов занимаются привлеченные специалисты из IT-отрасли. Как любая сфера деятельности, эта отрасль работает по своим правилам и имеет уникальную специфику. Бизнес может получить лучшие результаты, если не будет игнорировать особенности проектной работы.
В первых главах книги обозначены открытые вопросы, источники неопределенности в проектах. На эти вопросы не так просто ответить. Дело в том, что нынешние подходы к созданию цифровых продуктов для бизнеса сложились в прошлом, но за последние десятилетия ситуация кардинально изменилась. Старые методы больше не соответствуют текущему уровню сложности задач. Например, еще недавно мобильные приложения рассматривались как интересный способ привлечь аудиторию, теперь для многих компаний это основной канал продаж и коммуникации с клиентами. Цифровые технологии больше не могут рассматриваться как вспомогательные, они лежат в основе деятельности многих компаний. Это требует нового подхода, при котором IT-специалисты участвуют на стадии поиска новой бизнес-модели, а владельцы компаний учитывают возможности технологий.
Другое важное изменение – достижение предела возможностей по созданию комплексных продуктов в рамках текущих организационных форматов ведения проектной работы и способов привлечения специалистов. Самый распространенный формат – агентский – постепенно теряет эффективность, и многие компании стараются собрать продуктовую команду внутри, а к агентствам обращаются только для подключения дополнительных специалистов в формате аутстаффинга.
Уровень профессиональных компетенций, необходимый для современных проектов, намного превышает навыки и опыт типичного менеджера проекта. В результате и бизнес, и участники проектной команды вынуждены либо упрощать обсуждаемые вопросы, либо пускать их на самотек, поскольку менеджер становится узким местом в коммуникациях, своеобразным бутылочным горлышком. Очевидно, что для новых проектов нужен стиль управления, который позволит бизнесу и специалистам говорить на одном языке, не снижая уровень сложности задач.
Таким стилем управления и организационной формой является продюсерская модель. Она позволяет привлекать специалистов высокого уровня и организовать их работу так, чтобы находить решения для создания уникальных продуктов. «Метод параноика» задает принципы работы в продюсерской модели и ставит контроль неопределенности во главу угла.
Это то, что отличает «Метод параноика» от других подходов, которые либо игнорируют, либо рассматривают неопределенность лишь как один из факторов риска наравне с остальными. Если смотреть на природу проектной деятельности через призму неопределенности, становится ясно, что, если с самого начала не взять ее источники под контроль, все остальное в проекте будет отдано на волю случая. Когда вы делаете такую ставку в своем бизнесе, рассчитывать на долговременный успех сложно. Контролю неопределенности и посвящена данная глава.
Как взять неопределенность под контроль
Безусловно, существует разница между полным устранением неопределенности и разделением задач на предсказуемые и непредсказуемые. В первом случае вместе с неопределенностью пропадает и возможность придумать что-то новое. Во втором – удается избежать неконтролируемого развития событий и сохранить пространство для творчества.
Термин «взять под контроль» означает то же, что и взять что-то под управление. Например, неконтролируемая ядерная реакция способна превратить в пепел целый город, но, будучи локализованной в реакторе, она становится источником электричества. Так и с творческой энергией. Если креативным специалистам дать полную свободу, от проекта, скорее всего, ничего не останется. Но если выделить их в отдельную команду и обозначить границы, в которых они смогут проявить свое творчество, шансы получить что-то полезное кратно возрастут. Главное – не смешивать предсказуемые и непредсказуемые задачи.
Для лучшего понимания вопроса с практической точки зрения я предлагаю посмотреть на разные аспекты проекта:
• цели бизнеса;
• понимание того, каким должен быть продукт, чтобы их достигнуть;
• выбор специалистов для его создания;
• организация проектной работы;
• время, деньги и другие ресурсы, требуемые для реализации проекта.
Цели бизнеса
Мало кто задумывается о том, что цели бизнеса определяют тип проекта и, как следствие, подход к решению задач. Если говорить в терминах второй главы, то это «Мозги», «Седина» или «Процедуры». Второй и третий тип предполагают предсказуемые характеристики будущего продукта. Но что, если бизнес планирует кардинальную перестройку деятельности и ожидает индивидуальное решение своих задач, а специалисты предлагают внедрить типовой продукт? Справедливо и обратное, когда бизнес рассчитывает на результат благодаря отработанной технологии, а проектная команда ищет что-то новое.
К сожалению, бизнес сам часто не может сказать, какие цели преследует. Он формулирует задачу в технических терминах, например, «разработать мобильное приложение», а подрядчики склонны предлагать привычный для них тип проекта независимо от того, насколько он подходит под поставленную задачу. Поэтому, даже если удается решить формально обозначенные задачи, истинные цели могу остаться недостигнутыми.
Неопределенность целей бизнеса не проявляется сразу и обычно стороны начинают что-то подозревать ближе к концу проекта. До этого каждая сторона пребывает в иллюзии понимания. Коварство в том, что чем позже удается выяснить истинные цели, тем большую цену придется заплатить. Способом контроля подобной неопределенности является подход, предполагающий, что и бизнес, и специалисты всегда неверно понимают цели проекта, даже если кажется, что все «очевидно». Для специалистов цели бизнеса должны быть гипотезой, которая требует проверки на раннем этапе.
Тем не менее проверка взаимопонимания контролирует только часть неопределенности. Как быть с тем, что цели проекта не могут быть до конца определены, пока бизнес не проверит цифровой продукт на практике? Одно дело, когда руководитель предполагает, что инструмент поможет компании, и другое – когда сотрудники начнут его использовать.
Поэтому, чтобы контролировать неопределенность, связанную с целями проекта, нужно подтверждать не только гипотезы, лежащие в основе первоначальных требований, но и то, как изменится работа бизнеса с новыми цифровыми инструментами. Делать это в конце проекта бессмысленно, необходимо получать обратную связь в процессе и корректировать цели и видение продукта.
Понимание того, каким должен быть продукт
Даже если сразу знать цели бизнеса, все еще остается вопрос: каким должен быть продукт и как он должен быть устроен? В отличие от типовых проектов, где используются уже готовые решения, для уникальных задач видение продукта создается с нуля.
Вопреки распространенному желанию бизнеса, это невозможно сделать одномоментно. Продукт должен постепенно «проявиться», сначала на уровне общей концепции, а потом и в конкретных технических деталях. Однако из-за ошибочного понимания гибких методологий проектные команды слишком быстро переходят к работе над конкретными задачами, рассчитывая, что общая архитектура продукта сложится сама по ходу проекта. К сожалению, так неопределенность только увеличивается. Решение принципиальных вопросов откладывается, цена последующей перестройки системы с каждым шагом становится только больше. Но есть и другой подход.
Когда вы двигаетесь от общего к частному, сначала строится высокоуровневое понимание продукта, чтобы иметь перед глазами схему, которую можно охватить одним взглядом, а уже потом углубляться в детали. Если продукт представлен в виде понятной модели, гораздо проще выявить пробелы в требованиях и понять его действительный масштаб. К тому же представление продукта на высоком уровне абстракции позволяет одинаково понимать задачу и бизнесу, и специалистам.
В дальнейшем, после того как найдена принципиальная схема решения и неопределенность взята под контроль, можно переходить к итерационному формату работы. Гибкий подход проявляет свои лучшие стороны, опираясь на непротиворечивую архитектуру продукта. Его части могут проектироваться и передаваться в разработку по мере развития проекта, с учетом текущих реалий бизнеса, но без риска столкнуться с неразрешимыми системными противоречиями.
Тем не менее высокоуровневой картины продукта недостаточно, чтобы держать ситуацию под контролем. Неопределенность может проявляться в качестве самих решений. Как понять, что они «хорошие» или «плохие»? Нужны критерии, без которых продукт развалится как карточный домик или будет иметь скрытые дефекты, для устранения которых может потребоваться полная переделка. Понятия «хорошее» решение не существует в отрыве от целей проекта, когда даже качественный с технической точки зрения продукт может оказаться ненужным для бизнеса.
Отсутствие таких критериев и есть тот фактор неопределенности, который часто сталкивает между собой бизнес и специалистов. Он лежит на поверхности, но почти никогда не учитывается. В большинстве случаев представление о качестве решений напрямую связано с профессиональной специализацией участников проекта. Разработчики определяют его как элегантность архитектуры, дизайнеры смотрят на эстетику интерфейса, UX-проектировщики ставят во главу угла удобство использования, а бизнес настаивает на экономической состоятельности продукта. В каждом проекте нужно вырабатывать единые критерии.
Выбор специалистов, необходимых для работы над проектом
Сложность уникальных проектов проявляется не только в уровне решаемых задач, но и в выборе специалистов. Для определения необходимых компетенций участников нужно знать, на каких технологиях будет создан продукт. Когда речь идет о чем-то по-настоящему новом, изначально нет ясности, какой продукт требуется создать и как он будет устроен. Нужно время, чтобы из множества гипотез появился четкий образ решения задачи.
Такая неопределенность ведет к тому, что у бизнеса нет возможности нанять всю команду сразу и без промедления приступить к работе над проектом. Получается замкнутый круг: кто-то должен выполнить первоначальную работу, чтобы понять, каким должен быть продукт и команда, но кто это может сделать, если нет ясности с самим продуктом? Чтобы преодолеть это противоречие и начать действовать в условиях неопределенности, требуется другой подход к формированию команды и наличие универсальной точки входа в проект.
Такой точкой может служить проджект-раннер, чья роль совмещает несколько компетенций и позволяет находить решения на стыке бизнеса и технологий. Он запускает проект, формулирует совместно с владельцами компании концепцию продукта, а в дальнейшем подбирает необходимых под нее специалистов. Команда в продюсерской модели не статична, она гибко развивается вместе с проектом, подстраивается под его потребности на каждой стадии.
От точного подбора участников проджект-раннером зависит многое. Кажется, что все определяет соответствие компетенций решаемым задачам, но продуктовые решения в уникальных проектах рождаются на стыке дисциплин. Поэтому нужна более точная локализация зон ответственности, которым требуется внимание мультидисциплинарных специалистов. Здесь и срабатывает подход с высокоуровневой схемой продукта, где она позволяет увидеть пересечения разных областей, например бизнеса и технологий, функциональных требований и пользовательского интерфейса.
Организация проектной работы
Наличие проджект-раннера решает проблему с точкой входа в проект, но по мере роста команды у менеджера пропадает возможность следить за качеством принимаемых решений. Вообще, чем больше проект, тем меньше можно опираться на прямой контроль. И чем больше команда, тем меньше определенности в понимании того, что на самом деле происходит в проекте. Даже если вы как управляющий попытаетесь вникнуть во все детали, ваших человеческих способностей не хватит для удержания всего под контролем.
Получается, чтобы сохранить управляемость в сложном проекте, качество решений должно поддерживаться на каждом уровне, от бизнеса и до мелких технических деталей. Это достигается через распределение ответственности между участниками. Но ответственность нельзя просто так вменить людям, она возникает лишь как следствие личной заинтересованности и необходимости иметь дело с последствиями своих решений. С управленческой точки зрения это значит, что задачи должны быть локализованы в компактных группах, где участники напрямую видят результаты своей работы и не могут спрятаться за плечами большой команды.
Вернемся к идее о том, что нельзя смешивать предсказуемые и непредсказуемые задачи. Если нарушить это правило, то, например, в момент, когда будет готово 90 % работ, результаты маркетинговых исследований, отложенных на конец, могут потребовать пересмотра архитектуры продукта. Это частая ситуация, ведь бизнес апеллирует к тому, что без продукта невозможно проверять бизнес-гипотезы. Но такой подход сохраняет риск, что затраченный бюджет будет умножен на ноль.
Это относится ко всем задачам с разным уровнем неопределенности. Эксперименты с технологиями и разработка типовых компонентов, поиск новой бизнес-модели и детальное проектирование пользовательских сценариев, формулирование визуальной концепции продукта и отрисовка дизайна отдельных экранов, – все это смешанное в проекте в итоге не позволит прогнозировать работу даже над типовыми задачами. Да, вы можете быть уверены в компетентности специалистов, но их оценка не будет иметь значения с учетом такого мощного фактора неопределенности.
Исправить ситуацию можно за счет распределения задач в проекте так, чтобы вначале шел поиск принципиальных решений, креатив и проверка гипотез, и только потом – работа в рамках стандартных технологий и процессов. Данный подход необходим, чтобы с каждым шагом работа над проектом становилась более предсказуемой. Если результаты первоначальных экспериментов неудовлетворительны, проект можно остановить без потери основной части бюджета.
Ресурсы, необходимые для реализации проекта
Планирование ресурсов, необходимых для реализации проекта – самый яркий, с точки зрения неопределенности, аспект. Он порождает самое большое количество конфликтов между бизнесом и специалистами. Основная причина этих конфликтов – несоответствие между желанием бизнеса заранее знать параметры проекта и возможностью специалистов предсказать их.
Как уже говорилось в предыдущей главе, ложной является сама мысль, что можно заранее предсказать время и ресурсы, которые потребуются для создания уникального продукта. Конечно, есть проекты, сложность которых понятна с самого начала. Но этим и отличаются предсказуемые задачи от непредсказуемых. Тем не менее, и бизнес, и специалисты часто игнорируют эту разницу и либо фиксируют оценку всего проекта с самого начала, либо работают без оценки, определяя стоимость по факту.
Оба подхода не уменьшают неопределенность, а только переносят риски с одной стороны на другую. За ошибки планирования все равно приходится расплачиваться или бизнесу, или компаниям, выполняющим проекты. Очевидно, что это не выход, и нужны методы, чтобы взять источник такой неопределенности под контроль. В противном случае большинство проектов оказываются нерентабельными или останавливаются, когда у бизнеса заканчивается терпение или деньги. Все это приводит к масштабным потерям для всех участников рынка.
Как ни странно, здесь и находится решение этого противоречия. Первоначальная оценка должна заключаться не в попытке специалистов заранее предсказать параметры проекта, а в установлении внешних ограничений со стороны бизнеса – сроков и бюджета, в рамках которых проект должен быть реализован. Это логично, поскольку для любого проекта есть экономически обоснованный объем ресурсов, превышение которого делает его бессмысленным. Например, если вы создаете онлайн-сервис, то рассчитываете на определенный финансовый эффект от его использования. Затраты должны укладываться в бизнес-модель.
Согласитесь, для бизнеса довольно странно действовать исходя не из своих возможностей, а из условий, которые предлагает проектная команда. Одну и ту же задачу можно решить разными способами в зависимости от целей, разной будет и стоимость разработки. Пока не заданы приоритеты, специалисты выбирают вариант исходя из своих предпочтений, а не интересов бизнеса. Когда ограничения известны заранее, появляются объективные критерии для принятия решений.
Речь не идет о том, чтобы бизнес полагался на удачу в надежде получить результат в обозначенные сроки и уложиться в бюджет. Должен быть способ вовремя определить, не вышло ли все из-под контроля, чтобы избежать ситуации, когда проектная команда ставит бизнес перед фактом уже в момент выхода за рамки, и в проекте не остается пространства для маневра. Таким способом является метод переменного (или инверсного) формата оценки и планирования.
Обычно для всего проекта принято использовать одинаковый подход к оценке, независимо от характера работ на разных стадиях. Выбор делается из двух крайних вариантов: T&M (расчет по фактически затраченному времени специалистов) и Fixed Price (фиксированная стоимость за определенный набор задач). В случае же организации работы, когда неопределенные задачи решаются как можно раньше, а более предсказуемые идут следом, для каждой стадии применяется индивидуальный подход к планированию и оценке.
Для этого существует простое правило: чем более неопределенный характер у задач, тем более фиксированной должна быть их оценка. Звучит странно, но ведь цель проекта – успеть получить готовый продукт до того, как закончатся доступные ресурсы и время. Первая стадия, в рамках которой специалисты выясняют возможность достижения целей проекта, должна быть ограничена приемлемым бюджетом, которым бизнес готов рискнуть. Если бюджет исчерпан, а ответ не найден, есть возможность выйти из проекта с минимальными потерями.
По мере перехода к стадиям проектирования продукта и проверки ключевых гипотез, можно больше опираться на прогнозы самих специалистов, хотя лимиты ресурсов должны оставаться фиксированными. Когда появляется достаточно информации для более предсказуемой работы, например, над задачами по дизайну и разработке отдельных частей продукта, можно переходить на расчет по фактически затраченному времени. Здесь нет риска значительного превышения расходов, но T&M дает больше гибкости и служит своеобразным амортизатором для небольшого уровня неопределенности.