А с другой стороны такая ситуация для меняэто самый главный критерий провала менеджмента. Когда менеджер не видел проблем, а проект в результате провалился, это значит, что проект был фактически неуправляем.
Так что же является новым скоупом?
Если вы внимательно читали предыдущую главу, то у вас в голове наверняка царит неразбериха: Что же является расширением скоупа проекта? Какие просьбы заказчика нужно выполнять без вопросов, а за какие требовать дополнительный бюджет?
Ответ прост: новым скоупом является всё то, что вы смогли продать заказчику как новый скоуп. Нет, я тут не путаю причину и следствие. Вопрос расширения бюджетаэто вопрос продаж. На каких условиях он произойдёт зависит от умения менеджера вести переговоры, а также от заказчика и сложившейся переговорной позиции.
Я видел примеры, когда заказчик пропихивал бесплатно для себя новые требования в бюджет проекта. При этом часто он получал минусов больше, чем плюсов, так как проект в результате не укладывался в срок и приходилось резать критический функционал из-за добавленных плюшек. Я видел и обратные примеры, когда менеджер начинал настоящую войну из-за незначительных правок и заказчик был вынужден отказаться от них.
Здесь нет однозначно правильной для всех ситуаций стратегии. Можете сравнить это с покупкой авиабилета. В одной авиакомпании в стоимость перелёта оказывается включена вкусная еда, вино и приоритет при вылете перед другими самолётами. В другой авиакомпании внезапно дополнительные деньги берут просто за регистрацию на рейс или за выбор места. Конечно, второй билет должен быть гораздо дешевле первого иначе вы будете крайне недовольны. Но даже и задёшево все эти ограничения могут вывести из себя любого.
Именно поэтому мы в бюджет проекта закладываем очень большой буфер на возможные изменения. Мы знаем, что заказчик захочет сделать эти изменения, и отказ будет воспринят как дешёвый сервис. А IT компании работают (или пытаются работать) в области дорогого, а следовательно, качественного сервиса.
Если продолжать аналогию со сферой услуг, то можно сравнить IT разработку с парикмахерскими. В дешёвой парикмахерской вы можете только выбрать стрижку из короткого списка. В дорогой, вы излагаете ваши желания, а мастер вам помогает понять, что именно вам хочется. И параллельно вы получаете чашечку кофе, свежую прессу и хорошую фоновую музыку.
Так и при разработке проектов. Мы включаем в бюджет буфер на то, что заказчик будет вносить изменения в UI, что он будет уточнять и расширять бизнес-логику, что какие-то требования он вообще не сможет нам предоставить и нам их придётся создавать самим. Это всё составляет уровень сервиса, за который заказчик и платит.
Но для менеджера такой подход создаёт дополнительные трудности. Потому что заранее никто не знает, что именно включено в бюджет. Менеджеру надо точно отслеживать, остаётся ли объём задачи в рамках запланированного или нет. А после того, как он решит, что объём превышает план, его ждёт следующая ступенька квестанужно в этом убедить заказчика и как-то решить денежный вопрос.
Это как если клиент в парикмахерской просит дополнительно подровнять брови и к кофе дать шоколадку. Мастеру гораздо проще дать это бесплатно и сделать клиенту приятно, чем отказать и, потенциально, нарваться на конфликт. Но потом этот клиент попросит шоколадку ко второму своему кофе. И в следующий свой визит попросит бесплатную стрижку бровей. Чем дальше, тем труднее будет отказать такому клиенту. Ведь раньше всё было включено.
Так и с проектами. У менеджера есть выбор: либо продемонстрировать клиентоориентированность и гибкость и сделать, что просит заказчик, либо напомнить про бюджет и пойти на потенциальный конфликт. Менеджеры не враги себе, они выбирают простой вариант. Особенно при подходе Time&Material, когда все дополнительные хотелки всё равно будут выполнены за счёт заказчика.
Но когда в парикмахерской клиенту выставляют счёт и он видит, что его шоколадка стоит так же, как и стрижка, конфликт гораздо острее, чем объявленная заранее цена. Бесплатного ничего нет. За всё кто-то в конце-концов заплатит.
То есть менеджеру, чтобы эффективно контролировать scope creep, нужно как чётко понимать, какие работы были запланированы изначально и что добавилось позже, так и иметь хорошие навыки в переговорах/продажах. Однако такая ситуация имеет и плюсы. Если вы имеете мощные переговорные навыки, то некоторые упущения в контроле объёма работ, могут не быть такими критичными. И наоборот, если вы очень хорошо умеете планировать и отслеживать, что делает ваша команда, это даст вам отличные аргументы в переговорах с заказчиком.
История про предугадывание желаний
Однажды я пришёл в новую парикмахерскую. Мне нравится пробовать разные образы, и мне интересно давать свободу мастеру, поэтому стрижку я заказал, как обычно: "На ваше усмотрение, но чем безумнее, тем лучше". Мастер позадавал наводящие вопросы и пообещал сделать стрижку, "как в Омске точно не стригут" и "за эту стрижку из соседнего барбершопа мастера выгнали". Результат мне понравился, но я был немного удивлён. Мастер не использовал длину моих волос, а сделал очень короткую стрижку. Она была довольно сложная в исполнении, но не безумная, как я формулировал, а скорее практичная. Спортсмены и военные что-то подобное носят.
Я спросил у него, почему он сделал именно такую стрижку. Ответ сделал мой день: "Ну ты же программист, вряд ли хочешь сильно с укладкой париться". Мастер при этом улыбался знающей улыбкой, искоса поглядывая на меня, как бы говоря: Здорово я угадал, правда?
И здесь мы видим очень важный момент, с которым менеджеры сталкиваются постоянно. Обратите внимание, что мастер не спросил меня, готов ли я укладывать волосы. Вместо этого он спросил меня, чем я занимаюсь, и сделал выводы. Хотя казалось бы спросить напрямую гораздо проще и безопасней. Можно просто спросить, получить ответ и не рисковать ошибиться. Зачем играть в угадайку?
Ответ прост: людям нравится угадывать. Наш мозг эволюционно приспособлен к тому, чтобы делать выводы из очень невнятных предпосылок. Нам нравится выискивать закономерности и делать предсказания. Этим пользуются художники, выстраивающие композицию. Этим пользуется вся индустрия развлечений, от рулетки до кроссвордов.
В IT мы часто не имеем достаточно информации, чтобы сделать обоснованный вывод, поэтому все, и разработчики, и тестировщики, и менеджеры, и заказчики делают выводы, основываясь на неполных данных, угадывая, вместо того, чтобы знать наверняка. Часто мы угадываем правильно, так же часто мы ошибаемся. В IT очень много рисков и мы научились жить с ними.
Но что точно не стоит делать, так это эти риски преумножать. Если есть возможность уточнить, надо ею пользоваться. Лучше знать наверняка, чем пытаться угадать, как бы нашему мозгу не хотелось поиграть в его любимую игру.
Секреты успешных Fixed Price проектов
Абсолютное большинство аутсорсных проектов ведётся по принципу bodyshop. Компании продают разработчиков заказчику и в управлении проектами не участвуют или почти не участвуют. Это не интересный для менеджера проектов вариант.
Следующая ступенька, до которой уже доходят далеко не все, это Time&Material проекты, когда уже аутсорсер сам занимается управлением проектом, но оплата идёт по отработанным часам. В таких проектах заказчик имеет возможность подходить к бюджету гибко и изыскивать дополнительные финансы при необходимости.
Fixed Price проектысамые жёсткие. У заказчика есть фиксированный бюджет и в него нужно уложиться при любом раскладе.
Все аутсорсные компании хотят научиться делать Fixed Price проекты (и практически никто не умеет это делать). Дело не в том, что эти проекты дают больше прибыли (хотя это и так). Дело не в том, что успехи в Fixed Price проектах означают высокий профессионализм команд и совершенство процессов (хотя это тоже так). Дело в том, что Fixed Price проекты не могут быть сделаны никак иначе. У заказчика есть некоторый бюджет и требования, которые ему нужно реализовать. Он не может превысить бюджет по соображениям бизнеса. Он готов платить больше, чем он заплатил бы по Time&Material, но ему нужны гарантии, что он уложится в бюджет. Это требование бизнеса. И такие проекты могут получать только те, кто умеет делать Fixed Price.
Я видел достаточно успешных и неуспешных Fixed Price проектов, чтобы утверждать, что секрет их выполненияэто контроль скоупа проекта. Я уже писал в главе Куда ползёт scope про те источники превышения бюджета, о которых обычно забывают. Но с Fixed Price проектами описанное там приобретает на порядок большую важность.
Что будет, если менеджер на проекте Time&Material допустит превышение бюджета? Аутсорсер получит больше денег! Потому что, чтобы довести проект до конца, заказчик будет вынужден найти больше денег и компания-аутсорсер получит больше прибыли. Что будет, если менеджер на проекте 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 проектовэто не агрессия и жажда денег, это проявление профессионализма и уважения к заказчику.
История про объединение оценок
Однажды я работал под руководством очень хорошего менеджера, Владимира. И он применял удивительный и эффективный метод оценивания. Когда были готовы требования, он с помощью архитектора выделял высокоуровневые задачи и рассылал команде. Каждый из нас должен был декомпозировать задачи на более мелкие и оценить в часах каждую из мелких задач. Мы, не совещаясь друг с другом, делали эту работу, а потом отсылали ему. А потом Владимир организовывал созвон, где показывая на экране все оценки, собирал общую. Как основу он брал оценку архитектора, Дмитрия, и потом опрашивал всех.
Так, первый пункт Экран ввода данных, у Дмитрия общая оценка получилась 200 часов. Посмотрите ваши оценки, у вас такие же часы получились по подзадачам?
Нет, у меня больше на создание БД. 32 часа вместо 24. Мне кажется мы там провозимся, озвучивал я свои отличия.
Отлично, ставлю 32 на создание БД, Владимир не спорил.
А у меня ещё там есть подзадачка обновление юнит-тестов на 6 часов. Но её Дима, наверное, по другим раскидал, заметил другой разработчик, Алексей.
Хорошо, добавляю задачку на юнит-тесты на 6 часов, Владимир обновлял оценку, пока говорил ответ. Всё по этой задаче? Следующая: Отчёт по премиям.
У меня там на дизайн формы в два раза больше времени
А у меня ещё на экспорт и отправку почты маленькие задачи.
Добавлено, оценка росла как на дрожжах. Двигаемся дальше.
Так мы очень быстро проходили по всем пунктам, выбирая максимальные оценки и добавляя максимальное число задач. Я не выдержал:
Владимир, а почему ты выбираешь максимальные оценки и, не разбираясь, добавляешь задачи в список? Как-то бездумно получается.
Константин, мой опыт показывает, что если кто-то видит какую-то проблему, то он прав, эта проблема обязательно возникнет и мы потратим на неё время. Владимир шёл по задачам, округляя все числа в большую сторону. А это мне ещё все говорят, что я слишком оптимистичен.
Почему Scrum не решает менеджерских задач
Сразу скажу, что я очень уважаю Scrum как философию. Scrum привнёс очень много в индустрию разработки ПО. Достаточно вспомнить хотя бы скрам-митинги, которые сейчас используются повсеместно. И в продуктовой разработке, на которую Scrum ориентирован в первую очередь, результаты его применения очень хороши. Но проблема в том, что Scrum часто позиционируют как средство управления проектами, которым он совсем не является. Да и вообще, как средство управления Scrum вообще рассматривать не стоит. Давайте посмотрим, почему.
Сложность. В официальном The Scrum Guide Scrum определяется как нечто, что легко понять, но трудно овладеть. То есть если у вас Scrum не заработал, то это нормально. Scrum указывает некоторое направление, но совсем мало помогает в достижении ваших целей. Это не инструмент в обычном понимании.
Оценка и планирование. Что хочет знать заказчик, который приходит с некоторым проектом? Ему интересно знать, сколько будет стоить реализация его проекта, и когда будет результат. Какие ответы даёт на это скрам? Никаких. Это гениально, на самом деле, но ответа скрам не даёт. Сейчас даже про story point никаких упоминаний нет.
А как планировать какие-то даты? Если, например, нужно будет код интегрировать с куском, разрабатываемым другой командой, то на какую дату можно ставить эту интеграцию? Неизвестно.
Даже традиционные статистические методы предсказания конца проекта, которые неплохо работают в традиционных проектах (например, статистика багов), очень плохо работают в Скраме, так как он не даёт никаких ограничений на элементы баклога.
От руководителя проектов больше всего требуют конкретные сроки и прогнозы по их выполнению. Скрам тут не помощник.