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