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

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

Я видел примеры, когда заказчик пропихивал бесплатно для себя новые требования в бюджет проекта. При этом часто он получал минусов больше, чем плюсов, так как проект в результате не укладывался в срок и приходилось резать критический функционал из-за добавленных “плюшек”. Я видел и обратные примеры, когда менеджер начинал настоящую войну из-за незначительных правок и заказчик был вынужден отказаться от них.

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

Именно поэтому мы в бюджет проекта закладываем очень большой буфер на возможные изменения. Мы знаем, что заказчик захочет сделать эти изменения, и отказ будет воспринят как дешёвый сервис. А IT компании работают (или пытаются работать) в области дорогого, а следовательно, качественного сервиса.

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

Так и при разработке проектов. Мы включаем в бюджет буфер на то, что заказчик будет вносить изменения в UI, что он будет уточнять и расширять бизнес-логику, что какие-то требования он вообще не сможет нам предоставить и нам их придётся создавать самим. Это всё составляет уровень сервиса, за который заказчик и платит.

Но для менеджера такой подход создаёт дополнительные трудности. Потому что заранее никто не знает, что именно включено в бюджет. Менеджеру надо точно отслеживать, остаётся ли объём задачи в рамках запланированного или нет. А после того, как он решит, что объём превышает план, его ждёт следующая ступенька квеста – нужно в этом убедить заказчика и как-то решить денежный вопрос.

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

Так и с проектами. У менеджера есть выбор: либо продемонстрировать клиентоориентированность и гибкость и сделать, что просит заказчик, либо напомнить про бюджет и пойти на потенциальный конфликт. Менеджеры не враги себе, они выбирают “простой” вариант. Особенно при подходе Time&Material, когда все дополнительные хотелки всё равно будут выполнены за счёт заказчика.

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

То есть менеджеру, чтобы эффективно контролировать scope creep, нужно как чётко понимать, какие работы были запланированы изначально и что добавилось позже, так и иметь хорошие навыки в переговорах/продажах. Однако такая ситуация имеет и плюсы. Если вы имеете мощные переговорные навыки, то некоторые упущения в контроле объёма работ, могут не быть такими критичными. И наоборот, если вы очень хорошо умеете планировать и отслеживать, что делает ваша команда, это даст вам отличные аргументы в переговорах с заказчиком.

Однажды я пришёл в новую парикмахерскую. Мне нравится пробовать разные образы, и мне интересно давать свободу мастеру, поэтому стрижку я заказал, как обычно: "На ваше усмотрение, но чем безумнее, тем лучше". Мастер позадавал наводящие вопросы и пообещал сделать стрижку, "как в Омске точно не стригут" и "за эту стрижку из соседнего барбершопа мастера выгнали". Результат мне понравился, но я был немного удивлён. Мастер не использовал длину моих волос, а сделал очень короткую стрижку. Она была довольно сложная в исполнении, но не “безумная”, как я формулировал, а скорее “практичная”. Спортсмены и военные что-то подобное носят.

Я спросил у него, почему он сделал именно такую стрижку. Ответ сделал мой день: "Ну ты же программист, вряд ли хочешь сильно с укладкой париться". Мастер при этом улыбался знающей улыбкой, искоса поглядывая на меня, как бы говоря: “Здорово я угадал, правда?”

И здесь мы видим очень важный момент, с которым менеджеры сталкиваются постоянно. Обратите внимание, что мастер не спросил меня, готов ли я укладывать волосы. Вместо этого он спросил меня, чем я занимаюсь, и сделал выводы. Хотя казалось бы спросить напрямую гораздо проще и безопасней. Можно просто спросить, получить ответ и не рисковать ошибиться. Зачем играть в “угадайку”?

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

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

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