Комментарии 21
Границы можно пересогласовать, а объем можно изменить
Вся дипломатия в конечном итоге сводиться к главному вопросу - кто платит за изменения. Если заказчик на это согласен - прекрасно, пострадают только нервы исполнителей. Согласен частично - он хочет переложить свои проблемы на вас, фактически - ворует вашу прибыль. Т.е. частично доход ваш и вашей семьи.
Если заказчик не согласен - учитесь говорить нет. То, что заказчик будет недоволен, можно пережить. А вот если, раз за разом, маржа от проектов будет снижаться - недоволен будет работодатель.
Ваш первый вариант, когда платит заказчик, а страдают нервы исполнителей, очень часто на моих глазах приводил к выгоранию всеми командами. В худшем случае - команда разбредалась. А поиск команды в текущих условиях - удовольствие крайне дорогое.
Поэтому не всегда ради заказчика стоит рисковать нервами команды. С одним заказчиком мы отлично использовали все методы: и переносы сроков и фазирование и добросить ресурсы, параллельно договариваясь с командой, кто может поработать в выходные, и обещая, что какашка, которую мы сдаем как MVP, превратится во чтото полезное в следующей итерации.
И на моей практике, такие разговоры и занимают бОльшую часть времени РП. А вовсе не перетаскивание колбасок по Гантту. А на курсах я про это нигде не встречал. Поэтому и пишу.
Спасибо!
В целом, было бы весьма увлекательно послушать, чем на ваш взгляд различается работа пм’а в продукте бизнеса и в кулуарах его же (отличия в управлении проектами заказной разработки для «чужих», 3rd party заказчиков, и «своих», например эйчарам резко нужна система для трекинга бюджетов гибких бенефитов сотрудников, а финансам - для согласования платежей).
например, мне кажется, во втором кейсе ярче выражен репутационно-человеческий напряг, «нужно выглядеть непогрешимее», чем в первом. А еще почти нереально получить вменяемое ТЗ, не написав его самостоятельно.
С другой стороны и проекты меньше, проще, и успешный результат видно лучше.
Такая, игра на повышенных ставках ;)
Хорошая тема, кстати, запишу в блокнотик и тоже напишу отдельно.
Если коротко, то отличие только одно, но принципиальное.
Это не ТЗ. ТЗ будет у вас плохое и там и там, если вы его сами не напишете (я в пресейле 15 лет и когда до сих пор я вижу конкурсное ТЗ хорошего качества, мне хочется прыгать и хлопать в ладошки, потому что это бывает 1 раз на 50 где-то).
Это не заказчики. Закачик что во внутреннем ИТ, что на аутсорсе для нас - бизнес. А там ребята не шарят во всем этом ИТ, им надо сделать быстро, качественно и недорого))
Репутация... ну я тоже не заметил. За факап внешнего подрядчика могут грохнуть и лишить потенциальной выручки, а внутреннего сотрудника - уволить. Для меня, как РП и то и то - равно
А вот важное для меня, это отношение бизнеса:
РП заказной разработки - это бизнес единица в своей компании. Он приносит бабки, он их зарабатывает. Поэтому его слушают в его компании.
РП внутреннего ИТ - тратит деньги. Он как муха, летает, грузит вопросами, ноет что-то - отстань, не до тебя вообще.
вот это меня долго задевало, у меня больше внешнего опыта и я привык зарабатывать, а не тратить. Тут можно поспорить, граница зыбкая (экономя деньги бизнеса, ИТ помогает зарабатывать), да. Мой опыт такой.
Если у кого то есть другой - рад послушать :)
Я тоже не сторонник издеваться над исполнителями, сам таким был/бываю. Прямо сейчас веду проект, где многое "дорабатывается по ходу дела". Но по крайней мере, из оплаты хотелок можно выделить средства на лечение нервов.Профилактика только в проработаном ТЗ с начала, полностью согласен с уже высказанным тут мнением. Что не всегда имеем, особенно, когда включаешься в проект не до его начала..
Проработка ТЗ встречается с трудностями, когда проект большой и договор предполагает разработку детальных ЧТЗ. Именно на этом этапе возникают "сложности", когда Заказчик требует увеличить объём работ в разы (а договор уже подписан), а сроки - прежние. РП ему эти "разы" детально расписывает и обосновывает. В ответ - ЧТЗ на меньший объём, чем хочется, не подпишу.
В коммерческой сфере можно поспорить, а в гос. - "суд не принимает к рассмотрению аргументы Исполнителя".
согласен полностью, сталкивался, поэтому с гоструктурами не работаю. А равно - с неадекватными комерсами.
Очень благодарен одному заказчику с большим ЧСВ, который, ничтоже сумняшеся, позвонил как-то в майские праздники и потребовал сесть на самолёт и прилететь, что-то разрулить. После моих объяснений, что у меня с семьёй другие планы, был обруган и проклят. С тех пор с его стороны, когда надо было, звонили младшие чины ))) Знатно сберёг нервы тогда
А вот тут поможет замечательный проектный запас. Размер запаса обратно пропорционален проработанности ТЗ заказчика :)
и на вопрос заказчика: "а почему так дорого" я обычно по каждому требованию могу пройти и рассказть, какие там вопросы есть. Далее смотрю в глаза честно и спрашиваю: "коллеги, мы можем за пару недель с вами проработать все вопросы и уточнить оценку или заложить риски, на ваш выбор".
Собственно вариант по моей статье выше - не говорю нет некачественному ТЗ, я люблю некачественное ТЗ :) просто вот тут и вот тут заложим интеграцию , тут неясно что у вас с процессами, а тут вы не можете определить параметры доступности, потому считаем 99.6.
Оценка и допущения.
На выходе я получаю железобетонную позицию.
Не.
"Проектный запас" тут не помогает никак.
Я уже написал, что все требования в ЧТЗ и трудоёмкости со сроками расписаны руководителем проектов детально для заказчика. А затем несколько раз разъяснены в широком, узком и очень узком кругу Заказчика. На эти разъяснения и детализацию Заказчик отвечает - сделайте мне в 4,5 раза больше и в 2 раза быстрее. О последствиях разбирательств в суде я тоже писал. И "железобетонная позиция" превращается, превращается "железобетонная позиция" - в неустойки.
Конечно, не все Заказчики таковы. Но их есть, тем не менее.
А да. Речь о проектах в десяток+ тысяч человекодней трудозатрат.
Хмм. А вы про IT, да? Десятки тысяч чд (только реальных, а не по оценке, оценивать на такие значения я и сам умею) - это реально немало, особенно если за год.
Тут у меня другой вопрос был бы: а кто работал с заказчиком и почему вот так резко, без причины, вырос объем? По моему опыту это просто так не бывает. Бывает: сходили к министру и чето брякнули. Или от них министр потребовал - чего-то такое.
Тут скажу, что у меня до судов не доходило, было рядом, мы договаривались (речь шла не за десятки тысяч чд, просто за тысячи, но весьма реальные)
Я про ИТ, но не про тетрис.
Объём не вырос. На большие проекты заключаются контракты с "общим" (не детальным) ТЗ. Причина - детализация ТЗ в ЧТЗ требует непосредственной работы с десятками сотрудников Заказчика и достаточно длительной. При этом Заказчик не хочет (а часто и не может) платить деньги по отдельному контракту подготовки детального ЧТЗ (это, как правило, тысячи+ страниц) - "зачем мне эта ваша бумага?". И разработка ЧТЗ включается в общий контракт. Подрядчик же без допуска к специалистам Заказчика на раннем этапе таковое ЧТЗ не может разработать. Детализация упирается в фактически дополнительные требования от Заказчика, которых не было в общем ТЗ с громким криком - а мы без этого не примем. Но этого же нет в ТЗ. А нам надо.
В ходе проекта подрядчик формирует функционал под имеющиеся деньги, согласовывая это с Заказчиком, на что получает всё вышеперечисленное - а вот это и это и ещё под помидоры. Риск? Да. Формируется план на несколько лет с бюджетом. В этом контракте - вот это. Остальное - следующие контракты. Заказчик прикидывает ... и думает, да меня уже не будет к этому времени тут - делайте всё и сейчас.
Эээ ... "брякнуть министру" уже лет 15 ничего такого не получится. Те времена ушли.
Реальность трудозатрат проверяется Заказчиком в помесячных (а иногда и понедельных, но это ...) отчётах, и подписывают функциональщики от Заказчика, которые врать просто не рискуют, ибо проверки. И проверки часто внешние.
Любопытно. Я такого не встречал. Я делал оценки проектов в 15 млн долларов, было дело, на 100 человек на пару лет (плюс-минус). Да, мы прикидывали риски из понимания заказчика, его процессов и слабых мест, оценка заняла тогда 4 недели.
И для меня заказчик, который может прийти и сказать про увеличение в 4 раза после такого выглядит, как факап первичного анализа на стадии оценки. Или заказчик и правда неадекват. Первое я встречал (ошибки оценки), второе - реже, честно. Может, везло.
Разумеется, если заказчик неадекват, то моя статья нерелевантна: если на вас полезли с кулаками, дипломатия не поможет.
Но вообще любопытно, какой у вас подход был.
Классический подход по созданию ФГИС, насколько я его понимаю это:
Разработка нормативки и концепция + ОТЗ: 1-2 года (нормативка разрабатывается годами, это я для простоты)
Затем НИОКР на создание ТЗ для разных частей системы: 1 год
Затем пара этапов на создание: 1-2 года
все вместе занимает 3-4 года. Дробление как раз призвано снизить объем неизвестности на каждый год. То, что говорите вы, отличается: одно ТЗ на несколько лет - рискованная история, конечно.
То, что говорите вы, отличается: одно ТЗ на несколько лет - рискованная история, конечно.
Специфика госфинансирования. Гос. не может выделить денег на часть проекта (в ИТ) с частичным результатом, ему нужен завершённый фиксированный результат. ЧТЗ таким результатом не признаются (из моего опыта). Даже очень большие и подробные ЧТЗ. Для гос. это риск. На этот риск может пойти отдельное предприятие или корпорация. Но. За свои деньги.
и обещая, что какашка, которую мы сдаем как MVP, превратится во чтото полезное в следующей итерации.
Превратилась? Потому что в b2b разработке это должно быть уникальный случай )
За последние 5 лет почти все превратили. Да, иногда ругались с прямым заказчиком (ему надо было быстро), эскалировали на руководство, готовили презентации.
Делать хорошо непросто, но можно.
Я тут увольнялся, мне лид одного направления (душнила) припомнил один модуль, который так и не отрефакторили, хотя я обещал. Было. Но я честно 4 или 5 заходов делал. У бизнеса там строгое понимание, что они не хотят делать нормально, с понятным обоснованием. Ну так бывает.
А вообще, я скажу, что Госуслуги запустились в 2007 году, если мне не изменяет память. И поддержка тогда работала у них через ЖЖ. Оплата штрафов шла у меня 3 месяца )))) это сейчас, спустя >10 лет там идеально вылизанный сервис. Но все постепенно :)
Вы описали уже не PM, а почти PO. И это действительно правильный путь, респект за такой контент. А ещё scrum с госами тоже работает, хоть и противоречит 44 фз и 223му, но там палка о двух концах в детальности тз, оно работает только на взаимном доверии.
Да, все так и есть. Senior PM должен быть PO в моем понимании. Во внутреннем ИТ до продактов были вообще то Сервис менеджеры (по ИТИЛ) - это их роль.
А во внешнем - дальше можно расти в биздев смело.
про противоречия 223 и 44 реальности хочется сказать очень много, но нельзя :) работаем с тем, что есть :))))
Сейчас Сейл, но проекты веду совместно с РП до финала и я полностью соглашусь со всем, тут скорее вопрос подхода человека к миру и к работе в целом, зачем он это делает, это ведь распространяется не только на РП, но и на бухгалтерию, юристов, тех.блок и прочее. Из почти десятка РП в компании мне полностью комфортно работать с одним, мы честно помогаем друг другу, "затыкаем дыры" в проектах и в целом ищем решения, с остальными у меня ощущение, что мне одному надо, чтобы проект случился и я вообще назойливая муха)
Отлично вас понимаю. РП не любят сейлов - те чтото напродавали , а мне - выполняй. Я такое выижу очень часто, да и сам был таким.
Пока не прочитал одну из лучших книжек для РП (я считаю) "черная книга менеджера". Старая уже, но она мне мозги вправила. Сейлз - продает. Если вы не продадите, нам через полгода станет делать нечего и кушать тоже нечего. По крайней мере тут. Так что выгоднее помогать сейлзу, а не ныть. Так и получается командная игра.
И? Где ответ на вопрос заявленный в заголовке?
Порассуждали, рассказали мнение и?
Как сказать нет то?
Посыл в том, что "нет" говорить не надо вообще. Надо обрисовать проблему, показать, какие есть варианты решения и предложить заказчику выбрать самому любой вариант.
Пример из жизни: у заказчика есть 1 млн рублей и невнятное ТЗ на сайт + интеграцию с AD (к примеру, от балды). И надо сделать за 1 месяц. Заказчик говорит - админ есть, он все поможет. И чтобы дизайн был "ух"!
Для меня это как раз отличный пример всего и сразу. Что я делаю. Готовлю варианты
Для классного проработанного дизайна нужна хотябы карта сайта и согласованные блоки - но их нет. Понимая, что вам надо быстро, можем предложить базовые дизайны стандартного движка сайта (в Б24 их дофига, к примеру). Так будет и красиво и быстро и недорого
Опять таки, карты сайта нет, потому я сам предлагаю ограничиться разделами 1,2,3,4 и все - это можно сделать быстро и в красивом дизе
интеграцию в АД сделать вообще не проблема, правда ваш админ сказал, что она не работает, но если он починит - мы сделаем (надо через 2 недели)
Если вас такой подход устраивает - мы готовы сделать.
Смотрите, я не сказал "нет", но я сам очертил границы и задал скоуп, согласовав его. Это работает почти всегда. Исключение - когда заказчик уперся и хочет все таки все все и сразу. Там наступает момент когда можно сказать "коллеги, мы в указанный срок можем сделать Фазу1, а позже - Фазу 2"
(опять нет не сказал, смотрите)
Публикации
Руководитель проектов: как говорить заказчику «нет», когда заказчик хочет слышать только «да»?