Текст книги "Менеджмент цифрового продукта. От идеи до идеала"

Принцип втягивания означает, что производство и распространение определяются спросом, а не прогнозом спроса.

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

Сравним принципы выталкивания и втягивания (табл. 2.1).

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

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

Некий человек увидел в лесу дровосека, с большим трудом рубившего дерево совершенно тупым топором. Человек спросил его:

– Уважаемый, почему бы вам не наточить ваш топор?

– У меня нет времени точить топор – я должен рубить! – простонал дровосек…

Стремление к совершенству (Kaizen) подразумевает непрерывную ревизию текущих процессов на предмет их улучшения.

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

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

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

Перед вами несколько примеров Kaizen-процессов:

1. Ретроспектива спринта[17]17
  Спринт (англ, sprint – забег) – итерация в разработке, когда команда, ограниченная небольшим промежутком времени (до 1 мес.), сфокусирована на решении определенных задач.


[Закрыть] – обязательное мероприятие, проводимое в конце каждой итерации, для повышения эффективности последующих. (Подробнее о ретроспективе спринта см. в п. 3.2.) Команды проводят «разбор полетов», обсуждая, например, какие проблемы помешали успеть, какие процессы нужно внедрить, чтобы избежать подобных проблем впредь, какие процессы устарели и нужно от них избавиться и идеи, что нужно попробовать.

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

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

2.3. Бережливый цикл разработки

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

Рис. 2.2. Бережливый цикл

Одна из идей, описанных в книге, – цикл бережливого стартапа (Lean startup cycle) – идеального, максимально бережливого цикла для цифрового производства (рис. 2.2).

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

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

Табл. 2.2. Этапы бережливого стартапа

* Гипотеза жизнеспособности инициативы – перечень метрик инициативы и их пороговые значения, при достижении которых инициатива признается потенциально (в отдаленной перспективе) жизнеспособной.

2.4. Циклы открытия и поставки

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

➠ собрать идеи;

➠ оценить релевантность идеи потребностям пользователей;

➠ оценить рыночные условия;

➠ оценить идеи на предмет их инвестиционной привлекательности;

➠ определить объем работ и бюджет для запуска фазы MVP и фазы масштабирования.

Этап такого прояснения принято называть этапом открытия; также часто можно услышать «дискавери» (англ, discovery – открытие; рис. 2.3).

Рис. 2.3. Связь циклов открытия и циклов поставки

После того как объем работ определен и решение о старте работ принято, начинаются циклы поставки, итеративно улучшающие продукт от спринта к спринту.

Если цикл поставки – это интуитивно понятная составляющая производства цифрового продукта, то цикл открытия поэтапно появляется при достижении определенной зрелости компании. Например, сначала может появиться культура проведения исследований для оценки соответствия потребностям пользователя (CustDev, глубинные интервью), потом исследования рынка (конкурентный анализ, бенчмаркинг[18]18
  Бенчмаркинг (англ, benchmarking) – сопоставительный анализ на основе эталонных показателей как процесс определения, понимания и адаптации имеющихся примеров эффективного функционирования предприятия с целью улучшения работы.


[Закрыть]), а потом оценка инвестиционной привлекательности. (Подробнее о бенчмаркинге см. в п. 4.3.3.4.)

Логично, что бережливый подход подходит для цикла открытия и к нему применим механизм бережливого цикла. Артефакты, необходимые для принятия решения о запуске разработки, проходят этапы цикла максимально быстро и с минимальными отходами. Затем артефакты цикла дискавери определяют дальнейшую разработку и, следовательно, должны быть эффективны как граничный объект[19]19
  Граничный объект (англ, boundary object) – промежуточный артефакт, эффективный для передачи между группами для качественного взаимодействия. Компактный, понятный сторонами, но обладающий достаточной свободой интерпретации для более эффективной обработки получателем.


[Закрыть].

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

Табл. 2.3. Роли участников в разных циклах

Владелец продукта часто привлекает к работе в цикле открытия различных экспертов. Например, для декомпозиции и оценки объема работ инициативы – специалиста из команды разработки, для выравнивания видения образа результата – стейкхолдеров и внешних экспертов из других подразделений. Таким образом, можно говорить о виртуальной команде открытия, которая создается для проработки инициативы перед запуском. В этом случае владелец продукта, разработчики и стейкхолдеры постоянно могут сочетать в себе две роли – открытия и поставки (табл. 2.3).

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

Из хороших практик можно выделить трехэтапную модель цикла открытия:

1. Концепция. На этом этапе формируется краткое описание бизнес-идеи. Для эффективной генерации и обсуждения гипотез описание регламентируют, фиксируя его обязательные атрибуты, например: сегмент пользователей, проблема сегмента, возможные решения, поток доходов, поток расходов и прочее. За основу часто берется модель «бережливый холст» (Lean canvas) или ее предшественница «холст бизнес-модели» (Business model canvas) Александра Остервальдера. Описанные идеи обсуждаются со стейкхолдерами, и в случае веры в успех выделяются ресурсы для дальнейшей проработки концепции и превращения ее в гипотезу.

2. Гипотеза. На этом этапе производится анализ инвестиционной привлекательности инициативы – изучаются потенциальные конкуренты (конкурентный анализ) и их бизнес-показатели (бенчмаркинг). Определяются потенциальные бизнес-показатели инициативы – сроки прибыльности и окупаемости, потенциальная доходность. Для того чтобы уменьшить риск ошибки, в продуктовом подходе принято выделять пилотную фазу (MVP), которая позволяет, рискуя только частью бюджета, определить инвест-привлекательность. Для MVP также оцениваются бюджет и сроки и, главное, опережающие индикаторы, позволяющие как можно быстрее определить успех проекта. Формулируются гипотезы пилотного проекта – критерии, по которым принимаются решения о дальнейшем развитии или приостановке инициативы.

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

Более подробно этапы цикла открытия будут рассмотрены в главе 4.

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

Глава 3
Цикл поставки

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

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

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

Начали появляться новые подходы к разработке, такие как Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming и многие другие. Эти подходы, в свою очередь, черпали вдохновение в других быстрых практиках начиная от бережливого производства и заканчивая практиками армейской подготовки.

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


[Закрыть]). Основная идея этой концепции – короткие циклы поставки. Важно обратить внимание, что ключевое слово здесь «поставки». Подразумевается, что не реже чем раз в месяц жизнь пользователей становится лучше.

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

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

Побочным эффектом становится необходимость отслеживания всех промежуточных артефактов. На инвентаризацию уходило очень много времени, при этом было очевидно, что половина артефактов безвозвратно утратила актуальность, но они все равно мешались в бесконечных колонках Trello. Позднее мы узнали, что такой подход называется Scrum-fall: Scrum + Waterfall, и обычно он порождает массу проблем с производством и культурой – команда разделяется на этажи, каждый занят своим артефактом и не ориентирован на заботу о результате и пр. Я помню это удивительное чувство освобождения, возникшее, когда мы перешли в режим, в котором все делают все в одном спринте. Артефакты порождались и утилизировались в спринте и их не нужно было учитывать. Команда работала сообща и принимала решение о необходимости артефакта и качестве его проработки, а самое главное, от идеи до релиза проходило две недели.

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

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

Такой карго-культ[21]21
  Карго-культ – попытка добиться эффекта процесса за счет внешнего копирования без понимания сути. Последователи меланезийского культа самолетопоклонников внешне точно копировали атрибуты аэропортов из соломы и веток, чтобы привлекать самолеты с грузами.


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

Более подробно о гибком подходе Agile и лучшем известном способе организации цикла поставки Scrum будет рассказано подробнее в п. 3.1 и 3.2.

3.1. Agile

Практики Agile во многом контринтуитивны. Достаточно легко можно себе представить, как в изолированной компании зарождается водопадный подход, сводя к минимуму вероятность, что скопированный по образу и подобию гибкий фреймворк[22]22
  * [21] Фреймворк (англ, framework) – набор правил и ограничений для достижения целей команды. Не является методологией, но позволяет выработать методологию в процессе.


[Закрыть] типа Scrum приживется.

Тем не менее, как было описано ранее, молодые компании начали двигаться в сторону альтернативных подходов к разработке. Через некоторое время, на встрече 17 независимых практиков новых методик программирования 13 февраля 2001 года, был сформулирован свод общих принципов гибких подходов – манифест Agile (Agile Manifesto).

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

Табл. 3.1. Agile-манифест

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

Такая же картина и с внедряемыми инструментами. Первичная цель внедрения – это повышение эффективности, которая, в свою очередь, прочно связана с качеством опыта сотрудника (англ, employee experience, сокр. EX). Если в процессе использования инструмента создается ощущение несправедливости или пустой траты времени, то стоит задуматься о его замене или отмене.

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


[Закрыть]. Когда команда только запускалась, не было конкретных инструментов для отслеживания задач, команда работала, перемещая физические стикеры по Kanban-доске[24]24
  Kanban-доска – инструмент, использующийся в бережливом подходе для визуализации этапности прохождения артефактов. Подробнее в п. 3.1.3.6.


[Закрыть]. Через некоторое время команда внедрила диспетчер задач, и стало уходить заметно больше времени на ежедневные стендапы[25]25
  Daily standup meeting (сокр. DSM) – ежедневная короткая встреча для синхронизации статусов и планов, подробнее в п. 3.2.3.


[Закрыть], так как приходилось тратить время на настройку и оперирование инструментом. Также часть времени уходила на «нарезание» задач на спринт. Потом, после очередного тренинга, команда начала делать очень короткие спринты и дробить функциональность на небольшие элементы (пользовательские истории[26]26
  Пользовательская история (англ, user story) – способ описать элемент функциональности от лица пользователя. Шаблон описания: «Я как [тип пользователя] могу [новая возможность], чтобы [ожидаемый результат]».


[Закрыть]) размерностью менее одного дня разработки. На неделю спринта выходило 5–6 таких элементов, которые команда всем скопом каждый день доводила до релиз-кандидата[27]27
  Релиз-кандидат – версия приложения, развернутая в тестовой среде и максимально готовая к релизу в конце спринта.


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

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

Условно документацию, участвующую в разработке ПО, можно разделить на три группы:

1. Проектная – создается до запуска разработки для описания образа результата.

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

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

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

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

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

1. Сокращение горизонта планирования, покрытого документацией. Как уже говорилось ранее, чем больше срок планирования, тем больше вероятность, что часть планов будет не реализована. От 20 до 40 % годичных стратегических планов теряют актуальность, например, в связи с изменением технологического, бизнес– или регулярного ландшафта. Еще 20–30 % не реализуется по причине ошибок прогнозирования и культа амбициозности. Следовательно, чем меньше горизонт планирования, тем меньше вероятности сделать лишнюю работу.

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

3. Использование формата пользовательских историй при описании функциональных требований. Формат пользовательских историй (можно услышать юзерстори) позволяет описывать функциональность системы от лица пользователя. Это дает возможность бизнес-заказчику фокусироваться на финальном артефакте и оставлять промежуточные на усмотрение команды разработки. Формат отвечает на вопрос «что нужно сделать» и позволяет ответить на вопрос «как это сделать» разработчикам, выбирая при этом оптимальные способы и инструменты. (Подробнее о формате пользовательской истории см. в п. 3.2.4.1.)

Сокращение объема технической документации

1. Автоматически генерируемая документация. Нужно отдавать предпочтение решениям, которые позволяют генерировать документацию автоматически на основе структур кода. Например, фреймворк разработки[28]28
  Фреймворк разработки – набор кодовых библиотек, инструментов и договоренностей, увеличивающий эффективность написания кода.


[Закрыть] типа FastAPI позволяет из коробки автоматически генерировать документацию для интеграции потребителями сервиса. С появлением больших языковых моделей[29]29
  Большие языковые модели (англ. Large Language Models, LLM) – генеративные модели машинного обучения, создающие текст по текстовому запросу. Получили массовую популярность с появлением chatGPT.


[Закрыть] набирает популярность генерация документации на основе ИИ. Например, GitHub Copilot экономит время разработчиков на описание кода, отправляемого в репозиторий.

2. Pull-документация. Тут применяется принцип втягивания вместо вталкивания. Часто бывает, что документация пишется про запас, и, если сделать замеры, можно увидеть, что часть документов генерируется впустую. Принцип вытягивания подразумевает, что документация генерируется по запросу. При этом современная документация – это не обязательно текст. Более эффективно и наглядно по времени может быть записать скринкаст[30]30
  Скринкаст (англ, screencast) – трансляция экрана.


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