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

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

Типичный наступательный подход в НФЛ

В американском футболе цель состоит в том, чтобы забить тачдаун на другом конце поля. У команды, пытающейся забить гол («нападение»), есть четыре попытки («дауна»), чтобы продвинуться на 10 или более ярдов — если они преуспевают, они получают еще четыре попытки, чтобы продвинуться еще на 10 ярдов. И так далее — до тех пор, пока они не забьют, не перевернут мяч или не пройдут 10 ярдов и не должны будут отправить мяч обратно другой команде.

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

Нарушение без суеты

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

Почему? По ряду причин:

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

и самое актуальное для нас сегодня:

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

Пейтон Мэннинг, бывший квотербек «Кольтс» и «Бронкос», был мастером нападения без толпы и одним из лучших, когда-либо игравших в эту игру. Он знал, что ему нужно делать, и (как я предполагаю) верил, что со всей практикой, которую он и его товарищи по команде проводили в течение года (лет), работая вместе, они смогут выполнять требуемые действия без суеты.

Типичный гибкий подход к быстрой доставке решений

Большинство команд разработчиков программного обеспечения используют «гибкий» подход — в основном это процесс/набор рекомендаций о том, как запускать проекты и выполнять работу. Существует множество вариаций Agile, но для наших целей мы определим следующие типичные части процесса:

  • У команд есть цель — не набирать тачдауны, а выпустить новый продукт или серьезно обновить существующий.
  • Работа разбита на «спринты», обычно продолжительностью 2 недели, и в рамках этих спринтов выполняется ряд задач (или «историй», «проблем» и т. д.). т. е. четыре дауна для перемещения на 10 ярдов и более.
  • До и (обычно) во время спринтов проводятся различные встречи (или «agile-церемонии», такие как «планирование спринта» и «уточнение спринта»), на которых обсуждаются и планируются задачи, например, те, что в НФЛ.
  • Эти встречи по планированию могут быть простыми или сложными, короткими или длинными, в зависимости от степени детализации.

Подход без суеты

Я разработал новый подход с характеристиками:

  • Недельный спринт.
  • Еженедельная демонстрация со всеми заинтересованными сторонами, где показывается прогресс за предыдущую неделю, и на основе отзывов обсуждается план на следующую неделю.
  • Совещания по планированию и уточнению спринта приостановлены или, по крайней мере, сведены к минимуму, где задачи обсуждаются быстро, на очень высоком уровне.
  • Поддерживаются ежедневные «стоячие» встречи (быстрые встречи для обсуждения прогресса / блокирующих вопросов).
  • Ежедневное общение с коллегами/заинтересованными сторонами/пользователями/тестерами через Teams, Slack, электронную почту и т. д. — не нужно ждать запланированных встреч для обсуждения важных вопросов.

Этот подход предполагает следующее:

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

В общем, как и Пейтон Мэннинг с его результативными атаками, командам нужно знать, что делать, и уметь делать это быстро, с минимальными обсуждениями.

Когда это уместно для использования?

Подход без совещаний подходит не для всех проектов, команд и ситуаций. Обычно это подходит, когда:

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

Еженедельная демонстрация является ключевой частью

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

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

это гибкий

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

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

Предупреждения

Подход без совещаний, конечно, не идеален, и вы должны помнить о:

  • Выгорание — движение на высокой скорости — это временный подход, когда времени мало, а не круглый год.
  • Аналогичным образом, дополнительный рабочий день не является частью этого подхода — работать быстро не значит работать допоздна и по выходным. Если команды разработчиков программного обеспечения начинают работать сверхурочно, это показывает, что либо эффективность команды плохая, либо сроки проекта нереалистичны и должны быть изменены.
  • Люди могут рассматривать такой подход как неорганизованный, тогда как верно обратное. На прошлой неделе я обсуждал No-Huddle с коллегой, и он сказал, что «это звучит как подход «на лету», то есть придумывание по ходу дела. Это не так — этот подход подходит, когда вы точно знаете, что делать, и доверяете своей команде, чтобы сделать это.

Ключом к тому, чтобы люди были уверены в подходе, является:

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

Последнее примечание

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

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

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