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