Скорее соглашусь. По ходу проекта эта матрица нужна разве что новым участникам.
Но на старте проекта она может принести огромную пользу. На днях у нас был случай, когда мы, составляя матрицу, узнали о куче заинтересованных лиц в проекте с высоким на него влиянием. Хотя до этого мы о них даже не слышали)
все равно у Заказчика есть бюджет, из которого он может очень редко выпрыгнуть
Ситуаций бывает масса. Это лишь одна из. Да, самая распространенная, но это не значит, что в такой ситуации надо ставить крест и ничего не делать.
Вписываться можно либо снижая маржу, либо где-то уменьшая работы
Способы рабочие, но не единственные.
Пост написан для того, чтобы как раз и продемонстрировать все возможные варианты. Чем больше шаблонов, есть у менеджера, который пытается договориться, тем больше вероятность успеха. Я же не говорю, что все 25 пунктов надо использовать в каждом кейсе.
Если под эмоциями вы имеете ввиду пункт 12, то соглашусь, что его можно использовать далеко не всегда.
Но вообще во многих ситуациях - это рабочий способ. Смысл в том, что мы хоть и воспринимаем друг друга, как "Исполнителя" и "Заказчика", или как представителя фирмы, но по факту все мы люди (отставить шутки про КО). И если опуститься на уровень общения с человеком (а не разговаривать с ним, как с представителем фирмы Заказчика), то договориться о чем-то будет легче.
Соглашусь, что существуют ситуации, когда это применимо. Но в большинстве случаев вы просто напоритесь на то, что Заказчик останется недоволен вами, как Исполнителем (а с чего бы он должен остаться доволен, если вы обещали за 1000 рублей, а сделаете за 5000?). Из такой ситуации очень сложно вырулить, и риск вообще потерять Заказчика огромен, если идти на это сознательно.
С чего бы вдруг Заказчик должен согласиться заплатить в N раз больше, чем у него выделен бюджет? Он сначала будет до победного ругаться, что вы должны сделать всё, что планировалось в проекте, и это ваша проблема, что вы не так посчитали и вылезли какие-то неожиданные риски. Ну а дальше Заказчику будет проще Закрыть проект и начать новый, чем соглашаться на "кабальные" условия Исполнителя, который в его глазах некомпетентен.
Так в том-то и дело, что Заказчик зачастую не понимает, почему эти работы столько стоят. Наша цель как раз донести ему, что там много работы, показать сложность, обосновать вовлеченность других специалистов.
Не всегда Заказчик что-то говорит из "вредности", или манипулирует, или торгуется. Бывают случаи (и их не мало), что действительно не понимают.
Понимаю вашу боль, сами с таким сталкивались. Да, метеорит может упасть всегда. Но это не значит, что не надо ничего делать проактивно (о чём собственно этот пост), ждать чего-то плохого, а потом ходить и говорить "А я же говорил, что так и будет!"
Отдельный человек занимается рисками? То есть это не руководитель проекта?
Не очень себе это представляю, расскажите поподробнее, как это.
Этот человек выделен фулл-тайм на проект? Чем он занимается всё время? Если не выделен, то у него куча других проектов? Тогда у него, наверное, каша в голове из рисков. Или этот человек совмещает в себе несколько ролей на одном проекте?
Ну ТЗ есть всегда. Зачастую максимально верхнеуровневое. Нужно на этапе продажи понимать, что и где у Заказчика болит, и что он хочет от проекта. На основе этих данных делается оценка, контракт и начинаются работы.
А уже в ходе проекта начинается "веселье" с выяснением чётких требований, описанием частного технического задания/функциональных требований/технических решений/концепций и прочего. Плюс, как я уже писал выше, Заказчик начинает входить во вкус, начинает лучше понимать, что он хочет, начинает генерировать новые хотелки и изменить старые и тп.
А когда на страте пишется ТЗ объем неопределенности в проекте огромен.
В проектах с большим объемом неопределенности так сделать в принципе не получится. А в IT каждый второй проект такой.
Да даже если получится, вы в ТЗ будете описывать ЧТО надо сделать или КАК надо сделать? Если описывать только ЧТО, у вас остается большой простор для творчества. Если описывать ещё и КАК, у Заказчика может не хватать компетенций для обсуждения таких вопросов, ну или просто вы такой документ будете согласовывать полгода, если объем информации большой.
Да и в целом подход, когда "Всё согласовали, ушли делать, через год вернулись показали" - это классический водопад. Со всеми вытекающими. Рискуете сделать проект, который никому не нужен. И если вы думаете, что это проблема Заказчика, то вы ошибаетесь, это и ваша проблема в том числе.
Если на входе неясные требования зачем на них вообще натягивать водопад?
А какие есть ещё варианты, если договор Fix Price? Понятно, что надо максимально гибко подходить, но agile - это все-таки про Time&Material. В итоге всегда получается некий гибридный подход, в котором вы верхнеуровнево в водопаде, но внутри стараетесь в эджайл.
А ключевое просто не работать с мудаками и дебилами)
За больное задеваете =) Как раз недавно выкладывал тут пост, как мы напоролись на одного такого, который весь проект развалил. Сейчас думаем, как такие вещи выяснять на этапе пресейла.
На входе почти всегда требования "не очень ясные". Заказчик либо верхнеуровнево понимает, что он хочет, либо по ходу проекта начинает входить во вкус.
Подходы и инструменты, конечно, подбирать можно. Но если мы это будем делать, чтобы только угодить Заказчику, проект выйдет за бюджет сто процентов. Одного перехода на гибкий подход недостаточно, если не уметь правильно работать с Заказчиком
Ни для чего не существует универсальных механизмов, и каждый случай уникален. тут вы правы. Но нужно в голове держать все возможные шаблоны для дальнейшего развития событий.
Скорее соглашусь. По ходу проекта эта матрица нужна разве что новым участникам.
Но на старте проекта она может принести огромную пользу. На днях у нас был случай, когда мы, составляя матрицу, узнали о куче заинтересованных лиц в проекте с высоким на него влиянием. Хотя до этого мы о них даже не слышали)
Ситуаций бывает масса. Это лишь одна из. Да, самая распространенная, но это не значит, что в такой ситуации надо ставить крест и ничего не делать.
Способы рабочие, но не единственные.
Пост написан для того, чтобы как раз и продемонстрировать все возможные варианты. Чем больше шаблонов, есть у менеджера, который пытается договориться, тем больше вероятность успеха. Я же не говорю, что все 25 пунктов надо использовать в каждом кейсе.
А у нас и не на фрилансе есть такие кейсы)
Заказчик ушёл к тому, у кого дешевле. А через год вернулся, "наевшись" дешёвого результата =)
Если под эмоциями вы имеете ввиду пункт 12, то соглашусь, что его можно использовать далеко не всегда.
Но вообще во многих ситуациях - это рабочий способ. Смысл в том, что мы хоть и воспринимаем друг друга, как "Исполнителя" и "Заказчика", или как представителя фирмы, но по факту все мы люди (отставить шутки про КО). И если опуститься на уровень общения с человеком (а не разговаривать с ним, как с представителем фирмы Заказчика), то договориться о чем-то будет легче.
Спорный способ.
Соглашусь, что существуют ситуации, когда это применимо. Но в большинстве случаев вы просто напоритесь на то, что Заказчик останется недоволен вами, как Исполнителем (а с чего бы он должен остаться доволен, если вы обещали за 1000 рублей, а сделаете за 5000?). Из такой ситуации очень сложно вырулить, и риск вообще потерять Заказчика огромен, если идти на это сознательно.
С чего бы вдруг Заказчик должен согласиться заплатить в N раз больше, чем у него выделен бюджет? Он сначала будет до победного ругаться, что вы должны сделать всё, что планировалось в проекте, и это ваша проблема, что вы не так посчитали и вылезли какие-то неожиданные риски. Ну а дальше Заказчику будет проще Закрыть проект и начать новый, чем соглашаться на "кабальные" условия Исполнителя, который в его глазах некомпетентен.
Так в том-то и дело, что Заказчик зачастую не понимает, почему эти работы столько стоят. Наша цель как раз донести ему, что там много работы, показать сложность, обосновать вовлеченность других специалистов.
Не всегда Заказчик что-то говорит из "вредности", или манипулирует, или торгуется. Бывают случаи (и их не мало), что действительно не понимают.
Звучит смешно, но в жизни не сработает)
Если Заказчик хочет скидку, то делая долго и плохо, непонятно за счёт чего должно получиться дешевле)
Понимаю вашу боль, сами с таким сталкивались. Да, метеорит может упасть всегда. Но это не значит, что не надо ничего делать проактивно (о чём собственно этот пост), ждать чего-то плохого, а потом ходить и говорить "А я же говорил, что так и будет!"
Отдельный человек занимается рисками? То есть это не руководитель проекта?
Не очень себе это представляю, расскажите поподробнее, как это.
Этот человек выделен фулл-тайм на проект? Чем он занимается всё время? Если не выделен, то у него куча других проектов? Тогда у него, наверное, каша в голове из рисков. Или этот человек совмещает в себе несколько ролей на одном проекте?
Ну ТЗ есть всегда. Зачастую максимально верхнеуровневое. Нужно на этапе продажи понимать, что и где у Заказчика болит, и что он хочет от проекта. На основе этих данных делается оценка, контракт и начинаются работы.
А уже в ходе проекта начинается "веселье" с выяснением чётких требований, описанием частного технического задания/функциональных требований/технических решений/концепций и прочего. Плюс, как я уже писал выше, Заказчик начинает входить во вкус, начинает лучше понимать, что он хочет, начинает генерировать новые хотелки и изменить старые и тп.
А когда на страте пишется ТЗ объем неопределенности в проекте огромен.
Соглашусь. Рынок IT странно сравнивать со строительством, не смотря на то, что и там, и там есть "проекты". Специфика везде своя.
Хотя не исключаю, что из сферы строительства можно что-то почерпнуть и использовать в IT =)
В проектах с большим объемом неопределенности так сделать в принципе не получится. А в IT каждый второй проект такой.
Да даже если получится, вы в ТЗ будете описывать ЧТО надо сделать или КАК надо сделать? Если описывать только ЧТО, у вас остается большой простор для творчества. Если описывать ещё и КАК, у Заказчика может не хватать компетенций для обсуждения таких вопросов, ну или просто вы такой документ будете согласовывать полгода, если объем информации большой.
Да и в целом подход, когда "Всё согласовали, ушли делать, через год вернулись показали" - это классический водопад. Со всеми вытекающими. Рискуете сделать проект, который никому не нужен. И если вы думаете, что это проблема Заказчика, то вы ошибаетесь, это и ваша проблема в том числе.
А какие есть ещё варианты, если договор Fix Price? Понятно, что надо максимально гибко подходить, но agile - это все-таки про Time&Material. В итоге всегда получается некий гибридный подход, в котором вы верхнеуровнево в водопаде, но внутри стараетесь в эджайл.
За больное задеваете =) Как раз недавно выкладывал тут пост, как мы напоролись на одного такого, который весь проект развалил. Сейчас думаем, как такие вещи выяснять на этапе пресейла.
Управление рисками и ожиданиями Заказчика - это два ключевых навыка, которые я требую от руководителей проектов.
К сожалению, вы правы, с рисками у нас очень плохо работают.
На входе почти всегда требования "не очень ясные". Заказчик либо верхнеуровнево понимает, что он хочет, либо по ходу проекта начинает входить во вкус.
Подходы и инструменты, конечно, подбирать можно. Но если мы это будем делать, чтобы только угодить Заказчику, проект выйдет за бюджет сто процентов. Одного перехода на гибкий подход недостаточно, если не уметь правильно работать с Заказчиком
То есть то, что вы написали, относится не к ИТ? А в какой сфере тогда вы руководствуетесь такими принципами?
Что-то на утопическом)
Не встречал проектов, где на этапе инициации так чётко всё прописывается. Но если вы так делаете - это круто.
С госами соглашусь, с ними почти не работаем, поэтому специфику плохо знаю. Тут больше про B2B.
Ни для чего не существует универсальных механизмов, и каждый случай уникален. тут вы правы. Но нужно в голове держать все возможные шаблоны для дальнейшего развития событий.
Кстати, это достаточно частый вопрос на собесах, можно использовать, как шпаргалку