Comments 38
Друг мой, давайте будем честными. Для того, чтобы не было лишних хотелок от заказчика, надо на начальном этапе в паспорт проекта, в котором есть:
Цели и задачи по smart. Что вы и заказчик ожидаете от проекта, на решение какой проблемы он направлен.
Границы проекта по sipoc, т.е. все участники, всё, что входит в проект и особенно, то, что не входит
Этапы проекта по dmaic
Четкие kpi проекта. Что вы от него ждёте в измеримых величинах. В том числе сроки.
Подписываете паспорт проекта с этими данными и вам вряд-ли прилетит что-то сверху бесплатно.
Всё, что пишете вы, это последствия того, что незафксированы описанные пункты на начальном этапе.
Сам то в это веришь? Заказчик всегда будет генерить хотелки, и всегда РП захочет его "удивить" быстрым решением очередной хотелки Ни один РП из тех, что я видел, не умеет управлять ожиданиями заказчика, им это не дано. А устав проекта можно любой написать, что пооом деоать будешь, в арбитраж пойдешь, человекочасы отстаивать? . Любой водопад в середине проекта переходит в бардак аджайла. Единственное, что спасёт проект от убытка - это спрятать в план три хвоста стоимости.
Не просто верю, в то, что написал, был реализован не один проект, основываясь на данных принципах. То, что вы пишите про аджайл, выдает ваш опыт в ИТ проектах, к сожалению в этой области у меня опыта нет, но управление проектами это не только ИТ.
То, что вы пишите про руководителя проекта, вообще удивительно. Единственная цель руководителя проекта это успешно завершить свой проект. Его три задачи, завершить проект в установленный срок, с нужным качеством и не выходя за установленные ресурсы. Чтобы добиться этого и нужны паспорт проекта с описанными ранее пунктами, план управления проектом, верхнеуровнего описывающий этапы. ВБС структура работ и другие основополагающие документы, в которых описаны и в том числе ожидания заказчика. Кого-то удивлять, это точно не про руководителя проекта, это говорит о его непрофессионализме.
Как один из вариантов управления дополнительными хотелками заказчика, это включить в договор этап сопровождения на какой-то срок. Вы выполнили работы утвержденные по проекту и потом например год сопровождаете и допиливаете продукт под его хотелки.
Кстати, если на первом этапе у самого заказчика нет понимания, что он хочет, задача РП обязательно формализовать его хотелки, иначе будет то, что вы написали выше.
Единственная цель руководителя проекта это успешно завершить свой проект
Когда проект - это путь, а не цель (нет точки, по достижении которой проект считается завершенным, любые тн "продуктовые" компании), то РП переходят в тактический режим.
Тактический (административный) режим РП - это когда каждая хотелка становится проектом, тк ценность РП в таком случае измеряется в удобности для заказчика.
Удобный РП не задает вопросов, и не управляет ожиданиями: он удобный именно потому, что на любую хотелку говорит "Да, господин!", и доводит ее до реализации, без оглядки на последствия и целесообразность.
Качество реализации, постановки задачи, решений по неясным нюансам, сочетание с другими требованиями, как и прочие атрибуты хотелки, должны соответствовать единственному критерию: достаточно, чтобы при демонстрации сказать "Вы просили, и теперь это готово, господин!".
Это вообще отличительная черта менеджмента в авторитарных странах.
Отсюда крашеная трава, черная краска на шинах, мультики про достижения промышленности, фичи, которые ломают одна другую, сайты, которые делаются не для бизнеса, а для того чтобы один человек увидел и сказал "Ну вот, теперь Красиво! Здорово же я придумал!", итд итп.
Для таких управленческих структур походит термин "Ордынская архиткетура" (взял у Б.Акунина), вписывается идеально.
То есть то, что вы написали, относится не к ИТ? А в какой сфере тогда вы руководствуетесь такими принципами?
Подозреваю, что в строительстве. Когда новое здание строится, рядом с ним вывешивают выжимку из паспорта проекта. И вот там да, там чëтко всё оговаривается, что будет на конечном этапе, и никаких отступлений в процессе. И когда здание достроено, бригаде уже насрать на него
Да, строительство, но это не ограничивает сферу применения. Любая модернизация производства например
IT работает по совершенно иным законам, нежели строительство. Связано это с тем, что в ПО легко вносить изменения. А вот внести изменения в строящееся здание практически нереально. И если IT-подрядчик будет будет навязывать заказчику какие-то строгие планы работ, то будет очень быстро послан восвояси и заменён кем-то иным, благо желающих наверняка полно (я слышал, рынок аутсорса жесть какой перегретый и за заказчиков там нехилая борьба). Так что мораль: не хотите терпеть всё новые хотелки от заказчика - не работайте в сфере, где таковые в принципе возможны
Соглашусь. Рынок IT странно сравнивать со строительством, не смотря на то, что и там, и там есть "проекты". Специфика везде своя.
Хотя не исключаю, что из сферы строительства можно что-то почерпнуть и использовать в IT =)
Да ну. По тем же самым.
Было и комплекс зданий разворачивали на 180° после согласованного дизайн проекта.
И холл 1го этажа превращали в полуподвал.
😊
В договор вы можете включить только то, что вам заказчик позволит. Не надо фантазировать. Потому что он в подрядчиках как в сору роется. Возьмёт и в один день выгонит одного и на его место найдёт другого. Видел такое и не раз на любом этапе большого проекта в котором и ТЗ и Устав и прочее и прочее все как в учебниках.
это какой-то молодёжный сленг, описываюший тз?
Что-то на утопическом)
Не встречал проектов, где на этапе инициации так чётко всё прописывается. Но если вы так делаете - это круто.
Как уже написали - цели, рамки, критерии успешности. Но, если на входе требования не очень ясные, то нужно выбирать гибкие подходы и инструменты для реализации. ПМ обязан подбирать и адаптировать подходы и инструменты под каждый конкретный проект.
На входе почти всегда требования "не очень ясные". Заказчик либо верхнеуровнево понимает, что он хочет, либо по ходу проекта начинает входить во вкус.
Подходы и инструменты, конечно, подбирать можно. Но если мы это будем делать, чтобы только угодить Заказчику, проект выйдет за бюджет сто процентов. Одного перехода на гибкий подход недостаточно, если не уметь правильно работать с Заказчиком
Заказчик - это один из ключевых стейкхолдеров. А для работы с ними также применяются разные инструменты и стратегии.
Если на входе неясные требования зачем на них вообще натягивать водопад?
Поэтому и нужны цели, рамки, критерии в любом проекте чтоб были ориентиры для оценки хотелок.
А ключевое просто не работать с мудаками и дебилами)))
Если на входе неясные требования зачем на них вообще натягивать водопад?
А какие есть ещё варианты, если договор Fix Price? Понятно, что надо максимально гибко подходить, но agile - это все-таки про Time&Material. В итоге всегда получается некий гибридный подход, в котором вы верхнеуровнево в водопаде, но внутри стараетесь в эджайл.
А ключевое просто не работать с мудаками и дебилами)
За больное задеваете =) Как раз недавно выкладывал тут пост, как мы напоролись на одного такого, который весь проект развалил. Сейчас думаем, как такие вещи выяснять на этапе пресейла.
Тогда не понимаю как у вас сочетаются Fix Price, где д.б. прописаны содержание и объем (ТЗ), с неясными требованиями)) Что-то здесь не клеится.
В любом случае все начинается с цели проекта
Ну ТЗ есть всегда. Зачастую максимально верхнеуровневое. Нужно на этапе продажи понимать, что и где у Заказчика болит, и что он хочет от проекта. На основе этих данных делается оценка, контракт и начинаются работы.
А уже в ходе проекта начинается "веселье" с выяснением чётких требований, описанием частного технического задания/функциональных требований/технических решений/концепций и прочего. Плюс, как я уже писал выше, Заказчик начинает входить во вкус, начинает лучше понимать, что он хочет, начинает генерировать новые хотелки и изменить старые и тп.
А когда на страте пишется ТЗ объем неопределенности в проекте огромен.
Ну тогда понятно - подошли чисто формально к ТЗ и, соответственно, не верна выбрана форма контракта. Либо нужно закладывать размер риска в размере этой неопределенности) Ну я бы смотрел все таки в сторону итерационной модели - фиксированная команда с фиксированной производительность и с фиксированной ценой за фиксированный срок, как вариант. Ну и главное - цель, рамки, критерии.
Скажите, рисками вы управляли? У нас а России не любят ими заниматься. А очень зря.
Часто бывает, что новые требования, это хотелки одного конкретного человека. Причем этот конкретный человек, не может обосновать в цифрах, его выгоды для проекта.
Это все закладывается в риски, делается сценарий реагирования. Одно это может притормозить фантазии.
Управление рисками и ожиданиями Заказчика - это два ключевых навыка, которые я требую от руководителей проектов.
К сожалению, вы правы, с рисками у нас очень плохо работают.
При выстраивании системы проектного управления обязательно надо управлять рисками. У нас этим занимается отдельный человек
Отдельный человек занимается рисками? То есть это не руководитель проекта?
Не очень себе это представляю, расскажите поподробнее, как это.
Этот человек выделен фулл-тайм на проект? Чем он занимается всё время? Если не выделен, то у него куча других проектов? Тогда у него, наверное, каша в голове из рисков. Или этот человек совмещает в себе несколько ролей на одном проекте?
Отдельный человек, который умеет в риск-менеджмент. Он задаёт методологию, задаёт форматы, короче задаёт правила. Он один на все проекты. Первоначально по проекту проводится мозговой штурм с участием работников разных уровней, в ходе которого формируется пулл рисков. Потом риск-менеджер обрабатывает этот пул и совместно с руководителями верхнего звена выбираются наиболее важные риски, которые будут мониторится. Потом по каждому из рисков вычленяются факторы, которые влияют на этот риск. Под каждый риск-фактор разрабатываются мероприятия направленные на снижение риска. Назначаются владельцы рисков, те в чьём функционале риск, а так же владельцы мероприятий, те кто отвечает за их выполнение.
С условленной периодичностью мероприятия мониторятся и владелец риска понимает, тенденцию по своему риску, понимает работают ли мероприятия, ну и соответственно может эти мероприятия корректировать.
Надо считать деньги. То есть надо всегда понимать финансовый результат. Если проект перестаёт укладываться в норму прибыли (в широком конечно смысле), то заказчик перестаёт быть клиентом. И важный навык: не работать без задатка (не путать с авансом). Этот момент очень дисциплинирует заказчика. Да понятно корпорации выкручивают руки и тд и тп . А вы просто представьте себе кладбище вам подобных компаний , которое у них на заднем дворе. Если вы попались на удочку «перспектив» , то вам там сейчас копают свежую могилу.
Не, а если всё с ног на голову?
Предлагаем заказчику схему:
Пилим подробнейшее ТЗ.
Дальше правило: пока ТЗ 100% не сделаем - никаких изменений ТЗ, если исполнитель не согласен.
Можно даже поэтапную оплату ввести, попунктно даже.
Сделали-оплатили 100%? Пилим новое ТЗ. И так итеративно.
Если заказчик не согласен - идёт козе в трещину на любом этапе - каши с ним не сваришь.
Если у заказчика бюджет 300, а по ТЗ начитали 200, значит ему повезло и 30% пойдет на доделки-хотелки. Если насчитали 300, вероятность чего-то нехорошего будет почти 100%.
В проектах с большим объемом неопределенности так сделать в принципе не получится. А в IT каждый второй проект такой.
Да даже если получится, вы в ТЗ будете описывать ЧТО надо сделать или КАК надо сделать? Если описывать только ЧТО, у вас остается большой простор для творчества. Если описывать ещё и КАК, у Заказчика может не хватать компетенций для обсуждения таких вопросов, ну или просто вы такой документ будете согласовывать полгода, если объем информации большой.
Да и в целом подход, когда "Всё согласовали, ушли делать, через год вернулись показали" - это классический водопад. Со всеми вытекающими. Рискуете сделать проект, который никому не нужен. И если вы думаете, что это проблема Заказчика, то вы ошибаетесь, это и ваша проблема в том числе.
Пока будете это описывать - придут люди, которые готовы делать, например, бенч стоит не занятый…
Дополнительные хотелки - это дополнительные затраты. Затраты - это снижение маржи проекта. А изменение маржи проекта - это изменение его коммерческой составляющей, которой должны заниматься люди, ответственные за коммерцию. Задача РП - держать проект в рамках маржи. А переторговывать маржу должен сейлз, аккаунт или кто он у вас там. Это совершенно другая компетенция и другой уровень полномочий, которыми РП не обладает.
Так что не путайте тёплое с мягким. Заказчик хочет много новых фич, которых не было в ТЗ? Соберите их в документ и несите на проектный комитет - и пусть коммерсы переуиверждают с заказчиком цену, сроки, скоуп и т.д. Иначе будете бесконечно работать в минус на долгосроке - из-за чего и помирает большинство молодых проектных компаний.
За хотелку не заплатили...
Бывает такое, что половину DWH приходится переделывать, просто потому что пару лет проекта спустя вышел какой-нибудь весёлый законопроект. РП уволился в никуда. А расхлёбывать простым смертным.
А они тут на оплату фич жалуются.
Сколько грамотно ТЗ не пили. Как риски не считай - будь готов что с неба метеорит упадёт и придется его последствия разгребать.
Что делать, если Заказчик постоянно генерирует новые «хотелки» по ходу проекта