Хорошая визуализация помогает объяснять достаточно сложные вещи. Вместо большого количества слов достаточно одной картинки. У большинства консультантов есть свои любимые визуальные метафоры. Михаэль Вильямс в своей статье рассказывает о визуальных метафорах, которые он использует для объяснения принципиально важных моментов в организации работы по Agile.
Когда я учился в школе, я сделал открытие.
Я обнаружил, что я посредственно запоминаю числа, даты и формулы, но при этом фантастически легко запоминаю изображения и истории. Если я нашел способ изобразить что-то визуально, есть хороший шанс, что я запомню это навсегда. Если нет, то увы…
То, что появилось как подспорье в учебе, быстро стало моим стандартным способом усвоения и сохранения знаний. Будь то алгоритмы машинного обучения, статистические концепции или организационный дизайн, визуализации – это огромная часть того, как я интерпретирую и интернализирую мир.
Последние пару лет я занимаюсь с продуктовыми лидерами и продуктовыми командами, пытаясь трансформировать работу больших организаций. Мы говорим о таких вещах, как приоритет коммуникаций, о важности итеративного развития, и о том, как сбалансировать технологический долг с рефакторингом. Когда обсуждаются эти концепции, я рисую свою ментальную модель этой идеи, и она (почти) всегда помогает нам общаться намного эффективнее.
Вот несколько рисунков, которые я использую снова и снова.
Риск и частота релизов
Маленькие, частые релизы безопаснее, чем большие, редкие релизы.
Большинство компаний (особенно крупных) гораздо больше похожи на красную линию, чем на синюю. Они накапливают работу с течением времени, и выпускают релизы лишь изредка. Иногда это происходит потому, что у них есть какая-то технология, которая мешает им выпускать релизы чаще. Иногда это культурная вещь. Но независимо от причины, они не поставляют результат так часто, как могли бы.
Задержки с выпуском увеличивают риск. Существует риск ошибок, риск того, что приоритеты изменятся, и вам придется выбросить код до того, как он попадет в среду эксплуатации, а также риск того, что вы построите совершенно неправильную вещь. Ранняя поставка часто является противоядием от этих рисков.
С небольшими релизами, может показаться, что проблемы у вас случаются чаще. Но эти проблемы будут незначительными и управляемыми, а не большими и уродливыми. Если вы позволите работе накапливаться перед выпуском релизов, то рискуете столкнуться с кратно большими потерями.
Более быстрые выпуски = меньший риск.
Итерации
Итеративные улучшения бьют большие ставки.
Большие ставки – это захватывающе. Это прекрасно, когда возникает большая идея и люди объединяются вокруг нее. Но, как знает каждый, кто пробовал делать что-то новое, довольно сложно сделать это успешно с первой попытки. Большие, негибкие поставки часто вызывают больше проблем, чем они решают.
Чтобы проиллюстрировать эту идею, я люблю использовать метафору гольфа. (Худшими носителями этого заблуждения, как правило, являются большие боссы, поэтому использование гольфа дает мне возможность позлорадствовать).
Представь, что ты играешь в гольф серым, сырым, туманным утром. Ты знаешь, что лунка где-то на востоке, но ты не знаешь точно, где. Чтобы усложнить дело, твой рассеянный ассистент забыл все, кроме одной из твоих клюшек.
Вы бы предпочли играть роль драйвера (большой, мощный, решительный, может с легкостью пробить на большую дистанцию) или путтера (маленький, робкий, может ударить по мячу всего лишь на несколько футов за раз)?
В этой тонко завуалированной метафоре большинство людей выбирают драйвера. Они часами бьют по мячу около ста ярдов за попытку, пытаясь подойти ближе и ближе к лунке. Они перебрасывают его, поворачивают, перенаправляют и пытаются снова. После нескольких десятков попыток большинство людей сдаются, забирают мяч и идут в клуб за порцией утешительного напитка.
Между тем, люди, которые выбирают роль путтера, медленно отбивают мяч в сторону лунки, постоянно внося небольшие коррективы в направление. В конце концов они подбираются достаточно близко к лунке, чтобы ясно видеть ее и дело сделано. Путтер может выглядеть неэффективно в краткосрочной перспективе, но в долгосрочной – гораздо лучше.
В долгосрочной перспективе небольшие, постепенные улучшения продукта – гораздо более эффективный путь к успеху.
Размер бэклога и размер истории
Хороший размер историй означает меньше потерь в работе.
Многие команды, с которыми я занимаюсь, привыкли работать над гигантскими кусками работы. Для таких команд на выполнение одного задания могут уйти недели или месяцы. Это нормально, если приоритеты никогда не меняются, но в гибкой среде приоритеты, как правило, часто меняются (готовность к изменениям важнее следования плану). А когда приоритеты меняются, текущая работа приостанавливается или выбрасывается. Именно так это и должно работать. Команды всегда должны концентрироваться на самых важных вещах. Но вся эта отложенная и выброшенная работа приводит к большим потерям.
Один из способов ограничить потери – контролировать, скорость изменения приоритетов. Если вы когда-нибудь слышали, что “это не относится к нашему следующему спринту”, вы видели этот подход в действии. Блокировка позволяет ограничить потери, но это достигается за счет гибкости. Для большинства команд эта цена слишком высока.
Пятиминутная правка не должна ожидать в очереди четыре недели, проходя через формальный процесс расстановки приоритетов.
Мы можем подходить к снижению потерь с другой стороны. Вместо того, чтобы пытаться остановить изменение приоритетов, мы можем сосредоточиться на том, чтобы сделать изменение приоритетов как можно более безболезненным (Добро пожаловать в мир меняющихся требований, даже на поздних стадиях разработки). Правильный размер истории – фантастический способ достичь этого.
Истории должны быть как можно меньше по размеру, при этом они должны иметь некое собственное ядро, имеющее потребительскую ценность.
Если история слишком большая, при изменении приоритетов, вы вложите кучу времени в работу, которую нельзя будет поставить. Если же история слишком маленькая, то при смене приоритетов у вас останется куча фрагментов работы, которые “сделаны”, но не полезны без дополнительных усилий.
Истории оптимального размера обеспечат вам компактный объем, выполняемой в текущий момент, работы. Уровень риска при этом останется невысоким, а команды – гибкими.
