Переводчик Д. Кусакин

 

Алекс Коуэн

Hypothesis-Driven Development: Продуктовые гипотезы в разработке. — СПб.: Питер, 2025.

 

ISBN 978-5-4461-4241-5

© ООО Издательство "Питер", 2025

 

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

 

Благодарности

Моим родителям — Джоанн и Брюсу.

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

Но всему тому, о чем я буду здесь рассказывать, я научился не в одиночку. Как основатель стартапа я работал вместе со своей командой, основываясь на данных о наших клиентах. Как преподаватель я получал поддержку от работников Дарденской школы бизнеса при Университете Вирджинии (University of Virginia Darden School of Business), моих коллег-преподавателей и тех, с кем я сотрудничаю в отрасли. Кроме того, я имел удовольствие работать с сотнями студентов офлайн и с более чем 400 тысячами слушателей онлайн-курса.

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

Спасибо Иэну и Джейн Гру за помощь в создании и курирование практически всех визуальных материалов, которые я использую в своей работе с момента выхода моей первой книги в 2012 году. Спасибо также Рону Уайнеру и Сараванану Поннайяну за помощь в воплощении этого материала в жизнь.

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

Спасибо всем моим коллегам-преподавателям в Дардене за их поддержку и компетентность как в аудитории, так и за ее пределами. В частности, я бы хотел поблагодарить Майка Ленокса за его первые отзывы об этой книге, Джин Лидтку за ее действенные методики преподавания дизайна, Кейси Лихтендаля и Эрика Тассоне за их помощь и неиссякающий интерес к тому, как сделать применение анализа данных в контексте бизнеса более эффективным, а также Яэль Грушку-Кокейн за ее помощь в работе над черновиками. Кроме того, выражаю благодарность Майклу Альберту, Сашу Цорку и Ахмеду Абасси за то, что терпеливо отвечали на все мои вопросы о науке о данных и применении статистического мышления.

Я бы хотел поблагодарить институт предпринимательства и инноваций Баттена в Дардене (Darden’s Batten Institute for Entrepreneurship and Innovation), научным сотрудником которого я являюсь, за помощь, оказываемую с самого начала моей карьеры преподавателя. В частности, спасибо Эму Джею Томсу и Шону Карру за их постоянную поддержку. Вдобавок я хотел бы выразить признательность коллективу методистов и медиаотделу института за их компетентность и за сотни часов совместной работы над созданием и усовершенствованием набора курсов, которые на момент написания этого текста были прослушаны более 500 тысяч раз.

Спасибо Дрю Хэммонду и Джейсону Старки за их первые отзывы о книге.

Мне посчастливилось работать над этой книгой совместно с моей давней подру­гой и коллаборатором Стефани Рэй. Талантливая писательница, контент-стратег и практикующий технический специалист (сейчас Стефани является вице-президентом по продукту в ProjectManager.com) — лучшего редактора и представить невозможно.

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

Особую благодарность я выражаю моей прекрасной и терпеливой жене Саре и моим дочерям — Элиз и Эмилии — за их поддержку и заботу.

Хотя они в любом случае будут упомянуты в тексте, я все равно хочу выразить здесь свою признательность приглашенным редакторам за ценный опыт, которым они поделились. Это Джин Лидтка, Лора Кляйн, Роб Цубер, Кейси Лихтендаль, Эрик Тассоне, Даррен Бауэр Кахан, Конор Сибли, Колин Зима и Нир Эяль.

Наконец, я заранее прошу прощения у всех, кого должен был упомянуть явно, но не сделал этого, — с меня пиво (как минимум).

От издательства

Мы выражаем огромную благодарность клубу рецензентов ИТ-литературы ReadIT Club за помощь в работе над русскоязычным изданием книги и их вклад в повышение качества переводной литературы.

Ваши замечания, предложения, вопросы отправляйте по адресу comp@piter.com (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.

О научном редакторе русскоязычного издания

Дмитрий Бардин — ведущий разработчик, архитектор решений, один из авторов курса «Архитектор ПО» от «Яндекс Практикума». В настоящее время занимается разработкой бэкенда «КиноПоиска» с применением языков Go и Java. В прошлом руководитель службы продуктовой разработки и ресурс-менеджер. Опыт в ИТ — более 15 лет.

Глава 1. Вы и цифровой бизнес

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

Аналитическая отладка становится делом привычки.

Поэтому неудивительно, что технари начали задавать тот же самый вопрос применительно к технологическому бизнесу. Благодаря новоявленному проблемно-ориентированному подходу мы теперь используем такие методологии, как Agile (гибкая методология разработки), Lean startup (бережливый стартап), OKR (Objectives and Key Results — цели и ключевые результаты), Lean UX (бережливый UX) и дизайн-мышление. Сегодня, когда сфера технологий вышла из тени и заняла заметное и даже доминирующее положение в мире бизнеса, а ее естественный рост за счет инноваций все больше стал влиять на цены на бирже, эти методологии перестали быть чем-то, что используют только технические специалисты, — теперь их применяют и менеджеры. Создание качественных продуктов — все еще непростая задача, но перечисленные выше подходы помогают ее решать.

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

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

IBM: 19791

У iPhone нет никаких шансов занять позицию на рынке.

Стив Балмер из Microsoft (2007)

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

Что такое сфера технологий и где ваше место в ней

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

Если вы следите за тем, что происходит в мире бизнеса, то, вероятно, заметили, что в нем многое изменилось. Например, консультант McKinsey, который мог бы разрабатывать стратегию конкурентоспособности для компании AT&T в 1998 году, сейчас возглавляет команду, которая занимается цифровизацией данной компании и разрабатывает новое приложение, нацеленное на повышение эффективности ее работы и расширение перспектив. Или же магистр делового администрирования (MBA), у которого в 1998-м McKinsey числились на первом месте в списке возможных работодателей, сейчас с большой вероятностью претендует на должность продакт-менеджера в Google или Facebook. Ведущий аналитик переквалифицировался в специалиста по работе с данными, младшему специалисту по прямым инвестициям вместо управления финансами поручили переосмыслить используемые компанией технологии, а маркетолог теперь занимается «взломом роста» и проводит A/B-тесты.

Как бы то ни было, сфера информационных технологий прекрасна тем, что теперь не нужно строить корпоративную империю, чтобы заработать миллиард долларов: например, в Instagram работали всего 13 сотрудников, когда его купили за эту сумму. Чтобы достичь таких показателей, большинству стартапов все-таки нужно до некоторой степени масштабироваться. Но для работы над тем, что связано с технологиями, обычно необходимо собрать хорошую команду из 7–12 человек и предоставить им автономию, а не выстроить крупную организацию с командно-административной системой управления.

И вот здесь в игру вступаете вы.

Цифровые приложения, которые создаются такими командами, меняют стиль жизни и подход к работе, облегчая ее. Они могут скрашивать досуг, как это делает TikTok, или избавлять от рутины, как, например, приложение «Календарь», находящее в вашем графике наилучшее время для встречи, или Алекса, которая может выполнить для вас любые вычисления — только попросите. Более скучное и более прогрессивное объяснение заключается в том, что мы вступаем в эру распределенного интеллекта: часть интеллектуальной работы автоматизируется. Например, когда я утром собираюсь выйти из дома, мне уже не нужно смотреть прогноз погоды — я могу спросить об этом Алексу и решить, что мне надевать.

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

Но достаточно о вас. Теперь немного обо мне

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

Почти ни в чем толком не разбираясь, я бросил колледж в 1995 году и тогда же основал свою первую компанию, которая занималась ремонтом компьютеров, а позже — работой с внутренними IT-системами компаний. Мои занятия на этой работе варьировались от изучения того, как заменить дисковод на компьютере с процессором Intel 386, до обхода домов в центре Санта-Барбары с предложением своих услуг. В компании не было никаких отделов, и, хотя мой партнер был гораздо опытнее меня, нам обоим нужно было многому научиться — и мы сделали это. Компания, которая теперь называется GovPlace, стала довольно успешной. Я пытался закончить колледж в Стэнфорде, однако на последнем курсе снова бросил учебу, чтобы запустить другой стартап. Он провалился, но я продолжил работу и занялся консультированием нескольких успешных венчурных предприятий.

Проработав какое-то время в BroadSoft — компании, занимающейся разработкой ПО для телекоммуникаций, — на должности руководителя отдела обслуживания, я уволился и основал компанию Leonid Systems, чтобы заниматься исключительно корпоративными системами, которыми пользовались наши общие с BroadSoft клиенты. Это были такие операторы связи, как Verizon и Comcast. В 2015 году BroadSoft купила Leonid Systems, а несколько лет спустя сама была куплена Cisco. Затем я начал преподавать в Дардене, время от времени совмещая эту деятельность с работой в сфере технологий. Я инвестировал в Singularity Networks — стартап, специализирующийся на сетевой безопасности, — и консультировал его участников, но в 2019 году его тоже купил Cisco3. В настоящее время, одновременно с написанием этой книги, я работаю над языковым приложением виртуальной реальности с командой Jedburgh Technologies.

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

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

Преподавание в соответствии с придуманной мной теорией о том, что «универсалы — это супергерои», шло хорошо, а сама теория развилась в то, что я (и не только я) теперь называю разработкой, основанной на гипотезах (Hypothesis Driven Development, HDD), поэтому я создал несколько онлайн-курсов и опробовал их на широкой аудитории. Сейчас я с гордостью могу сказать, что мне выпала возможность поработать с более чем 400 тысячами студентов, которые в общей сложности более 500 тысяч раз прослушали курсы по разработке успешных цифровых продуктов с использованием подхода, основанного на гипотезах. Многие из этих студентов были специалистами широкого профиля — как магистры в Дардене; и вместе с тем я был поражен разнообразием этой публики: в ней были и дизайнеры, и универсалы, и инженеры4.

Вернемся к вам. Супергерой-универсал

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

Я видел, как на эти позиции приходили как нетехнические многопрофильные специалисты, так и технари. Главный вопрос, который задавали себе «не технари» и который становился для них большим препятствием, звучал так: нужно ли мне учиться писать код? Хотя дело было вовсе не в том, что когда-то они пытались заниматься программированием и у них ничего не получилось. Да, научиться профессионально писать код — так же сложно, как и хорошо делать что-либо другое. Но если у вас в руках оказалась эта книга, то вы почти наверняка сможете за две недели освоить базовый курс, например, по JavaScript, зайдя на сайт наподобие Codeacademy.

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

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

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

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

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

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

Введение в разработку, основанную на гипотезах (HDD)

Я понял, что с этими двумя проблемами прекрасно справляется разработка, основанная на гипотезах (Hypothesis-Driven Development, HDD). Как и Agile, HDD — это большая область разнообразных подходов и практик, связанных одной целью и единым набором принципов. Перечислю основные принципы HDD.

1. Четко формулировать цели — общепринятый принцип разработки продуктов.

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

3. Принимать четкие решения, опираясь на эти выводы, учитывая итерации разработки и внесение изменений в продукт, — общепринятый принцип методологий Lean startup и Agile.

Я заметил, что просто быть хорошим специалистом в чем-то одном — дизайне продуктов, дизайн-мышлении, Lean startup, A/B-тестировании или Agile — для постоянного и гарантированного достижения отличных результатов недостаточно. В HDD мне нравится то, что этот подход выделяет общие элементы всех основных методологий и тем самым позволяет получить единую точку зрения на достигаемые результаты. А это, в свою очередь, помогает многопрофильным специалистам всех категорий выстраивать взаимодействие со своими коллегами на базе общего видения того, каким путем они собираются прийти к этим результатам. И, что немаловажно в контексте области с постоянно меняющимися границами, HDD дает «вечным студентам» понимание того, какие навыки им следует развивать. В сфере технологий косо смотрят на тех, кто использует словосочетание «лучший подход», — ведь мы знаем, что различия между двумя компаниями, продуктами и даже командами могут быть настолько существенными, что сама мысль о существовании некоего единого подхода, который будет эффективен в любой ситуации, приносит скорее вред, чем пользу. HDD предлагает качественное решение этой проблемы — благодаря прогрессивному принципу командного взаимодействия, заложенному в основу этой методологии.

Поиск пути к успеху

HDD — не про «аналитический паралич» и не про то, чтобы не предпринимать никаких действий, не имея полной уверенности в выбранном пути. Удача любит смелых, особенно в сфере технологий. В HDD мы исходим из того, что поведение пользователя практически непредсказуемо. Закулисная история почти каждой стартап-команды изобилует эпизодами отказа от множества идей, прежде чем был достигнут желаемый результат. Если старый подход к новым проектам звучит примерно так: «Давайте построим киоск с лимонадом», — то в HDD мы дополняем его и получаем что-то вроде: «Давайте построим киоск с лимонадом на пересечении 4-й авеню и Мейн-стрит в эту субботу, и если выручка будет больше 50 долларов, то мы будем считать это успехом».

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

Рис. 1.1. Цикл разработки продукта

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

Бизнес-стратегия и HDD

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

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

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

Я и сам был частью такого хаоса — и даже не раз. В начале нулевых, будучи молодым, я во второй раз отчислился из колледжа, чтобы стать первым сотрудником компании Scout Electromedia. Мы потратили миллионы долларов на сборку фирменного оборудования и разработку фирменного ПО, фирменной сетевой инфраструктуры и фирменного путеводителя по городу, и все это было выполнено, скажу без ложной скромности, на высшем уровне. Однако наши спонсоры перестали нас финансировать, когда мы уже заканчивали работу над продуктом (рис. 1.2).

Рис. 1.2. Наш продукт — Modo!

И хотя мои коллеги впоследствии многого добились (например, основали и продали несколько успешных стартапов), я не думаю, что кто-либо из нас считает, что наша модель работы в Scout была образцовой со стратегической точки зрения. Наша стратегия тогда состояла в том, чтобы создать некий крутой продукт (на должном уровне) и отталкиваться от него. Могли ли мы прийти к этому другим путем? Скорее да. Готовы ли нынешние инвесторы вкладываться в такие предприятия на начальных стадиях? Скорее нет.

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

…стартапы — это не мини-версии больших компаний. Они отличаются друг от друга во всех отношениях: от целей и показателей успеха до сотрудников и корпоративной культуры7.

Показатель product/market fit (соответствие продукта рынку) как раз и определяет точку равновесия между инновациями и масштабированием. В общем и целом идея состоит в том, что если определенный продукт достигает этого соответствия, значит, его можно масштабировать. Очень часто концепцию product/market fit описывают через построение бизнес-модели по шаблону, придуманному Александром Остервальдером (рис. 1.3).

Рис. 1.3. Шаблон бизнес-модели

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

Чтобы довести до конца работу по распространению информации о приоритетах компании внутри нее и донести ее до отдельных команд, в ориентированных на инновации компаниях (например, в Google8) применяют такой надежный, но в то же время гибкий метод, как OKR (objectives and key results — цели и ключевые результаты). В его основе лежит идея о том, что цели определяют направление работ, а ключевые результаты позволяют оценивать прогресс. Как правило, цели устанавливаются ежегодно, а ключевые результаты пересматриваются и определяются каждые три месяца. Цели и ключевые результаты фиксируются старшим руководством, и на их основе руководители отделов и команд выстраивают свою работу над конкретными задачами.

Многие из этих концепций впервые были реализованы в контексте стартапов, но оказалось, что они вполне подходят и для сегодняшних развитых компаний, которые начинали как стартапы и выросли в устойчивые франшизы. Например, это компании FAANG: Facebook (сейчас Meta), Amazon, Apple, Netflix и Google. Достижение product/market fit не дает никаких гарантий — компания всегда будет либо приближаться к этому соответствию, либо удаляться от него. Сосредоточенность и дисциплинированность по-прежнему важны для всех, кто имеет дело со сферой технологий, особенно для компаний, бизнес-модель которых ориентирована на инновации. Множество стартапов, которые достигают product/market fit и затем масштабируются до больших компаний, сталкиваются с трудностями, когда перестают концентрироваться на своих целях. Относительно недавний пример этому — Evernote (веб-сервис и ПО для создания и хранения заметок)9. В книгах в духе «Конца конкурентного преимущества»10 высказывается идея о том, что устойчивое и долговременное конкурентное преимущество иметь больше невозможно, хотя многие технологические компании и доказывают своим примером, что вложения в защиту данных и социальные сети являются богатым источником преимуществ.

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

Выше я говорил о том, что цифровые технологии расширили возможности малочисленных команд (7–12 человек). Чтобы такая команда могла успешно разрабатывать инновации, критически важно дать ей ориентир, сонаправленный с целями компании, но при этом позволить ей автономно работать над решением своих задач. Общепринято, что лучший способ организации команды — это самоорганизация. Вы, вероятно, наслышаны об Agile — практически повсеместно применяемом подходе к организации работы, используемый подобными командами. В следующем разделе мы кратко рассмотрим эту методологию и то, как она вписывается в практику HDD.

Agile и HDD

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

Что такое Agile? В 2001 году группа разработчиков ПО создала «Манифест разработки программного обеспечения» (Agile-манифест)11. Он состоит всего из 67 слов, однако произвел революцию в мире разработки ПО и продуктов (а некоторые считают, что и в управлении проектами в целом) и сейчас де-факто является подходом, который применяется практически в каждом бизнес-проекте, связанном с цифровыми инновациями.

В манифесте говорится следующее:

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

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

1. Спринты или итерации.

2. Стендап-встречи.

3. Пользовательские истории и восходящее проектирование.

Спринты или итерации с фиксированным временем прохождения — это то, с помощью чего большинство Agile-команд создают опорные точки для адаптивного улучшения того, что они поставляют клиенту, и организуют совместную работу. Команда разбирает бэклог — отсортированные по приоритету задачи — и в конце спринта представляет готовое ПО («задача в работе» не считается результатом спринта). Спринту предшествует планирование — руководитель создает бэклог. Этот руководитель может играть роль продакт-менеджера или владельца продукта (если команда использует Скрам — одну из гибких методологий). Часто, но не всегда, задачи в бэклоге формулируются в виде пользовательских историй. А на стендап-встречах каждый член команды отвечает на следующие вопросы.

1. Что я сделал вчера?

2. Что я сделаю сегодня?

3. Что мешает моему прогрессу?

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

Рис. 1.4. Итерация гибкой разработки, или спринт

Как использовать Agile эффективно

Определить, что гибкий подход работает, можно по следующим признакам:

а) команда открыто обсуждает важные вопросы в рамках ретроспективы, учитывая новые практики, которые они будут тестировать;

б) члены команды (в частности техники и те, кто занимается непосредственно бизнесом) общаются между собой в основном неформально — количество формальных встреч сведено к минимуму;

в) в конце спринтов почти не возникает неожиданностей.

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

Использование HDD в цикле разработки продукта

Цикл разработки продукта представлен на рис. 1.5. В табл. 1.1 более подробно описаны четыре области деятельности, осуществляемой при разработке продукта, а также их отношение к различным методологиям и практикам, связанным с Agile. Какие-то из приведенных ниже терминов вы, возможно, слышали, какие-то нет — в любом случае они здесь просто для справки, знать их необязательно.

Рис. 1.5. Показатели и цикл разработки продукта

Таблица 1.1. Четыре основные области деятельности 12

Область деятельности	Описание	Распространенность	Родственные области и термины
Непрерывное проектирование, где успех определяется отношением количества выпущенных функций к количеству успешных функций	Эта область связана с определением того, что именно нужно создавать. В то время как многие Agile-команды всегда стабильно тестируют юзабилити, диагностике проблем, оценке спроса и юзабилити интерфейса редко уделяется должное внимание. Успех в этой области деятельности определяется тем, какая часть выпущенных командой функций обеспечивает высокую вовлеченность клиентов или высокую продуктивность внутренних пользователей	Низкая/возрастает	Дизайн продукта. Дизайн-мышление. Customer Discovery (исследование аудитории). Customer Development (CustDev, кастдев). Lean Startup (бережливый стартап). Lean UX (бережливый UX). Lean Analytics (бережливая аналитика). Дизайн-спринт. Устаревшие практики Сбор требований. Приемочное тестирование
Разработка приложения, где успех определяется скоростью выпуска функций	Эта область связана с созданием ПО и систем ПО. Agile в этой области является по сути неофициальным стандартом. Успех в этой области определяется «скоростью» — значимостью и количеством функций, выпущенных за определенный промежуток времени	Высокая/стабильная	Скрам. SAFE (Scaled Agile Framework). Канбан (отдаленно). Экстремальное программирование. Парное программирование. Разработка через тестиро­вание. Оценка задач. Очки за пользовательскую историю. Устаревшая практика Каскадная модель разработки
Непрерывная доставка, где успех определяется частотой релизов	Эта область связана с интеграцией тестирования и развертывания ПО в процесс его реализации. Успех в этой области определяется тем, насколько часто команда выпускает новые версии ПО. Непрерывная доставка	Средняя/возрастает	DevOps1. Непрерывная интеграция. Модульное тестирование. Интеграционное тестирование. Системное тестирование. Инсценировка. Управление релизами.
	означает, что когда разработчик вносит изменения в код и фиксирует их, они автоматически (если обновленная версия пройдет серию тестов) появляются и у пользователей		Устаревшая практика QA
Проверка гипотез, где (как и в непрерывном проектировании) успех определяется отношением количества выпущенных функций к количеству успешных функций	Эта область (имеющая непосредственное отношение к непрерывному проектированию и непрерывной доставке) связана с проведением экспериментов, в ходе которых команда получает доказательства «готовности» продукта. Успех в этой области опреде-ляется тем, под­тверждает ли наблюдаемое командой напрямую поведение пользователей «готовность» того, над чем они работали	Низкая/возрастает	A/B-тестирование. Экспериментирование

Что можно измерить — тем можно управлять в Agile

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

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

Представим такую ситуацию: вы на пятничной встрече, на которой команда обсуждает, как прошел недельный спринт и что можно было бы сделать по-другому в следующий раз. В Agile это называется ретроспективой. Эта конкретная встреча — комбинация ретроспективы и того, что иногда называют грумингом (backlog grooming), — обсуждения задач, над которыми команда будет работать на следующей неделе. Специалист по надежности систем (site reliability engineer, SR-инженер), обращающий особое внимание на то, насколько часто команда выпускает обновления и какова их эффективность, считает, что команде нужно больше поработать над автоматизацией тестирования приложения, учитывая количество возникающих в нем багов. А разработчики считают, что количество багов в целом в пределах нормы и команде следует сосредоточиться на завершении работы над новым набором функций. Каждый по-своему прав, и все хотят добиться наилучших результатов.

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

F — единственная формула, которая вам потребуется

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

Рис. 1.6. Формула F

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

Как рассчитать F? Сначала нужно оценить, сколько будет стоить реализация командой одной функции — это затраты на команду, деленные на объем функций, над которыми они работают, то есть (c$ + g) / (fe × (1 – rf)) в формуле. Предположим, эта величина равна 5000 долларов.

Стоимость/наполнение — числитель дроби. Это значение — стоимость результата. Но то, что получается на выходе, само по себе важнее в контексте, скажем, завода по изготовлению кроссовок, чем в контексте управления цифровой командой. Большое количество ПО оказывается непригодным к использованию, а стоимость функции может быть отрицательной. Это происходит, когда неиспользуемая функция перегружает ваш код, увеличивает технический долг (technical debt) или, что еще хуже, делает ваш продукт сложным в использовании и увеличивает UX-долг. Поэтому мы делим стоимость/наполнение на долю успешных функций — в формуле это sd. Например, если создание набора функций командой стоит 5000 долларов, но лишь 50 % из этих функций можно назвать успешными, то стоимость создания успешной функции равна 10 000 долларов.

Кратко рассмотрим каждую из переменных в формуле. Числитель — отношение стоимости к наполнению релиза, то есть стоимость реализации определенной функции. Чтобы определить ее, нужно знать, сколько стоит команда. Эта стоимость рассчитывается так: мы берем заработную плату членов команды и связанные с ней расходы наподобие бонусов — c$ — и добавляем к ней стоимость необходимого оборудования и сервисов, которыми пользуются участники команды — g. Затем мы численно выражаем результат работы команды за определенный период времени — в формуле это fe. Теперь переходим к rf — последнему элементу, который мы учитываем при расчете того, сколько стоит реализация какой-либо функции командой. Показатель rf (release friction, трение релиза) отражает, сколько времени команда тратит на такие действия, как ручное тестирование и устранение ошибок. Брать его в расчет необязательно, но суть рассматриваемого равенства состоит в том, чтобы учесть самые разные факторы, которые влияют на величину F, а rf зачастую является достаточно весомым фактором. Еще более значимым фактором является знаменатель дроби, sd, который обозначает долю успешных функций и на который мы делим, чтобы рассчитать, сколько стоит реализация не функции вообще, а именно успешной.

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

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

HDD, цифровая стратегия и Agile в реальной жизни

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

Положение «ОВиК без промедления» на рынке

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

Цифровая команда «ОВиК без промедления» и ее цель

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

Что имеет значение для этого бизнеса? Почему? Что для него означает product/market fit? Как они его достигают?

Целевая аудитория «ОВиК без промедления» — сегмент среднего бизнеса. Обслуживание малых компаний обходится дороже (по сравнению с выручкой), а у крупных компаний есть собственные специалисты. Поскольку мы стремимся к достижению product/market fit и масштабированию, нам следует сосредоточиться именно на этом сегменте (рис. 1.7).

Рис. 1.7. Product/market fit в компании «ОВиК без промедления»

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

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

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

Цели и ключевые результаты «ОВиК без промедления»

Главная цель бизнеса в целом: «Стать ведущим поставщиком систем ОВиК для среднего бизнеса во всех регионах нашей страны». Ключевые результаты (КР) на текущий квартал таковы:

• КР1 — увеличить долю на рынке на 10 пунктов;

• КР2 — увеличить прибыль на 8 % по сравнению с прибылью за предыдущий квартал;

• КР3 — удерживать отток клиентов на уровне ниже 5 % за квартал.

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

• КР1 — развернуть приложение для заказа запчастей (в течение первого месяца квартала);

• КР2 — привлечь не менее 100 пользователей для тестирования приложения;

• КР3 — добиться того, чтобы более 80 % заказов запчастей были сделаны пользователями из тестовой группы через приложение.

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

Как читать эту книгу

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

1. Как выстроить структуру работы, опираясь на проверяемые на практике идеи (гипотезы), критерии эффективности которых напрямую связаны с тем, что лежит в основе бизнес-модели компании.

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

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

Что вы получите, прочитав эту книгу?

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

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

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

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

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

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

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

Чему вы научитесь

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

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

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

Рекомендации по практике и дополнительные ресурсы

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

Опишите бизнес и product/market fit с помощью шаблона бизнес-модели

Выберите компанию, о деятельности которой вы осведомлены (например, компания, в которой вы работаете, или ваш сторонний проект), и опишите ее с помощью шаблона. Выделите на это 50 минут, но будьте готовы к тому, чтобы возвращаться к шаблону и пересматривать его по мере того, как будете применять его к разработке новых идей для продукта. По ссылке ниже вы найдете необходимые материалы, включая пошаговое руководство, шаблон (в Google Slides или PowerPoint) и, если вы хотите углубиться в материал, онлайн-курс: https://www.alexandercowan.com/hdd-book-ref/.

Определите направление работы команды с помощью OKR (целей и ключевых результатов)

Выберите компанию (возможно, даже ту, которую вы описывали, создавая шаблон бизнес-модели) и подготовьте список целей и ключевых результатов. В частности, если это компания, в которой вы работаете, то попробуйте конкретизировать данный список для вашей команды (см. примеры в ресурсах ниже). Выделите на это 30 минут, но будьте готовы к тому, что список может впоследствии измениться. По ссылке https://hdd.works/3oc4XqW вы найдете примеры и некоторые известные книги на эту тему.

Примените Agile на практике

С каждой главой мы будем все глубже погружаться в Agile, и я думаю, что большинству читателей этого будет достаточно для обретения более полного понимания. Тем не менее, если вы хотите погрузиться в тему Agile прямо сейчас, то по ссылке ниже найдете введение в Agile и несколько онлайн-курсов: https://hdd.works/3PExe5n/.

Изучите стратегию и цифровизацию

Если вы являетесь членом группы по разработке стратегий или взаимодействуете с ней, то вам может понадобиться более подробная информация о цифровизации и о том, как HDD соотносится со стратегическим планированием. Сведения об этом доступны по адресу https://hdd.works/3aP2UpF/.

Создайте образовательную программу или курс на основе книги

Учебный план моего курса, программы семинаров и рассматриваемые кейсы можно найти здесь: https://hdd.works/3oamJed.

И пожалуйста, не стесняйтесь писать мне!

---

Глава 2. От идеи к проектированию

У меня нет весомых доказательств этому, но я думаю, что около половины разрабатываемого ПО (новые продукты, новые функции для уже существующих продуктов, а также ИТ-проекты в целом) оказывается в мусорной корзине14. Причина проста: если в основе продукта лежит плохая идея, то неважно, насколько грамотно он будет спроектирован, реализован, выпущен и протестирован — он все равно будет обречен на провал. И здесь возникает интересный вопрос: как тестировать идеи, особенно собственные, которые мы обычно склонны оценивать положительно?

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

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

Во-первых, хорошо работать — сложно! Я знаю, что нужно делать, чтобы быть в идеальной физической форме. В идеальной ли я физической форме? Нет. Я поддерживаю себя в более-менее неплохой форме, но даже это дается мне сложно, поскольку у меня в целом нет привычки к этому. Во-вторых, наиболее передовые цифровые практики (например, дизайн продукта, дизайн-мышление, Agile, Lean Startup) до сих пор недостаточно интегрированы в структуру работы компаний и даже в большинство образовательных программ.

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

Рис. 2.1. Непрерывное проектирование и HDD

Непрерывное проектирование на практике

В главе 1 вы познакомились с четырьмя областями деятельности в HDD. Первой областью в этом списке было непрерывное проектирование (табл. 2.1).

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

Таблица 2.1. Непрерывное проектирование на практике

Область деятельности	Описание	Распространенность	Родственные области и термины
Непрерывное проектирование, где успех определяется отношением количества выпущенных функций к количеству успешных функций	Эта область связана с определением того, что именно нужно создавать. В то время как многие Agile-команды всегда стабильно тестируют юзабилити, диагностике проблем, оценке спроса и юзабилити интерфейса редко уделяется должное внимание. Успех в этой области деятельности определяется тем, какая часть выпущенных командой функций обеспечивает высокую вовлеченность клиентов или высокую продуктивность внутренних пользователей	Низкая/возрастает	Дизайн продукта. Дизайн-мышление. Customer Discovery (исследование аудитории). Customer Development (CustDev, кастдев). Lean Startup (бережливый стартап). Lean UX (бережливый UX). Lean Analytics (бережливая аналитика). Дизайн-спринт. Устаревшие практики Сбор требований. Приемочное тестирование

Мне очень нравится, как свою точку зрения на это изложила моя коллега Джин Лидтка. Она разрабатывает способы применения инструментов дизайна практически ко всему — от менеджмента общего профиля (об этом она пишет в своей книге The Designing for Growth Field Book) до работы некоммерческих организаций (этому посвящена ее книга Design Thinking for the Greater Good15). Она противопоставляет образы мышления двух вымышленных персонажей — Джеффри и Джорджа. Их сравнение вы можете видеть на рис. 2.2.

Подумайте о своей работе и своем взаимодействии с коллегами. Кто из них больше похож на Джеффри, а кто — на Джорджа? Как вы думаете, почему? А что вы скажете о себе?

Успешное применение HDD в этой области способствует формированию установки на рост в не меньшей степени, чем все остальное. Вы поймете, что она у вас сформировалась, если вам будет интересно пробовать новые методы и наблюдать