Планирование поставки программного обеспечения без дорожной карты
Мы прошли половину квартала. Мы с менеджером по продукту сидим в маленьком безвоздушном конференц-зале. Видение, планирование и стратегия кружатся вокруг нас. Ограничения - это факт жизни.
Ресурсов всегда не хватает, времени всегда, работы слишком много. Что самое важное, что мы можем делать? Достаточно ли у нас людей для этого? Как много времени это займет? Что дальше? А когда он будет в производстве?
Но что-то не так. Мы смотрим на «Таблицу». Он имеет цветовую кодировку, аккуратно выложен, красиво отформатирован. Выглядит профессионально. Соблазнительно уверенный.
Есть цвета для определенности, шрифты стили для статуса, даты предполагаемого завершения, даты предполагаемого начала. Но мы боремся.
Мы пытаемся найти место для новых функций. Это трудно. Чтобы добавить работу, нам нужно поставить ее напротив даты. У нас нет другого выбора, кроме как подразумевать, что мы оцениваем дату поставки, когда все, что нам нужно, это визуализировать одну возможную реальность, пока мы планируем некоторые мощности.
Таблица не дает нам достаточного контекста. Как скоро команды смогут работать над чем-то еще? Можем ли мы полагаться на эти оценки или они были всего лишь «пальцем в воздухе»? Свободен ли разработчик встроенных систем, чтобы помочь, или они заняты подготовкой к чему-то, что уже находится в стадии разработки?
Я имею в виду, мы могли бы пойти и спросить их. Но весь смысл запроса активных обновлений электронной таблицы состоит в том, чтобы избежать синхронных прерываний и иметь единый источник истины. Но, пытаясь предоставить что-то для всех, он изо всех сил пытается быть вообще полезным.
«Это не работает, я не знаю, в каком состоянии эта история», - говорит менеджер по продукту. «Мне нужно…»
А потом приходит прозрение, мы оба смотрим вверх и хором крикнем: «Государства, а не свидания!»
Состояния, а не даты
Перенесемся на год вперед. «Таблица» исчезла. Мы заменили ее на «Стену», доску Канбан, отражающую текущее состояние всех наших незавершенных инициатив по продуктам, дизайну и проектированию.
Мы собираемся у стены каждые две недели для быстрого обсуждения «дельты». Работаем справа налево, что-нибудь изменилось? Это место для открытий и согласований. Не место для обсуждения, а место, где можно обнаружить, что обсуждения должны происходить.
У нас есть состояния, а не даты!
И какое-то время я был счастлив. Затем кто-то попросил меня обновить дорожную карту моей команды по Confluence. У меня учащается пульс, что-то начинает дергаться за моими веками, и я обнаруживаю, что подбираю слова очень осторожно и очень осознанно. Я не счастлив.
Это таблица, возвращенная из могилы. Разве у нас не было этой битвы? Разве я не выиграл? Но вот он снова перевоплотился. Другое тело, та же душа.
И когда мое тело и разум готовятся к бою, когда непрошеный протест срывается с моих губ, я искренне задаюсь вопросом, почему это меня так сильно беспокоит? Почему он попадает мне под кожу? Почему я в конечном итоге срываюсь с дорожными картами и датами? Боюсь, что я приобрел «репутацию».
На самом деле, я, возможно, переборщил до такой степени, что однажды наш бывший технический директор отвел меня в сторону и спросил: «Что с тобой случилось, чувак? Похоже, здесь глубокая психологическая травма! »
Да, есть. Совершенно верно. Не люблю дедлайны. Кто делает? Но дело не в этом. Не только это. После глубоких поисков души я заглянул внутрь себя и нашел закономерность.
Слова имеют значение
Это семантика. Это придирки. Само слово «дорожная карта» меня очень беспокоит. Это слово. Но это имеет значение.
Слова имеют значение, когда ваш менеджер по разработке просит вас разработать архитектуру MVC для новой интерфейсной инициативы, и вы делаете это, с гордостью возвращаясь через три дня со страницами диаграмм Visio только для того, чтобы вам сказали: Это не MVC!
«Да, это так», - протестуете вы, дрожа нижней губой. «Я могу показать вам, где об этом говорится в этом университетском учебнике, который я читал, потому что я также заканчивал магистратуру в области компьютерных наук на полставки, в то время как я погружался в архитектурные диаграммы, исключая человеческий контакт и счастье, так что вот архитектура MVC, которую вы хотели. Сэр."
«Нет, нет, нет», - говорят вам. «Я хочу…»
И я опущу остальную часть разговора, потому что важная часть состоит в том, что, когда этот менеджер по развитию закончит объяснять, вы скажете: «Ой. Ой! Ой. Верно. Я понял. В этом есть смысл. Я могу это сделать ».
«Но это не MVC ,, и я бы не потратил три дня, если бы вы использовали правильные слова в начале. Я бы попросил разъяснений, если бы не понял, что вы имели в виду, но я знаю, что означает «MVC», поэтому я не понимал, поэтому нельзя называть это MVC? Потому что это не то ».
Но это битва, которую вы проигрываете, и каждый разговор, который вы ведете с каждым новым сотрудником навсегда, начинается со слов: «Итак, у нас есть архитектура, которую босс называет« MVC », но это не MVC…. Я должен предупредить вас, что любой класс, который заканчивается на «Stack», на самом деле является Очередью ».
Нет больше дорожной карты
Приведенный выше пример был лично болезненным, но потратил только время. Есть и другие примеры. Мы больше не занимаемся обработкой невыполненных работ, мы их улучшаем. Мы должны перестать использовать термины «главный» и «подчиненный», когда говорим о первичных и реплицированных серверах.
Сейчас мы говорим о климатическом кризисе, а не об изменении климата или глобальном потеплении. Это специально. Язык имеет значение. Это действительно очень важно.
Вдвойне хорошо, если ваш язык соответствует вашим намерениям, и непостижимо - представить, что у нас будут правильные разговоры, если мы переработаем слова, которые означают что-то еще.
Это, я думаю, основная причина того, почему я начинаю нервничать, когда слышу, что «дорожная карта» используется для описания того, как современные компании-разработчики программного обеспечения, подобные той, над которой я сейчас работаю, планируют свою работу.
То, что мы делаем - это не дорожная карта. Я волнуюсь не потому, что не хочу оценивать (ну, не только…), а потому, что пытаюсь коренным образом изменить наш разговор.
Дорожная карта. Мы должны перестать использовать это слово. Не потому, что «это не означает то, что вы думаете», а потому, что это так! И я хочу поговорить о другом.
Неудобная правда о продукте (дорожные карты)
Я позаимствовал заголовок этого раздела у Марти Кейгана (автора Вдохновленный), который использовал его в собственной статье, чтобы аккуратно резюмировать, почему дорожные карты, ориентированные на заинтересованные стороны, не работают:
- Большинство наших идей не сработают.
- Даже те идеи, которые могут сработать, скорее всего, потребуют нескольких итераций для правильного воплощения.
Таким образом, мы имеем дело с несколькими уровнями неопределенности. Нам приходится иметь дело не только с технической неопределенностью («Сколько времени потребуется на внедрение?»), Мы должны беспокоиться о том, является ли «это» правильным для создания!
Кент Бек красноречиво выразил это в своих выступлениях 3X: Исследуй, расширяй, извлекай.
Дорожная карта продукта может иметь смысл на этапе «Извлечение», когда вы создали прибыльный продукт, который вы хотите поддерживать, постепенно расширяя его. Но во время фазы «Исследуй» цель состоит в том, чтобы делать много маленьких ставок в надежде получить крупную выплату.
Более того, если мы делаем свою работу хорошо, мы думаем за пределами ближайшего горизонта. У нас в рукаве есть несколько более серьезных идей, которые мы можем опробовать, в зависимости от того, какие из них окупятся, или нет, в зависимости от обстоятельств.
Вышеупомянутый менеджер по продукту однажды заметил мне: «Мне нужна блок-схема, чтобы визуализировать это, а не дорожная карта!»
В этом случае идея прогнозирования развития на целый квартал или более не кажется разумной. Я бы также сказал, что наличие дорожной карты дает некоторую ложную уверенность.
Слишком легко относиться к оценкам как к обязательствам и к работе над созданием функций, которые были проданы, но не существуют. После подписания контракта легко переоценить важность удовлетворения «клиента» - этого единственного клиента - в ущерб гораздо большей потенциальной аудитории.
Не раз я видел команду разработчиков, отягощенную необходимостью поддерживать или дополнять функцию, которая используется только наименьшим процентом клиентов. Или совсем нет.
Иногда это неизбежно. Открытие того, что рынок не реагирует на наши усилия, приходит слишком поздно. Иногда мы действительно обнаруживаем это со временем. Нарушение контракта, связанного с выпуском функции, которую мы больше не хотим создавать, неприятно. В любом случае, даже хуже, вынуждены создавать эту функцию.
Итак, учитывая опасности, зачем вообще иметь дорожную карту? Разве мы не можем просто выбросить это и лучше столкнуться с неопределенностью лицом к лицу? Таким образом, нет опасности, что мы попытаемся продать функции, которые еще не создали. Нет опасности, что мы назначим произвольную дату в качестве «крайнего срока».
Я пытался! Ой, как я старался ...
Когда я представил эти точные аргументы нашему бывшему техническому директору, он с неподдельным любопытством спросил: «Если некоторые из этих функций радикально изменят то, как мы продаем продукт, продвигаем его на рынок и обучаем наших пользователей, как мы все это скоординируем? деятельность?"
Я застенчиво ответил: «Ну… мы делаем оценку снизу вверх и планируем дату, к которой каждый сможет работать».
«В таком случае, - мягко спросили меня, - почему бы нам не сделать это для всех наших текущих проектов и не записать? Таким образом, у всех нас есть документ, на который мы можем указать, и уменьшить потребность в таком большом количестве синхронных статусных встреч? »
«Я согласен с тем, что это только наше предположение, но разве мы не должны всегда прилагать усилия, чтобы знать, как наши проекты отслеживают и транслируют наше текущее понимание? И разве это не лучше, чем все время проводить статусные встречи? "
Звучит так разумно! Возможно, нам нужны состояния и даты. Но если я попытаюсь поместить их в один документ и назвать это «дорожной картой», мы получим неправильные разговоры.
Итак, я хочу сломать это. Я хочу выяснить, какие разговоры мы должны вести, и оттуда мы можем работать в обратном направлении.
Я определил, что, по моему мнению, является двумя ключевыми загадками, которые пытается решить наш собственный стартап, когда мы (ошибочно!) Обращаемся к дорожным картам:
- Как мы узнаем, что сейчас работаем над самым важным?
- Как мы можем отслеживать обязательства по датам, которые действительно имеют значение?
Важное о важных вещах
«Как я узнаю, что продуктовая команда работает над самым важным?»
В этом, казалось бы, простом вопросе есть нюанс. На базовом уровне мы смотрим только на три временных горизонта: «сейчас, потом и позже».
Если мы постоянно переносим самую важную работу, которую мы подали под «позже», в верхнюю часть «следующей» стопки, и всегда выбираем ее с вершины кучи, когда начинаем новую работу, то все, что происходит «сейчас», должно быть самая главная вещь.
Нюанс в том, как мы решаем, что важно. Кому важно? Как мы оцениваем разницу между «важным» и «срочным»? Что произойдет, если мы отложим функцию? Какова «цена задержки»?
Мы также должны понимать, что у работы есть свой импульс. Если нашей компании нужно быстро изменить тактику, мы не хотим бросать на землю большую незавершенную функцию и тратить много усилий (не говоря уже о возникшем техническом долге, связанном с перетаскиванием незавершенного кода), или откладывать на необоснованное количество времени, чтобы завершить функцию, которую мы больше не считаем стратегически важной.
Один из способов представить это - сначала взвешенное кратчайшее задание. Эта концепция исходит от SAFe, что… как я могу быть дипломатичным? … Вряд ли будет разумным реализовать. Именно здесь гибкость и бережливость прекрасно сочетаются друг с другом.
У меня инженерное образование, и я полагаюсь на менеджеров по продуктам, которым я доверяю, чтобы они могли решить, на что они хотят сделать свои ставки, когда мы ищем ценность для клиентов.
Но тогда, когда вступают в силу принципы гибкого программного обеспечения, необходимо убедиться, что работа имеет соответствующий масштаб и сегменты, а технические риски известны.
Тогда мы знаем, где мы можем использовать существующие части продукта, а где нам нужно инвестировать в новую архитектуру или разобраться в запутанном «спагетти-коде», который все стартапы на ранней стадии накапливают в своем стремлении к минимально жизнеспособному продукту.
Но откуда взялась эта работа? Если вы работаете в режиме «исследования», передача решений и функций в группу инженеров извне вряд ли будет хорошей идеей.
Самые эффективные продуктовые компании создадут автономную команду, сосредоточенную вокруг конкретных целей, руководствуясь бизнес-стратегией и видением. Возможно, мы установим OKR. Вероятно, нам следует проверять наш прогресс в достижении этих целей еженедельно или даже ежедневно.
Продукт, инженерия и дизайн будут работать вместе, чтобы выявить потенциальные идеи, которые могут «сдвинуть иглу». Таким образом, они могут формировать задачи, которые мы добавляем к нашему «более позднему» горизонту.
Это не дорожная карта. Марти Кейган называет это невыполненным портфелем возможностей. Команда BaseCamp называет его столом для ставок. Я считаю, что оба этих варианта предпочтительнее дорожной карты.
Но как мы можем это визуализировать, если мы не используем традиционную дорожную карту? Лично я предпочитаю доску в стиле Канбан, которая отслеживает «эпики», в идеале сгруппированные по потокам, целям или темам продуктов.
Это дает нам очень простой способ получить представление о перспективах «сейчас, потом, позже», а также позволяет нам понимать и реагировать на поток работы в нашей организации.
Если вы проживаете в одном доме и у вас достаточно места, вам будет сложно превзойти гибкость и индивидуальность гигантской стены. Мне также нравится ограниченность работы с физическим пространством как естественным ограничением размера колонны и возможность собрать команду, чтобы встать вокруг нее и «поговорить с доской».
Если у вас нет места или ваша команда распределена, выбранное вами программное обеспечение для управления проектами, вероятно, сможет создать доску «эпиков».
Подобный совет может работать очень хорошо, когда представитель каждого бизнес-подразделения и руководители групп регулярно выступают перед ним.
Это упрощает еженедельное «отслеживание изменений», обсуждение рисков и предположений, а также обнаружение скрытых зависимостей между предстоящей работой и другими бизнес-единицами (например, «О, маркетингу нужно будет написать для этого копию перед запуском! »).
Я рассматриваю такой стенд не как место для глубокого обсуждения статуса и взаимозависимостей между отделами, а как место, где необходимо обнаружить, что эти разговоры должны происходить. Результатом должно быть «никаких сюрпризов».
Предостережение заключается в том, что, как и любой «живой документ», его необходимо постоянно пересматривать и использовать, чтобы поддерживать его в рабочем состоянии.
Кроме того, то, что это большая стена, мимо которой проходят все, направляясь к своим столам, не означает, что кто-то действительно будет на нее смотреть. Или поймите, что означает каждая карта, если они это сделают.
Если у вас нет обычного стендапа или асинхронного эквивалента с использованием стены, вряд ли вы заметите какую-либо пользу.
Другая вещь, на которую такая плата напрямую не обращается, - это когда.
Обязательства, а не сроки
Иногда даты не имеют значения, и мы можем доверять внутренне мотивированной команде, которая просто выполнит свою работу, приняв разумные решения о размерах и объеме.
Иногда да.
- Разумно ли для нас попытаться завершить эту функцию вовремя, чтобы представить ее на отраслевой конференции в конце этого года?
- Как внутренняя заинтересованная сторона, как мне узнать, сколько времени у меня будет на подготовку к выпуску функции, например Как менеджер по маркетингу, как я узнаю, сколько времени мне нужно для исходящих сообщений?
- Как управлять разногласиями при ограниченных ресурсах? Если для выполнения высокоприоритетной задачи требуются специализированные ресурсы (например, дизайн, интерфейс, ввод от специалиста по данным), как скоро этот ресурс освободится? Если столбец в нашем конвейере доставки пуст, сколько времени нужно, чтобы перегруженный менеджер по продукту заполнял его?
Я не хочу здесь углубляться в дебаты #NoEstimates. Другие это сделали. Давайте начнем с места доверия.
Моя команда будет полагать, что если мы должны работать в срок, это происходит не потому, что функция была продана клиенту, которого еще не существует. Это не потому, что кто-то думает, что наши разработчики расслабятся и не торопятся, если у них не будет приближающегося крайнего срока. Это не потому, что предположение было заключено в рамку на дорожной карте и было ошибочно воспринято как обещание.
Моя команда будет знать, что если на меня вынуждают предоставить оценки и даты, то это потому, что я получил содержательный ответ на вопрос: «Почему? Какой бизнес-результат изменится в зависимости от моего ответа? » Они знают, потому что я сказал им, что спросил, и я сказал им ответ.
Одним из примеров хорошего ответа на этот вопрос было то, что мы хотели протестировать стратегию продаж, чтобы определить, стоит ли ее придерживаться. Стратегия продаж предусматривала ограниченную по времени «бесплатную пробную версию».
Мы приближались к концу года и чувствовали, что, если бесплатный пробный период упадет на новый год, перебои в работе уменьшат количество и качество отзывов, которые мы получаем.
Работая в обратном направлении с последнего дня года, на который мы реально могли рассчитывать получить обратную связь, мы разработали дату запуска. Нашим вариантом было либо уложиться в дату запуска, либо отложить испытание на месяц.
Будучи молодым стартапом, который беспокоился о «взлетно-посадочной полосе», мы решили потерять месяц, решая, какую стратегию продаж придерживаться, было более рискованным, чем пытаться попасть в очень амбициозную дату.
Мы установили дату запуска и активно определили объем, максимально детально проработав наши требования, отбросив те, которые не подходили, и выбрали несколько сокращений и компромиссов в дизайне, чтобы их достичь.
Мы знали, что если это сработает, мы потратим время позже, чтобы «сделать это правильно». Если не получится, мы все выбросим. Понимая это, мы соответствующим образом спроектировали эту функцию.
Это сработало блестяще, и мы назначили дату запуска с минимальным, но работоспособным набором функций и без работы допоздна или в выходные дни. Как сказал сказочный Тим Оттингер: Нарезка работает, отжим - нет.
Родственная жемчужина от Shape Up - это понятие аппетит. Все мы знаем о железном треугольнике управления проектами. Как говорится: Вы можете прийти вовремя, в рамках бюджета, в рамках…. выберите любые два. "
Toyota смогла доказать, что железный треугольник - это ложь, и те же принципы работают в контексте разработки программного обеспечения. На самом деле мы можем одновременно улучшить нашу скорость, качество и наш продукт одновременно.
«Аппетит» работает путем искусственного ограничения оси «времени», чтобы вынудить принять соответствующие решения по анализу объема работ. Стоит ли использовать эту функцию только в том случае, если ее можно быстро исправить? Достаточно ли это важно, чтобы оправдать переписывание подсистемы?
Аппетит - это способ отразить точку зрения бизнеса на то, сколько времени целесообразно инвестировать, при этом оставляя место для уважения мнения команды разработчиков продукта о том, чего можно реально достичь в течение этого периода времени.
Чтобы понять, насколько реалистичен предложенный объем работ в рамках окна аппетита, необходима хорошая оценка. Оценка трудна. Оценка контекстная.
Слишком часто мы, инженеры, говорим что-то вроде: «Я нашел эту штуку в Интернете, и если она сработает, мы сделаем это за несколько часов. Если нет, то вернемся к чертежной доске, так кто знает? Может, неделю или две? " Примерный временной диапазон «два часа или две недели», вероятно, никому не поможет.
Я согласен с оценкой Shape Up о том, что оценки не отражают неопределенности. Опять же, нам нужны состояния, а не даты.
Shape Up предлагает использовать метафору холма, чтобы отразить эту неопределенность. Как только вы достигнете вершины холма, когда все неизвестные и технические риски будут устранены, вы сможете выполнить то, что Марти Кейган называет обязательством высокой честности.
Итак, немного уступив, я думаю, мы можем иметь состояния и даты. Но мы пока не говорим о дорожной карте. Этот процесс намного сложнее.
Мы говорим об оценке ценности и жизнеспособности элементов в нашем портфеле возможностей, чтобы мы могли брать на себя высококачественные обязательства. Это немного скучно, но, возможно, «конвейер доставки» - хорошая фраза, чтобы резюмировать этот процесс и его почти бесконечные варианты.
Oobeya, может быть?
Дорожная карта понятна, проста для восприятия и легко умещается на одном слайде. Но это ложь.
В этом посте я обсудил альтернативы, которые, как я считаю, приводят к гораздо более здоровым результатам для всех участников. Но у нас больше нет простого документа, которым можно поделиться.
У нас есть OKR, и мы делимся своим прогрессом в достижении этих целей. У нас есть таблица ставок или невыполненная работа, наш конвейер доставки, наш график обязательств. Я не могу представить себе ни одной визуализации, которая охватила бы все это.
Но это напоминает мне попытку предыдущего работодателя, когда мы строили банк с нуля, Обея. Это слово в переводе с японского означает большая комната и было создано производственной системой Toyota. Решающим для управления проектами Oobeya является принцип визуализации работы.
Элементы, которые мы хотим визуализировать, включают:
- Показатели эффективности (наши OKR или KPI, отражающие бизнес-цели); а также
- «Макроплан» (наш конвейер доставки).
Техника Oobeya включает в себя все элементы, которые мы обсуждали в этой статье, и расширяет их еще дальше, привлекая голос клиента, бизнес-возражения и активный мониторинг командного потока.
Помещение регулярно посещается всеми участниками проекта и используется как точка синхронизации для всех действий.
Однако цель состоит не в том, чтобы просто посмотреть на эти элементы, а в том, чтобы использовать их для быстрого обнаружения и устранения любых проблем, рисков или узких мест. Попробуйте сделать это с помощью дорожной карты!
И в этом моя забота об этом слове, этой концепции.
Он предлагает слишком удобный мысленный ярлык, который закрывает наш разум для улучшений, которые мы можем сделать, если отбросим его - сделаем шаг назад - и переоценим результаты, которых мы пытаемся достичь.
