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

Если вы внимательно читали предыдущую главу, то у вас в голове наверняка царит неразбериха: “Что же является расширением скоупа проекта? Какие просьбы заказчика нужно выполнять без вопросов, а за какие требовать дополнительный бюджет?”

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

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

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

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

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

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

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

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

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

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

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