Я уже много лет занимаюсь созданием IT-продуктов. Всё это время для себя и коллег собираю метафоры, которые позволяют наглядно показать, как нужно и как ненужно выстраивать работу по созданию ПО.
По мере работы над IT-продуктом мы узнаем что-то новое о рынке и пользователях и за счет этих знаний продукт перестраиваем. В физическом мире довольно сложно постоянно перестраивать, а в IT – это повседневная задача. По мере перестройки системы мы получаем результат, который все лучше и точнее попадает в запросы клиентов, что и приводит нас к прибыли.
Я рассмотрю 5 моих любимых метафор, которые помогают сонастраивать общее видение процесса для команды разработки и заказчика:
Создаем минимально жизнеспособный продукт
Рисование картины большими пятнами
Метод прогрессивного джипега
Fix Time, Fix Budget, Flex Scope (FFF)
Шаг, понятный обезьяне
№1 Создаем минимально жизнеспособный продукт
Первая модель описывает, каким образом мы можем постепенно выдавать пользователю всё более и более полезный для него продукт:
Идея в том, чтобы создать минимально жизнеспособный продукт (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. Они тоже очень полезны и их надо изучать и использовать. Я же взял именно картинку Максима, потому что она сильно наглядней и ближе к жизни.
Метафоры – способ выстраивания коммуникации
Мы с вами создаем ПО, которое абстрактно, это модели в голове всех участников процесса. Поэтому крайне важно находить точные метафоры и договариваться между собой о процессе создания.
Пять метафор, которые я описал, помогают выровнять видение подхода к разработке между командой разработки и заказчиками (инвесторами, владельцами бюджета).
Комментарии (26)
kalbas
21.06.2023 11:31+1Суть в том, что мы даем обещание выдать бизнес-результат к определенному сроку и за фиксированный бюджет, но договариваемся, что объем работы будет "плавающий".
FFF классный. Бюджет фиксирован, время фиксировано и мы просто сдаем в аренду свою команду, которая умеет делать качественно, но когда сделаем MVP не говорим. Кажется это вообще не про создание MVP в его базовом понимании, потому что он нужен ровно для того, чтобы протестировать какую-нибудь гипотезу, и если она не сработает -- то выбросить код без сожаления.
AlexanderByndyu Автор
21.06.2023 11:31FFF и правда не про MVP. Мы по нему делаем довольно большие с ложные продукты, которые уже много лет как ушли от стадии MVP.
Ykkks
21.06.2023 11:31+2Обратите внимание, что в MVP по второму варианту мы полностью выкидываем работающую систему, и делаем вместо неё совсем другую. То есть, это скорее иллюстрация пивота, а не MVP. Далеко не все заказчики и разработчики к такому готовы.
AlexanderByndyu Автор
21.06.2023 11:31Почти так, но иллюстрация подразумевает, что наработки переходят от стадии к стадии и переиспользуются. В реальном мире, конечно, это маловероятно, но в IT такое частенько происходит. Если смотреть на схему, как на работу в физическом мире, то было бы точнее назвать, как вы сказали — каждая следующая стадия это пивот
QtRoS
21.06.2023 11:31+2Кажется на странице какая-то "верстко-бомба" - если долистать до видео в тиктоке, то под ним неконтролируемо растет пустое пространство, скролл уменьшается, мышкой и пальцем не удается обогнать, только кнопкой page down. Воспроизвелось дважды.
AlexanderByndyu Автор
21.06.2023 11:31+1У вас карма настоящего QA :) А вообще я писал статью в редакторе Хабра, так что, возможно, их визивик шалит.
WASD1
21.06.2023 11:31+2[на второй картинке] Основной минус в том, что на самокате неудобно ехать в дальние поездки, он медленный, он небезопасен, он не закрыт от дождя, т.е. он слишком
далек от того, что действительно хочет клиент в итоге. Поэтому у нас
есть шанс на этом этапе клиента потерять.А по-моему на второй картинке основной минус в том, что вы последовательно создаёте 4 разных продукта просто в рамках "создания VMP". Так ещё и вряд ли приобретаете компетенции по ходу дела (вряд ли умение делать велосипеды поможет вам при изготовлении автомобиля).
AlexanderByndyu Автор
21.06.2023 11:31Если взять метаформу физического мира, то это правда будет 4 разных продукта. В IT всё-таки код можно сильно проще переиспользовать и трансформировать.
muradali
21.06.2023 11:31+1Уровень неопределенности бывает совершенно разный. Есть стартап, который нащупал идею, которую никто никогда не думал и не делал в мире, и, с другой стороны шкалы, сложившаяся компания с прописанными бизнес-процессами, которым надо автоматизировать их.
Во втором случае фига там строить велосипед или изобретать колесо? Любой опытный ПМ врубится в задачу за неделю, сняв требования со стейкхолдеров и за вторую неделю набросает кликабельный прототип. После этого можно пилить, 90% не изменится.
В первом случае (стартап) это поиск в мутном болоте непонятно чего, там может быть и колесо сначала, и велосипед. Если в мире не было еще изобретено "колесо" возможно нам нужен первый вариант, чтобы сначала изобрести его, а потом по любому придется собрать тележку без двигателя или самокат и только дальше автомобиль.
Все три варианта применимы в разных ситуациях в разработке ПО.
AlexanderByndyu Автор
21.06.2023 11:31Да, разные варианты для разных "состояний" проекта. Если в уже существующей системе надо добавить "кнопку", то нет смысла идти издалека. Надо просто добавить кнопку. С другой стороны, даже в устоявшемся бизнесе и в давно существующих системах надо сделать нечто, чего в них раньше не было. Тогда подходы с "самокатами" отлично применимы. Я бы за основу брал Cynefin framework, чтобы понимать, как лучше двигаться к решению.
gluck59
21.06.2023 11:31+1Когда я попытался объяснить своему генеральному, что задуманный им большой и сложный проект нужно пилить по MVP-схеме и расписал ее на примере автомобиля, генеральный подумал и ответил: "Хорошо, давай сделаем как ты предлагаешь, только в понятие "минимальный" добавим коробку-автомат, холодильник-бар и массаж в сиденьях".
MarinaNi
21.06.2023 11:31ведь, метафоры не годятся для убеждений, а только для объяснений... К тому же, метафора про MVP очень неточная. У авто, самоката, байка принципиально разные сценарии использования, они закрывают разны потребности. Это как ставить в один ряд гречку и мороженое — мороженое едят не для того, чтобы насытиться.
AlexanderByndyu Автор
21.06.2023 11:31Если на велосипед и самокат смотреть, как на объекты реального мира, то метафора неточная. Если мы говорим про абстракции в IT-продукте, то там вполне одно может перетекать в другое.
AlexanderByndyu Автор
21.06.2023 11:31Я согласен, что для убеждения надо использовать механизмы "продажи" идеи. А вот для синхронизации подхода к разработке уже подойдут эти картинки
dkuzminov
21.06.2023 11:31+1Я использую Cynefin Framework, причем не только на работе. Этот фреймворк объясняет много причин фейлов тех проектов, где с его помощью ничего не анализировали. Например, он объясняет эффект Даннинга-Крюгера, карго-культы, разницу в обучении на своих и чужих ошибках, микроменеджмент. А еще он демонстрирует самую (на мой взгляд) жестокую ошибку софтверной инженерии: смешение анализа и синтеза (исследований и разработки).
AlexanderByndyu Автор
21.06.2023 11:31Круто! Всё понял, кроме последнего. Можете, пожалуйста, расписать подробнее вот эту часть?
> самую (на мой взгляд) жестокую ошибку софтверной инженерии: смешение анализа и синтеза (исследований и разработки)dkuzminov
21.06.2023 11:31+1Инженерия описывается доменом Complicated. Это домен, где у нас есть вся необходимая информация, мы знаем некие хорошие практики, которые гарантировано могут решить задачу при наличии неограниченного времени и ресурсов. Единственное, чего у нас нет -- это понимания, какую из практик предпочесть, чтобы уложиться в имеющиеся ресурсы и выполнить требования. Грубо говоря, мы можем закрыться от внешнего мира в гараже (в библиотеке, на рабочем месте с интернетом), произвести анализ имеющихся данных, а потом начать создавать продукт.
Домен Complex отличается от предыдущего существенным пробелом в знании внешнего мира. Мы уже не можем закрыться в гараже и вынуждены отправиться добывать недостающую информацию, причем методом проб и ошибок. Это тот домен, где происходят исследования: вначале формулируется гипотеза, затем она либо опровергается, либо принимается.
Если взять реальную инженерную разработку (например, постройку моста), то можно заметить, что проектирование не начинается без знания точного места, где его нужно строить, без точных данных о рельефе местности и розе ветров. Тут четко разграничены Complex и Complicated части, и это дает некие гарантии качества постройки.
Теперь перейдем к "software engineering". Я взял это выражение в кавычки потому что в современном мире это стало какой-то "морской свинкой": не всегда про software и редко про engineering. У нас есть комок грязного легаси кода, про который уже никто не уверен, как оно работает. Вместо того, чтобы вначале разобраться, как оно вообще должно работать, мы бросаемся в пекло и наваливаем еще больше грязи. Энтропия возрастает, и мы все больше заняты багфиксом (который принадлежит домену Complex), и все меньше заняты проектированием фич (Complicated). Я даже придумал замещающий термин, "software surgery", поскольку такая деятельность больше напоминает работу хирурга в реанимации, когда присутствует существенная доля неопределенности, и мы вынуждены "вести разведку боем". Только у хирурга нет копии пациента, чтобы произвести повторную операцию с учетом допущенных ошибок; у программистов же есть возможность вначале уточнить проблему сделав прототип, а потом перейти к созданию продукта с учетом новых знаний о проблеме. Только прототип стоит выкинуть, чего современные программисты не делают, отправляя сырую грязь сразу в продакшн.
skris
21.06.2023 11:31А есть ещё контр-метафора, за авторством Карла фон Клаузевица "Нельзя перепрыгнуть канаву наполовину". Не совсем, конечно, про IT, но тоже актуально
AlexanderByndyu Автор
21.06.2023 11:31А это «контр» к какой из метафор статьи? В них же речь идет о полноценном «прыжке», а не половинчатом. В конце маленького прыжка получаем ценность.
Если мы говорим о прыжках, то точнее будет сказать «нельзя перепрыгнуть гору за один прыжок, делай маленькие и смотри вокруг, чтобы понять куда дальше»
skris
21.06.2023 11:31+1Канава закрывается буквой V в аббревиатуре MVP - продукт должен быть живой, т.е работать. До этого - это дно канавы.
Так же как с автомобилем, без колёс, трансмисии и двигателя - это дно.
Согласен, что метафора не контр, а скорее дополняет картинки из п.№1 с машинками
FantasyOR
Есть некое лукавство "Если сравнить с первым вариантом, то наш клиент сильно обгонит своих конкурентов" - он не может обгонять т.к. сидит и ждёт пока вы создадите что-то похожее на плохой автомобиль.
Т.е. точка 1 на шкале III равна точкам 3 на шкалах I и II
Т.о. пользователь на шкале I может играться с колесом, видеть что строится шасси, пользователь на шкале II уже отмахал пару сотен км на самокате - велике - мопеде, а пользователь на шкале III сидит и слушает менеджера как он будет обгонять всех на свете, пока инженеры собирают фактически готовый автомобиль
Ykkks
Это вы исходите из предположения, что в первом варианте мы заранее точно знаем, что именно хотим построить, и именно это у нас в итоге и получается. Но в случае разработки так почти никогда не получается — заказчику сложно заранее сказать, что в точности ему нужно. Вот когда он увидит что-то похожее — тогда скажет — то, или не то.
AlexanderByndyu Автор
Отчасти да, но это же только метафора. Как я писал, не каждый клиент встанет на самокат и захочет крутить крутить педали велосипеда. Если вынашиваю такого клиента, то это удача. Он правда может обогнать других.
MikhailZakharov
Мне кажется, чтобы снять вопросы по этой теме надо вначале описания методик указать, что все продукты на ранних стадиях для клиентов типа innovator и early adopter. Никто не будет на 100% пересаживаться на этот продукт, или полностью завязывать свои бизнес процессы. То есть условный клиент ездил на лошади, а мы ему даем самокат. На этот самокат он посадит свою фокус-группу. А на автомобиль перейдет полностью по итогам опытной эксплуатации и доведения продукта.
AlexanderByndyu Автор
Михаил, да, тут много разных нюансов. Я думаю, что по первой картинке можно написать (точнее уже написано) много разных книг. Я скорее хотел дать общее направление мысли, чтобы были варианты при планировании метода создания продукта.