Метафоры подходов к созданию IT-продуктов
Я уже много лет занимаюсь созданием IT-продуктов. Всё это время для себя и коллег собираю метафоры, которые позволяют наглядно показать, как нужно и как ненужно выстраивать работу по созданию ПО.
По мере работы над IT-продуктом мы узнаем что-то новое о рынке и пользователях и за счет этих знаний продукт перестраиваем. В физическом мире довольно сложно постоянно перестраивать, а в IT — это повседневная задача. По мере перестройки системы мы получаем результат, который все лучше и точнее попадает в запросы клиентов, что и приводит нас к прибыли.
Я рассмотрю 5 моих любимых метафор, которые помогают сонастраивать общее видение процесса для команды разработки и заказчика:
Создаем минимально жизнеспособный продукт
Рисование картины большими пятнами
Метод прогрессивного джипега
Fix Time, Fix Budget, Flex Scope (FFF)
Шаг, понятный обезьяне
№1 Создаем минимально жизнеспособный продукт
Первая модель описывает, каким образом мы можем постепенно выдавать пользователю всё более и более полезный для него продукт:
Разные варианты создания MVP
Идея в том, чтобы создать минимально жизнеспособный продукт (MVP), с помощью которого мы соберем обратную связь с рынка и, возможно, получим первые продажи.
Представьте себе, что у клиента есть запрос: добраться из Москвы в Санкт-Петербург. Мы взяли этот запрос и начали создавать продукт для перемещения нашего клиента по дороге.
1.1. Первая линия
Здесь нарисован классический вариант, когда мы до последнего не выдаем ценность, т.е. MVP не создаем:
У клиент есть сначала колесо. Ценность для него равна нулю, т.к. никуда он на этом колесе не уедет.
Дальше мы постепенно добавляем детали автомобиля.
Только на последнем этапе пользователь получает готовый автомобиль и может начать ехать.
Не самый хороший подход, потому что слишком долго клиент остается без ощутимой для себя пользы, а значит он может уйти к конкурентам во время ожидания. И вторая проблема — мы слишком долго не получаем от него обратную связь, из-за чего мы можем ошибиться в выборе решения и в итоге выдать результат, который «не попадает» в рынок.
1.2. Вторая линия
Следуя логике создания MVP, мы выдаем решение как можно раньше:
Сначала даем клиенту самокат. Он дешевый, его можно быстро создать, клиент сразу начнет свое движение из Москвы в Питер.
По мере развития продукта и получения обратной связи мы даем клиенту всё более и более совершенные средства передвижения.
На последнем этапе клиент уже едет на автомобиле.
К плюсам можно отнести то, что клиент сразу начинает двигаться к своей цели. Мы сразу получаем от него обратную связь, т.е. держим руку на пульсе его желаний и замечаний.
Основной минус в том, что на самокате неудобно ехать в дальние поездки, он медленный, он небезопасен, он не закрыт от дождя, т.е. он слишком далек от того, что действительно хочет клиент в итоге. Поэтому у нас есть шанс на этом этапе клиента потерять.
1.3. Третья линия
Создаем MVP, который максимально приближен к желаниям клиента как можно раньше:
Мы создаем некое подобие автомобиля, которое удовлетворяет минимальным критериям нашего клиента: безопасность, крыша над головой, можно сидеть, не надо постоянно использовать свои мышцы для перемещения.
Пока клиент едет до Москвы, мы собираем обратную связь и совершенствуем наш продукт, выдавая ему новые версии автомобиля.
Если сравнить с первым вариантом, то наш клиент сильно обгонит своих конкурентов, потому что выехал намного раньше: пока первый клиент сидел в Москве с одним колесом, наш клиент уже ехал к своей бизнес-цели.
Еще одно следствие этого подхода — возможно клиент доедет до Питера до того, как мы доведем наш продукт до финальной стадии. Это значит, что мы быстрее запланированного дадим бизнес-ценность и, возможно, даже не понадобится делать идеальный продукт.
В этом вариант много плюсов, кроме одного нюанса — иногда, чтобы создать первый недоавтомобиль, надо потратить слишком много сил и поэтому этот вариант становится похож на первый без-MVP. Но если правильно организовать работу и «отрезать» всё лишнее, то третий вариант самый эффективный и полезным для бизнеса и клиента.
№2 Рисование картины большими пятнами
Увидел в TikTok очень классную метафору создания картины, которая применима при создании IT-продукта. Мне очень близок такой подход, каждая мысль заслуживает внимания:
Картина в начале не должна быть красивой. Она должна быть правильной в тональном отношении, по размерам и формам. Проверяйте и совершенствуйте пропорции, проверяйте где и какой тон, работая большими пятнами.
Когда у вас готова основа, начинается кропотливый процесс преображения некрасивого рисунка в красивый.
Если картина не получается, то можно пробовать что-то сверх-необычное, то, что вы бы никогда не сделали на удачной картине.
У художника очень наглядко получилось показать подход, который мы можем применить в разработке ПО. Именно так можно создавать IT-продукты: работая большими мазками, заботясь о правильной структуре и внутреннем качестве, постепенно уточняя детали там, где это необходимо.
№3 Метод прогрессивного джипега
Этот метод прекрасно описан у Артемия Лебедева в его онлайн-книге Ководство.
Метод прогрессивного джипега
Слева показано, как изображение загружается сверху вниз, сразу на 100% отрисованное. Можно сказать, что браузер работает «без MVP». Конечный результат мы увидим только ближе к концу загрузки. До конца загрузки, например, нельзя наверняка сказать нет ли внизу песка или большой бабочки.
В варианте справа нам показывают сначала сильно сжатое изображение, видны только основные контуры. Что при таком подходе хорошо для нас, как для пользователей:
Очертания изображения выдают очень быстро, быстрее, чем в левом вариант прогрузится хотя бы треть.
По мере загрузки деталей, изображение уточняется и становится всё более четким. При этом мы сразу видим всю картинку целиком, понимая, что нас ждет в конце.
Метод прогрессивного джипега похож на то, как художник из предыдущего раздела, рисовал картину. Он рисовал большими мазками, постепенно приближаясь к результату.
4. Fix Time, Fix Budget, Flex Scope (FFF)
Изначально идея была описана в книге Getting Real. Суть в том, что мы даем обещание выдать бизнес-результат к определенному сроку и за фиксированный бюджет, но договариваемся, что объем работы будет «плавающий».
При этом за отведенные срок и бюджет мы сделаем максимум из возможного, чтобы довести продукт до бизнес-цели. Возможно, в нем не будет всех-всех функций и, возможно, часть из реализованного будет проработана не идеально, но оно будет работать достаточно хорошо.
Такое «забивание колышков» на бюджете и сроке дает предсказуемость для всей цепочки поставки бизнес-ценности, в которую включен и наш релиз. Все участники большого конвейера могут планировать свои активности, зная, когда получат от нас результат.
Есть много нюансов при таком подходе. Подробно я описал этот подход в статье и рассказывал в интервью у Алексея Пименова, поэтому здесь не буду повторяться. Хочу только отменить, что для меня самое важное в FFF — это возможность фиксировать качество на высоком уровне. Это становится возможным за счет того, что мы можем «флексить» объем работы. Если бы такой возможности не было, т.е. объем работы был бы тоже зафиксирован, то при изменениях в требованиях и изменениях, которые мы получаем по обратной связи, мы бы обязательно жертвовали качеством. Грубо говоря, мы бы говнокодили, чтобы успеть выполнить своим обещания по сроку, бюджету и объему работ.
Фиксируем всё, кроме объема работ
В бюро Горбунова нарисовали классную иллюстрацию про FFF и описали, как они видят этот подход с точки зрения своей работы:
План есть, но по дороге может случится всё, что угодно
На картинке видно, что мы не приравниваем план к обязательству, а скорее воспринимаем его как первый набросок. По дороге может случиться всё, что угодно, но мы, так или иначе, дойдем до цели в обозначенный срок. Методы того, как мы будем доходить до цели, могут выбираться по ходу движения и скорее всего будут отличаться от того, что было описано в плане.
Я очень рекомендую FFF, чтобы договариваться между собой о том, как вы будете вместе приходить к результату, сохраняя высокое качество.
5. Шаг, понятный обезьяне
Напоследок оставил классную метафору от Максима Дорофеева из книги Джедайские техники, где он описал метод рационального фланёра (это из Антихрупкости Талеба) и подход «Тойта»:
Работа на проекте с высокой неопределенностью
Чтобы успешно справляться с делами и проектами, нам необходимы три вещи:
Видение конечного результата
Ближайшее целевое состояние
Следующий конкретный шаг, который можем добавить в список задач.
Нет смысла пытаться сделать так, чтобы в сложном проекте всё стало понятно с самого начала. Всегда есть серые зоны.
Максим пишет, что некоторые люди склонны впадать в «паралич анализа» из-за высокой неопределенности, которая ждет их впереди. Видимо, поэтому айтишники так любят четкие ТЗ и не знают, когда остановиться их уточнять. Поэтому, если ваш проект имеет высокую неопределенность и построить детальный план слишком дорого и долго, то запланируйте ближайший шаг, получите обратную связь от мира (ЖОПП), сделайте выводы и снова планируйте ближайший шаг.
Здесь можно сделать отсылки к циклу Демига и Cynefin framework. Они тоже очень полезны и их надо изучать и использовать. Я же взял именно картинку Максима, потому что она сильно наглядней и ближе к жизни.
Метафоры — способ выстраивания коммуникации
Мы с вами создаем ПО, которое абстрактно, это модели в голове всех участников процесса. Поэтому крайне важно находить точные метафоры и договариваться между собой о процессе создания.
Пять метафор, которые я описал, помогают выровнять видение подхода к разработке между командой разработки и заказчиками (инвесторами, владельцами бюджета).
