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

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

В Fixed Price проектах команда должна понимать всю сложность проекта и очень осторожно действовать с требованиями, оптимизациями, предложениями и замечаниями заказчика.

Тут меня могут спросить: “А как же Agile?! Мы же все такие гибкие и ориентированные на изменения под требования заказчика!” Всё так и есть. Здесь Fixed Price проекты не выделяются. Я успешно делал Fixed Price проекты по Scrum (и это было весело). Но надо учитывать, что высший приоритет заказчика – это бюджет. Любые предложения что-то добавить ведут к необходимости что-то выкинуть. Это можно сделать и реально делается, но надо быть осторожным.

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

Причём, заказчик в Fixed Price проектах абсолютно осознанно сам за объёмом работы не следит. Он ведь специально заплатил вам больше денег, чтобы вы это делали за него. И в контракте его очень точно прописано, что нужно сделать и за сколько. Так что любые улучшения, которые вы предложите и на которые он согласится, будут за ваш счёт.

Жёсткое отслеживание объёма работы в случае Fixed Price проектов – это не агрессия и жажда денег, это проявление профессионализма и уважения к заказчику.

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