Вехи: неожиданное решение проблем в разработке продукта

Корень многих зол в инженерии — наша сосредоточенность на проектах.

Большинство инженерных организаций сосредоточены на реализации проектов. Вместо этого они должны сосредоточиться на вехах.

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

В этом посте я описываю:

  1. Я рекомендую вам перенять особый вкус вех.
  2. Почему люди отказываются от проектов?
  3. Почему мы на самом деле хорошо разбираемся в вехах?
  4. Квадзиллионы способов доставки на основе вех делают все лучше.
  5. Как перейти на поэтапную доставку?

Возьмите эти вехи и засуньте их

Я использую специальную версию вех, и вам рекомендую. Эти вехи обладают следующими свойствами:

  1. Маленький. Вехи — это одна-три недели работы, не больше. Одна или несколько вех образуют проект.
  2. Высокое качество. Каждый раз, когда вы завершаете веху, оставьте все лучше, чем когда вы начали. Кодовая база и пользовательский опыт не должны ухудшаться. Единственным исключением является случай, когда вы делаете одноразовый прототип. Это сохраняет вашу способность приносить пользу с течением времени. Когда вы закончите с вехой, ее можно будет каким-то образом выпустить. Вы можете решить не выпускать его для всех клиентов, но он должен выглядеть как-то определенным образом.
  3. Понятно. Выберите названия вех, которые сообщают о ценности, которую вы предоставляете. Любой не инженер в компании должен понимать, что делает веха. Мне нравится использовать фразу «[предоставление ценности] с помощью [подхода]». Это касается как инженерной части, так и остального бизнеса. Например: «ускорить результаты поиска на странице со списком, внедрив ElasticSearch». Деловые люди понимают ценность части. Команда инженеров поймет, что мы делаем, из заходной части.
  4. Ценный. Каждая веха приносит пользу. Если вы работаете над проектом со многими вехами, вы должны уметь останавливаться на полпути. Даже если вы не завершите все этапы, вы должны принести пользу.

Для последней части значение может быть

  1. Потребительская ценность
  2. Ценность бизнеса или
  3. Информация.

Акроним для этих атрибутов вехи SHUV.

Зачем использовать вехи? Ну, давайте начнем с разговора о том, почему бы не проекты.

Люди ужасны в управлении проектами

Имею большой опыт управления проектами:

  • Я руководил проектами в течение нескольких десятков лет.
  • Я запускал программы во многих командах и во многих проектах.
  • Я изучал теорию управления проектами. И,
  • Я разработал и написал программное обеспечение для управления проектами.

Управление проектами завораживает. Это создает иллюзию контроля над очень хаотичным процессом.

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

Лучшей альтернативой управлению проектами является управление вехами. Все, что вы делаете, это «заменяете все разговоры о проектах вехами».

Позвольте мне объяснить, почему это простое изменение желательно.

Инженеры, как правило, плохо разбираются в поэтапном проектировании

Инженеры предрасположены к монолитному проектированию и последовательной работе. Опытные инженеры умеют работать поэтапно. Но в инженерных организациях основное внимание уделяется проектированию в горизонтальных слоях.

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

  • Проведите беседу или создайте документ, над которым вы работаете. Дизайнер предоставляет макеты.
  • Согласуйте, как будет выглядеть API, между фронтенд- и бэкэнд-инженерами.
  • Бэкенд-инженеры приступают к работе над API. Они проектируют модель данных, создают операции CRUD, затем добавляют интересную бизнес-логику. Раскручивают для нее новый сервис.
  • Фронтенд-инженеры приступают к работе над созданием пользовательского интерфейса. Они строят его из моков, создавая компоненты для каждой вещи. Делайте это страница за страницей. Смоделируйте бэкэнд, пока он не будет доступен, затем подключите его.
  • Решите неизбежные проблемы между интерфейсом и сервером.

Инженеры полного стека часто строят вещи одним и тем же горизонтально разработанным способом.

Что не так с этим подходом?

  1. Это вообще не инкрементально.
  2. Вся ценность доставляется в конце.

Мы поговорим о лучшем способе сделать это позже.

Дизайнеры также плохо разбираются в поэтапном проектировании

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

Это необходимо. Дизайнеры должны проделать работу, чтобы подумать о конечном состоянии. Но это еще больше смещает вашу подачу в сторону монолитности. Это ловушка!

Менеджеры по продукту думают о долгосрочных конечных целях

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

Эффективной оценки проекта почти не существует

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

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

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

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

Иногда я вижу, как люди преуспевают в строгой оценке. Но это редко бывает системным — обычно в этом преуспевает один человек. И опирается на них. Если они уезжают в отпуск на неделю, их модель никто не может прокормить, и она разваливается. Хотя это отличное умение, для меня это исключение, подтверждающее правило. Подумайте об этом так: если один из двадцати человек может оценить в сложной ситуации, сколько из них могут быть более успешными в менее сложной ситуации?

Проекты часто вредны для людей

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

Это симптомы болезни: за ней стоят проекты.

Люди на самом деле довольно хороши в управлении этапами

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

Управление программами — гораздо более сложный навык, чем управление проектами. Управление проектами — гораздо более сложный навык, чем управление вехами. Почему бы не сыграть в самую легкую игру, особенно когда результаты могут быть намного лучше. Перечислим все эти способы.

Оценить от одной до трех недель работы легко

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

Он анонимный по запросу.

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

Разбивка проекта на этапы позволяет формировать проекты

Когда люди разбивают проект, они обычно разбивают его на технические задачи. Некоторые более опытные команды могут разбить его на пользовательские истории.

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

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

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

Вехи находятся на нужной высоте, чтобы с ними можно было играть.

Есть много способов реализовать способность. Одним из наиболее неиспользуемых аспектов доставки продукта является игра с последовательностью и способом разделения работы. Одним из наиболее ценных способов использования времени является рассмотрение нескольких подходов к созданию проекта.

Мне нравится просить команды придумать три разных способа упорядочить проект. Я прошу их обсудить компромиссы и выбрать лучший.

Компромиссы, которые следует учитывать, включают:

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

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

Компромиссы:

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

Вехи поощряют разделение исследовательских и исполнительных проектов

Вехи помогают разделить результаты на две категории:

  1. Исполнение. Работа, которую можно разбить, и
  2. Исследование. Работа, которая имеет много неизвестных и не может быть разбита.

Это позволяет отделить покупку возможностей от покупки информации.

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

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

В таком случае вы можете попросить команду провести расследование. Результатом вехи может быть презентация или прототип. Команда также должна стремиться предоставить три разных способа последовательности будущих этапов для реализации этой возможности.

Столкнувшись с необходимостью расставить приоритеты по этапу, который предоставляет информацию, менеджер по продукту может сделать рациональный выбор: стоит ли эта информация пары недель времени команды?

Вехи естественным образом способствуют вертикальному поэтапному проектированию

Ранее мы привели пример того, как команды обычно создают программное обеспечение: горизонтально. Это выглядело так:

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

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

  • У вас будет разговор или проектный документ, над которым вы работаете. Возможно, дизайнер предоставляет макеты.
  • Вы будете думать как о полной функции, так и о первой вехе этой функции. Если функция достаточно сложна, у вас есть технический проект для всего этого. Если вы можете делать это постепенно, вы просто разрабатываете следующую веху.
  • У дизайнера есть проект конечного состояния, но он также должен разработать проект только для вехи.
  • Вы сосредоточитесь на первой вехе, которая имеет узко определенное подмножество функций, которые вы можете создать, чтобы обеспечить ценность.
  • Frontend и backend инженеры работают вместе, чтобы создать веху.
  • Бэкенд-инженеры могут не создавать полный API. Они строят то, что необходимо для вехи. Они проектируют модель данных, создают операции CRUD, затем добавляют интересную бизнес-логику. Раскручивают для нее новый сервис. Но они пропускают части, которые еще не нужны.
  • Передние инженеры приступают к работе над созданием пользовательского интерфейса. Макеты, с которыми они работают, тоньше, чем конечное состояние, поэтому они создают более тонкую функцию. Они создают компоненты для каждой вещи. Они могут имитировать вызовы бэкэнд-API в течение нескольких дней, если они не будут выполнены, но когда они это сделают, они должны быть в состоянии быстро предоставить обратную связь и выполнить итерацию с бэкэнд-инженерами.
  • По ходу они демонстрируют свою работу, а в конце вехи у них есть готовый набор работ, которые они могут продемонстрировать вместе.

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

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

Как разбить этапы проекта

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

Приоритизация с помощью вех достаточно хороша

При расстановке приоритетов у вас будет приблизительное представление о стоимости функций на основе количества этапов (для проектов исполнения). Вероятно, вам не нужна такая точность, как вы думаете, для определения приоритетов функций.

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

Как сформулировал Дональд Рейнертсен, автор Принципов потока разработки продукта (одной из моих любимых книг по разработке продукта):

Команды преуспевают, когда они постоянно приносят пользу

Команды, которые приносят пользу бизнесу каждые пару недель, чувствуют себя прекрасно. У них постоянный поток достижений. Работа кажется значимой, когда вы приносите пользу миру. Люди развивают чувство импульса и уверенности, что помогает сплотить команду и развить способность критиковать и улучшать друг друга.

Вехи гибки в том смысле, что изменения кажутся естественными

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

Есть некоторые ситуации, когда вы захотите остановить веху: если что-то действительно срочно. Но если вы сделаете это, вы сделаете сознательный выбор, чтобы понести расходы, связанные с отказом от работы. И это менее вероятно, потому что конец вехи, скорее всего, близок.

Вехи делают проектирование привлекательным и укрепляют доверие

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

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

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

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

Управление вехами легче

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

Доставка на основе проекта против доставки на основе этапов

Как перейти на доставку на основе вех

Переход на поэтапную доставку не особенно сложен. Вы просто начинаете отчитываться о вехах, а не о проектах.

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

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

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

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

Заключение

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

Кроме того, другая вещь, на которой вы можете сосредоточиться вместо проектов, — это результаты. Я за это, но это более сложное изменение, поэтому я считаю его более продвинутым методом. Для компаний, которые привыкли к проектам, переход к вехам не является огромным изменением. Движение к результатам может быть в конечном счете лучше, но это труднее сделать.

Want to Know More About the Author?
If you’re interested in receiving future posts, please subscribe. Also, the latest version of this post will always be available here.
This whole article owes a huge debt to Jim Shore. He introduced the concept of a Minimum Marketable Feature to New Relic. It was the inspiration for this whole post. He has a lot of experience in this realm and the second edition of his book, The Art of Agile Development, has just come out. Donald Reinertsen’s tweet is included in this article, and his book on product development is a master course in the principles behind product development. I’d also like to thank [anonymous VPE] who shared his study on project estimation with me and let me include it here.