Вадим Митякин - Метод параноика. Как взять под контроль неопределённость в проектах при создании цифровых продуктов для бизнеса

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

Кажущейся альтернативой могут служить открытые (читай, бесконечные) сроки и бюджет, что, конечно же, невозможно представить, по крайней мере в нашей Вселенной. Хотя на таком варианте прямо или косвенно настаивает достаточно большое количество представителей ИТ-отрасли. Конечно, есть вероятность того, что команда специалистов, подобно природе, за бесконечное количество итераций сможет создать совершенный продукт. Но вряд ли такое расходование ресурсов оставит бизнес в живых.

Как видите, мы все равно неизбежно приходим к тому, что поиск способов снижения или локализации неопределённости – необходимый путь к снижению проектных рисков и в конечном счёте к получению бизнесом именно того результата, на который он изначально рассчитывает. Это один из базовых принципов «Метода параноика».

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

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

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

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

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

На проекты, целью которых является создание цифровых сервисов для бизнеса, нужно смотреть таким же образом. Если в результате проекта есть риск потратить бюджет, сопоставимый с прибылью компании за полгода, но по итогу не получить работающий продукт, то есть смысл серьёзно подумать, стоит ли оно того. Когда венчурный инвестор вкладывает деньги в перспективное направление, то от проекта сразу ожидается возможность потери бюджета, с другой стороны, в случае успеха прибыль может многократно превысить расходы. Если же речь идёт про работающий бизнес, которому не грозит сокращение доли рынка из-за действий конкурентов или потери эффективности, вряд ли стоит делать ставку на изменения в цифровой инфраструктуре, потенциально способные привести к остановке всей деятельности или потери существенной доли прибыли. На первый взгляд это кажется странным, как ИТ-проект может быть столь опасным, но разве неработающий сайт онлайн-магазина не означает остановки бизнеса? А бывают ситуации гораздо серьёзнее.