Часто можно увидеть ошибочное трактование циклического подхода, когда итеративно поставляется не финальный артефакт, а промежуточные. Несмотря на внешнее сходство, результат может получиться драматическим.
То, что промежуточная производственная станция, например дизайнер, раз в неделю ритмично поставляет дизайн-макеты, совершенно не значит, что эти макеты будут утилизированы в будущем или вообще нужны для реализации финального артефакта.
Такой карго-культ[21], помимо противоречия бережливому принципу втягивания, может посадить сразу несколько видов потерь – перепроизводства, лишних запасов и пр.
Более подробно о гибком подходе Agile и лучшем известном способе организации цикла поставки Scrum будет рассказано подробнее в п. 3.1 и 3.2.
3.1. Agile
Практики Agile во многом контринтуитивны. Достаточно легко можно себе представить, как в изолированной компании зарождается водопадный подход, сводя к минимуму вероятность, что скопированный по образу и подобию гибкий фреймворк[22] типа Scrum приживется.
Тем не менее, как было описано ранее, молодые компании начали двигаться в сторону альтернативных подходов к разработке. Через некоторое время, на встрече 17 независимых практиков новых методик программирования 13 февраля 2001 года, был сформулирован свод общих принципов гибких подходов – манифест Agile (Agile Manifesto).
3.1.1. Agile-манифест
Левая часть каждого тезиса важнее чем правая, но не отрицает его. Манифест не говорит о том, что нужно прекратить следовать плану, бросить писать документацию и отменить процессы. Разберем каждый его элемент.
Табл. 3.1. Agile-манифест
3.1.1.1. Люди и взаимодействие важнее процессов и инструментов
Если процесс мешает людям работать и взаимодействовать, то должна существовать возможность от него избавиться. Некоторые процессы просто устаревают, другие, в теории показавшиеся эффективными, на практике оказываются тягостными и вредят эффективности и удовлетворенности от работы.
Такая же картина и с внедряемыми инструментами. Первичная цель внедрения – это повышение эффективности, которая, в свою очередь, прочно связана с качеством опыта сотрудника (англ, employee experience, сокр. EX). Если в процессе использования инструмента создается ощущение несправедливости или пустой траты времени, то стоит задуматься о его замене или отмене.
Например, я на практике наблюдал несколько волн джирафикации и деджирафикации, иногда даже в одной команде. Под джирафикацией я имею в виду внедрение инструмента управления задачами типа Jira[23]. Когда команда только запускалась, не было конкретных инструментов для отслеживания задач, команда работала, перемещая физические стикеры по Kanban-доске[24]. Через некоторое время команда внедрила диспетчер задач, и стало уходить заметно больше времени на ежедневные стендапы[25], так как приходилось тратить время на настройку и оперирование инструментом. Также часть времени уходила на «нарезание» задач на спринт. Потом, после очередного тренинга, команда начала делать очень короткие спринты и дробить функциональность на небольшие элементы (пользовательские истории[26]) размерностью менее одного дня разработки. На неделю спринта выходило 5–6 таких элементов, которые команда всем скопом каждый день доводила до релиз-кандидата[27]. При таком подходе отсутствовала необходимость в декомпозиции задач, так как каждый день задачи порождались и утилизировались в финальном артефакте. И команда опять перешла к физическим стикерам.
Через некоторое время, когда продукт вырос и был интегрирован в продуктовый ландшафт компании, понадобился возврат к системе управления задачами. Например, баг, который отловила служба поддержки, или какой-то из других продуктов должен быть доставлен до ответственного за исправление, или нужно показать зависимость задачи с задачами из других систем и продуктов. В команде началась повторная джира-фикация.
3.1.1.2. Работающее ПО важнее подробной документации
Условно документацию, участвующую в разработке ПО, можно разделить на три группы:
1. Проектная – создается до запуска разработки для описания образа результата.
2. Техническая – создается в процессе разработки для осуществления и повышения ее эффективности. Используется разработчиками продукта и другими разработчиками и участниками. Можно выделить нормативную техническую документацию, которая создается для получения сертификатов соответствия, аудита и прочего.
3. Пользовательская – создается для внешних потребителей. Сюда входит руководство для конечных пользователей, b2b-интеграторов, вендоров и других. В пользовательской документации также можно выделить нормативную часть, например описание того, как будут обрабатываться персональные данные в случае их сбора.
Из всех перечисленных типов лишь пользовательская документация является финальным артефактом и частью пользовательского опыта. В связи с этим объем и качество проработки целиком определяется ценностью для конечного пользователя. Развитие пользовательской документации можно сравнить с развитием функциональности продукта. В каждом конкретном случае владелец продукта принимает решение о том, даст ли доработка дополнительную ценность и как это соотносится с расходами на доработку.
Проектная и техническая документация – артефакты промежуточные, и в этом случае, исходя из бережливого подхода, нужно уменьшать количество таких артефактов и сокращать расходы, связанные с их производством, для того чтобы быстрее и в большем объеме дать дополнительную ценность для пользователя – работающее ПО.
Далее приведены различные способы сокращения разных типов документации.
1. Сокращение горизонта планирования, покрытого документацией. Как уже говорилось ранее, чем больше срок планирования, тем больше вероятность, что часть планов будет не реализована. От 20 до 40 % годичных стратегических планов теряют актуальность, например, в связи с изменением технологического, бизнес- или регулярного ландшафта. Еще 20–30 % не реализуется по причине ошибок прогнозирования и культа амбициозности. Следовательно, чем меньше горизонт планирования, тем меньше вероятности сделать лишнюю работу.
2. Применение дорожной карты. Если есть необходимость описать долгосрочное видение, то можно использовать дорожную карту – высокоуровневое описание этапов без жесткой привязки к конкретным датам. Важно, что дорожная карта может актуализироваться периодически, исходя из текущей ситуации. Это дает возможность сфокусироваться на ближайшем этапе разработки и детально его описывать в случае необходимости.
3. Использование формата пользовательских историй при описании функциональных требований. Формат пользовательских историй (можно услышать юзерстори) позволяет описывать функциональность системы от лица пользователя. Это дает возможность бизнес-заказчику фокусироваться на финальном артефакте и оставлять промежуточные на усмотрение команды разработки. Формат отвечает на вопрос «что нужно сделать» и позволяет ответить на вопрос «как это сделать» разработчикам, выбирая при этом оптимальные способы и инструменты. (Подробнее о формате пользовательской истории см. в п. 3.2.4.1.)
Сокращение объема технической документации
1. Автоматически генерируемая документация. Нужно отдавать предпочтение решениям, которые позволяют генерировать документацию автоматически на основе структур кода. Например, фреймворк разработки[28] типа FastAPI позволяет из коробки автоматически генерировать документацию для интеграции потребителями сервиса. С появлением больших языковых моделей[29] набирает популярность генерация документации на основе ИИ. Например, GitHub Copilot экономит время разработчиков на описание кода, отправляемого в репозиторий.
2. Pull-документация. Тут применяется принцип втягивания вместо вталкивания. Часто бывает, что документация пишется про запас, и, если сделать замеры, можно увидеть, что часть документов генерируется впустую. Принцип вытягивания подразумевает, что документация генерируется по запросу. При этом современная документация – это не обязательно текст. Более эффективно и наглядно по времени может быть записать скринкаст[30] с объяснением голосом. Потом такое видео добавляется в базу знаний и отправляется по запросу. Подход втягивания имеет еще и культурно-оздоравлива-ющий эффект – разработчики начинают больше общаться и помогать новичкам вливаться, что отличается от культуры выталкивания, в которой новичка могут отправить штудировать обширную базу документов о продукте. Разумеется, принцип pull-документации нельзя использовать повсеместно, например для нормативной документации, создаваемой по требованиям стандартов. Но само движение в сторону перевода генерации артефактов от выталкивания к втягиванию позволит значительно оптимизировать процесс и сделать деятельность сотрудников более содержательной и осмысленной.
3.1.1.3. Реагирование на изменения важнее следования плану
«Давайте сначала все по договору закроем, а потом начнем вносить правки», – именно так я отвечал клиенту, управляя небольшой компанией заказной разработки. Планы разработки шли тогда 3 4 квартала и уже на 1-2-м квартале накапливалось смещение сроков, и изменения в процессе – даже очевидные и существенные – были подобны смерти.
Тяжелое и деморализующее действие на всех участников процесса оказывает понимание в середине пути, что мы идем не туда. Заказчики теряют деньги и упускают возможности рынка, разработчики бесцельно проживают свои годы, занимаясь бесславным трудом.
Уже тогда ко мне пришло понимание, что нужно дробить большие проекты на фазы, каждый раз открывая какую-то часть функциональности на пользователей. Бюджетировались фазы отдельно, а значит, в процессе их можно поменять местами или вообще заменить.
3.1.2. Пример гибкого подхода
Предположим, что у нас есть участок земли с коммуникациями и идея построить отель. Если мыслить интуитивно в водопадной логике, то проект будет состоять из нескольких этапов:
➠ Проектирование, в результате которого мы получаем проект отеля на 20 номеров разной комфортности и вместимости, с открытым бассейном.
➠ Вырываем котлованы под основное здание и под бассейн.
➠ Возводим стены этаж за этажом.
➠ Ставим крышу.
➠ Проводим отделку.
➠ Строим бассейн.
➠ Запускаем постояльцев.
Проблема такого подхода в том, что продукт становится ценным для пользователя только по завершении всех работ. Есть очень большой риск, что если мы не сможем продолжать инвестировать в проект в середине процесса, то потеряем все инвестиции.
Гибкий подход позволяет возвращать инвестиции как можно раньше, постепенно наращивая объем входящего денежного потока.
Рассмотрим строительство отеля с активным применением гибкого подхода:
➠ Привозим на участок жилой блок-контейнер.
➠ Делаем рекламу и запускаем жильцов.
➠ Собираем обратную связь об их предпочтениях: например их полностью устраивает уровень комфорта блок-контейнера.
➠ Входящий денежный поток позволяет закупить в сезон еще несколько контейнеров.
➠ По обратной связи мы понимаем, что вместо открытого бассейна постояльцам не хватает теннисного корта.
➠ Возводим теннисный корт.
➠ Собираем статистику по составу отдыхающих семей, что позволяет скорректировать проекты блок-контейнеров по наиболее востребованным сценариям; это позволило увеличить наполняемость и снизить расходы на рекламу
➠ Полученные данные о финансовой модели привлекли инвестора, который вложил деньги в еще несколько контейнеров и расширение участка.
Рис. 3.1. Сравнение водопадного и итеративного подходов
Как видно на рис. 3.1, второй пример получился более устойчивым к непредсказуемым ситуациям на рынке, начал возвращать деньги практически сразу и, главное, основатели получили обратную связь, которая позволила скорректировать и быстрее расширить бизнес.
Разумеется, гибкий подход не всегда и не везде показывает максимальную эффективность. Давайте рассмотрим области применимости разных типов подходов.
3.1.3. Область применения гибких подходов
После знакомства с гибким подходом возникают две радикально противоположные идеи. Одни считают, что Agile нужно использовать повсеместно, другие, что в их случае (госзаказ, корпоративные закупки и т. и.) этот подход неприменим. Рассмотрим, в каких же случаях какие типы процессов уместно применять.
В 1999 году Дэйв Сноуден из IBM Global Services предложил свою модель классификации «миров», в которых приходится действовать. Модель называется Cynefin (среда обитания, пристанище), и в ней определены четыре операционных контекста:
➠ Simple (понятный или очевидный) – мы находимся в предсказуемой среде, все объекты и процессы знакомы и можно применять сложившиеся лучшие практики для достижения результата.
➠ Complex (комплексный, сложный в значении многосоставный) – в этом операционном поле причинно-следственные связи можно получить ретроспективно, в результате совершенного действия. Тут работает цикл «исследуй-восприни-май-реагируй».
➠ Complicated (запутанный, сложный в значении содержащий неизвестные элементы) – в этом домене мы осознанно двигаемся в неизвестную область. Это мир, где нужно разобраться в новых сущностях, приобрести экспертизу в новом деле, например открыть новый рынок для уже существующей компании.
➠ Chaos (хаотичный) – мир, в котором нельзя полагаться на прогнозы и нужно экспериментировать. Это как идея для стартапа, его жизнеспособность может быть доказана только после коммерческого эксперимента.
Нелишним будет сказать, что Сноуден добавил еще один операционный контекст «Неопределенность» – это когда непонятно, в каком из перечисленных выше контекстов ты находишься, и нужно сделать выбор.
Впоследствии Ральф Стейси в своей книге «Стратегический менеджмент и организационная динамика – вызов сложности» связал операционные контексты с уровнем ясности требований «что мы делаем» и наличием экспертности «как мы делаем».
Рис. 3.2. Квадрант операционных контекстов
Условно ситуации, в которых принимаются решения о применимости типов процессов, можно разделить на четыре типа по тому, насколько определены требования к результату, и по тому, насколько есть определенность в способе реализации. Типы ситуаций приведены на рис. 3.2.
3.1.3.1. Водопадный подход
Водопадный, или каскадный подход (часто можно услышать «ватерфол» – англ, waterfall), идеально подходит для ситуаций, когда понятно, что и как делать. Все участники однозначно трактуют договоренности об образе результата, и есть четкая декомпозиция реализации на подзадачи каждого участника с точными временными рамками и зависимостями. В описанной ситуации полной определенности водопадный подход максимально эффективен, так как позволяет продумывать параллельность выполнения разных процессов для сжатия сроков.
Рис. 3.3. Пример диаграммы Ганта
Классическое представление водопадного плана – диаграмма Ганта, приведенная на рис. 3.3.
Каскадный подход идеален для однотипных, регулярно повторяемых процессов. Например, я сталкивался с компаниями, стилизующими стандартные интернет-магазины под фирменный стиль заказчика. Эта работа состоит из одинаковых, четко определенных по времени этапов.
В моей практике был период, когда я делал сайты-визитки на заказ. На каждый этап работ был определен объем трудозатрат каждого участника, например «дизайн одного варианта главной страницы по утвержденной концепции» включал в себя 16 часов работы дизайнера, 2 часа арт-директора и2 часа аккаунт-менеджера. Суммарная длительность этапа, соответственно, составляла 8 часов. Подобная унификация позволяла считать бюджет и формировать график работ автоматически с использованием специального калькулятора в Excel, практически в реальном времени общаясь по телефону с потенциальным заказчиком.
Проблемы начинались, когда для сайтов заказывались нестандартные функции – онлайн-калькулятор, оригинальная форма обратной связи и пр. В этом случае нужно было затрачивать ресурсы на дополнительную оценку. Отсутствие экспертизы в решении подобного класса задач уменьшало качество прогноза.
Чем более новый и нестандартный продукт нужно создавать, тем больше требуется времени на оценку.
Вторая, более серьезная проблема водопадного подхода – горизонтальная декомпозиция работ. На протяжении всего периода проекта промежуточные артефакты переходят с одного каскада на другой, и пользователь получает ценность лишь в самом конце, часто со значимым смещением сроков, в отличие от вертикальной декомпозиции, когда вся функциональность продукта разбивается на релизы и в конце каждого релиза пользователи получают дополнительную ценность (рис. 3.4).
Рис. 3.4. Горизонтальная и вертикальная декомпозиция
Горизонтальная декомпозиция порождает горизонтальную интеграцию[31]компании, при которой она распадается на этажи, отвечающие за определенный этап.
Пока идет длительный этап анализа требований, дизайнеры работают по согласованным требованиям из предыдущего проекта, разработчики действуют по дизайну для позапрошлого и т. д.
Это порождает еще большую проблему – этаж перестает отвечать за результат в целом. Каждый отрабатывает свои часы, очень занят, а то, что происходит с произведенным артефактом дальше, – проблема следующего этажа.
Симптомом может служить ситуация, когда дизайнеры начинают жаловаться, что сделали классный дизайн, а вот они (показывают в неопределенном направлении) опять все испортили – не смогли сверстать.
Водопадный подход неустойчив к доработке артефактов предыдущих каскадов – верхний этаж очень занят и не может прерваться на доработку. Поэтому возникает следующая проблема – ресурсозатратный процесс приемки артефактов предыдущего каскада.
Требования к качеству артефакта становятся все выше и избыточнее (это же проблемы верхнего этажа!), а процедура приемки – все дольше. Как следствие, мы имеем отходы на переработку артефакта и смещение сроков из-за цикла доработок.
Водопадный подход плохо переносит исключительные срочные ситуации. Например, если нужно срочно что-то починить и доработать в одном из проектов, это смещает сроки по остальным. На этот момент компания становится вертикально-интегрированной, и все работают сообща в кросс-функциональной[32] команде для достижения цели.
Итак, водопадный подход максимально эффективен, если понятно, что и как делать. Идеально, если это регулярно повторяемые однотипные проекты.
В остальных случаях водопадный подход может вызывать негативные эффекты, как краткосрочные – смещение сроков, избыточная обработка промежуточных артефактов, так и долгосрочные – разобщенность и безответственность этажей.
3.1.3.2. Scrum
Когда есть четкое понимание, что делать, но нет понимания как, лучше всего работает Scrum. Детально мы будем разбирать этот фреймворк в и. 3.2, а сейчас обсудим общие идеи.
Для описания Scrum идеально подходит поговорка «слона нужно есть по частям». Комплексная задача разделяется на несколько поменьше, и, решая небольшие задачи, команда постепенно приобретает экспертизу и приходит к цели.
Еще одна метафора – движение по болоту на свет маяка в тумане. Чтобы достигнуть цели, мы каждый раз выбираем максимально ориентированное на нее направление, определяем, куда можно поставить ногу, делаем шаг – и процесс повторяется. Возможно, путь будет не идеальным, но мы получаем прогресс на каждом шаге.
Один из основных принципов Scrum – это итеративность, при этом каждая итерация должна нести ценность для конечного пользователя. Каждую итерацию команда проясняет объем функциональности, который планирует реализовать в следующем спринте. В конце каждого спринта команда демонстрирует результат, анализирует актуальность процессов, корректирует их при необходимости и планирует, что будет реализовано в следующем спринте.
Scrum хорошо выдерживает возникновение срочных исключительных ситуаций и быстро адаптируется к изменениям среды и реакции пользователей. Фреймворк подразумевает вертикальную декомпозицию работ, что влияет на изменение компании в сторону вертикальной интегрированности, делая ее диверсифицированной и антихрупкой.
Scrum позволяет быстро достигать видимых результатов. Это создает позитивную атмосферу динамики и движения вперед.
Инкрементальный подход дает возможность каждый спринт фиксировать риски непопадания в сроки, так как уже с первых итераций появляется продукт, обладающий основной функциональностью.
Scrum внедрен в большинстве ведущих IT-компаний. Это означает, что требуется меньше времени на адаптацию нового сотрудника в команду.
Адепты Scrum считают, что этот фреймворк можно использовать в любой ситуации, от приготовления пирожков и до создания атомных реакторов.
Из минусов можно отметить его контринтуитивность и тесную связь с культурой компании.
3.1.3.3. Контринтуитивность
Как уже говорилось ранее, компании быстро интуитивно могут прийти к водопадному процессу. Scrum же требует высокоуровневого понимания всех элементов и их связи.
К сожалению, мне лично приходилось участвовать во внедрении Scrum по книжке, и это привело к резкому падению эффективности. Процесс, внешне похожий на Scrum, может оказаться Scrumfall (Scrum+Waterfall) или другим вариантом галлюцинаций на тему процессов. Подобное неудачное внедрение часто вызывает травматичный опыт, и сотрудники, его пережившие, становятся противниками внедрения.
Идеально, если Scrum внедряет сертифицированный эксперт с опытом внедрения и обладающий практическим опытом работы по фреймворку в роли Scrum-мастера.
3.1.3.4. Связь с культурой компании
Scrum подразумевает прозрачность, плоскую структуру, высокий уровень самостоятельности и фокус на результат.
Если среди проблем участники команды перечисляют:
➠ непонятные цели поставленных задач или беспричинную срочность;
➠ двоевластие;
➠ недоступность владельца продукта или стейкхолдеров;
➠ выработку человеко-часов важнее ценности поставки,
то, скорее всего, Scrum/Agile внедрен в компании декларативно, а за фасадом скрываются совсем другие процессы.
В этом случае Scrum может показать обратную эффективность.
3.1.3.5. Связь между Scrum и водопадом
Когда функциональность ближайшего релиза определена, команда может использовать водопадный подход для планирования задач каждого участника внутри спринта, чтобы оптимальным способом достичь результатов. Но стоит добавить, что для оптимизации работы внутри спринта водопад не является единственной и лучшей практикой. Например, есть такие практики как «роение» (англ, swarming), которую мы обсудим в и. 3.2.4.2.
3.1.3.6. Kanban
Kanban (яп. , – вывеска, рекламный щит) – это важнейший элемент бережливого производства, который глубоко интегрирован в гибкие подходы к разработке.
Изначально Kanban был создан для визуализации прохождения артефактов в процессе производства Toyota.
Kanban очень хорошо показывает себя в запутанном мире, когда мы осознанно двигаемся в область неизведанного.
Например, в цикле открытий, который подробнее будем рассматривать в главе 4. Лица, ответственные за дискавери с фиксированной периодичностью (например, один раз в неделю), собираются для фиксации прогресса.
На рис. 3.5 представлен пример Kanban для цикла дискавери.
Рис. 3.5. Пример Kanban для управления циклом открытий
Следует обратить внимание на ограничение количества спикеров в каждой ячейке (практика WIP limit[33]). Подобный подход не дает возможности сфокусироваться на одной работе за раз и, не накапливая промежуточные артефакты, доводить дело до конца.
Еще одна важная практика Kanban – четкие критерии перехода из стадии в стадию.
Третий инструмент, «плавательные дорожки» (swimlane), позволяет видеть зависимости между двумя командами, которые работают в продукте, и приходить на помощь в случае, если у кого-то происходит «пробуксовка».
Kanban позволяет быстро выявлять проблемы в процессе. В случае, показанном на рис. 3.5, у второго владельца продукта происходит «затоваривание», он набирает много задач и из-за потерь на переключении падает фокус. При этом много задач застревает в накопителях, а значит, он не доводит дело до конца. У третьего владельца продукта проблемы другого рода – у него есть пустые ячейки, что говорит о том, что время, возможно, расходуется недостаточно эффективно.
3.1.3.7. Связь между Scrum и Kanban
Kanban может использоваться Scrum-командой для ежедневного отслеживания прогресса – движения элементов функциональности (пользовательской истории) от ToDo[34] к Done или для движения задач разработчиков в процессе выполнения одной пользовательской истории в отдельной дорожке (такой Kanban называется Scrum-доска или Scrum-борд).
Рис. 3.6. Scrum-доска (слева) и Kanban-доска статуса функциональности (справа) для управления спринтом в режиме «роения»
В примере на рис. 3.6 команда взяла в спринт три истории и разбила реализацию каждой из них на задачи отдельных исполнителей. Современные таск-трекеры типа Jira могут отображать Scrum-доску в двух представлениях: в разрезе задач и в разрезе поставленной функциональности (историй). Если все задачи по истории перенесены в Done, то и история переносится в Done. Подобный подход позволяет делать акцент на том, чтобы двигались пользовательские истории (конечный артефакт, ценный для пользователей), а не на том, как двигаются задачи разработчиков (промежуточный артефакт). Это позволяет избежать ситуации, когда к концу спринта закрыто большинство задач, но не сделано ничего ценного. Вторая хорошая практика – фокусироваться на одной истории за такт (практика «роение»). Это дает максимальный фокус и уменьшает потери при переключении между историями.
3.1.3.8. Бережливый стартап
Когда создается что-то новое, чего не было в опыте, мы действуем в хаотичном мире, и здесь лучше всего работает паттерн «действуй – ощущай – отвечай». В отличие от комплексного мира, где понятны направление и цель, в хаотичном работает модель постижения через действие – мы понимаем, куда двигаться дальше, только когда сделаем шаг.
Мы не можем спрогнозировать, будут ли пользователи покупать наш продукт, значит единственный вариант – провести эксперимент. Тут на помощь приходит упомянутый выше бережливый стартап. Суть подхода заключается в том, чтобы как можно быстрее пройти цикл «разработай – протестируй – доработай (или брось)».
Бережливый означает, что проверить потенциальную жизнеспособность продукта нужно с минимальным количеством отходов.
Для этого из продукта и из процесса его разработки нужно убрать все лишнее, чтобы минимальными затратами и максимально быстро проверить гипотезу жизнеспособности. Такой продукт называется минимально жизнеспособным продуктом или общепринятым сокращением MVP. Часто в этом значении используется термин «пилотный проект».
Представим, что мы решили запустить новый для себя бизнес по продаже винтажных велосипедов.
Вариант 1. Гипертрофированный водопадный подход:
➠ Закупить партию велосипедов.
➠ Арендовать склад.
➠ Арендовать магазин.
➠ Заказать брендинг для компании.
➠ Заказать дизайн интерьера.
➠ Сделать ремонт в магазине.
➠ Пошить униформу.
➠ Нанять персонал.
➠ Сделать сайт с каталогом продукции.
➠ Заказать в рекламном агентстве кампанию.
Вариант 2. Гипертрофированный Lean startup подход:
➠ Дать бесплатное онлайн-объявление о том, что продается винтажный велосипед, используя фото из интернета.
➠ В случае, если кто-то откликнется, перепродать велосипед, доставив самостоятельно.
➠ Проанализировать, может ли бизнес быть прибыльным и как увеличить объем продаж:
➠ заказ напрямую у поставщика;
➠ закупка оптом;
➠ организация собственной службы доставки;
➠ др. вариант.
➠ Итеративно внедрять улучшения в бизнес, чтобы дать ценность максимальному количеству пользователей.
Очевидно, что оба примера гипертрофированы и используются для того, чтобы максимально эффективно показать разницу в подходах.
Проблема первого варианта в том, что затрачен максимальный объем инвестиций еще до того, как ценность была доказана. В случае неуспеха риск потери очень велик. Бизнес, созданный по этому варианту, обладает множеством компонентов, и в случае неудачи непонятно, какой элемент нужно улучшить. Еще одна, менее очевидная проблема первого варианта – он с самого начала начинает генерировать расходы.
Подход бережливый стартап (второй вариант) позволяет без избыточных издержек протестировать гипотезу жизнеспособности продукта, фиксируя при этом риски на каждом этапе. Как только становится понятно, что модель не сходится[35], есть возможность моментально отказаться от продолжения эксперимента.
Важно, что после первого «проворота» lean-цикла становится понятно, к какому элементу цепочки ценности важно приложить усилия. Возможно, компании вообще окажется не нужен сайт или физический склад, а упор нужно сделать на оптовую закупку или собственное производство.
При этом следует учесть, что вариант 1 может вполне хорошо показать себя в простом мире. Например, если это запуск очередного бизнеса для серийного предпринимателя, который уже запустил несколько брендов в области локальной мобильности (велосипеды, самокаты и т. п.), в этом случае можно все спланировать заранее, и проект может быть успешно разыгран как по нотам. Это позволит быстро захватить рынок, пока другие экспериментируют. Но даже в этом случае нет гарантии, что именно винтажные велосипеды не окажутся радикально отличающимся продуктом. Так что, возможно, имеет смысл даже для на первый взгляд понятных продуктов использовать методики lean-стартапа, чтобы проверить самые рискованные гипотезы с минимальными потерями.
Есть несколько популярных способов добиться сокращения издержек на тестирование гипотезы жизнеспособности.
1. Ограничение функциональности. Убрать из продукта все лишнее, оставив только те функции, которые позволяют проверить гипотезу жизнеспособности. Как правило, это новые, уникальные функции (дифференциаторы), которых нет у конкурентов или неизвестна их эффективность.
2. Ограничение качества реализации функциональности. Намеренное занижение качества пользовательского опыта для сокращения стоимости и сроков разработки. Например, использование готовых компонентов интерфейса может быть не оптимальным с точки зрения клиентского путешествия – потребуется большее количество действий для достижения результата, чем если бы компоненты разрабатывались непосредственно под данную задачу с учетом лучших практик. Другой вариант: использование чат-бота в мессенджере вместо классического приложения с экранными формами. Это позволяет очень быстро разработать функциональность с ограничениями в UX[36], свойственными диалоговым интерфейсам.
3. Ограничение стабильности. Продукт работает стабильно только для количества пользователей, достаточного для получения репрезентативных данных[37][36]. Применяется дешевый или бесплатный стек технологий, домашняя или грантовая[38] облачная инфраструктура.
4. «Волшебник страны Оз»[39]. Человек имитирует действия системы, например изображая интеллектуального чат-бота.
5. «Педальный привод». Часть функциональности берет на себя человек, например сотрудник службы поддержки.
6. Ограничение аудитории. Сокращая пользовательский сегмент, можно сократить разработку. Например, сначала сделав разработку для пользователей с операционной системой Android, а потом переходить на iOS или web-версию. Также можно ограничить поддерживаемые версии операционных систем или браузеров, что значительно может уменьшить сроки эксперимента.
7. Более дорогое решение. Если идея вашего продукта – удешевление уже существующего сервиса, то можно использовать более дорогой сервис под капотом для тестирования. Например, для тестирования приложения доставки персональной еды можно использовать существующие сервисы доставки и рестораны. Да, Юнит-экономика[40] не будет сходиться, но можно сделать выводы о востребованности продукта и готовности пользователей за него платить. С появлением больших лингвистических моделей типа ChatGPT появилась возможность использовать его для решения более простых задач, вроде проверки корректности вводимых данных. Например, указал ли клиент отчество ребенка и совпадает ли оно с именем отца. В случае удачного эксперимента можно начать использовать более дешевые специализированные алгоритмы.
Идеально, если получится проверить гипотезу о жизнеспособности, вообще не разрабатывая продукт, компонент или какую-то другую инициативу.
Популярный слоган адептов – «Fake it till you make it» («Имитируй, пока не сделаешь»).
Например, прежде чем разработаешь продукт, можно организовать предзаказ или кампанию на Kickstarter и таким образом замерить интерес. Или сделать «Fake door» (фальшивую дверь) – одну или несколько рекламных кампаний, чтобы протестировать, какие свойства будущего продукта или стилистика оформления будут наиболее привлекательны.
Для тестирования интереса к новой функциональности можно создать фальшивую кнопку в интерфейсе, якобы ведущую на новую функциональность.
На моей памяти есть оригинальный случай, когда по нажатию на фальшивую кнопку пользователям предлагалось «скинуться» на новую функциональность в обмен на преимущественное право использования.
Так как нет возможности заранее предсказать результат эксперимента, в компании должна быть развита культура совершения ошибок. Один из подходов, культивирующих культуру ошибки, – «Fail fast» (быстрый провал). Вместо того чтобы искать подтверждения жизнеспособности, возможно, более эффективным будет подтверждение того, что эксперимент провалится. Тогда, помимо продуктовых гипотез типа «мы идем на это, если…», формулируются контргипотезы «мы не идем на это, если…».
Табл. 3.2. Пример записи гипотез и контргипотез пилотного проекта
Выявление присущих рисков, оценка их объема и принятие – важные этапы пилотного проекта, позволяющие всем заинтересованным лицам подумать о том, что отрицательный результат – это тоже результат, и не ошибается только тот, кто ничего не делает.
Рис. 3.7. Связь процессов из оперативных контекстов с циклами открытия и поставки
Как уже стало понятно, в компании может быть несколько типов процессов, для которых применимы разные подходы.
Например:
1. Проработка идей того, какие гипотезы стоит проверить, – это запутанный мир, где следует применять Kanban.
2. Проверка гипотезы – хаотичный мир, где лучше всего работает бережливый стартап.
3. Превращение гипотезы в продукт для большого количества пользователей – комплексный мир, где зарекомендовал себя Scrum.
4. Если в процессе появляется ранее воспроизводимая операция, то максимальную эффективность показывает водопад.
Важно отметить, что предложенный каскад процессов – лишь общая практика, и многие процессы могут ситуативно меняться, например:
➠ На этапе стартапа, когда компания строится вокруг одного продукта, может быть рано применять конвейер открытий.
➠ Если все заинтересованные лица экспертно приняли решение, что нужно начинать разработку, то можно пропустить этап бережливого стартапа и сразу переходить к Scrum.
➠ Если внутри одной поставки недостаточно очевидно распределение ролей в команде, то не обязательно использовать водопад для планирования и действовать параллельно для достижения результата.