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

Я спросил у аудитории, правда ли это. Многие кивнули. Несколько человек аплодировали.

Я спросил у scrum-мастеров, донесли ли они проблему до руководства. Они сказали, что сообщали об этом, но им приказали молчать.

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

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

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

Однажды мне позвонил старый друг. Он работал над крупным журналистским проектом, который проводили по всей стране и в котором участвовали десятки репортеров и редакторов. И он не мог продвинуться. Как и весь проект. Для некоторых задач им нужны были подтверждения, но получить их не удавалось. Вице-президент был занят. Он не отвечал на электронную почту. Или говорил: «Скажите scrum-мастеру, что я этим займусь, а сейчас мне нужно быть на важном совещании».

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

Решайте возникающие проблемы. Хотя бы начните ими заниматься. Покажите людям, что вы делаете для решения проблем. Так вы очень четко даете понять, что обязуетесь стать scrum-компанией.

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

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

Ведущий владелец продукта в Scrum Inc. Патрик Роуч описывает это так: «Вы направляете экспедицию в неизвестность, и успех предприятия будет зависеть от вашей стратегии действий. Выживание зависит от вашей способности вдохновлять творчество в тех, кто вокруг вас, иначе вы неизбежно потерпите фиаско. Это головокружительная роль, которая может повлечь тяжкие последствия». Причем очень тяжкие.

Одно из самых грустных зрелищ, которым я был свидетелем, – ситуация, когда очень хорошие люди выполняют по-настоящему невероятную работу и очень быстро, но заняты неправильным делом. Или действуют неправильно. Приведу два примера. Nokia Mobile всего за несколько лет прошла путь от лидера индустрии до полной несообразности. При этом у нее были очень хорошие scrum-команды. Быстрые. Даже был Nokia-тест, который определял, гибкие вы или нет, с помощью вопросов, например: «Сколько длится спринт в вашей организации? У вас есть владелец продукта? А диаграмма сгорания задач? У вас есть приоритизированный бэклог?»

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

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

Подлинной причиной успеха того проекта стала отличная группа владельцев продуктов, которые сосредоточили все свое внимание на том, чтобы поставить нужный бэклог в нужное время. Они не позволяли отвлекаться на работу, не прописанную в бэклоге. Владельцы продукта несли ответственность за каждый спринт. Они периодически присылали мне диаграмму сгорания задач за весь проект. Задачи сгорали практически идеально, компания должна была добиться своей цели в нужный день. Ей это удалось. К Черной пятнице они полностью перешли на новую систему: 600 транзакций в секунду, время отклика 50 миллисекунд, коэффициент использования 99,9 %. Теперь они могли обновлять модель защиты от мошенничества незаметно для пользователей. Это сэкономило им 38 млн долларов в год. А за счет отказа от услуг посредника они сэкономили еще 40 млн. Вот на что способен отличный владелец продукта.

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