Посвящается моему другу у которого на проекте ПМ просрал всё, что можно и их ждёт 2 месяца хардкора и овертаймов.
Problem statement
При выполнении fix price проекта был допущен ряд ошибок, что привело к проблеме со сроками сдачи. В Fix Price проектах определены объем работ (scope) и бюджет, но с течением времени может возникнуть ситуация известная как "scope creep", когда объем работы неожиданно расширяется, в то время как бюджет остается прежним.
Как обычно
Традиционные подходы решения данной проблемы:
Загнобить команду и сделать виноватыми - криворукие багоделы развели багодельню, ничего не могут и не умеют.
Утопить команду в овертаймах, чтобы через несколько недель или месяцев люди напоминали лошадь, загнанную до кровавой пены.
Залить проблему людьми в надежде, что кровавые боги деливери примут жертву и это как-то поможет ситуации.
В результате этих действий между командой и менеджером растёт напряжение и теряется доверие.
Также становится общепринятым, что менеджер проекта подвергает сомнению (или даже отвергает) оценки команды по времени выполнения задач. Это делается в попытке сократить время выполнения и попасть в запланированные сроки.
Типичный диалог между менеджером проекта (ПМ) и командой(К):
К: Мы оценили эту задачу в 120 часов.
ПМ: На фазе дискавери эта задача была оценена архитектором в 40 часов! Мне надо чтобы она была сделана за 40 часов!
К: Но задача на 120 часов.
ПМ: Она должна быть сделана за 40 часов и точка!
На этом этапе полезно остановиться и попробовать понять мотивацию каждой стороны.
Для менеджера проекта ключевая проблема заключается в сроках выполнения задачи. Если задача не выполнена в срок, это означает потерю денег и, возможно, штрафы. Плюс над ним всегда босс (портфолио или програм менеджер, или заказчик) который ставит его в коленнопреклонную позу по той же самой причине - сроки/деньги. Поэтому за сроки и возможность их сокращения ПМ загрызёт всех и каждого в команде (заказчика же страшно).
С другой стороны, команда может видеть менеджера проекта как человека, который не слушает их мнение. Они понимают, что даже если задача будет оценена в 40 часов, это не сделает ее выполнение быстрее.
В этом моменте начинается ключевое задание - найти способ достичь общей цели.
Выполнить проект в срок, без овертаймов и в соответствии с требованиями клиента.
Как надо
Сложность этого задания в том, что нужно работать осознанно и слаженно всем. Вот простой способ для решения этой проблемы:
К: Эту задачу мы оценили в 120 часов.
ПМ: На фазе дискавери задача была оценена в 40 часов. Почему сейчас она выросла до 120? Вы можете мне, пожалуйста, объяснить?
К: Мы декомпозировали задачу она состоит из подзадач А, Б и В. Подзадача А - 40 часов, Б - 40 и В тоже 40 часов.
ПМ: Задачу В мы уже решали в рамках проекта. Мы можем переиспользовать её?
К: Думаю да, но нам понадобится 10 часов на интеграцию.
ПМ: Коллеги, я понимаю, что мы смогли ужать задачу до 90 часов. Но как нам ужать её до 40?
К: Можно выкинуть вот это, это и ещё это. Но кое-что надо утвердить с заказчиком. Но всё равно получается 50.
ПМ: Хорошо. Я постараюсь решить вопрос с заказчиком. Но если вы видите, что мы ещё можем сэкономить 10 часов, дайте немедленно об этом знать.
В ситуации, когда менеджер челенджит команду и подвергает сомнению их оценку нет ничего плохого. Различия в оценке задач между менеджерами и командой разработчиков - обычное явление. Важно понимать, что вызывать вопросы и обсуждать оценку не является негативным действием, если это делается с нужной целью и подходом. Причины могут быть разными:
Усталость команды: когда команда работает над проектом долгое время, её взгляд может стать "замыленным". Иногда нужен взгляд со стороны, чтобы помочь рассмотреть задачу с разных сторон или сподвигнуть к этому на фоне усталости.
Переусложнение задачи: иногда команда может усложнить задачу, стремясь обеспечить слишком высокую совместимость, масштабируемость или иные нефункциональные требования. Здесь менеджер может ограничить уровень сложности и сохранить фокус на основной задаче.
Отсутствие связи с заказчиком: команда может не иметь прямого доступа к заказчику, и поэтому может быть лишена возможности влиять на объем работ. В этой ситуации менеджер может вступить и обсудить, какие функции действительно необходимы, и есть ли возможность сократить объем работы.
Повторение задач: иногда команда может не заметить, что она решает одну и ту же задачу несколько раз. ПМ может помочь, обозначив ранее решенные задачи и избегая повторного выполнения одних и тех же работ.
Завышение оценок. Команда может давать завышенные оценки просто потому, что. Здесь менеджер может помочь, обсудив и выравнив оценки.
К сожалению, это обычная ситуация, когда изначальная оценка проекта оказывается недостаточно точной, а исправлять все это приходится команде. В отдельной статье мы рассмотрим, как избежать подобных проблем для менеджеров проектов.
Я специально не рассматриваю в этой статье проблемы people management'a т.к. это достаточно обширный тема для отдельный статьи и что-то уже из этого я рассматривал в своём личном блоге.
Комментарии (27)
Samedi_Da_Kapa
05.06.2023 09:30+1Не доводить ситуацию до "scope creep" и все что выходит за рамки изначальной договоренности оценивать отдельно и оплачивать дополнительно?
Да не, ерунда какая-то.
LuggerFormas
05.06.2023 09:30+1Проще, проще!
Если заказчик накидывает - пусть платит. Если на "дискавери" оценку провалила команда - пусть тянет на хардмоде, сама виноватая.
ПМ в данном случае должен знать, рукопопы у него или нет и множить, иногда надвое.
Неожиданно бывает, ага...
>> Был допущен ряд ошибок
Кто допустил - расхлебывает.
cupraer
05.06.2023 09:30+5К сожалению, если задача чуть сложнее круда с джейсонами, когда на каждый чих есть готовая библиотека, — команда не сможет оценить сроки правильно примерно никогда.
Mephistophele Автор
05.06.2023 09:30Может, но нужна полноценная фаза дискавери. А вот её-то зачастую не делают.
cupraer
05.06.2023 09:30+1С этой фазой качество задач, для которых можно получить оценку, расширяется, это правда, но и близко не до ста процентов.
Есть вещи — и чем сложнее задача, тем их больше — которые не оценить без работающего прототипа, а в результате оценки — рабочий прототип может оказаться непригодным в принципе.
Почти весь хайлоад, например, такой.
Mephistophele Автор
05.06.2023 09:30Что-то мне подсказывает, что это упирается в понимание NFR + ASR, которые можно и до MVP осознать.
cupraer
05.06.2023 09:30Ну, можно, значит можно. Особенно если уметь ввернуть к месту абстрактный акроним, вообще ничего не значащий в реальном мире.
Mephistophele Автор
05.06.2023 09:30Тем более зачем париться, когда запряг аишечку и оно выдало удобоваримый бред. Без разницы к месту или нет.
DMGarikk
05.06.2023 09:30+5Кто допустил — расхлебывает.
отличный аргумент в решнии проблем, если его активно использовать, можно добиться срывом договора на разработку вообще отказом (увольнением) всех разработчиков от проекта
а проект превращается с поиск зацепок — на кого свалить все проблемы, вплоть до придирки в запятых при постановке задач.
p.s. как же я ненавижу заказную разработку… ох..
cupraer
05.06.2023 09:30Когда-то очень давно (еще до возникновения слова «фрилансер») я работал под заказ в одно, простите, рыло. Начиная со второго (sic!) заказа — я выработал железное правило: никогда, ни при каких обстоятельствах, не брать ни копейки предоплаты. Хотя родителей-миллионеров у меня не было. Более того, я соглашался на работу только спустя три дня после первого разговора, и все это время уходило на набрасывание прототипа в режиме 20×7, чтобы понять: насколько оно вообще выполнимо за условный человеко-месяц.
Кидали ли меня? — Иногда. Зато я сохранил значительную часть нервных клеток и любовь к своей работе.
akakoychenko
05.06.2023 09:30Если на "дискавери" оценку провалила команда - пусть тянет на хардмоде, сама виноватая.
Вроде ж, крепостное право отменили? Не?
Команда - это конкретные люди, которые пришли продавать 8 часов своего времени за рыночную оплату такой работы. И тот факт, что работа во время дискавери была выполнена некачественно, вообще никак этот расклад не меняет. Их ждут дома дети и домашние дела. А в линкедин пописывают рекрутеры, и друзья на пиве иногда могут вакансию подкинуть.
Как бы, да, иногда можно нефинансовыми методами получить с человека больше, чем договорились, но это не только аморально, но и ненадежно и немасштабируемо)
Mephistophele Автор
05.06.2023 09:30Кривые assumptions, косяки в контракте и т.д. и т.п. Плюс на том конце провода всегда сидят весьма "зубастые" ребята, что способны из копейки рубль выжать.
Но всегда очень сказывается нелюбовь менеджеров идти и торговаться с заказчиком или другими стейкхолдерами. Т.е. вместо того чтобы отстоять команду предпочитают её утопить.
Samedi_Da_Kapa
05.06.2023 09:30Это вопрос квалификации менеджера. Если человек не может отстоять свою точку зрения - какой же он руководитель? Просто передаст какой-то.
Плюс к этому, если процессы в компании настроены хоть сколько-то адекватно и это не команда однодневка, то таких косяков должно быть очень мало, на самом деле.Mephistophele Автор
05.06.2023 09:30Это вопрос квалификации менеджера. Если человек не может отстоять свою точку зрения - какой же он руководитель? Просто передаст какой-то.
Я полностью согласен, но за свою менеджерскую карьеру как-то мне крайне редко попадаются управленцы способные перед клиентом отстаивать свою или команды точку зрения, а не заткнуть языком задний проход.
Плюс к этому, если процессы в компании настроены хоть сколько-то адекватно и это не команда однодневка, то таких косяков должно быть очень мало, на самом деле.
А вот здесь нюанс. Вы можете выстроить процессы в маленькой и маленько-средней компании. В большой компании начинается свалка и кто в лес, кто по дрова. Будь то google, amazon, accenture - на большом скейле почти никто не способен выстроить унифицированные процессы и выжать эффективность.
pyrk2142
05.06.2023 09:30+3Имхо, одна из главных проблем таких статей - в качестве решения предлагаются исключительные случаи:
Задачу В мы уже решали в рамках проекта. Мы можем переиспользовать её?
Нет, там была совсем другая задача, ее не переиспользовать. Плюс 30 часов обратно
Можно выкинуть вот это, это и ещё это. Но кое-что надо утвердить с заказчиком. Но всё равно получается 50.
Молодцы, хорошая попытка, но заказчику надо все же то, за что он заплатил, плюс 40 часов обратно
Здесь причина проблемы - непонятная оценка архитектора. Оценил правильно - пусть общается с командой и обьясняет, как надо делать. Оценил неправильно - пусть компенсирует неправильно оценённое время из «архитекторского запаса» или делает сам. Что такое 160 часов сверху для такого профессионала? Вполне сможет после работы отработать за рабочую неделю, правда без обеда придётся 5 дней посидеть, но это мелочи.
А если серьезно, то важно не перекладывать ответственность с тех, кто допустил серьезную халатность на тех, кто это должен исправлять.
Ivan22
05.06.2023 09:30а у нас заказчики в большинстве случаем соглашаются выкинуть то что не успевает в девелопмент.
Mephistophele Автор
05.06.2023 09:30В рамках каких контрактов они это выкидывают? Продукт, тм или фикс?
Ivan22
05.06.2023 09:30в рамках любых, ну точнее в продаже продукта заказчик внутренний, поэтому там с этим сложнее
Mephistophele Автор
05.06.2023 09:30+1Ну да, ну да сложнее. XD
Если внутренний заказчик, то там всё по другому. Знаем плавали. Даже в очень крупных компаниях бюджеты растягивают как силиконовые. Максимум сроки, но там скоуп режут только в путь под это дело.
Ivan22
05.06.2023 09:30бюджеты силиконовые а людей не хватает. Сроки торопят прям как не в себя, овертаймы чтобы "срочно к НГ надо выпустить релиз" просто постоянно !!!!
barloc
05.06.2023 09:30Кто как оценил, тот пусть так и делает. Оценка задачи без принятия фактора уровня исполнителя - мусор.
DMGarikk
05.06.2023 09:30(сарказм)
все же знают что исполнитель спит и видит как часов накинуть чтобы бабла содрать и ничего не делать, ведь он называет 120 часов, а все делает за 5 часов… я видел видел!!! вон сидит ютубчик смотрит и на хабре чтото пишет
Ivan22
05.06.2023 09:30+3Лучшая оценка на старте выглядит как - "от 20 до 200 дней". Самая точная получается уже после окончания работы
akakoychenko
TLDR: если менеджер проекта имеет компетенции в архитектуре, программировании, продуктовом менеджменте, владеет доменом, и готов применить все эти навыки во благо проекта, то любая фикспрайсная жопа имеет выход
Mephistophele Автор
К сожалению не любая. Да и не так страшен фикс прайс как его рисуют.