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

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

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

В моей практике был забавный случай, когда я пришёл на новый проект, где вроде бы были проблемы с оценками, и поэтому случился кризис. Когда я стал разбираться, то выяснилось, что изначальные оценки были сильно уменьшены, так как заказчику они показались большими. И параллельно объём требований увеличился в десять (!) раз. После такого адекватность самих изначальных оценок можно было и не проверять. Там могли бы быть случайные числа, на “успех” проекта это не повлияло бы.

В общем, все эти, показавшиеся мне очевидными, рассуждения об оценках я убрал. Но, возможно, я был неправ. Если вам не хватает информации об оценивании задач и проектов, напишите мне, пожалуйста, о том, что именно вам хотелось бы знать: borisovke@gmail.com.

Но один момент в оценивании необходимо упомянуть, так как я часто вижу, что его игнорируют и попадают в беду. Важно понимать, что оценка – это субъективная величина. Про это легко забыть, когда смотришь на результат оценки в долларах. Кажется, что если проект оценён в $1’000’000, то это объективно. Ведь величина бюджета – это объективная величина! Как будто у нас есть некий мешок работы и мы его взвесили. Всё точно!