Константин Борисов - Как хорошему разработчику не стать плохим менеджером

С другой стороны, у 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, про то, как проверять оценки, про оценку рисков. Но меня не оставляло ощущение, что эти главы малополезны и я их убрал из окончательного варианта книги, оставив только пару неочевидных моментов.