Текст книги "Scrum на практике. Высокая продуктивность и результаты – прямо сейчас"

Реальность постоянно меняется

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

Начинается все довольно типично: Том находит дом для перепродажи, обычно в ценовом диапазоне 80–100 тысяч долларов. Затем он собирает свою команду, которая состоит из подрядчиков – как правило, пары генеральных подрядчиков, электрика, сантехника и плотника. Все эти люди могут работать, на кого захотят, но они предпочитают сотрудничать с Томом.

Том и его команда обходят дом и обсуждают, что им нужно сделать, чтобы в дальнейшем продать его. Так они создают бэклог, который вешают на стену дома и разделяют на три колонки с помощью стикеров «нужно сделать», «в процессе» и «готово» (Scrum подразумевает использование очень липких первоклассных бумажек Super Sticky), обсуждая, что включено в каждый элемент (будь то снос стены или реставрация полов), и принимая решения о том, при каких условиях можно перенести каждый стикер из колонки «нужно сделать» в колонку «готово». После того как вид и объем работ становятся понятны каждому участнику, они приступают к делу.

Свою работу они делят на шесть спринтов, каждый из которых занимает неделю. Как правило, в первый спринт происходит снос ненужных конструкций, затем в среднем два спринта занимают работы с электричеством, сантехникой и структурные работы. Еще два спринта уходят на специфические улучшения, а в последний спринт происходит чистовая отделка. Каждую неделю они собираются вместе, планируют работу, которую будут выполнять в следующий спринт, решают, какими будут критерии готовности для каждой задачи, и приступают к работе. Каждый день команда обращается к бэклогу и совместно решает, как выполнить работу, чтобы достичь поставленной цели к концу недели. Конечно, у всех своя специализация, но члены команды знают, что любой успех или неудача общие. В конце недели приходит Том и они проводят обзор спринта, вместе обходя дом и решая, что готово, что нет, как этот спринт повлияет на бэклог следующих спринтов. Может быть, они снесли стену или, как часто бывает при ремонте домов, обнаружили, что задача, которая казалась легкой, на самом деле сложна: например, в перекрытиях поселилась семья енотов или проводка не соответствует нормам. По мере обсуждения готовой работы Том расплачивается с подрядчиками. При подряде строителям обычно не платят до тех пор, пока весь проект не готов. Даже после этого клиенты обычно не торопятся, но Том настаивает на том, чтобы оплачивать инкрементально[11]11
  Инкрементальный – пошаговый, увеличивающийся постепенно. Прим. ред.


[Закрыть] доставленную ценность.

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

Еженедельно после обзора спринта члены команды собираются и обсуждают свою совместную работу. Как электрику и плотнику лучше действовать на следующей неделе? Есть ли лучший способ справиться с неизбежными зависимостями? Зависимость – это когда нужно ждать, пока что-то произойдет или какой-то этап завершится, прежде чем вы сможете продолжить работу. Нечто вроде: «Ой, нам нужно ждать доставки из строительного магазина» или «Он должен доделать свою работу прежде, чем я начну свою». Каждую неделю они используют то, что узнали за предыдущую, чтобы изменить то, что планируют сделать, в зависимости от текущих условий, и то, как они будут работать, в зависимости от потока задач на проекте. Хотя дома в целом схожи, в каждом конкретном случае есть своя специфика.

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

Стоит подчеркнуть важность сокращения количества доработок. При перепланировке дома время и материалы могут стоить очень дорого, например если необходимо сложное восстановление антикварных деревянных конструкций. Такая работа требует привлечения высококвалифицированных мастеров и использования очень дорогой древесины. Однако, выполняя только часть работы, например реставрируя отдельные элементы затейливой потолочной лепнины и показывая ее в таком виде покупателю, они вкладывают небольшое количество времени и денег. Если покупатель скажет: «Я знаю, что настаивал на дубе, но теперь вижу результат и хочу, чтобы вы использовали красное дерево», – будет не так сложно все переделать, как если бы пол уже был сделан полностью. Инкрементальный подход позволяет передумать дешевле. Вы можете реагировать на условия работы – семью енотов из нашего примера – и быстро получать обратную связь от клиентов.

Мы знаем, что работа изменится. Мы знаем, что клиент передумает, когда увидит что-то (вспомните закон Хемфри). Вместо того чтобы сражаться с неизбежными изменениями, Scrum принимает их. На крупных проектах порой целые компании сопротивляются изменениям. Они меняют запросы, и Комиссия по контролю внесения изменений реагирует на это ограничением предложения. И поскольку мы знаем, что все меняется, выходит, они платят людям, чтобы убедиться в том, что потребитель не получит желаемого.

Иди ва-банк или домой

Приведу другой пример: масштабнее, но процесс аналогичен. Компания 3М производит все, от стикеров, респираторов, лент для нанесения дорожной разметки и пленки для тонировки автомобильных стекол до стоматологического оборудования и программного обеспечения для здравоохранения. В 2017 году ее прибыль превысила 30 млрд долларов. Она работает по всему миру. Не исключено, что сегодня вы использовали один из ее продуктов.

В марте 2017 года я провел несколько тренингов в Сент-Поле для сотрудников разных подразделений 3М. Один из них, менеджер Марк Андерсон, выступал в аудитории. Он не смог точно объяснить мне, чем занимался, но спросил, использовался ли когда-нибудь Scrum для слияния и поглощения. Я честно сказал ему, что не слышал о таком применении фреймворка, но не вижу причин, почему это не получится.

Несколько недель спустя я наткнулся на следующий пресс-релиз.

3М (Фондовая биржа Нью-Йорка: МММ) сегодня объявила о том, что заключила соглашение о приобретении компании Scott Safety у Johnson Controls по общей стоимости, составившей 2 млрд долларов. Scott Safety – основной производитель инновационных продуктов, включая системы изолирующих дыхательных аппаратов, приборы обнаружения возгорания и утечек газа и другие устройства, которые пополнят портфель средств индивидуальной безопасности 3М.

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

Без опыта интегрировать поглощение сложно, тем более при подобных масштабах. Нужно учесть операционные вопросы, продажи, зарплаты и кадры, процессы, маркетинг, финансы, исследования и разработки. По моему опыту, самая сложная часть – культура. В существующую корпоративную культуру нужно привнести культуру поглощающей компании. Особенно сложно это при наличии сильных культур в обеих компаниях. В 3М выдающаяся инженерная культура, существующая десятилетиями. Жизни людей зависят от продуктов 3М, которые должны сработать с первого раза и работать всегда. В Scott Safety похожий дух. Средства защиты органов дыхания, датчики тепла и другие устройства для пожаротушения, которые должны правильно сработать с первого раза и работать всегда.

Марк позвонил мне в конце 2017 года, чтобы сказать, что они не только сделали это, но и что все вышло иначе, чем если бы они действовали традиционными методами. Традиционный способ управления проектами в Scrum – каскадная модель. При ее использовании руководители стараются распланировать весь проект до его начала. Собираются все возможные требования – иногда их тысячи. Я видел документы с требованиями, стопка которых, если их распечатать, в высоту достигала метра. Подписывая ее, люди пребывают во взаимно согласованной иллюзии о том, что кто-то действительно прочел все это, и только потом команда менеджеров проекта делит работу на фазы. «Сначала мы сделаем эту часть, – говорят они, – и это займет две недели». И рисуют полосочку в верхней части диаграммы Ганта[12]12
  Инструмент планирования и управления задачами, придуманный американским инженером Генри Гантом. Внешне выглядит как поле с горизонтальными полосами в определенной последовательности, расположенными между двумя осями: по вертикали – список задач, по горизонтали – даты. Прим. ред.


[Закрыть]. «Затем мы приступим к следующей фазе; она займет два месяца». Тут они рисуют еще одну полоску на графике, ниже и правее предыдущей. И так далее. Похоже на очень красивый водопад. Эта цветная диаграмма может тянуться месяцами, даже годами. Я видел такие графики высотой тридцать сантиметров и длиной несколько метров. Они в самом деле бывают произведением искусства. Восхитительно. Но они всегда ошибаются. Всегда. Ведь ничто не идет по плану. Никогда. Всегда что-то случается, и приходится менять график. То, что нужно, не поставляется вовремя. Проект затягивается. А значит, и диаграмма неверна. Но она не может быть неверна. Поэтому компании нанимают людей, чтобы диаграмма выглядела реальной, ведь реальность меняется. Это базовый человеческий недостаток: «Если я хорошо подумаю над этим, я смогу устранить ошибку». Но это иллюзия контроля.

«Scrum позволил нам изменить стратегию, учиться по ходу дела, пользоваться удобным моментом чуть позже, в процессе», – сказал Марк. По его мнению, ключевой стала быстрая реакция и ответ на неизбежные изменения, такие как риски и возможности.

Как же им это удалось? В первую очередь они составили бэклог всех задач, которые нужно решить. Затем определили, какие области компетенций необходимы для выполнения его элементов. Они собрали кросс-функциональную команду владельцев продукта, обладающих нужными навыками: компетентностью в сферах финансов, исследований и разработок, продаж, маркетинга, кадров. Эти группы нужны были для дальнейшей координации того, что должно быть интегрировано, чтобы Scott Safety стала частью 3М.

У каждого владельца продукта была команда. Или команда команд. Марк сказал, что только отделы IT-исследований и разработок использовали Scrum в полной мере. Такой уровень координации все равно оказался крайне важным для проекта. Что было главным? Владельцы продуктов постоянно собирались вместе, чтобы координировать усилия, делиться знаниями, обращаться друг к другу за помощью и изменять приоритет элементов бэклога по мере поступления новой информации. Например, если финансовому отделу нужны были данные по зарплатам, они обращались к бэклогу продукта за полной интеграцией, и каждая команда получала данные о том, что ей нужно сделать, чтобы ее часть работы считалась готовой.

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

Они работали недельными спринтами. Каждую среду они просматривали бэклог, определяли приоритетность задач на следующую неделю, оценивали усилия, необходимые для реализации каждого элемента, который, по их мнению, они могут выполнить за один спринт, и начинали работу. Они не всё делали так, как я рассказывал: отводили на ежедневный Scrum по 15 минут трижды в неделю, а не каждый день. Так, они встречались по пятницам, чтобы сообщить, что все в порядке, затем собирались в понедельник. И каждую среду, прежде чем планировать следующую неделю, они проверяли, сколько работы готово на самом деле из того, что было запланировано.

По словам Марка, результаты его поразили. В первую очередь прозрачность: картина всегда была ясна и очевидна. Можно было точно определить, где работа встала, ведь на доске постоянно и наглядно отражалась вся поступающая информация. Также он сказал, что фокус на скорости вместо надежды на то, что они когда-то все сделают, позволил им ускориться на самом деле.

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

Результат? В первый день все менеджеры оказались на местах, а каждый сотрудник должен был отчитаться. Финансовый отдел отреагировал незамедлительно: никаких проблем с несогласующимися или запутанными прогнозами, все отслеживалось и было прозрачным. Проект запускался глобальный, и HR четко обозначили это. Невероятно сложные взаимосвязанные части крупной интеграции сомкнулись без зазоров. 3М гордится собой как постоянным инноватором не только в части продуктов, но и операций. Насколько мне известно, тогда Scrum впервые использовался для многомиллиардного корпоративного поглощения. Причем успешно.

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

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

Изменения происходят всегда

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

По данным Standish Group, в любом проекте в процессе разработки меняется 67 % требований. Почему? Потому что люди обучаются по ходу работы. Когда мы создаем что-то, то узнаём, что некоторые вещи, казавшиеся важными, на самом деле не так существенны. Нам становится известно, что покупатели, обозначившие задачи и подписавшие пачку требований, на самом деле не были уверены, что меняется рынок и мир.

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

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

Суть в том, чтобы изменения были быстрыми, дешевыми и веселыми. И если не получается – значит, вы что-то делаете не так.

ВЫВОД

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

Обман и «каскады». Сократите риски и повысьте вероятность успеха – таковы обещания традиционных каскадных систем управления проектами. Проблема в том, что они не работают. При планировании каждой детали не учитывается, что нечто неожиданное обязательно случится. Обязательно. Когда вы в последний раз видели диаграмму Ганта, соответствующую реальности?

Scrum 3-5-3. В Scrum всего три роли: владелец продукта, scrum-мастер и член команды. Пять мероприятий: планирование спринта, спринт, ежедневный Scrum, обзор спринта и ретроспектива спринта. И три артефакта: бэклог продукта, бэклог спринта и инкремент продукта, который команда создает за каждый спринт. Это не сложно, но требует дисциплины.

БЭКЛОГ

1. Начните внедрять Scrum 3-5-3 на своем рабочем месте.

2. Кто будет заниматься приоритизацией?

3. Кто будет коучем?

4. Кто будет выполнять работу?

5. Составьте бэклог продукта.

6. Составьте план вашего первого спринта.

7. Вперед!

8. Ежедневно встречайтесь, чтобы координировать усилия и вносить изменения в планы.

9. Сделайте что-то полностью готовое к концу спринта.

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

11. Повторите снова.

Глава 3. Почему мы не можем решить

У вас есть проблема – вы только что о ней узнали.

Это может быть что угодно. Вы создаете что-то и понимаете, что дизайн нужно изменить. Вы наткнулись на то, чего не ожидали, когда планировали работу, и вам нужно решить, что делать. «Мне сейчас решить этот срочный вопрос или подождать и работать над чем-то невероятно важным, что потом станет очень ценным?»

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

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

С кем ее обсудить? Нужно ли ждать, пока соберется комитет для решения проблемы? Есть ли возможность разобраться с ней сегодня или все очень заняты и вам придется отложить вопрос на завтра-послезавтра? Какова будет цена задержки?

Задержка решения

Джим Джонсон, основатель и председатель Standish Group, начал интересоваться этим вопросом несколько лет назад. С 1985 года компания в основном занимается исследованиями работы проектов по всему миру с помощью интервью, фокус-групп и опросов. Мы говорим о десятках тысяч проектов. Она регулярно публикует CHAOS Report, содержащий разного рода данные о том, почему проекты преуспевают или терпят неудачу. График, объясняющий всемирное распространение Agile, выглядит так.

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

Но проясним кое-что: не каждый agile-проект заканчивается хорошо. Компания Scrum Inc. и Джим рассматривали причины, по которым 50 % agile-проектов испытывают затруднения, затягиваются, превышают бюджет или оставляют клиентов неудовлетворенными.

Какова глубинная причина неудачи проекта? Что в scrum-проектах повышает вероятность их успешного исхода? Несколько лет назад, когда Джим брал интервью у главы бюро закупок штата Массачусетс, он понял, в чем дело.

«Он рассказал мне историю, – говорит Джим. – Он работал в городском Совете Бостона. Им требовалось получить решение заместителя мэра, чтобы перейти к следующему этапу проекта. У них было 60 подрядчиков, ждущих решения. Шестьдесят человек в течение шести недель не могли работать. Именно столько заняло принятие решения».

Джим изумился. Наверное, это была исключительная ситуация. Тогда в свои исследования он начал включать вопрос: «Как быстро вы принимаете решения?» И когда он посмотрел на проблемные проекты, то понял, что это не исключение, а распространенная практика. В провальных проектах люди просто не принимали решения. А больше всего Джима удивило то, что в большинстве случаев решения не были невероятно сложными или запутанными. Обычные, повседневные. И их просто не приняли!

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

«Оказалось, – говорит Джим, – данные показывают, что на каждую потраченную на проект тысячу долларов приходится одно решение. Для миллионного проекта вам придется принять тысячу решений». Картинка быстро складывалась. Чем дольше принимать решения, тем дороже они обойдутся, согласно замечательному следствию общей теории относительности Эйнштейна: не только время и пространство – один континуум, но также время и деньги. Так Джим придумал метрику, которая показывает, сколько времени занимает принятие решения, начиная с момента, когда становится понятно, что оно необходимо, и заканчивая моментом, когда оно принято. Он назвал это задержкой решения. Затем он сопоставил показатели со статистикой успешности проектов. Он учел сотни проектов по всему миру. Каковы же результаты? Хуже, чем вы думаете.

Графики показывают конечный результат сотен проектов. Из тех, в которых решения были приняты быстро, меньше чем за час, успешно завершились 58 % (они также уложились во временные рамки и бюджет). Если на это уходило больше 5 часов, вероятность успеха резко снижалась: только 18 % таких проектов работают. Пять часов. Это не так много.

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

«Реакция была очень интересная, – вспоминает Джим. – Сначала они говорили, что такое невозможно, что это не может быть глубинной причиной. А затем немного обдумывали данные, возвращались и сообщали, что я подал им интересную идею».

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

В крупной международной компании, производящей автомобили, с которой мы работали, использовалась японская система согласия под названием ринги. Ее цель – обеспечить согласованность руководства в вопросах принятия решений. Когда кто-то вносит предложение, оно попадает к каждому в цепочке принятия решений; когда все соглашаются с ним и высшее руководство подписывает его, решение принято. Идея в том, что вы должны спокойно фоново работать, чтобы обеспечить согласованность, подготовить почву для предложения. Японцы называют это немаваси, буквально «ходить вокруг корней»: копать землю вокруг корней дерева, прежде чем пересадить его.

Расскажу немного грустную историю о том, как это работает. Предположим, вы трудитесь на автомобильной фабрике в США и хотите потратить деньги на что-то, допустим, оборудование для завода. Хотя деньги на него в годовом бюджете уже предусмотрены, вам нужно сдать ринги – на бумаге. Необходимо подробно и убедительно описать причины того, почему вы хотите потратить деньги. Включить все бухгалтерские данные: сколько вы планируете потратить, откуда поступают средства, кому идут. Повторю еще раз: на бумаге. Затем вам надо провести обзор среды: сколько электричества потребляет прибор, будут ли от него какие-то выбросы. Все это также записывается на бумаге. Стопка бумаг и есть ринги.

Затем их нужно одобрить. Сначала бумаги отправляются центральной группе планирования. Один из инженеров сказал мне: «Они должны проверить документы на ряд параметров, которые мы даже не понимаем». Центральная группа планирования либо отправляет бумаги обратно на доработку, либо одобряет их.

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

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

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

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

Здесь будет два преимущества. Во-первых, процесс станет прозрачным. Сейчас никто не знает, на чьем столе лежат бумаги, никто не может сказать, на каком они этапе рассмотрения. Почти готово? Наполовину? Кто-то держит бумаги у себя по неизвестной нам причине? Во-вторых, при таком положении дел, если вам нужно сделать копию ринги, запущенной несколько лет назад, поскольку вы просите о том же, о чем идет речь в ней, вам нужно найти человека, который ее создал, надеясь, что он сохранил бумажную копию (а он мог и не хранить ее), а затем сделать копию для себя. Переведя это в цифровой формат, они смогут по крайней мере иметь доступ к ринги предыдущих лет и копировать их.

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

«Scrum так изящен потому, что позволяет вывести решения на уровень команды, – говорит Джим. – Для этого нужны только владелец продукта и команда. Тогда стейкхолдерам или высшему руководству не придется принимать много решений».

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

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