В предыдущем посте я написал о том, что делать, если Заказчик приходит с просьбой сделать часть работ бесплатно. В этом посте хотелось бы поговорить, как сделать так, чтобы либо подобные вопросы в проекте вообще не возникали, либо чтобы процесс был управляемым.
Сразу оговорюсь, что эти ситуации применимы на больших проектах с внешними корпоративными Заказчиками. На фрилансе, в госах, на небольших проектах и тп могут быть другие нюансы, тут у меня опыта немного.
Вот мой список шагов, которые можно предпринять, чтобы снизить вероятность прихода Заказчика к вам с просьбой бесплатных работ, либо снизить влияние этого запроса на трудозатраты и бюджет вашего проекта.
1. Закладывайте на подобные работы 3–5% от стоимости контракта сразу на этапе продажи. И в следующий раз, когда Заказчик придёт с просьбой бесплатных работ, оцените сколько вы потратите, запишите в общий бэклог таких хотелок и следите за тем, чтобы не превышать этот лимит. Правда тут есть тонкая грань, как сделать так, чтобы в определенный момент, когда этот буфер в 3–5% у вас закончится, не словить непонимание у Заказчика «как так, вы всегда принимали наши мелкие хотелки, а теперь вдруг упёрлись».
2. Основная проблема в дополнительных работах не в том, чтобы обосновать Заказчику, что это не входит в скоуп, а в том, что у Заказчика на это уже нет денег, так как бюджет на проект выделен и больше денег не дадут. Поэтому на этапе продажи договаривайтесь на выделение определенного риск‑буффера у Заказчика, который он будет использовать по своему усмотрению. В идеале, это должно быть не менее 10% от стоимости проекта. Захотели доп.хотелку, которой нет в скоупе — залезли в выделенный риск‑буффер и потратили, сколько надо. У нас такой опыт был, так что проверено — работает очень классно.
3. Чтобы снизить вероятность возникновения дополнительных хотелок по ходу проекта, необходимо перед стартом основного проекта сделать аудит или небольшой пилотный проект. Для Заказчика плюс в том, что он будет знать реальное состояние дел, сколько денег потребуется для реализации проекта, увидит, что из себя представляет продукт (если речь про небольшой пилот) и сможет гораздо лучше и осознаннее сформулировать к нему требования. Для вас плюсы все те же самые, и в дополнении вы оцените Заказчика — насколько сложно с ним будет работать в реальном проекте, попробуете оцените будет ли он генерировать бесконечные требования, насколько сложно у них происходят согласования и предоставление запрашиваемой информации. Ну и как следствие — вы сможете дать более точную оценку. Если вы думаете, что Заказчики не идут на пилотные проекты и проекты по аудиту, потому что по результатам не получат то, ради чего будет открываться проект, то смею вас разубедить — для нас это распространенная практика, таких проектов много.
4. Если пилота или аудита не было, то на старте проекта (а лучше, конечно, еще на этапе формирования ТЗ) необходимо продемонстрировать Заказчику пример готовой работы. То есть показать то, что получится на выходе из проекта. Таким образом Заказчик сформирует правильные ожидания, сможет лучше описать свои требования, а вы обозначите рамки готового продукта.
5. Если пример готовой работы продемонстрировать не получается, то, чтобы сформировать правильные ожидания, на старте проекта можно описать User Story и Use Case. Первые сосредоточены на том, что пользователь хочет, а вторые — это детальное описание сценариев использования системы, то есть то, что должно произойти в системе, когда пользователь выполняет определенное действие. Use Case описывают действия пользователей, систему и результаты. Честно признаюсь, мы в своей практике используем User Story и Use Case либо при подготовке ПМИ, либо на этапе обсуждения уже каких‑то конкретных требований. Но очевидно, что формирование подобных сценариев и кейсов на старте проекта более эффективно, чем в середине или ближе к концу проекта.
6. Если пилота или аудита не было, а показать пример готовой работы не получилось, то одна из главных задач для вас в проекте — сделать MVP как можно быстрее. Не будем вдаваться в теорию проектного управления и обсуждать водопадную модель и agile‑подход. Тут нас в первую очередь интересует вероятность получения новых требований от Заказчика по ходу проекта и способы уменьшения этой вероятности. Поэтому, чем быстрее вы дадите Заказчику результат, который можно пощупать и сформировать правильные ожидания и требования, тем лучше будет для проекта.
7. Независимо от того, получилось ли у вас пройти по пунктам 3–6, команда (и в первую очередь менеджер проекта) должны уметь управлять ожиданиями Заказчика. Необходимо делать так, чтобы образ результата в голове у Заказчика совпадал с образом результата в голове у команды Исполнителя. И это делается не только на старте проекта, это постоянная и регулярная работа. Любое обсуждение каких‑то задач и проблем в проекте, должно сопровождаться работой с ожиданиями Заказчика. То есть он должен в деталях понимать, к чему приведет любое решение на проекте, и как будет работать тот или иной функционал.
8. На этапе инициации проекта договориться с Заказчиком по процессу управления требованиями. Сразу «на берегу» договариваетесь, кто может генерировать новые требования, как определяется, входит ли это в скоуп проекта, как новые требования оцениваются, как выглядит процедура эскалации, кто принимает финальные решения.
9. Независимо от того, договорились ли вы с Заказчиком по пункту 8, у вас в любом случае должен существовать процесс управления этими требованиями. Необходимо обязательно учитывать информацию о том, какие требования уже уточнили, какие выполнили, какие новые требования поступили. Вы можете вести этот документ только у себя, а в следующий раз, когда Заказчик скажет «да что вам стоит там немного поправить», вы ему показываете фактуру, в которой таких «да что вам стоит» уже два десятка набралось.
10. Сложнореализуемый пункт, к которому мы сами ещё не пришли, но уже очень активно «смотрим в его сторону». Использование Fix price flexible scope модели, которая совмещает в себе фиксированный скоуп проекта и эджайл подход. В ней мы берем лучшее от обеих моделей. Смысл в том, что мы фиксируем бюджет, за который проект не выйдет, как в fixed price, но при этом позволяем клиенту менять scope в лучших традициях T&M и эджайла. Главное, что нужно сделать для FPFS модели — определить, какой scope нельзя выкинуть ни под каким соусом. С этим обычно проблем нет, Заказчики даже на старте проекта знают, что вот эти 4 фичи из 10 нужны кровь из носа, а остальные можно пустить под нож (flexible scope). Сначала делаем наши 4 фичи и ставим им приоритет highest. На протяжении всего проекта они висят в топе бэклога. С заказчиком четко проговариваем, что они идут в работу первыми. Хотим добавить новые фичи? Не проблема — добро пожаловать в бэклог. Но сначала мы сделаем наивысший приоритет, а потом все остальное.
11. Не соглашаться на всё подряд. Даже если выглядит, что сделать это дешево и быстро, а вы больше времени потратите на то, чтобы доказывать Заказчику, что это за доп.бюджет. Вроде бы очевидно, зачем брать лишние работы, да ещё и бесплатно? Однако, в огромных проектах, которые идут годами, в моменте об этом можешь не задумываться. А если вы не ведёте список того, на что соглашаетесь, то вам вдобавок ещё и трудно будет оценить, сколько вы такого уже реализовали. В итоге Заказчик привыкает, что вы подписываетесь на всё подряд, а вы потратите дополнительные трудозатраты и усложните систему, из‑за чего впоследствии может возникнуть больше проблем (попробуйте через год доказать Заказчику, что бага, исправление которой критично для проекта, вылезла из‑за работ, которые вообще в проект не входили).
12. Если вы всё‑таки соглашаетесь на какие‑то работы, которые в скоуп не входили, обязательно нужно зафиксировать это письмом. И обязательно ответным письмом Заказчик должен это согласовать. Люди увольняются, нюансы за давностью событий забываются, и вспомнить потом, почему вы это сделали, кто вас просил и на каких условиях вы это согласовали, без такой фактуры будет очень проблематично. Доказано горьким опытом.
Если интересны посты с подобными советами, о повышении продуктивности своей работы и практические советы об эффективных способах борьбы с прокрастинацией, можете подписаться на мой канал.
Комментарии (37)
Thisnicknameisbusy
11.06.2024 18:25Как уже написали - цели, рамки, критерии успешности. Но, если на входе требования не очень ясные, то нужно выбирать гибкие подходы и инструменты для реализации. ПМ обязан подбирать и адаптировать подходы и инструменты под каждый конкретный проект.
ilyagot Автор
11.06.2024 18:25На входе почти всегда требования "не очень ясные". Заказчик либо верхнеуровнево понимает, что он хочет, либо по ходу проекта начинает входить во вкус.
Подходы и инструменты, конечно, подбирать можно. Но если мы это будем делать, чтобы только угодить Заказчику, проект выйдет за бюджет сто процентов. Одного перехода на гибкий подход недостаточно, если не уметь правильно работать с Заказчиком
Thisnicknameisbusy
11.06.2024 18:25+1Заказчик - это один из ключевых стейкхолдеров. А для работы с ними также применяются разные инструменты и стратегии.
Если на входе неясные требования зачем на них вообще натягивать водопад?
Поэтому и нужны цели, рамки, критерии в любом проекте чтоб были ориентиры для оценки хотелок.
А ключевое просто не работать с мудаками и дебилами)))
ilyagot Автор
11.06.2024 18:25Если на входе неясные требования зачем на них вообще натягивать водопад?
А какие есть ещё варианты, если договор Fix Price? Понятно, что надо максимально гибко подходить, но agile - это все-таки про Time&Material. В итоге всегда получается некий гибридный подход, в котором вы верхнеуровнево в водопаде, но внутри стараетесь в эджайл.
А ключевое просто не работать с мудаками и дебилами)
За больное задеваете =) Как раз недавно выкладывал тут пост, как мы напоролись на одного такого, который весь проект развалил. Сейчас думаем, как такие вещи выяснять на этапе пресейла.
Thisnicknameisbusy
11.06.2024 18:25+1Тогда не понимаю как у вас сочетаются Fix Price, где д.б. прописаны содержание и объем (ТЗ), с неясными требованиями)) Что-то здесь не клеится.
В любом случае все начинается с цели проекта
ilyagot Автор
11.06.2024 18:25Ну ТЗ есть всегда. Зачастую максимально верхнеуровневое. Нужно на этапе продажи понимать, что и где у Заказчика болит, и что он хочет от проекта. На основе этих данных делается оценка, контракт и начинаются работы.
А уже в ходе проекта начинается "веселье" с выяснением чётких требований, описанием частного технического задания/функциональных требований/технических решений/концепций и прочего. Плюс, как я уже писал выше, Заказчик начинает входить во вкус, начинает лучше понимать, что он хочет, начинает генерировать новые хотелки и изменить старые и тп.
А когда на страте пишется ТЗ объем неопределенности в проекте огромен.
Thisnicknameisbusy
11.06.2024 18:25Ну тогда понятно - подошли чисто формально к ТЗ и, соответственно, не верна выбрана форма контракта. Либо нужно закладывать размер риска в размере этой неопределенности) Ну я бы смотрел все таки в сторону итерационной модели - фиксированная команда с фиксированной производительность и с фиксированной ценой за фиксированный срок, как вариант. Ну и главное - цель, рамки, критерии.
TimoshkinVlad
11.06.2024 18:25Скажите, рисками вы управляли? У нас а России не любят ими заниматься. А очень зря.
Часто бывает, что новые требования, это хотелки одного конкретного человека. Причем этот конкретный человек, не может обосновать в цифрах, его выгоды для проекта.
Это все закладывается в риски, делается сценарий реагирования. Одно это может притормозить фантазии.
ilyagot Автор
11.06.2024 18:25Управление рисками и ожиданиями Заказчика - это два ключевых навыка, которые я требую от руководителей проектов.
К сожалению, вы правы, с рисками у нас очень плохо работают.
alferiusgmailcom
11.06.2024 18:25При выстраивании системы проектного управления обязательно надо управлять рисками. У нас этим занимается отдельный человек
ilyagot Автор
11.06.2024 18:25Отдельный человек занимается рисками? То есть это не руководитель проекта?
Не очень себе это представляю, расскажите поподробнее, как это.
Этот человек выделен фулл-тайм на проект? Чем он занимается всё время? Если не выделен, то у него куча других проектов? Тогда у него, наверное, каша в голове из рисков. Или этот человек совмещает в себе несколько ролей на одном проекте?
alferiusgmailcom
11.06.2024 18:25Отдельный человек, который умеет в риск-менеджмент. Он задаёт методологию, задаёт форматы, короче задаёт правила. Он один на все проекты. Первоначально по проекту проводится мозговой штурм с участием работников разных уровней, в ходе которого формируется пулл рисков. Потом риск-менеджер обрабатывает этот пул и совместно с руководителями верхнего звена выбираются наиболее важные риски, которые будут мониторится. Потом по каждому из рисков вычленяются факторы, которые влияют на этот риск. Под каждый риск-фактор разрабатываются мероприятия направленные на снижение риска. Назначаются владельцы рисков, те в чьём функционале риск, а так же владельцы мероприятий, те кто отвечает за их выполнение.
С условленной периодичностью мероприятия мониторятся и владелец риска понимает, тенденцию по своему риску, понимает работают ли мероприятия, ну и соответственно может эти мероприятия корректировать.
AnatolyEmelin
11.06.2024 18:25Надо считать деньги. То есть надо всегда понимать финансовый результат. Если проект перестаёт укладываться в норму прибыли (в широком конечно смысле), то заказчик перестаёт быть клиентом. И важный навык: не работать без задатка (не путать с авансом). Этот момент очень дисциплинирует заказчика. Да понятно корпорации выкручивают руки и тд и тп . А вы просто представьте себе кладбище вам подобных компаний , которое у них на заднем дворе. Если вы попались на удочку «перспектив» , то вам там сейчас копают свежую могилу.
kh0
11.06.2024 18:25Не, а если всё с ног на голову?
Предлагаем заказчику схему:
Пилим подробнейшее ТЗ.
Дальше правило: пока ТЗ 100% не сделаем - никаких изменений ТЗ, если исполнитель не согласен.
Можно даже поэтапную оплату ввести, попунктно даже.
Сделали-оплатили 100%? Пилим новое ТЗ. И так итеративно.
Если заказчик не согласен - идёт козе в трещину на любом этапе - каши с ним не сваришь.
Если у заказчика бюджет 300, а по ТЗ начитали 200, значит ему повезло и 30% пойдет на доделки-хотелки. Если насчитали 300, вероятность чего-то нехорошего будет почти 100%.ilyagot Автор
11.06.2024 18:25В проектах с большим объемом неопределенности так сделать в принципе не получится. А в IT каждый второй проект такой.
Да даже если получится, вы в ТЗ будете описывать ЧТО надо сделать или КАК надо сделать? Если описывать только ЧТО, у вас остается большой простор для творчества. Если описывать ещё и КАК, у Заказчика может не хватать компетенций для обсуждения таких вопросов, ну или просто вы такой документ будете согласовывать полгода, если объем информации большой.
Да и в целом подход, когда "Всё согласовали, ушли делать, через год вернулись показали" - это классический водопад. Со всеми вытекающими. Рискуете сделать проект, который никому не нужен. И если вы думаете, что это проблема Заказчика, то вы ошибаетесь, это и ваша проблема в том числе.
ivankudryavtsev
11.06.2024 18:25Пока будете это описывать - придут люди, которые готовы делать, например, бенч стоит не занятый…
Asterris
11.06.2024 18:25+2Дополнительные хотелки - это дополнительные затраты. Затраты - это снижение маржи проекта. А изменение маржи проекта - это изменение его коммерческой составляющей, которой должны заниматься люди, ответственные за коммерцию. Задача РП - держать проект в рамках маржи. А переторговывать маржу должен сейлз, аккаунт или кто он у вас там. Это совершенно другая компетенция и другой уровень полномочий, которыми РП не обладает.
Так что не путайте тёплое с мягким. Заказчик хочет много новых фич, которых не было в ТЗ? Соберите их в документ и несите на проектный комитет - и пусть коммерсы переуиверждают с заказчиком цену, сроки, скоуп и т.д. Иначе будете бесконечно работать в минус на долгосроке - из-за чего и помирает большинство молодых проектных компаний.
titan_pc
11.06.2024 18:25За хотелку не заплатили...
Бывает такое, что половину DWH приходится переделывать, просто потому что пару лет проекта спустя вышел какой-нибудь весёлый законопроект. РП уволился в никуда. А расхлёбывать простым смертным.
А они тут на оплату фич жалуются.
Сколько грамотно ТЗ не пили. Как риски не считай - будь готов что с неба метеорит упадёт и придется его последствия разгребать.
ilyagot Автор
11.06.2024 18:25Понимаю вашу боль, сами с таким сталкивались. Да, метеорит может упасть всегда. Но это не значит, что не надо ничего делать проактивно (о чём собственно этот пост), ждать чего-то плохого, а потом ходить и говорить "А я же говорил, что так и будет!"
alferiusgmailcom
Друг мой, давайте будем честными. Для того, чтобы не было лишних хотелок от заказчика, надо на начальном этапе в паспорт проекта, в котором есть:
Цели и задачи по smart. Что вы и заказчик ожидаете от проекта, на решение какой проблемы он направлен.
Границы проекта по sipoc, т.е. все участники, всё, что входит в проект и особенно, то, что не входит
Этапы проекта по dmaic
Четкие kpi проекта. Что вы от него ждёте в измеримых величинах. В том числе сроки.
Подписываете паспорт проекта с этими данными и вам вряд-ли прилетит что-то сверху бесплатно.
Всё, что пишете вы, это последствия того, что незафксированы описанные пункты на начальном этапе.
SSukharev
Сам то в это веришь? Заказчик всегда будет генерить хотелки, и всегда РП захочет его "удивить" быстрым решением очередной хотелки Ни один РП из тех, что я видел, не умеет управлять ожиданиями заказчика, им это не дано. А устав проекта можно любой написать, что пооом деоать будешь, в арбитраж пойдешь, человекочасы отстаивать? . Любой водопад в середине проекта переходит в бардак аджайла. Единственное, что спасёт проект от убытка - это спрятать в план три хвоста стоимости.
alferiusgmailcom
Не просто верю, в то, что написал, был реализован не один проект, основываясь на данных принципах. То, что вы пишите про аджайл, выдает ваш опыт в ИТ проектах, к сожалению в этой области у меня опыта нет, но управление проектами это не только ИТ.
То, что вы пишите про руководителя проекта, вообще удивительно. Единственная цель руководителя проекта это успешно завершить свой проект. Его три задачи, завершить проект в установленный срок, с нужным качеством и не выходя за установленные ресурсы. Чтобы добиться этого и нужны паспорт проекта с описанными ранее пунктами, план управления проектом, верхнеуровнего описывающий этапы. ВБС структура работ и другие основополагающие документы, в которых описаны и в том числе ожидания заказчика. Кого-то удивлять, это точно не про руководителя проекта, это говорит о его непрофессионализме.
Как один из вариантов управления дополнительными хотелками заказчика, это включить в договор этап сопровождения на какой-то срок. Вы выполнили работы утвержденные по проекту и потом например год сопровождаете и допиливаете продукт под его хотелки.
Кстати, если на первом этапе у самого заказчика нет понимания, что он хочет, задача РП обязательно формализовать его хотелки, иначе будет то, что вы написали выше.
karrakoliko
Когда проект - это путь, а не цель (нет точки, по достижении которой проект считается завершенным, любые тн "продуктовые" компании), то РП переходят в тактический режим.
Тактический (административный) режим РП - это когда каждая хотелка становится проектом, тк ценность РП в таком случае измеряется в удобности для заказчика.
Удобный РП не задает вопросов, и не управляет ожиданиями: он удобный именно потому, что на любую хотелку говорит "Да, господин!", и доводит ее до реализации, без оглядки на последствия и целесообразность.
Качество реализации, постановки задачи, решений по неясным нюансам, сочетание с другими требованиями, как и прочие атрибуты хотелки, должны соответствовать единственному критерию: достаточно, чтобы при демонстрации сказать "Вы просили, и теперь это готово, господин!".
Это вообще отличительная черта менеджмента в авторитарных странах.
Отсюда крашеная трава, черная краска на шинах, мультики про достижения промышленности, фичи, которые ломают одна другую, сайты, которые делаются не для бизнеса, а для того чтобы один человек увидел и сказал "Ну вот, теперь Красиво! Здорово же я придумал!", итд итп.
Для таких управленческих структур походит термин "Ордынская архиткетура" (взял у Б.Акунина), вписывается идеально.
alferiusgmailcom
Согласно PMBOK:
Проект — это временное предприятие, направленное на создание уникального продукта, услуги или результата.
Извините, но проект не может быть "путь", он всегда конечен по времени, ресурсам и качеству.
karrakoliko
Google (или любой Google ***) это проект? Когда закончат?
alferiusgmailcom
С точки зрения ИТ - проект заканчивается, когда его сдают в промышленную эксплуатацию. После задачи идёт эксплуатация
ilyagot Автор
То есть то, что вы написали, относится не к ИТ? А в какой сфере тогда вы руководствуетесь такими принципами?
zergon321
Подозреваю, что в строительстве. Когда новое здание строится, рядом с ним вывешивают выжимку из паспорта проекта. И вот там да, там чëтко всё оговаривается, что будет на конечном этапе, и никаких отступлений в процессе. И когда здание достроено, бригаде уже насрать на него
alferiusgmailcom
Да, строительство, но это не ограничивает сферу применения. Любая модернизация производства например
zergon321
IT работает по совершенно иным законам, нежели строительство. Связано это с тем, что в ПО легко вносить изменения. А вот внести изменения в строящееся здание практически нереально. И если IT-подрядчик будет будет навязывать заказчику какие-то строгие планы работ, то будет очень быстро послан восвояси и заменён кем-то иным, благо желающих наверняка полно (я слышал, рынок аутсорса жесть какой перегретый и за заказчиков там нехилая борьба). Так что мораль: не хотите терпеть всё новые хотелки от заказчика - не работайте в сфере, где таковые в принципе возможны
ilyagot Автор
Соглашусь. Рынок IT странно сравнивать со строительством, не смотря на то, что и там, и там есть "проекты". Специфика везде своя.
Хотя не исключаю, что из сферы строительства можно что-то почерпнуть и использовать в IT =)
SSukharev
В договор вы можете включить только то, что вам заказчик позволит. Не надо фантазировать. Потому что он в подрядчиках как в сору роется. Возьмёт и в один день выгонит одного и на его место найдёт другого. Видел такое и не раз на любом этапе большого проекта в котором и ТЗ и Устав и прочее и прочее все как в учебниках.
SuperKozel
это какой-то молодёжный сленг, описываюший тз?
alferiusgmailcom
Это инструменты, можно сказать методология, позволяющая чётко и структурировано формализовать этапы проекта. Уж точно не молодёжный сленг )
ilyagot Автор
Что-то на утопическом)
Не встречал проектов, где на этапе инициации так чётко всё прописывается. Но если вы так делаете - это круто.
alferiusgmailcom
Всегда надо стремиться к идеалу. А как вы закрываете проект не имея его чётких границ?