Список ограничений можно продолжать долго. Проще сказать, что скрам не закрывает ни одной функции менеджера. Значит ли это, что менеджеры должны его игнорировать? Ни в коем случае! Я считаю, что сейчас каждый работающий в сфере разработки ПО должен хорошо представлять, что такое скрам и уметь работать с ним. Но относиться к скраму нужно не как к инструменту менеджмента, а как к набору идей, которые расширяют сознание и вырабатывают полезное отношение ко всему процессу разработки.
Для чего нужен Scrum
После предыдущей главы у кого-то, возможно, в голове возникает вопрос: “Ну и зачем этот скрам вообще тогда нужен?!” На самом деле, существование скрама очень полезно для всех.
Во-первых, давайте рассмотрим, почему скрам вообще возник. Скрам объявляет эмпиризм своей основой, то есть он полностью ориентирован на практику. А какая самая заметная черта проектов в IT? Самая заметная черта – это то, что они, в основном, проваливаются.
В соответствии с Chaos Report от Standish Group в 2015м году процент успешных проектов в IT был всего лишь 29% Причём, этот процент мало изменился с 1996го года (тогда он был 27%). Что это значит? По большому счёту, это значит, что менеджмент проектов в IT не работает. Если проект провалился, то это провал руководителя проекта.
С одной стороны, это связано с недостаточной квалификацией менеджеров. Как я уже писал, IT требует нетривиальных знаний и навыков, которых менеджерам часто не хватает (поэтому хорошие менеджеры очень ценятся). Scrum со всей своей практичностью просто отказывается от управления проектами в классическом смысле. Если мы всё равно не можем управлять проектами качественно, так давайте не управлять ими и сэкономим время, деньги и усилия.
С другой стороны, у IT проектов есть особенности, которые иногда сводят на нет усилия даже опытного менеджера. Первая особенность заключается в том, что успех проекта сильно повышается, когда руководство заказчика его поддерживает и понимает цели бизнеса. Standish Group в своих отчётах пишет этот вывод постоянно.
А вторая особенность заключается в том, что маленькие проекты завершаются успехом гораздо чаще, чем большие. Среди успешных проектов 62% было маленького размера и 21% “небольшого” размера (moderate, что меньше medium).
Теперь становится понятней, почему Scrum “работает”. Он во-первых, ограничивает количество людей в команде. А во вторых, требует постоянно актуальный и отсортированный баклог и всегда доступного Product Owner’а, который как раз обеспечивает необходимое участие заказчика в проекте.
Прелесть Scrum’а в том, что он уже является своего рода стандартом разработки. Все заказчики его знают и понимают. Поэтому, менеджеру очень легко пользоваться им как инструментом.
Например, сроки горят и заказчик требует увеличить команду с семи человек до двадцати. Ситуация стандартная и, обычно, менеджеру приходится прилагать много усилий, чтобы отговорить заказчика от этой идеи. А тут можно очень просто сформулировать: “Это противоречит Scrum Guide и может привести к непредсказуемым последствиям. Оно вам правда надо?” Слово “Scrum” для заказчиков является аргументом, потому что они знают, что это Best Practice отрасли . Иногда даже использование Scrum прописывается в контракте. Тогда всё ещё проще.
Или вот тоже распространённая проблема, когда заказчик затягивает с ответами на вопросы команде. Раньше приходилось всю ночь вылавливать заказчика в его часовом поясе и выслушивать какие-то отговорки. А сейчас можно просто отправить грозное письмо: “В соответствии со Scrum для работы команды необходим Backlog с чётким описанием каждого элемента. Сейчас мы такого баклога не имеем. Последствия могут быть любыми”. В кратчайшие сроки заказчик сам выйдет на связь и сделает со своей стороны нужную работу.
Scrum ещё хорош тем, что он сразу устанавливает команду как self organizing, то есть по Scrum команда должна сама за себя отвечать. Обычная проблема, когда разработчики сидят и ждут, чтоб им сказали, “что и как надо делать”, снова отпадает. Мне кажется, это оказывает настолько же мощное воздействие, как активное участие заказчика в разработке. В свою очередь, разработчики получают много возможностей влиять на проект, чтобы сделать его именно таким, каким они хотят его видеть.
Огромной ошибкой, которую я вижу у некоторых менеджеров, является игнорирование Scrum’а. Они назначают Scrum-мастера и устраняются из процесса. У них какие-то свои дела, а разработчики работают по Scrum’у. Так не стоит делать. Это противоречит основным идеям Scrum: прозрачности и ориентации на взаимодействие. Чтобы пользоваться преимуществами Scrum’а, менеджер должен быть его частью.