Comments 41
Исполнитель выбран на условиях честного тендера.
То есть тот, кто обещал сделать дешевле всего.
Это не всегда так. Зависит от условий. Могут выбрать не самого дешёвого =)
Тогда это уже не честный тендер.
Все почему-то усердно перекладывают вину на тендерные условия, мол "выбрали самого дешевого", забывая при этом что "самого дешевого, который может соблюсти требования заказчика".
Если вы в требованиях в тендере не написали "Должны поставить гайки диаметром 10мм и толщиной 15 мм", а только "гайки диаметром 10мм", то жаловаться что выбрали самого дешевого и он привез гайки с толщиной 5 мм - как минимум глупо.
Кто перекладывает? Автор говорит, что выбрали по результатам тендера, потом пишет "Это не всегда так. Зависит от условий. Могут выбрать не самого дешёвого =) " - что само по себе уже не честный тендер, т.к. тендер - это когда выбирают самое дешевое, подходящее под ТЗ.
не факт. в условиях тендера вполне может быть прописан механизм оценки предпочтительности заявки, например, на основе выставленных цен кандидатам присваивается балл (1- самая низкая цена, 2- вторая, 3- третья и т.д.), на основе данных о выполненных работах за предыдущий год кандидатам присваивается балл (1- больше всех суммарная цена выполненных работ, 2- второе место, 3- третье, и так далее), ну и там, возраст компании, например, так же в баллах оценивается. побеждает кандидат с наименьшим итоговым баллом. и при не самой низкой цене первое место может получить крупная контора с долгой историей, а дешевая микроскопическая однодневка- ни при какой цене такой контракт не выиграет. зато мастодонты могут пободаться за снижение цены. и кмк- это вполне честный тендер.
Я из закупок. Тендер - не всегда самое дешёвое. Есть ещё коэффициенты бонус-малус. Не надо все подгонять под простую арифметику.
боюсь, это неправда. Тендер - это тендер по условиям. То, что в результате тендера компания должна сделать согласно ТЗ/требований - это как отче наш. Но есть еще требования с коэффициентами, типа компания имеет аналогичные проекты такой же компетенции, сколько у компании сотрудников по профилю, что есть из сертификатов и так далее - в общем, это так же параметры честного тендера, не только цена. И итог - это кэф*цену, то есть приведенная цена контракта
Где мнение противоположной стороны? Что-то мне подсказывает...ツ
Это интернеты, поэтому придётся основываться только на одной стороне конфликта)
Но, на самом деле, в посте более важны опыт и выводы, которые мы сделали из истории, чтобы другие старались избегать наших ошибок.
Ага. А то чувствую что ПМ который пришел на последние полгода двухлетнего проекта на котором сделано 40% "но не по вине подрядчика" начал вдруг "мешать встречаться и договариваться" естественно, он же видел результаты этих договорняков. Может он просто хотел достичь целей проекта а не потихоньку замести под половичок и подписать бумажки какие все молодцы? Был я в роли такого злого ПМ правда не на этом проекте точно, так как было 10+ лет назад но и ситуация и бюджет примерно такие. И да всех все устраивало, да все сроки про...пущены, да функционал по букве почти дотягивает (но именно почти но это почти сводит ценность проектамк нулю) но всех все устраевает, спонсор проекта все понимает но ему тоже какбэ неудобно, он то полтора года получается непонятно что контролировал...
Тем временем KPI менеджера со стороны заказчика:
20%: Успешное выполнение проекта
80%: Проявлять лидерство (что бы это ни значило)
Без конкретики не читается совершенно. Как задачка по алгебре.
Лицо А препятствует лицам Б и В выполнить пункт 1 договора Г путем действий, не подпадающих под правила Д этики.
Спасибо за конструктивное замечание. Учту это в следующий раз. Но в данном конкретном примере не хотелось давать конкретики, чтобы не подставлять действующих лиц.
Конкретика - это не обязательно имена, должности и название фирмы.
начинает напрямую доносить информацию о некомпетентности Исполнителя, естественно, искажая все факты в свою пользу
Во тут, например, можно было написать: Менеджер заявил, что у исполнителя нет специалистов такого профиля, что он никогда не делал подобные проекты, что его прошлый проект провальный и т.д. (что там менеджер реально доносил?)
Но в статье: "начинает напрямую доносить информацию о некомпетентности"
Нормальный Заказчик всегда назначает РП со своей стороны, но его функция не непосредственное руководство вашим проектом или даже портфелем проектов, а организация комиссий, экспертиз, архитектурных советов для исправления косяков Исполнителя и комитетов по изменениям для исправления косяков концепций и ТЗ Заказчика (и те и другие всегда есть - без них не бывает) и прочих необходимых мероприятий по приемке работ, включая снятие с Исполнителя статусов для корректного ведения претензионной работы. Ведение же матрицы коммуникаций, управление совещаниями, управление заинтересованными сторонами - это всё процессы Исполнителя. Если он этого не делает, то он не проект реализует, а фрилансит - не создает системный программный продукт, а пишет программку, что на порядок дешевле и не имеет бизнес-ценности.
Вот и вопрос к автору: А где настоящий РП, который ВСЕГДА со стороны Исполнителя? Это по какому фреймворку Исполнитель что-то ждёт от Заказчика не на старте, а уже исполнив 40% работ? По изложенному очевидно, что Исполнитель не умеет как минимум в управление проектом - у него есть контакт и с ФЗ и выход на высшее руководство, но он ждёт, пока вместо него его проектом займется кто-то другой.
У исполнителя РП, конечно, был со старта проекта. Более того, учитывая масштабы проекта, в условиях договора прописывалось, что РП со стороны Заказчика должен быть выделен full-time на проект. И даже зафиксировано, что этот РП должен делать.
Всё нормально у Исполнителя и с бизнес-процессами, и с управлением проектами, и с опытом ведения подобных проектов в подобных заказчиках. (понимаю, что без мнения со второй стороны это всё голословно, но исходим из того, что есть)
Про комиссии, экспертизы и исправление косяков - хорошее замечание, тут вы правы. Но эти работы не означают, что больше ничего другого РП со стороны Заказчика делать не должен. Он, как минимум, должен не мешать, а как максимум, прикладывать все усилия, чтобы проект был реализован.
Если же вы намекаете на некомпетентность Исполнителя, то, повторюсь, когда был первый РП работы по проекту шли (да, медленнее, чем планировалось, но там объективные причины с обоих сторон). Когда назначили третьего РП, работы тоже шли, причём очень бодро. А за 10 месяцев присутствия второго РП проект не сдвинулся ни на 1%.
Не факт, что именно один менеджер развалил. Там же куча людей участвовало, наверное. Просто не смогли договориться и правильно оценить риски и сроки. Да и как оценить сроки у современных проектов, если они зачастую настолько сложные и с таким количеством неопределённостей, что никто из сторон сам толком не знает, что в итоге должно получиться?
Ну я в почте написал, что, конечно, не один менеджер виноват, но его вклад, по ощущениям, близок к 80%.
Оценка сроков на больших и сложных IT-проектах - это, конечно, боль. Есть интересная модель - Fix price flexible scope. Сами по ней ещё не работали, но теория мне нравится. почитайте, если интересна эта тема.
договор на поэтапное исполнение и оплату работ выглядит хорошим вариантом в таких ситуациях.
Особенно, если включить в него возможность переоценки дальнейших этапов, чему, конечно, будет сопротивляться заказчик
возможность переоценки дальнейших этапов, чему, конечно, будет сопротивляться заказчик
Там по пути проекта, кстати, могут быть полезны точки, в которых стоило бы остановиться и подумать, а стоит ли вообще продолжать проект. Может, он уже и никому и не нужен стал с момента старта.
Проект и так был очень сложные и долгий, поэтому изначально был поделён на этапы. Я об этом в выводах не написал, так как у нас это было, но замечание очень хорошее
Вы забыли про Гражданский кодекс. Оплату за этап почти всегда можно вернуть при ненадлежащем исполнении остальных. Этапность не про это, а про обход авансирования.
Ох много вы не договариваете. ИМХО шел себе вялотекущий проект на который всем было пофиг. Пришел новый РМ который нашел кучу косяков, исполнитель стал в позу отказываясь признавать косяки. Менять исполнителя не захотели т.к. оплачивать исправление косяков пришлось бы из своего кармана. Спустя 10 месяцев выноса мозга руководству заказчика, согласились хоть на что-то, по-тихому переместив РМа на другой проект. Но даже в таких условиях исполнитель не смог завершить проект.
Откуда такие выводы:
При неадекватных менеджерах, адекватные команды сами находят путь к коммуникации
В тексте прослеживается явная агрессивность "Эскалация", "Исполнитель ликует, враг повержен", " были и другие рычаги влияния на Заказчика ". Т.е. о поиске компромиссов речь не идет вообще. Мы Дартаньяны, а остальные .... ну вы поняли
"хотя на тот момент даже со стороны Заказчика все признавали, что менеджер неадекватный " но общий язык все равно найти не смогли.
Ну и выводы это просто шедевр для "опытного" исполнителя. Пункты 1,2,3,4,6 это база проектного управления. Если вы эти вещи осознали только зафакапив проект, то значит проект был абсолютно не вашего уровня.
Поддерживаю, еще порадовало, что через полтора года, когда уже все должно быть реализовано, и должно быть обучение, опэ и отлов багов, сделаны даже не классические 70%, а 40% по каким-то загадочным объективным причинам. Если причины объективные, то нормальные люди фиксируют это протоколом и допником, в противном случае продолб сроков вдвое странненький. Выглядит как будто новый РП реально не дал замести проект под коврик, но в итоге Заказчик решил, что с таким исполнителем все равно ничего не сваришь, плюнул и закрыл проект.
А вы были в курсе что все счета выставленные в процессе были оплачены? и в полном ли объеме?
я вот потому что видел разок подобные странности, и потом неожиданно узнал почему так происходило
А все просто, в бюджете по статье на этот проект нет денег, вероятно в этом и причине почему внезапно ушел менеджер проекта со стороны заказчика
по статье на какието операционные расходы деньги есть, а непосредственно на разработку нет, завалить проект по вине заказчика это встрять на бабло кактето договорное заказчик логично что не хочет, по этому начинается саботаж и попытки задолбать исполнителя так чтобы он или слился или накосячил так чтобы его официально выгнать с зависшего проекта
А что Исполнителю отвечали в руководстве Заказчика? С ним (руководством/владельцем) вообще разговаривали?
Руководство Заказчика (главный stakeholder всего проекта, на-минуточку) поменяло РП. Почему? М.б. изменились приоритеты? Или произошло что-то ещё? [Тут даже не важно независимое мнение другой стороны, хотелось бы увидеть как это было понято на стороне Исполнителя]. Всё-таки прошло 1.5 года, поменялась бизнес-среда, изменилась расстановка сил внутри компании Заказчика. С руководством кто-то об этом говорил?
С моей точки зрения в список выводов следовало бы добавить пункт 0: Всегда общайтесь со всеми стейкхолдерами. Всеми, без исключения и на регулярной основе. Внимательно изучайте кто у Заказчика поддерживает проект, кто против и как их мнение изменяется со временем. [Это все называется stakeholder management]
Из того что есть в посте, создается ощущение, что Заказчик, недовольный развитием проекта (и не факт что он видел в этом вину Исполнителя), решил понизить приоритет и расходы - и поставил соответствующего РП. Ну 40% сделали и м.б. когда-нибудь доделают остальное. Для заказчика эти 2 млн евро (200млн руб) за 2-3-4 года возможно не сильно значимая сумма и проще спустить на тормозах, т.к. уже не понятно какое бизнес value он получит после завершения работ еще через 2-3 года...
Спустя полтора года работ в проекте со стороны Заказчика увольняется менеджер проекта, на его место берут нового человека. К этому моменту вместо положенных 75% работ было сделано только 40%, поэтому задачи перед ним стояли достаточно амбициозные.
Уже на этом месте интриги не осталось. Чтоб сделать 60% проекта за 25% времени нужно работать со скоростью х2.4 от плановой. С учетом того, что предыдущие полтора года скорость была х0.53, нужно ускориться в 4.5 раза. Так просто не бывает. Налицо конкретный непрофессионализм Исполнителя.
Налицо конкретный непрофессионализм Исполнителя.
не всегда проект тормозит исполнитель
зачастую сам заказчик может не выдавать данные, не предоставлять площадки, застревать на долгие месяцы в согласованиях
Я видел наприме ситуацию когда посреди проекта СБ выкатили требование которые в корне меняет архитектуру проекта (до этого им было норм, а стало ненорм) но "все ТЗ утверждены делаем по ТЗ"...и месяц разборок "почему не работает"... ведь ТЗ написано, а СБ оно не волнует менеджера проекта от заказчика...и вот полгода ничо не происходит и проект стоит на месте.. виноват исполнитель?
Ну смотрите, Исполнитель взял на себя обязательства. Что делает "Исполнитель здорового человека" в такой ситуации - план график, контрольные точки, этапы, карта рисков. При выпадении из графика - разбор полетов по какой причине и работа с этими факторами. Листы разногласий, допники к договорам с изменением объема и сроков. Элементарно сбор доказательной базы для возможного дела в суде. Если договор составлен криво то чтобы максимально рано понять и иметь возможность соскочить за дешево.
Что сделал наш Исполнитель? Первые полтора года из двух по договору Исполнитель не делает примерно ничего для управления проектом. После смены РП на нового человека, Исполнитель вешает на него всех собак. Не на процессы, не на какие-то службы, а на конкретную персоналию. Это как минимум непрофессионально.
И я могу понять нового РП - его ставят на по-факту провалившийся проект. Шансов на успех - ноль. Единственная его опция - поднять бурление говна на такой уровень, чтоб с этим проектом размежеваться. Новый РП требует фактического выполнения того что заявлено как сделанное (а на деле полагаю там половина не работало и держалось на устных договоренностях со старым РП). Команда со стороны исполнителя всеми правдами и неправдами старается повысить % завершенности проекта и не хочет терять время на исправление того что уже сдано но работает криво.
Всё-таки чуть технических подробностей хотелось бы :(
Ибо "строительство условного ЦОДа" - тоже около-ИТшный проект.
Но в нём достаточно сложно успокоиться на 60% выполненных работ.
Нужен завершённый и сданный объект капитального строительства...
Назвали бы хоть что внедряли или что делали, а то так как-бы и интересно но все скрыто.
Это же элементарно:
вместо положенных 75% работ было сделано только 40%
...А фактически принятых наверняка меньше 15%
Решение РП: очевидное, гнать с пляжа такого исполнителя, которое он не смог продавить на уровне первых лиц и пытался сделать это сам и руками команды. Что у него тоже не получилось.
Не удивлюсь если РП при входе в проект обещали золотые горы и полные полномочия, которые так и остались обещаниями со стороны руководства.
Третий РП уже видя что поменять исполнителей не выйдет, стал играть доброго полицейского.
Реализовано в общей сложности примерно 60% от общего объема работ
Вот самое интересное, как эти проценты расценили?
функциональный Заказчик не знал, что он хочет и не был в состоянии принимать решения
Зачем вы вообще ввязались в такую работу? Хотели сделать "как обычно и как 20 раз до этого" и надеялись что примут? Так как техзак показал себя тряпкой и вы думали что ему удастся впарить то, что получилось?
Спустя 2 месяца достучались до СЕО, (подозреваю, что дали по шапке новому РП)... Исполнитель ликует, враг повержен, можно продолжать дальше нормально работать.
То есть на про...пущенные 75% срока (1.5 года со старта) и при почти полном отсутствии закрывающих документов вы называете "НОРМАЛЬНОЙ РАБОТОЙ"????
Вы сделали хорошие выводы для себя, такие как: утверждение первоначального ТЗ, контакт-лист участников, организация документооборота, ведение протоколов, даже про психолога не забыли.
А что вы бы посоветовали РП2, ну вот просто попробуйте сначала со своей позиции не меняя ничего в вашем мировоззрении. Мне реально интересно.
P.S.
Если что я не тот РП2, я вообще не из IT сферы, а мои проекты оцениваются миллиардами, пока рублей правда. В моей практике были более 5 таких кейса где я был РП2 и во всех пришлось менять РП со стороны исполнителя, часто по 2 раза, и на треть непосредственных специалистов. После чего проекты в 70% случаев успешно завершилась. Причем, те 30 неудачных, это были следствием внутренних проблем заказчика, когда отсутствовала поддержка руководства чтобы до конца дожать исполнителя на смену неэффективных РПисполнителя и специалистов.
P.P.S.
Т.к. я сейчас ввязываюсь в новый проект с 75% срока и на 40% выполненного (почему это соотношение прям магически повторяется) ваша публикация мне прям очень актуальна, в плане переосмысления моего опыта и первых шагов в нем.
Прям большое человеческое спасибо.
Понабирают по объявлению.
Извините, но не верю. Как может вообще один PM развалить команду? Это не армия, не гос и не поехавший гендир. У остальных лапки, они не могут работать без менеджера? Любая адекватная команда пошлет неадеквата и самое простое будет общаться в своих чатах, а самое плохое, уйдет половина.
Вы считаете что команда это всегда единый самоуправляемый организм и у всех скрам всегда?
однако это далеко не всегда так, далеко не все любят скрам, плоские структуры и работу без менеджеров
также у плоских команд есть вполне объективные проблемы с управлением проектом, они требуют только квалифицированного персонала чтобы оно хотябы базово работало
Я работал на проекте где были ВСЕ сеньоры и не было тимлидов, был полноценный скрам и несмотря на нацеленность комманды на результат и обсуждение внутри и вся вся эта биирюзовая чепуха что люди все лучше знают сами... в коде в итоге генерился изолированный атомарный код который зачастую дублировал друг друга, потому что некоторые участники и целые команды не считали нужным упарываться во взаимодействие с коллегами, комуто в целом лень было выходить за рамки задач от ПМов
в остальном где я видел, если в команде джуны и миддлы и проект какойто 'скучный' (какойто ентерпрайз или сугубо технический сервис), они зачастую не сильно заинтересованы в проекте как таковом чтобы бороться с чужим ПМом
p.s. я работал в компании где был такой ядовитый ПМ, у нас ушли из команды два аналитика и несколько разработчиков... мне сложно представить что было в голове у топов нашей компании но видимо такой проект был важен раз таким образом к нему относились
p.p.s. не стоит работать в галерах если нет какойто определенной цели это делать специально
они требуют только квалифицированного персонала
Я работал на проекте где были ВСЕ сеньоры
Ваша логическая ошибка тут. Не сеньорность определяет слаженность команды. Это очень большая тема про софты и все такое.
Если конечно смотреть на PM еще и по аутсорсу/аутстафу, у меня компаний за карьеру было не так много, но проектов за 30 и ни разу не видел, чтобы именно от PM зависела разработка.
Пример №1, PM нет или они часто меняются. Экспертиза и аналитика размазывается между тимлидом и продактом, +X% к таймтумаркету, полимеры целые, команда целая, никто не выгорел.
Пример №2, PM есть, но не вмешивается в техническую работу. Периодические срачи с заказчиком по графику релизов дают +Y% к таймтумаркету, все работают как работали.
Ваша логическая ошибка тут. Не сеньорность определяет слаженность команды.
слаженная комманда джунов сделают такой продукт что его проще будет выкинуть чем использовать, сеньор в данном смысле нужен потому что он знает как делать нельзя, а в условиях когда нет лидов и начальников..никто не остановит команду которая начнет хрень делать какуюто
но проектов за 30 и ни разу не видел, чтобы именно от PM зависела разработка.
ПМ иногда управляет бюджетом и приоритетом задач
в моем случае ПМ отстреливал задачи в беклоге со словами "мы за это платить не собираемся"
бывает очень по разному, я был в ситуации когда все хорошо, когда средне и когда все плохо
и вот когда хорошо - бывает нечасто
Тезис был к тому, что для слаженной команды PM не сильно то и нужен, а если и есть, то просто усиливает, не давая каких-то уникальных бонусов. Слаженные джуны такой же провал как и неслаженные синьоры. Так что да, можно поверить в правдивость истории, с поправкой что команда изначально была настолько слабая с организационном плане, что там именно PM командовал парадом, работая и лидом и аналитиком. Можно предположить что и вся компания скорее всего так выстроена. Я просто знаю примеры, когда команда не то что PM-ов, а неподходящих тимлидов выгоняла на мороз. Но история выставлена так, что кривые процессы и рекрутинг превратились в "к нам пришли и все развалили".
Я клоню к тому что ваше видение команды скорее идеализировано. такое бывает далеко не всегда в реальности
выгнать тимлида это норма, поскольку это линейный специалист. А вот ПМ это уже человек частично от бизнеса и представляет его интересы, который имеет совсем другие точки зрения на проект чем команда разработки. по этому мнение команды разработки зачастую не должно влиять на продукт в отрыве от остального бизнеса
я соглашусь что тут проблема в кривых процессах и провалов вышестоящего менеджмента...но боюсь что это общая проблема почти для всех, я вот почти везде сталкивался с проблемами коммуникации между департаментами или соседними командами и отдавать решение этой проблемы на откуп команде..это довольно наивное решение
Статья интересная, спасибо. Призывает к размышлениям. Второй стороны не хватает, конечно. По ситуации-РП разные бывают, со стороны исполнителя и со стороны заказчика могли реально быть рукопопы.. Тут однозначно не скажешь, надо ситуацию знать. Но вот как РП имеющий опыт и там и там, могу сказать, что например работая на стороне Заказчика, ооочень часто приходилось управлять не так, как считаешь нужным и говорить то, что ранее спустилось с вышестоящего руководства..при этом вышестоящее руководство могло присутствуя на этих же встречах искренне делать вид - «да я такое первый раз слышу, да что ты говоришь» и параллельно где-то в чатике наставлять-а-ля «не реагируй, я это специально говорю».Поэтому тут еще подумать надо, а РП ли виноват. Возможно, он и был тот самый «крайний» , виноватый, не имеющий возможности вообще на проект влиять «от себя»
История о том, как один «эффективный» менеджер проекта может развалить проект на сотни миллионов рублей