Для чего нужен 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’а, менеджер должен быть его частью.
История про удовлетворённость клиентов
В истории маркетинга есть очень известная байка про компанию Rolls Royce. Я её периодически вспоминаю, но уже применительно к IT.
Однажды в компанию Rolls Royce пришла жалоба от клиента, которая звучала примерно так: “Вы называете свои автомобили лучшими, но их качество разочаровывает. В недавно купленном автомобиле полно явных инженерных просчётов. Наиболее раздражающий – это часы. Их тиканье настолько громкое, что я его отчётливо слышу, даже на скорости в 60 миль в час! Это просто позор!”
Байка не говорит, что ответили на эту претензию. Наверное, как-то помогли клиенту сделать часы тише. Всё-таки ценовой уровень обязывает.
Но зато известно, что именно из этой претензии родился известный слоган компании Rolls Royce: “На скорости 60 миль в час самый громкий шум в салоне – это тиканье часов”. Этот слоган наполняет гордостью работников и привлекает новых клиентов. Этот слоган показывает качество.
Я вспоминаю эту историю каждый раз, когда премию менеджера привязывают к числу жалоб клиентов. Это простой и, вроде бы, объективный показатель, который нужно и полезно отслеживать.
Но каждый раз я задумываюсь, что именно в тех жалобах: возмущение по поводу заваленного проекта или “тикание часов”?
Оценки задач
Я написал несколько глав про оценки: про PERT, про то, как проверять оценки, про оценку рисков. Но меня не оставляло ощущение, что эти главы малополезны и я их убрал из окончательного варианта книги, оставив только пару неочевидных моментов.
На практике я редко вижу проблему именно в оценках. Да, когда проект заваливают, то часто говорят, что промазали с оценкой и надо было заложить побольше буферов. Но обычно так прикрывают неспособность контролировать изменение требований и управлять проектом.
В моей практике был забавный случай, когда я пришёл на новый проект, где вроде бы были проблемы с оценками, и поэтому случился кризис. Когда я стал разбираться, то выяснилось, что изначальные оценки были сильно уменьшены, так как заказчику они показались большими. И параллельно объём требований увеличился в десять (!) раз. После такого адекватность самих изначальных оценок можно было и не проверять. Там могли бы быть случайные числа, на “успех” проекта это не повлияло бы.
