Джей Сазерленд - Scrum на практике. Высокая продуктивность и результаты – прямо сейчас

Дейв Слейтен – один из заклинателей владельцев продукта в Scrum Inc. Один из тех неудержимых людей с вкрадчивыми голосами. Он видел смерти многих компаний, почивших из-за плохого владения продуктом, и поэтому решил разработать набор инструментов, который поможет исправить ситуацию. Я хотел бы поделиться с вами той его частью, которую считаю наиболее важной в жизни владельца продукта: что не нужно делать.

Дейв проводит упражнение, которое называет картой синхронизации. Я же – «стеной боли». Дейв для начала просит владельцев продукта покинуть комнату (ведь они должны проводить с командой только половину своего времени) и записывает самые важные задачи для команды. Как только владельцы продуктов ушли, он просит членов команды записать, над чем они на самом деле работают. Затем он приглашает владельцев продуктов обратно к командам и просит их сравнить записи. Б о льшую часть времени, по словам Дейва, команды действительно работают над какой-то из приоритетных задач. Но очень важно учесть то, что они делают из задач с низким приоритетом. Тех, которые никому не нужны.

Исправление очень простое, уточняет Дейв. Научите владельцев продуктов иначе думать об элементах бэклога. Необходимо четко определить, что нужно в точно определенное время обозначить минимальную доставку, как называет это Дейв. Если элементы бэклога записаны верно, записи владельца продукта и членов команды полностью синхронизированы. Это упражнение помогает связать владельца продукта с командой, поскольку подчеркивает важность четких критериев соответствия, которые пишутся специально, чтобы ответить на простой вопрос: «Я знаю, что это сделано, когда…»

Как объясняет Дейв, добротные критерии соответствия «не говорят команде, что ей нужно сделать», но проясняют, «чего ей делать не нужно». Решать, что не нужно делать, гораздо важнее, чем определить, что делать. Создавайте только то, что нужно прямо сейчас. В этот спринт. Не пытайтесь все сделать сразу.

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

Внутри этого безликого здания находилась безликая переговорная комната, примечательная только размерами. Она была огромна. За большим столом в форме буквы U одновременно сидели 30 или 40 исполнительных директоров. Проходило их ежегодное собрание по планированию, где они решали, какими проектами займутся в следующем году. Мне было интересно увидеть, как они станут принимать решения.

Один из главных вице-президентов вывел на экран проектора таблицу с перечнем проектов. Они были не слишком приоритизированы: просто было перечислено то, что казалось нужным. «Основные задачи». Главный вице-президент осмотрел комнату: у каждого из присутствующих за столом имелись куча бумаг и ноутбуки с открытыми презентациями, у каждого были ассистенты, которые периодически им что-то нашептывали. Он сказал: «Хорошо, у нас 500 тысяч человеко-часов в следующем году. Это с учетом сотрудников и подрядчиков. Сара, у тебя первый элемент из списка. Сколько часов, по-твоему, уйдет на реализацию?»

Сара посмотрела в свои бумаги, в ноутбук и переговорила с ассистентом. «Двадцать пять тысяч часов».

Другой вице-президент вмешался: «Разве этого достаточно? Могут быть проблемы».

«Хорошо, пусть будет тридцать пять тысяч».

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

Когда собрание только началось, я уже знал, что команда Сары – независимо от того, сколько людей на самом деле отработают 35 тысяч часов, и того, что они, вероятнее всего, в разных командах по всему земному шару, – скорее всего, доставит тот первый проект. Потому что возле 35 тысяч часов (неважно, насколько это точная оценка) были указаны требования, бюджет и даты.

Мой коллега Джо Джастис рассказал мне еще более дикую историю об – скажем так – «уникальном» способе принятия решений по проектам и бюджету. Он работал с международной производственной компанией, и его пригласили на сессию планирования на следующий год. Она проходила на круизном лайнере. Оказалось, что это алкокруиз. «Подвыпившие люди сидели в танцевальном зале на корабле и напивались, обсуждая приоритеты на следующий год, бюджеты, распределяя ответственность за проекты, – сказал мне Джо. – Безумие. За всем этим не было никакой аргументации. Никакой логики. Никаких данных. Только кучка нетрезвых директоров». И они решали, как потратить сотни миллионов долларов.

Знаете что? Обе эти компании, возможно, делали все, что могли. Поскольку у них не было нужных данных.

Scrum обеспечивает значительные объемы данных: скорость, эффективность процесса, метрики счастья и т. д. Но нужно уметь ими пользоваться. Знать скорость своих команд. Позволить оценивать работу тем, кто будет ее выполнять. Отслеживать прогресс в реальном времени, спринт за спринтом. И если проект начнет отклоняться от курса, вы сразу узнаете об этом и сможете внести коррективы.

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

Пытаясь сойти с этого пути, они создали команду владельцев продуктов, чтобы были те, кто наблюдал бы за происходящим. Они смогли сократить количество продуктов до двухсот в двадцати разных группах. Команда владельцев продуктов на тот момент представляла собой группу ведущих владельцев продуктов, каждый из которых направлял действия ведущих владельцев продуктов в своих группах, где у каждого была своя команда владельцев продуктов, которая независимо работала со своими командами. (В одной из групп было три уровня ведущих владельцев – и да, они часто обращались к человеку на вершине иерархии, как к дроиду C3PO из «Звездных войн» – Chief3 Product Owner.)

Все владельцы продуктов собирались вместе раз в неделю, чтобы посмотреть, на чем они остановились, и поговорить о том, как события повлияли на их приоритеты. Раз в квартал они решали, на что в дальнейшем выделять средства, а на что – нет. Они проводили тщательный анализ каждого проекта, делились гипотезами, подкрепленными данными, которые предоставили их scrum-команды и которые касались того, что те могут доставить, по их собственным оценкам. Финансирование они получали только на квартал. Через несколько месяцев они были вынуждены приходить снова, чтобы показать, что они узнали, с какими проблемами планируют работать и когда выпустят продукт. Только после этого они получали финансирование.