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

Абсолютное большинство аутсорсных проектов ведётся по принципу bodyshop. Компании продают разработчиков заказчику и в управлении проектами не участвуют или почти не участвуют. Это не интересный для менеджера проектов вариант.

Следующая ступенька, до которой уже доходят далеко не все, это Time&Material проекты, когда уже аутсорсер сам занимается управлением проектом, но оплата идёт по отработанным часам. В таких проектах заказчик имеет возможность подходить к бюджету гибко и изыскивать дополнительные финансы при необходимости.

Fixed Price проекты – самые жёсткие. У заказчика есть фиксированный бюджет и в него нужно уложиться при любом раскладе.

Все аутсорсные компании хотят научиться делать Fixed Price проекты (и практически никто не умеет это делать). Дело не в том, что эти проекты дают больше прибыли (хотя это и так). Дело не в том, что успехи в Fixed Price проектах означают высокий профессионализм команд и совершенство процессов (хотя это тоже так). Дело в том, что Fixed Price проекты не могут быть сделаны никак иначе. У заказчика есть некоторый бюджет и требования, которые ему нужно реализовать. Он не может превысить бюджет по соображениям бизнеса. Он готов платить больше, чем он заплатил бы по Time&Material, но ему нужны гарантии, что он уложится в бюджет. Это требование бизнеса. И такие проекты могут получать только те, кто умеет делать Fixed Price.

Я видел достаточно успешных и неуспешных Fixed Price проектов, чтобы утверждать, что секрет их выполнения – это контроль скоупа проекта. Я уже писал в главе “Куда ползёт scope” про те источники превышения бюджета, о которых обычно забывают. Но с Fixed Price проектами описанное там приобретает на порядок большую важность.

Что будет, если менеджер на проекте Time&Material допустит превышение бюджета? Аутсорсер получит больше денег! Потому что, чтобы довести проект до конца, заказчик будет вынужден найти больше денег и компания-аутсорсер получит больше прибыли 6 6 Если превышение будет в разумных пределах, конечно. Иначе у заказчика может не найтись нужного бюджета и он закроет проект. Но аутсорсер всё равно получит свою прибыль, хоть и с недовольным клиентом. . Что будет, если менеджер на проекте Fixed Price допустит превышение бюджета? За это придётся заплатить компании, и она потерпит убытки.

Часто на проектах Time&Material даже ставятся задачи найти какой-то дополнительный объём работы и “допродать” его заказчику. Это фактически управляемый scope creeping. При Fixed Price дополнительные объёмы всегда идут по одной схеме: закончите этот проект качественно и в срок, и мы будем дальше с вами работать.

Подходы эти настолько разные, что я бы даже не рекомендовал одному менеджеру вести одновременно Fixed Price и Time&Material проекты. Потому что нужно иметь совсем разный настрой и по-другому общаться с заказчиком. Конечно, менеджерские навыки там и там нужны одинаковые, но их использование сильно отличается.

Но дело даже не только в настрое менеджера и его квалификации. К команде тоже предъявляются другие требования. Я видел компании, где для менеджеров проводятся тренинги по Fixed Price проектам и ведётся анализ успехов и неудач, но на разработчиков очень редко обращают внимание. А это важно.

Помните ту историю, которую я рассказал в главе “Куда ползёт scope” о разработчике, который прямо не митинге с заказчиком реализовал какие-то требования? Так вот, если бы в проекте Fixed Price такое произошло, то наверняка бы раздался звук чего-то тяжёлого, брошенного менеджером в голову этого разработчика, чтобы вывести того из переговорного процесса. Потому что в bodyshop-проекте такое поведение является желаемым (инициатива полезна!), в Time&Material – иногда терпимым (путает процесс, но работает на удовлетворение заказчика), а вот в Fixed Price – категорически вредным.

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

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