Принцип сериала | Метод параноика

Метод параноика: принцип сериала

Части главы:
Замкнутый круг прогнозирования — Оценка проектов типа «Мозги» — Решение уравнения от обратного — Как принцип сериала берет под контроль неопределённость — Организация проектов типа «Мозги» — Фирменный проектный процесс — Концепция продукта — Высокоуровневое проектирование — Детальное проектирование — Разработка

Замкнутый круг прогнозирования

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

Для специалистов ситуация выглядит обратным образом. От них требуется предсказать стоимость и сроки ещё до начала работ, т.е. в момент, когда известно минимум информации. Чтобы появилась хоть какая-то ясность, необходимо пройти определённый путь. И даже сделав

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

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

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

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

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

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

«Нарезать» проект означает расставить в нём контрольные точки, через которые он проходит и в которых все его части проходят проверку и соединяются вместе. Согласно принципу проектирования это нужно для того, чтобы не копить неопределённость, а периодически выкладывать карты на стол и убеждаться, что проект движется в нужную сторону. Учитывая исследовательский характер проектов типа «Мозги», в какой-то момент может оказаться, что поиски решения зашли в тупик и правильнее будет просто остановить работы, зафиксировав убытки. Чем раньше вы об этом узнаете, тем дешевле обойдётся ошибка. Поэтому без контрольных точек не обойтись. С другой стороны, если производить проверку слишком часто, то не получится дать команде достаточно пространства для творчества, без которого не бывает нестандартных

решений. Интересные идеи просто не успеют получить нужного развития.

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

Оценка проектов типа «Мозги»

Всё, что я описал, нужно для того, чтобы сделать работу над цифровым продуктом более предсказуемой. Но всё равно это не позволяет ответить на вопрос о стоимости и сроках в самом начале. И это неудивительно, ведь в проектах типа «Мозги» вопрос стоит иначе — получится ли в принципе достигнуть цели, а заодно как в случае провала не потерять больше, чем может себе позволить бизнес и как увеличить шансы на успех. Другими словами, для проектов такого типа нужна совершенно иная стратегия прогнозирования.

В проектах типа «Седина» поиск решений, по сути, уже выполнен, и задача состоит в том, чтобы применить их в конкретной ситуации. Т.е. самая непредсказуемая часть вынесена за скобки проекта. Похожим образом складывается ситуация в «Процедурах», где масштаб и сложность задач низкие, что создаёт узкое пространство вариантов решения, из которых нужно выбрать. В случае же с типом «Мозги» поиск решений является основным их содержанием. Пока не будут найдены все ответы, нельзя достоверно назвать его параметры.

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

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

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

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

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

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

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

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

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

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

Решение уравнения от обратного

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

Для ясности проиллюстрирую эту идею. Возьмём, к примеру, компанию, которая шьёт одежду на заказ. Её точки продажи и мастерские находятся в нескольких

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

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

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

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

В дополнение к ограничениям бюджета существуют также

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

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

Такая постановка не отменяет того факта, что, находясь в начале проекта, мы по-прежнему находимся в состоянии неопределённости. Как уже было сказано выше, потребуется выполнить исследовательскую работу, чтобы внести достаточную ясность. У этой ясности есть своя цена, и исходный вопрос теперь должен звучать так: «Сколько нужно заплатить, чтобы узнать, как за доступный бюджет и срок получить то, что требуется?» Умение на него ответить — жизненно важный навык для продюсера, который, несмотря на высокую неопределённость, присущую проектам типа «Мозги», берёт на себя ответственность за их результаты.

Как принцип сериала берет под контроль неопределённость

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

Это подобно тому, как если бы мы задумали снять

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

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

бы связан с нашей способностью угадывать будущее ещё до того, как мы что-то начнём делать.

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

Действуя подобным образом, мы получаем сразу несколько преимуществ.

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

Во-вторых, развитие цифрового продукта через серию версий даёт возможность бизнесу и проектной команде подойти к проектированию и проверке гипотез более естественным образом. Об этом же говорит всё тот же закон Галла, который утверждает, что «любая работающая сложная система развивается на базе работающей простой системы. Сложные системы, созданные с нуля, никогда не будут работать в реальном мире, поскольку в процессе разработки на них не влияли факторы отбора, присущие среде. Из-за неизвестности вы никогда не сможете предсказать все эти связи и переменные, а следовательно, будете постоянно сталкиваться с различными проблемами».

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

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

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

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

Это касается не только бюджета проекта. Гибкие методологии — это не карт-бланш на работу над

продуктом в режиме «здесь и сейчас», потому что проект — это всегда способ для бизнеса попасть из точки А в точку Б. У этого есть допустимая цена и время, за которое необходимо пройти путь. Если за выбором следующего шага в проекте не стоит понимание того, куда в конечном счёте нужно попасть, то это похоже на езду в автомобиле, когда водитель произвольно крутит руль влево-вправо и не следит за дорогой. Гибкие методологии должны, прежде всего, давать тактическую свободу, но стратегически необходимо понимать, куда вы двигаетесь.

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

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

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

Здесь же удаётся этого избежать, потому что истинная гибкость, о которой там много говорят, опирается, прежде всего, на гибкость конструкции, лежащей в основе цифрового сервиса.

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

Если суммировать сказанное, то принцип сериала отвечает на вопрос: «Как подойти к оценке нетиповых проектов, а вместе с этим организовать работу в условиях высокой

внешней неопределённости со стороны бизнеса?» Следующие части главы как раз описывают то, как именно структурировать работу, как сделать первые исследовательские шаги, как сформировать пространство, в котором будет развиваться продукт и как затем перейти к воплощению замысла. Одновременно с этим даётся понимание, как продюсер должен подойти к организации проектной команды и прогнозированию работ на каждой из стадий.

Организация проектов типа «Мозги»

Контрольные точки проекта. Динамические команды и продюсерский подход. Модель продукт.

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

Давайте посмотрим, какие инструменты предлагает «Метод параноика» для организации проектов типа

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

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

исследований и дальнейшего воплощения было в пользу последнего.

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

В мире реальных вещей имеет значение стоимость их производства, а в индустриальный период все продукты были физическими, начиная от одежды и заканчивая транспортными средствами. Представляете себе огромные ангары, в которых строятся самолёты? Их проектирование могло быть дорогим, но производство ещё дороже. Поэтому было важно, насколько эффективен был сборочный процесс. Если к этому добавить возможность экономии на объёме, то производство одинаковых

продуктов в большом количестве было более предпочтительным. Неудивительно, что предсказуемость операций, составляющих технологию производства, стала синонимом успеха, и на её достижение были направлены все силы. Сразу вспоминаются Дао Тойоты и бережливое производство (Lean), теория ограничений (TOC) моего любимого Голдратта и, конечно же, Канбан.

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

стороны проектов типа «Мозги».

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

Контрольные точки проекта

Звучит замечательно, но, если вы тот, кто предоставляет команде свободу действий, то вас точно будет

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

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

Такое управление происходит за счёт того, что

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

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

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

Не существует каких-то чётких правил к определению критериев оценки для контрольных точек, это творческий процесс, как и всё в проектах типа «Мозги». В зависимости от выбранной стратегии, для работы над проектом, которая должна привести бизнес из точки А в точку Б, можно по-разному подойти к набору стадий. В качестве примера в последней части главы я покажу один из вариантов структурирования проекта, подходящего под принцип сериала. Но в любом случае нужно помнить, что план — это всегда гипотеза, как и всё остальное в проекте. За очередной контрольной точкой открывается новый вид на территорию, и продюсеру вместе с проектной командой необходимо всё время пересматривать маршрут.

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

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

Динамические команды и продюсерский подход

Из предыдущего абзаца логично следует, что динамические команды — неотъемлемая часть проектов типа «Мозги». Если на разных стадиях проекта к его участникам предъявляются индивидуальные требования в соответствии с меняющимися задачами, то вполне понятно, что состав команды должен регулярно обновляться. Применительно к принципу сериала это означает, что участники меняются в зависимости от той

версии, которая готовится к выпуску. Это похоже на работу над настоящим сериалом, когда для съёмок отдельных эпизодов привлекаются разные специалисты и актёры.

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

Будьте внимательны, продюсер — не босс и не менеджер, а такой же участник творческого процесса. Просто он смотрит на весь проект целиком и настраивает работу остальных участников, но он ими не «командует», а направляет и создаёт условия, при которых те могут проявить свои лучшие качества. Его сила проявляется в том, чтобы ясно представлять образ конечного продукта и помогать его увидеть остальным участникам.

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

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

Ровно по этой же причине в динамических командах нет обычных для проектов UX-дизайнеров, ИТ-архитекторов,

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

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

Модель продукта

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

…Ставки для меня очень высоки каждый раз, когда я выхожу на съёмочную площадку. Вы понимаете, я же ставлю жизнь, карьеру, достоинство. Мои коллеги, которые утверждают, что не чувствуют давления, они пиздят! Господи, я только спустя пять лет перестал блевать в первый съёмочный день на площадке!»

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

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

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

Фирменный проектный процесс

Проект как выпуск эпизодов сериала

Любой, кто опирается на принципы метода, может по-своему подойти к тому, как их интерпретировать для работы над своими задачами. В момент написания книги я имел возможность увидеть, как читатели уже опубликованных глав смогли применить описанные в них идеи, даже не находясь в роли продюсеров, а проекты, в которых они участвовали, имели типы «Седина» и «Процедуры». Но важно помнить, что «Метод параноика» максимально раскрывает свой потенциал при работе над проектами, где цель состоит в нахождении уникальных решений и где неопределённость достигает максимального уровня.

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

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

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

Одновременно с этим, по мере уменьшения неопределённости, должен меняться стиль управления и сам состав проектной команды. Если на первых этапах от

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

Вместе с изменением характера работы должен меняться и способ оценки для каждой из стадий. И бизнес, и компании-подрядчики привыкли выбирать один вариант для всего проекта, отталкиваясь, например от стоимости часа работы специалиста. Но это в корне неверно! Выше я уже показал, насколько сильно может отличаться подход к прогнозированию бюджета и сроков в зависимости от того, идёт ли речь о креативных задачах или выполнении чётко регламентированных процедур. Степень их предсказуемости разная: в одном случае можно легко спрогнозировать объём работ, а в другом это не представляется возможным вовсе. Это, кстати, лишний раз

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

Проект как выпуск эпизодов сериала

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

Для того чтобы история получилась связанная, а на

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

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

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

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

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

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

Концепция продукта

Цель стадии и характер работ. Требования к участникам. Способ оценки и планирования. Критерий прохождения контрольной точки. Модель продукта.

Цель стадии и характер работ

Хочу в очередной раз повторить свою любимую мудрость о том, что «перед тем как взбираться по лестнице, убедись, что приставил её к нужной стене». Большинство ИТ-проектов начинается с прямого запроса со стороны бизнеса в стиле «нужно разработать мобильное приложение для нашего сервиса». Работа над такими проектами — это уважаемая профессия, но она, к сожалению, не отвечает на вопрос, поставленный китайцами много тысяч лет назад. Для задач, которые выполняются в рамках уже найденного решения, это нормально, ведь вы не спрашиваете себя, туда ли вы идёте, делая очередной шаг. Но когда вы находитесь только в начале пути или стоите на перекрёстке, вопрос вполне уместен и даже неизбежен.

Именно так всё и выглядит в случае запуска новой

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

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

невозможно двигаться к ней одновременно по нескольким маршрутам.

Требования к участникам

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

Всё это продюсер делает конечно не один, а привлекая профильных специалистов. Их состав — это первая версия динамической команды, которая в дальнейшем будет заниматься работой над проектом. Кто именно в неё

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

Способ оценки и планирования

Стоимость разработки концепции является ответом на тот самый вопрос «сколько нужно заплатить, чтобы узнать, как за доступный бюджет и срок получить то, что требуется?» Ответ на него зависит от того, насколько нестандартная стоит задача и как далеко готов зайти владелец компании в своём желании придумать по-настоящему новую бизнес-модель. Чаще всего дело ограничивается адаптацией уже

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

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

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

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

Прогнозирование сроков работы над концепцией аналогично оценке стоимости. Есть доступное бизнесу временное окно для того, чтобы понять, в каком направлении можно развивать компанию. Оно зависит от текущей рыночной ситуации и, конечно же, от темперамента владельцев. Концепция должна давать принципиальный ответ — стоит ли игра свеч и есть ли возможность запустить компанию с новой бизнес-моделью. Завершив эту стадию, у команды должно оставаться ещё достаточно времени, чтобы реализовать сам проект. Именно поэтому длительность работы над концепцией продукта всегда стоит чётко ограничивать по длительности — по моему опыту она не должна превышать двух месяцев. Связано это в том числе и с психологическими аспектами, когда из-за отсутствия

видимых результатов бизнес и участники проекта начинают терять контроль над ситуацией.

Критерий прохождения контрольной точки

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

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

бизнес сможет сказать: «Да, мы готовы рискнуть и продолжить проект» или «Риски столь высоки, так что мы останавливаем работы». Это, кстати, ещё одна причина, по которой не стоит в начале таких проектов сразу обращаться в компании, занимающиеся разработкой, и тем более работать с ними по гибким методикам типа Скрама. Они зарабатывают на продаже человеко-часов своих специалистов и, подобно брокерам, получающим процент с любой транзакции, выигрывают независимо от того, терпит ли проект в конце неудачу или начинает приносить пользу его владельцам. Не в их интересах, чтобы бизнес уже на такой ранней стадии мог отказаться от проекта, когда ещё не потрачен весь доступный бюджет. Делая упор на быстрый переход к разработке, они упускают выбор той самой стены, к которой предстоит приставить лестницу.

Модель продукта

В отличие от описанной ситуации, продюсер действует иным образом. Его мотивация построена на успешности

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

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

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

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

Высокоуровневое проектирование

Цель стадии и характер работ

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

Именно для такой подготовительной работы в фирменном процессе «Метода параноика» предусмотрена стадия высокоуровневого проектирования. Её цель — выстроить архитектуру системы и создать инструменты, используя которые можно сделать продукт более надёжным, а работу над его отдельными версиями быстрой и недорогой. Только так можно получить настоящий эффект от гибкого подхода к разработке. В противном случае, что толку от того, что участники проекта договорились не ограничивать бизнес в его желании произвольно менять список задач для каждой итерации, если за это они вынуждены копить технический долг и подолгу стабилизировать систему?

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

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

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

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

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

функцией продукта и этим нужно воспользоваться.

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

Требования к участникам

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

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

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

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

Способ оценки и планирования

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

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

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

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

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

Критерий прохождения контрольной точки

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

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

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

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

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

Такой подход сильно облегчает взаимодействие проектной команды с бизнесом, ведь теперь есть возможность заранее «потрогать» и оценить продукт непосредственно на смартфоне или в браузере, а не в виде слайдов на презентации дизайн-концепции. Не нужно беспокоиться, что у разных людей по-своему работает воображение,

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

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

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

Модель продукта

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

проекта в виде последовательности «эпизодов» или версий продукта. Всё это должно быть отражено в его модели. Посмотрим, в чём именно это выражается на каждом из уровней.

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

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

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

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

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

Детальное проектирование

Цель стадии и характер работ

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

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

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

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

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

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

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

Требования к участникам

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

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

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

Способ оценки и планирования

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

пользовательские сценарии и то, как они будут отражены на уровне новых функций продукта.

В таких условиях прогнозирование стадии может быть достаточно точным, хотя это не означает полной предсказуемости. У участников должна быть известная степень творческой свободы, поскольку принцип сериала для того и разбивает проект на самостоятельные «эпизоды», чтобы в них могли найти своё место идеи, которые были не очевидны в начале проекта. Иногда участники могут даже ставить эксперименты в стиле «штанги Талеба», когда часть функций новой версии решает заранее согласованные задачи, а другая — служит способом проверки новых гипотез на реальных пользователях.

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

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

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

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

Критерий прохождения контрольной точки

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

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

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

проверять, что конечный результат соответствует переданной документации.

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

Ещё одним преимуществом прохождения контрольной

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

Модель продукта

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

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

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

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

В случае с тремя уровнями модели продукта это выглядит следующим образом. На функциональном уровне необходимо описать контекст работы продукта с точки зрения сценариев и точек контакта пользователей с системой. Иногда это называют CJM и их цель — выявить набор функций продукта, закрывающих все требуемые сценарии. Далее функции предстоит наделить внутренней логикой, опирающейся на структуру данных. Удивительно, но даже многим опытным проектировщикам кажется, что это ответственность разработчиков. Нет, продукт по своей сути представляет собой набор алгоритмов, и именно они позволяют ответить на вопрос «что должна делать система».

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

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

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

Разработка

Цель стадии и характер работ

Стадия разработки — вторая часть в цикле выпуска новой версии продукта. В ней фокус смещается с системного уровня на инструментальный. Это вовсе не означает, что поиск решений заканчивается и начинается чисто механическая работа. Разработка требует не меньше изобретательности от специалистов, чем проектирование, но уровень абстракции, на котором идёт работа, другой. Цель стадии разработки состоит в том, чтобы решения об устройстве продукта обрели плоть и заработали в реальности.

Мне нравится думать об этом как о совместной работе композитора и исполнителей. Я видел, с какой тщательностью и вниманием подходят профессиональные музыканты к подготовке выступления. От их интерпретации произведения зависит, сможет ли

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

Требования к участникам

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

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

Способ оценки и планирования

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

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

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

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

Критерий прохождения контрольной точки

У стадии разработки есть две заинтересованные стороны, и они выступают в роли тех, кто может подтвердить её успешное завершение. Для прохождения контрольной точки, отделяющей новую версию продукта от пользователей, нужно получить «добро» со стороны бизнеса и продюсера вместе ключевыми участниками, выполнявшими проектирование. Бизнесу важно получить работающий продукт, а продюсеру — завершить проектный цикл.

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

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

работы специалистов.

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

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

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

Важно помнить, что цель — не узнать о плохом результате в конце стадии, а периодически отслеживать ход работ и вовремя давать обратную связь участникам команды, чтобы у них было время учесть замечания. Ставить перед фактом, показывая только итоговый вариант — не очень удачная идея. И здесь важна инициатива не только проектной команды, но прежде всего бизнеса. Он должен рассматривать себя как непосредственного участника проекта, а не как «клиента», который ждёт сразу готовый результат. Работа в течение стадии разработки должна быть построена так, чтобы к моменту её завершения продукт был готов настолько, что прохождение контрольной точки было в некотором роде формальностью.

Модель продукта

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

В этой книге уже много раз сказано о том, что проектная документация — это не скучные документы, постфактум фиксирующие решения, а инструмент коммуникаций между участниками. Когда на стадии разработки выясняется, что какие-то решения оказались ошибочными или неполными, то разработчики посылают «сообщение» об этом в контексте проектных артефактов, например спецификации или дизайна интерфейса, а проектировщики отвечают им, уточняя документацию.

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

Предыдущая глава

Принцип продюсирования

Ключевая глава книги, дающая понимание продюсерского формата работы над проектами.

Следующая глава

Принцип вовлеченности бизнеса

Глава о вовлеченности бизнеса, в которой показано, как меняется результат в случае, если бизнес уделяет проекту не меньше внимания, чем специалисты.

Книга

Заказать в бумажном формате, загрузить электронную копию, послушать аудиокнигу или почитать онлайн на сайте

Автор

Вадим Митякин — консультант и автор метода, действующий ИТ-предприниматель с более чем 25-летним опытом создания цифровых продуктов для разных компаний, среди которых Сбербанк, Visa, Афиша, Коммерсант, Ведомости, Литрес, Майкрософт, Яндекс, Связной и многие другие. В роли консультанта работает с такими компаниями, например, как автопроизводитель электромобилей Атом и частная космическая компания SR Data.

Консалтинг

Внедрение методологии продуктовой разработки, построение проектных офисов и настройка команд, проектирование и анализ бизнес-моделей для компаний и цифровых продуктов.

Подкаст

Подкаст об устройстве компаний и продуктов, в который я приглашаю их создателей. Это совершенно разные люди, но всех их объединяет одно — любовь к делу, которым они занимаются.