Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Как я справился с бойкотом от заказчика

В этой статье я описываю, как вышел из крайне нестандартной ситуации, в которой даже коллеги с большим опытом ведения корпоративных проектов затруднились что-то посоветовать.

В момент происходящего я был в роли руководителя проектов. Наша компания разрабатывает программное обеспечение на заказ. Работаем в основном с финансовыми институтами, банками, товарными и фондовыми биржами.

Иллюстрация Алины Самолюк

Мизансцена

Осталось несколько дней до сдачи проекта заказчику. Мы находимся на стадии приемочного тестирования, но из-за особенностей отношений с клиентом часто переписываем части проекта. В принципе не особо критично, но на сроки, конечно, влияет. Очень часто приходится работать допоздна и в выходные, чтобы это компенсировать.

Например, несколько раз переделывали аналитический график, потому что никто до конца не понимал, как он должен выглядеть и какие данные должен показывать. Какие-то отсылки к существующим решениям, которые мы приводили, игнорировались. Но это обычная ситуация при разработке на заказ.

Во время очередного конф-колла с руководством заказчика мы отчитались по проекту, обрисовали ситуацию, взяли на себя ответственность за косяки, обозначили, что от представителей бизнеса клиента иногда приходят несколько противоречивые указания, которые вынуждают сдвигать сроки и тому подобное. В общем, ничего нового — все как во всех проектах.

Надо сказать, что сроки проекта были «экстремальными». За два месяца мы должны были переписать существующее решение, в связи с чем было много технических проблем, которые мы сами выявляли и исправляли. Поэтому то, что от клиента уже несколько дней не было сообщений, мы заметили не сразу.

Первое, что приходит в голову: там просто все расслабились после того, как мы отчитались руководству. Не страшно, думаю, надо просто напомнить о себе. Пишу что-то вроде «коллеги, напоминаю, что незакрытыми остались такие-то вопросы, мы делаем то-то, обновимся тогда-то». Ответа нет. Задаю адресные вопросы, реакции — ноль.

Так продолжалось день-два. Напомню, что мы нашли много косяков. То есть работа кипит, мы периодически обновляем разные модули, пишем заказчику, но никто не отвечает.

Конфликт

То, что все представители заказчика просто решили не вести дальнейшую коммуникацию с нами, мы поняли не сразу, учитывая абсурдность ситуации. Однако в определенный момент это стало невозможно отрицать.

Причем в бойкот, по всей видимости, вошли все участники проекта: бизнес, аналитики, проектный менеджер и руководитель IT!

На встрече проектных менеджеров, которая еженедельно проводится в нашей компании, я обрисовал руководству ситуацию, попросил у других PM’ов совета, что можно сделать. Но максимум, что рекомендовали — это позвонить директору IT со стороны заказчика и поговорить. Но мои звонки оставались неотвеченными.

Отступление

По понятным причинам я не могу назвать заказчика, но это крупная организация с миллиардными оборотами и сотнями сотрудников. То есть вполне адекватный клиент.

Игнорировать ситуацию нельзя, так как за сроки отвечает наша компания. Причем я как руководитель проекта лично писал план-график работ и защищал его перед самым высоким руководством заказчика.

Несмотря на то, что я не имею MBA и не читал (еще) PMBOK, все же за плечами у меня более 10 лет опыта руководства разного рода. За свою жизнь я руководил и логистическими процессами в производственных цехах, и торгово-производственной компанией, и продуктовыми магазинами, вел непростые переговоры с региональными властями, силовыми структурами, руководителями крупных местных и иностранных корпораций. И при этом всем к «обиженному» клиенту я не был готов.

Здесь важно подчеркнуть, что ситуация осложнялась карантином, к заказчику просто нельзя было куда-то приехать, а на звонки и письма он не отвечал. Сообщения прочитаны, ответа нет. Позади уже три дня молчания на самой критичной стадии проекта.

Кроме того, надо понимать, что к этому моменту проектная команда уже несколько месяцев работала со значительными переработками и новость о том, что сдача проекта под угрозой, критично отразилась на обстановке в коллективе. Никто не хотел, чтобы все было зря.

Анализ ситуации

Чтобы понять, что с этим делать, надо выяснить, что к этому привело. То есть ретроспективно проанализировать, когда ситуация поменялась. Последний момент нашей коммуникации — отчетная встреча с руководством заказчика. Тогда мы рассказали о статусе проекта.

Не знаю, с какого момента, но в нашей компании принято вести запись переговоров с заказчиками. Это много раз помогало разобраться, так как зачастую разные участники одной и той же встречи могут совершенно по-разному толковать произнесенное на ней.

Причина конфликта

Причиной бойкота оказалось то, что в ходе отчета я указал, что от представителей клиента поступают противоречивые указания, что не дает гарантировать сроки проекта. Это с их стороны никак не было прокомментировано. И тем более не вызвало никакой острой реакции ни у наших коллег, ни у их руководства.

То есть сотрудники заказчика, очевидно сговорившись, решили, что лучше никак не вести проект дальше, вместо того чтобы давать какие-то предварительно проработанные замечания, которые не будут приводить к постоянным переделкам, плодящим ошибки.

Кульминация

Итак, что мы имеем:

  • проект, который должен быть сдан в течение нескольких дней;
  • представители заказчика, которые с нами не коммуницируют;
  • множество вопросов по бизнес-логике проекта, требующие согласования со стороны «обидевшегося» заказчика.

Что нам нужно:

  • согласовать некоторые бизнес-решения;
  • запустить проект;
  • не обострять взаимоотношения с руководством заказчика.

Надо сказать, что компания клиента существуют очень давно, и за это время в ней сформировалась внутренняя «экология», которая позволяла многим избегать принятия решений и не возлагать на себя какую-то ответственность. То есть можно было затягивать принятие решений, делегируя всю ответственность какому-нибудь бедолаге, который персонально отвечает перед высшим руководством за сроки и прочее.

В этом проекте таким бедолагой был я.

Иллюзия выбора

Когда-то я читал статью об иллюзии выбора, когда от постановки вопроса зависит ответ респондента. Рассматривалось это на разнице в количестве людей, которые согласны на донорство органов в случае смерти, и тех, кто против. Там, где вопрос ставился таким образом «Согласны ли вы на донорство органов...», было значительно меньше доноров, нежели там, где вопрос звучал иначе: «Отказываетесь ли вы от того, чтобы стать донором...»

Я не помню всех деталей статьи, но суть была в том, что людям проще не ставить галочку особенно в критических вопросах, потому что они таким образом вроде бы «не принимают никакого решения».

Возвращаемся в ситуацию

На текущий момент решение не готово к публикации, хотя все более-менее критичные технические проблемы решены, остались только вопросы, не согласованные с точки зрения бизнес-перспективы. Это могло снова привести к переработкам, что само по себе не критично: ресурсы в проекте на это были, однако мотивация команды упала, коллеги начали обсуждать, что не будут больше оставаться допоздна и работать в выходные.

То есть под вопросом была не только сдача проекта, но и моя персональная репутация внутри команды. Вроде все бились за результат, а в итоге все выглядело так, как будто руководитель проекта поругался с заказчиком и всех подвел.

Все сводилось к тому, что необходимо было заставить заказчика выйти из бойкота, при этом нельзя было прибегать к эскалации, так как непонятно, как это скажется на отношениях с высшим руководством. Свои сотрудники все же ближе, и если нажить себе сразу так много врагов, не только этот проект пострадал бы, а вообще все. А в перспективе их было достаточно. При этом нельзя было падать в глазах собственных коллег, ведь в ситуации, когда все измотаны, важнейшую роль играет авторитет руководителя.

Задача была найти такую постановку вопроса, в которой молчание было бы принятием решения, со всеми вытекающими из этого последствиями.

Пишу в общую переписку: «Коллеги, мы решили все технические проблемы и, если никаких возражений нет, готовы к публикации уже сегодня. В течение двух часов мы подготовим письмо и отправим на согласование».

Главная часть сообщения — «если возражений нет», то есть молчание с их стороны уже является принятым решением. При этом я не шел на открытый конфликт, но обрисовал жесткий дедлайн, не дав прийти к еще каким-то кулуарным договоренностям.

Сразу после этого очнулись все, кто только мог, потому что понимали: то, в каком виде решение выходит в свет, не проработано именно со стороны бизнеса. Переписка стала даже более активной, чем была ранее. Мы в течение следующих дней получили ответы на все вопросы, причем некоторые даже в выходные дни.

Отношение ребят внутри компании тоже изменилось. Нельзя было не заметить разницу не только в активности заказчика, но и в тоне коммуникации — все вдруг стали вовлеченными. Это положительно сказалось на внутренней обстановке в коллективе, и наши коллеги тоже закатили рукава.

Заключение

Справедливости ради стоит признаться, что проект еще не был сдан около месяца, однако мы не получили никаких серьезных замечаний от пользователей после запуска, наладили коммуникацию с заказчиком и, самое главное, остались с ним в хороших отношениях, а проект существует и развивается по сей день.

В итоге после запуска проекта, несмотря на наличие конфронтации, я получил благодарность со стороны заказчика как «уникальный и лучший руководитель проектов».

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось50
До обраногоВ обраному14
LinkedIn

Схожі статті




65 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

А в это время вся команда от заказчика просто отмечала китайский новый год.
За историю спасибо, познавательно.

Молодца! Всё правильно порешал, я обычно действую так же в в подобных ситуациях (без жесткача, как тут — обычное человеческое головотяпство и пофигизм):
1. Письмо в стиле «слушай, надо вот это у тебя узнать». Молчание.
2. Письмо «ты не ответил на вопрос, сроки поджимают, нам нужен ответ». Молчание.
3. Письмо «у нас дедлайн по задаче такой-то. В случае отсутствия ответа мы считаем, что эта функциональность работает вот так. Если наши предположения неверны — пожалуйста укажи это в ответе». И, внезапно, ответ приходит :)

Ситуацию нельзя назвать необычной, а решение уникальным, не часто, но встречается.

Но зато что автор, подробно обрисовал ситуацию, описал интригу и создал атмосферу триллера, а потом в доступной форме описал решение, респект и уважуха! :)

Из комментариев стало понятно что вам проект нужен был для открытие окна возможностей чтобы получить других жирных проектов.
То есть ваша мотивация как руководства понятна.
Так же в статье описаны овертаймы и работы на выходных.

Подскажите, как команде объясняли зачем им это нужно?

Материально, интереными задачами, инновационным продуктом, бесценным опытом?

Ну например, руководитель может оставаться с командой на овертайм и покупать команде горячий ужин за свой счет и потом развозить по домам, это очень мотивирует.

А ему это зачем?

Чтоб мотивировать же.

Зачем это самому руководителю?

Получить повышение или бонус за успешную сдачу проекта

Опять таки — Руководитель готов что угодно делать. У него прямая и понятная мотивация.
Команда может и дома поужинать, ужин так-то не в ресторане мишлен ;-)

это также мотивирует искать работу без постоянных овертаймов и с зарплатой, позволяющей оплатить собственный ужин

Тоже верно. Ведь стакан всегда наполовину.

Кому-то стек проекта понравился, кому-то надо было строчку в резюме, кому-то деньги на новый мак. Каждый получил своё, кто-то — репутацию внутри компании. Все очень индивидуально.

Кто-то просто терпит, потому что так надо. Зато на ДОУ все крутые, спасу нет.

Такая стандартная ситуация для фикспрайса в условиях аутсорса, что прям страшно.

За свою карьеру насмотрелся на вот такие замечательные проекты, потому готов с уверенностью могу заявить — это самая обыденная и шаблонная ситуация, которую только можно представить.

Проблему с коммуникациями получили по одной простой причине: все риски и условия приняты вашей стороной и закреплены в контракте.

Объяснение бизнес логики и помощь в создании документации в таком случае скорее проявление доброй воли стороны заказчика, а не его обязанности. Если в контракте есть еще и штрафные санкции за сорванные сроки, то это отличный мотиватор сэкономить на расходах отдела и при этом все равно получить результат.

Раз источник риска это тип контракта, то и работа с такими рисками производится в момент подписания контракта. Не перед релизом.

Ну и это, не подписывайте контракт на фикспрайс до момента выявления всех деталей и формирования утвержденной документации)

Кровавый энтерпрайз никогда не даст всех деталей. Ибо там >100 субподрядчиков со своими командами, и чтоб выяснить все детали — надо всех опросить, а когда опрос будет закончен, то часть информации будет из него уже не актуальной, так как за время опроса взяли еще пару десятков новых субподрядчиков, пару десятков закрыли свои подряды и сменилась куча разных сотрудников, которые понятия не имеют, что именно вы там делаете и зачем оно нужно.

Скорее всего в этом кейсе и произошло что-то подобное.

Кровавый энтерпрайз способен дать достаточно деталей для реализации большинства проектов.
Но для того, чтобы уточнить «все детали» о них нужно подозревать и спрашивать заказчика о них.

А представителю заказчика тоже дают не всю информацию.

То, что вы нашли выход из ситуации — отлично. Но мне интереснее, как вы в нее попали. Вы пишете, что причиной

оказалось то, что в ходе отчета я указал, что от представителей клиента поступают противоречивые указания

Рискну предположить, что причиной могло оказаться не что вы сказали, а как. Эта классическая проблема наших ребят, когда они общаются с западными заказчиками и ведут себя так, как они бы вели себя на обычном внутрикомандном митинге. После чего наши уезжают с чёткой уверенностью, что смогли донести всю суть проблемы и на той стороне все поняли. А «та сторона» переживает весь спект эмоций от злости или негодования до банального страха («боже, с кем мы связались?»). Наши умеют так попросить о чем-то, что на той стороне могут обидеться и костьми лягут, чтобы просьбу саботировать. Просто различие культур (см. Эрин Мейер «Карта культурных различий. Как люди думают, руководят и добиваются целей в международной среде»). Пара минут small talk, критика в стиле shit sandwich, словарный запас для _уважительного_ несогласия и возражения могут творить чудеса. Еще раз, я только предполагаю, что могло бы стать настоящей причиной, свечку я не держал.

Тут плюсую с двух рук

только вот автор из компании, работающей на пост-совок

но за шіт сендвіч дісреспект

Впечатление от щит сендвича очень разное, в зависимости от того, вы его готовите или для вас его готовят)

Вы и Андрей Роговский указали очень ценное направление, если решение от автора не только ценно, но и проблема предсказуема, то вот каковы должны быть дальнейшие шаги, пожалуйста? dou.ua/...​rums/topic/33538/#2136258

Интересный выход из ситуации, и история очень жизненная, спасибо за статью! Вопрос такой — в течении всего проекта, насколько тесная и дружеская у вас была коммуникация с руководством клиента (то что начало бойкот)? И что бы вы сейчас сделали в начале, чтобы до такого не дошло?

В самом начале обстановка была рабочей. Испортилось все именно из-за того, что мы указали на их ошибки (противоречивые требования) на уровне их руководства. Как бы «нажаловались».
А формулировка была такая:
«Работаем, есть наш эти косяки — исправляем, по срокам — тяжело попадать, из-за переделок, которые инициируются вашими коллегами.»

да це було тупо, вони просто подумали шо ви всю вину на них спихаєте, не можна бавитися в гру чия тут вина, всетаки колаборація

Не знаю написали вам уже или нет, но вы выстрелили себе в ногу. Ну и вся статтья соответственно о том как «я куда-то выстрелил, получилось в ногу, сначала ходить не мог, затем сам вытащил пулю, обработал рану, и зажило».

Исправили вы вроде как правильно, хотя другой вариант — эскалировать уровнем выше и взять кого-то из коллег для отыгрыша в «хорошего полицейского».

Вы также очень много оговорились о проекте, что характеризует его как нездоровый: жесткие сроки, отсутствие стабильных требований, переработки. То есть вы заранее уже зарядили себе пистолет, выстрел в ногу для вас был только вопросом времени.

Спасибо за классный кейс!

Всё прекрасно, но только одно осталось не понятым, после вот этого проекта вы «зашли к клиенту» и что, дальше всё это мозголюбство, закончилось и больше не приходилось «всё переделывать, сдвигать сроки и овертаймить»?

Перманентного эффекта конечно нет. Просто решили локальную проблему, дали результат.

Отказываться от заказчика который не «клюет мозг» — отказаться почти от всех заказчиков.

А про «зайти к заказчику» — положительный опыт сотрудничества в таких компаниях даёт преимущество на перспективу. Хотя, Говоря откровенно, больше Проектов не было.

Никогда не овертаймить — круто. Если есть компании гарантирующие своим сотрудникам такие «стерильные» условия Работы — очень здорово. Но у нас не так, по крайней мере пока не так

Достаточно не брать fixed price для начала.

Овертаймы овертаймам рознь. Понятно, что совсем без них — только верхом на розовых единорогах. Раз в пару месяцев надо что-то срочно доделать из-за внезапных ситуаций — это можно понять и простить, а если у вас политика управления а ля «ребят, мы тут подписали @#!вый контракт, поэтому следующие 3 месяца вы будете безбожно овертаймить и переделывать по пять раз по прихоти клиента» — это, конечно, тоже понятно, но вот не простительно вообще ни разу.

Да уж, звучит и правда в стиле «овертаймить плохо, но мы овертаймим и гордимся этим».

Автор пытается доказать, что работа это прямо какая-то драма, требующая постоянных овертаймов и это норма, по другому не выжить. А выглядит все так что в погоне за клиентами, они же сами себе эти условия и создают. И политика управления действительно похожа, на ту что вы описали.

Могу ошибаться конечно.

Но далеко не везде такой подход, так что с точки зрения хорошего специалиста, это явно не повод оставаться в компании.

Коллега, очень правильный ход! Лучше принять неправильное решение, чем никакого.
Руководителя от подчиненного отличает то что он понимает последствия и старается минимизировать риски даже принимая непопулярное решение.
Запишу вашу историю в свою копилку. Удачи вам на проектах!

Руководителя от подчиненного отличает то что он понимает последствия и старается минимизировать риски даже принимая непопулярное решение.

Точно-точно? А не фигню ли я прочитал?

Спасибо большое, и вам удачи!

Интересная история. Но все же в итоге, команда работала с овертаймами, сроки подвинуты на месяц, но все закончилось хорошо и менеджер — молодец?

Нет, конечно.
Однако, перед проектом, я всей команде поставил вопрос, согласны ли они на то, что придётся перерабатывать или нет.
Не считая «коллективной ответственности» обязан никто не был. Уйти мог любой, один и отказался, без последствий.
Сроки, да сдвинули в итоге. Но, опять же, по причине разных требований от заказчика. И мы об этом объявили.
Нет я не считаю что я хороший PM (в этом конкретном примере), я написал это чтобы показать признание от тех, с кем была хоть и холодная но все же конфронтация.

Овертаймить или уйти? Звучит, как ультиматум, а не предложение, которое хоть как-то выгодно вашим коллегам.

Уйти не из компании, из проекта)))) в другой проект

Вот тут подход очевидно неправильный.
Вы берёте проект, который очевидно не закончить вовремя с текущей командой даже в случае идеальных условий? Эт оч зря.
Я вижу 2 возможных расклада, как надо было выходить из ситуации:
1. На этапе согласования объяснить, что низзя построить коллайдер на вчера и оговорить вменяемые сроки.
2. Увеличить размер команды. Опять-таки, до старта проекта. Просчитав все риски от задержек и боттлнеков типа «ключевые люди на той стороне недоступны», «спецификации неточны», «есть спайки, которые низзя распараллелить».
В любом случае, идти на проект с открытыми глазами, а не «денег насыпали, ввязываемся в драку, а там разберёмся».

Ещё в старину, признаком очень рискового проекта был отказ заказчика согласовать и подписать «Устав проекта», в котором в первых пунктах прописан ответственный со стороны заказчика который обязан разруливать все со своими там. Или поставлен такой,который никаких прав у себя не имеет, и все свои могут смело посылать его на йух

Скорость с которой заказчик предоставлял такого человека со своей стороны, тоже подсказывала о том что у них там за отношение к проекту. Как и загрузка этого ответственного другими активностями, препятствующими оперативному реагирования, не говоря о выполнении одной из главных ролей — продакт овнера.

Мы изначально знали что проект с рисками. Он нужен был на не только ради просто денег. Надо было «зайти к заказчику» Проектов там много, а аутсорс только так и выживает

Это очень меняет дело. Этой детали не хватило в вашем рассказе.

Скажу так, за 15+ лет в управлении проектами еще ни разу не удавалось «зайти к заказчику» с неадекватными рисками и командой заказчика. С горем пополам закрыть проект да, но построить что-то большее — почти никогда.

Вроде взрослые люди, речь о больших бабках а обижаются как школьницы.

Мы находимся на стадии приемочного тестирования, но из-за особенностей отношений с клиентом часто переписываем части проекта. В принципе не особо критично, но на сроки, конечно, влияет. Очень часто приходится работать допоздна и в выходные, чтобы это компенсировать.

Хз, все менеджеры с которыми я работал сразу поясняли заказчику что каждая фича и переделка это доп время и перенос релиза. Овертаймы хоть x2 были? :)

и не читал (еще) PMBOK

в PMBOOK ничего такого и нет. Это вообще базовая книга которая объясняет «что по чем». Что такое проект, программа, портфель и т.д. Что необходимо для достижения целей проекта — т.е. в первую очередь наличие четко определенных цели и показателей их достижения и т.п. и далее по списку. Кстати очень хорошая формализованый документ который всем рекомендую прочитать в независимости от специализации. Cook Book — ка по решению ситуаций там нет, в отличие скажем от Де Марко Deadline.

Молодцом, реверс-инженернул ака боженька!

Вроде бы история закончилась хеппи-эндом, но в целом и в деталях очень хорошо напомнила за что я не люблю аутсорсинг :)

Совершенно тоже самое может быть и в продукте. Если компания большая, есть некая несогласованность (интриги, перестройка процессов и так далее), то вы как инженер можете получить совершенно тоже самое. на раз:
отдел а считает, что надо так, отдел б — так, а на просьбу определиться начинается перекладывание о-ти и так далее.

В продукте не может быть так. На всяких таких «обиженных» всегда можно будет найти управу через вышестоящих.

Нет. Иногда нельзя.

Да. Всегда можно, если ты — ключевой специалист со своим ноу-хау.

Это «политиканство обыкновенное». В продукте этого даже еще больше может быть. В моем случае клиенты оборвали все линии связи при массовом появлении на рынке x86-64 процессоров. Приложения у всех из за нашей либы крешаться. Настаиваю — давайте делать x86-64 версию, в тихую сделал прототип на выходных. Но — нет, не дают потому что отдел продаж оттягивает x86-64 как отдельный релиз, за который хочет выставить лицензию не входящую в бесплатное обновление. Вот на меня спускают всех собак на сапорте — причем так что нет времени пилить эту самую 64-ти разрядную версию и т.д. Короче все тоже самое — психологическое давление c целью достижения собственных финансово политических целей. С аутсурсинговым фиксет прайсом — по идее на договоре профукали, его подписали из опасений что подряд отдадут конкурентам. По накатанной схеме заказчик — начал подсовывать «доделки» не принимая систему мотивируя чем угодно. Аутсафинг, где time and material — делают тоже самое но через «адские сверх-сроки». Технология такая — понижают эстимейт на планингах в том числе через «само эстимейтинг» (когда эстимейт тебе спустили сверху и требуют в него уложится). Таким образом выставляют команду на объем работы котороый ведет к бесплатным овертаймам. Тут воздействуют на психику по другому — ежедневным напоминанием кол-ва дней до конца итерации и состоянением по каждому из тикетов и т.п. Планируемым количеством стори-пойнтов на разработчика и т.п. По идее хороший менеджер это парирует, плохой — всегда «поддакивает» клиенту или вообще ничего не делает.

1. Это был fixed price?
2. Кто выдвигал условия по срокам?

Да, фикс. Но риски и овертайм мы закладывали.
Сроки мы ставили сами, но от заказчика сверху «попросили уложиться в другие». Мы пошли на риски, но предупредили, что все, особенно команда заказчика, должны показать вовлечённость.
Изначально проект засетапили неправильно, и это полностью моя вина, но нам нужен был этот проект, чтобы «открыть окно» с заказчиком.

Теперь понятно. Коллективизация ошибок и приватизация достижений.

Вот здесь и ошибка.
Хотят другие сроки? Не вопрос. Давайте другие деньги, возьмём команду в 3 раза больше.

Очень жизненная и толковая история, спасибо !

Підписатись на коментарі