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

Приоритет – старое слово. Оно появилось в конце XIV в. Французы позаимствовали латинское слово, чтобы обозначить предшествование – тот факт, что одно событие произошло раньше другого. В английский язык оно вошло в начале XV в. и обозначало первоочередность в правах или статусе [16].

Если вы запустите поиск Google Ngram (сервис, подсчитывающий количество использований слова в книгах за последние несколько сотен лет) по слову «приоритеты» (priorities) на английском, то получите следующий результат.

Но до 1940 года множественного числа у этого слова даже не было. Я не уверен на 100 % в причинно-следственной связи, но прослеживается некая корреляция роста современного управленческого движения в послевоенный период с рождением нового слова, которое звучит условно логично и строго, а на самом деле бессмысленно. Мне кажется, это неспроста.

Когда мы со Scrum Inc. приходим в компанию для оценки ее гибкости, то, как правило, обнаруживаем, что около 30 % ее работы выполнять вовсе не нужно. Чаще всего она идет вразрез с целями бизнеса. Остановитесь. Согласно данным Standish Group и нашим наблюдениям, 64 % из оставшихся 70 % задач – работа над функциями, которыми потребитель пользуется редко или не пользуется вовсе. Получается, 75 % сотрудников компании либо активно работают против интересов бизнеса, либо корпят над тем, что никому не нужно. Попробуйте осознать это. Три четверти сотрудников вашей компании не должны заниматься тем, чем они занимаются.

Причина в том, что люди отказываются от приоритизации или не знают, как ее выполнять. (Еще один маленький лингвистический факт: очевидно, слово prioritize (приоритизировать) не утвердилось в английском языке до тех пор, пока бюрократы в правительстве не придумали его в 1950-е и не популяризировали в президентской кампании 1972 года, когда политическим деятелям пришлось выбирать целевые избирательные округа. По данным Оксфордского словаря английского языка 1982 года, это «слово, которое в настоящий момент нетвердо зафиксировано в языке». Очевидно, так же нетвердо оно зафиксировано в практиках сотрудников.)

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

У нас есть множество противоречащих друг другу приоритетов.

Наши команды постоянно переключаются на новые приоритетные задачи.

Все задачи – с приоритетом номер один.

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

В Confirmation.com у каждого были свои приоритеты. Отдел продаж требовал более качественный перевод на японский, чтобы продавать продукт в Японии; маркетинг хотел запустить ребрендинг сайта; руководство занималось вопросами конкуренции. На чем же сфокусироваться продуктовым командам? «Я всегда с нетерпением жду, какие же новые правила прозвучат сегодня», – сказал один из руководителей компании в беседе с Ави Шнейером, руководителем проекта со стороны Scrum Inc. Когда Ави спросил, что главное для компании, ему ответили: «Выполнение работ в срок». Заметьте: срок сам по себе, а не задача, которую нужно решить.

Ави хотел, чтобы они работали над настоящими приоритетами компании. Что важнее всего? Он помог компании увидеть, что без списка приоритетов она все равно что без руля и каждый день выбирает новое направление. И она сделала верный выбор. Это возможно, но требует искренней рефлексии и трудных решений.

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

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

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

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

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