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

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

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

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

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

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

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

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

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

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

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

Предположим, вам нужно принять решение. Вы договариваетесь о совещании. Допустим, на встрече двадцать человек и решение принимается за час. Спросите себя: во сколько оно обошлось? Посчитаем стоимость одного только времени: сколько денег вы потратили за час. А теперь посчитаем все бесполезные совещания, которые прошли у вас на этой неделе.

Мой друг раньше работал в университете из Лиги плюща. Иногда он говорил мне, что приходит на совещания, даже не зная, зачем он там. А если и знает, то совещания длятся вечность. Упражнения ради мы решили посчитать. Каждая встреча, по нашим выкладкам, стоила около тысячи долларов. За ту неделю он был по меньшей мере на десяти – пятнадцати совещаниях. Делаем выводы.

На деле все даже хуже: решения, которые принимаются на совещаниях, с высокой вероятностью будут отклонены. По данным Standish Group, так происходит более чем с 40 % подобных решений. Предположим, решение принимается за одно совещание и мероприятия проходят раз в неделю. За неделю первое решение уже начинает внедряться, а каждый из тех, кто его принял, передумал. Принимается новое. Это не только потеря недели времени, но и переделка всей уже выполненной работы. Все равно что копать ямы и тут же их засыпать. Сизифов труд.

Согласно исследованию Standish Group, это случается по двум причинам: из-за тех, кто был на совещании, и тех, кого там не было. Решение, к которому приходят в комнате, обычно принимается самым громким человеком в аудитории. Он бульдозером едет по всем, кто стоит на пути. И когда совещание закончено и люди возвращаются к своим рабочим местам, они порой говорят: «Хм, по здравом размышлении я не вполне согласен с тем решением. На следующей неделе подниму этот вопрос».

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

По словам Джима Джонсона, каждый раз проект становится на день ближе к провалу. Каждый день задержки повышает вероятность неудачи. По дню за раз: медленный марш к катастрофе.

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

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