Избежать овертаймов. Как договориться с Заказчиком?

Разбор кейсов на тему переработок и овертаймов показал, что эта тема является актуальной или болезненной для многих: 3000+ просмотров видео и 60+ комментариев к 2 статьям. При том, что многие не поддерживают этого подхода, работа в дополнительные часы (иногда в ненормальных количествах) остается самым популярным и простым решением проблем проекта.

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

Забегая вперед скажу, что я пересмотрел свой «дефолтный подход» (подход по умолчанию) и теперь первым приоритетом идет анализ и переговоры с Заказчиком, а потом овертаймы.  Изменить свой подход к таким ситуациям с переработками меня заставили 2 случая:

1. Начну с истории, которую можно было назвать «бесстрашием обреченных».

Вместе с моим коллегой мы «продали» проект, конечно же за fixed price, под даты, которые нам назвал Заказчик. Да мы сделали это (хотя это неправильно!), потому что от этого зависел наш бизнес. Через несколько недель мы осознали, что проект не закончится вовремя. Точнее мы не успеем сделать все до указанной даты.

Все простые (внутренние) варианты решений и резервы команды мы уже исчерпали: работали несколько недель по 60+ часов в неделю; отказали в отпуске всем «до выхода из кризиса»; перебросили людей из другого проекта. Запасы ресурсов и вариантов выхода из кризиса закончились  и помощи не предвиделось. Терять нам стало нечего, кроме репутации  и пришлось идти к Заказчику с вопросом об изменении сроков или объема работ.

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

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

Наши аргументы во время переговоров: Мы хотим сдать проект и хотим, чтобы он был нужным и полезным! У нас не хватает ресурсов, чтобы сделать все к этой дате. Денег, чтобы нанять новых людей у нас нет (проект уже не прибыльный) и даже если наймем кого-то, то нужно будет долго вводить их в курс дела. И другие аргументы о качестве и стоимости, которые я приводил от лица «умного Заказчика» в «пути овертаймов». В качестве уступок предложил дополнительный продукт в подарок (без доработок) и значительное увеличение в прозрачности управления проектом.

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

2.       История 2: «Все оказалось намного сложнее»

Мы работали с командой по модели Time&Material, но в рамках «годового бюджета». Хотя все аутсорсеры и называют T&M модель раем, даты релизов никуда не уходят. Бюджет формируется на основании каких-то ожиданий. Большие менеджеры со стороны наших Заказчиков также сформировали свои ожидания по поводу того, что будет сделано в этом году.

Изначально нашей командой была проведена оценка одного из под-проектов. У нас была неделя на оценку. За неделю (работая по 16 часов в день, что было приемлемо для нас троих) мы выжали «the best we can get» и отправили оценку Заказчику. Оценку приняли за базу и мы начали работу. Через пару месяцев стало понятно, что технически мы сделали правильную оценку, но overhead (доп. нагрузка) связанная с процессом разработки и тестирования сделала все наши оценки нереальными. Ожидания на основании наших оценок уже сформированы, но мы столкнулись с тем, что должны делать больше. Были различные варианты решения (см. историю №1), но все они делали проект невыгодным для компании. Да, последующие проекты с этим Заказчиком должны были бы сделать свое дело и окупить затраты. Только до последующих проектов нужно «дотянуть» (не растерять все сбережения и сохранить лояльность Заказчика).  Да и рассчитывать на последующую лояльность Заказчика довольно рискованно: а вдруг проект из разряда «одноразовых»?

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

Рассматривались несколько вариантов: найм дополнительных людей, овертаймы, отказ от проекта, смена команды на более дешевую и т.д. В любом из случаев мы проигрывали. Все равно НАСТОЛЬКО мы не могли изменить объем трудозатрат.  Одним из решений, которое рассматривалось, было увольнение меня как ПМа чтобы потом, свалив все на «неправильное управление» на мои ошибки, можно было бы идти на новый виток переговоров.

В итоге, мы собрали аргументы к переговорам: неоцененный объем работ, специфический для Заказчика (настаивая на том, что технические оценки правильные); указание того, что сроки недостижимы при таком объеме работ; последним аргументом стало то, что нам дешевле отказаться от проекта заплатив неустойку, чем доделать его, но указали, что другие вендоры не сделают проект за меньшее время и тот же бюджет. В результате переговоров команду увеличили, но дату оставили той же. За 10 человек согласился платить Заказчик, за 4 – мы.

Я не зря рассказал об этих историях. Я вынес из них очень важные уроки управления проектами, особенно работы с Заказчиком. Как оказалось, Заказчики готовы к диалогу, когда у вас в руках есть разумные аргументы (ошибки, риски, изменившиеся обстоятельства, новые задачи…). Предыдущие истории стали для меня ключевыми, так как я был в безвыходном положении и отступать было некуда.

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

  • Есть основания говорить о переносах сроков проекта или изменении объемов работ
  • Процесс работы требует пересмотра (организация процесса разработки, тестирования, управления требованиями, …)
  • Срабатывают риски или возникают неучтенные изменения

То есть, руководитель проекта проводит переговоры каждый раз, когда он должен сообщить неприятный факт или изменить ожидания Заказчика в худшую сторону! В лучшую умеют почти все – это не сложно.

Большим неприятным открытием, для меня стало то, что переговорам нигде не учат в курсе проектного менеджмента. Будь то PMBoK, MSF, SCRUM методологии, они все умалчивают об этом! То есть они подразумевают, что Заказчики (а заодно и твои боссы) не люди(!) и они спокойно принимают все логические аргументы и соглашаются с этим. Да не бывает так! Помню, во время одних из переговоров Заказчик кричал, матерился и обещал приехать и разнести наш офис. И угрозы эти звучали очень реально. Тогда я растерялся и наобещал лишнего, что стоило нам очень дорого.

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

Вывод: Нужно признать, что одним из действенных вариантов выведения проекта из кризиса могут и должны стать переговоры с Заказчиком. Ситуации, когда никакие переговоры не решают вопрос – редкость. Чаще всего менеджеры не умеют этого делать (задайте себе вопрос, кто ВАС обучал это делать правильно?) и поэтому наши попытки поговорить с Заказчиком или откладываются на неопределенный срок или приводят к провалу. Ведь Заказчики они же, зачастую, из бизнеса, где переговоры – это норма. А мы (ИТ-шники) не особо опытны в переговорах и поэтому Заказчики выигрывают так сказать «на классе». 

Nov 14th, 2011
  1. Nov 14th, 2011 at 11:35 | #1

    >> работа в дополнительные часы (иногда в ненормальных
    >> количествах) остается самым популярным и простым
    >> решением проблем проекта.

    кстати хотел уточнить – это скорее всего относится к большим корпоративным заказчикам.

    а для средних и мелких проектов самым популярным “решением проблем проекта” остаётся таки перенос сроков, причём часто на морозе, без предварительной подготовки и т.п. с формулировкой “ну не смогла…”

  2. Nov 14th, 2011 at 13:32 | #2

    “Избежать овертаймов. Как договориться с Заказчиком?”
    В такой формулировке цель переговоров – избежать овертаймов.

    Для большинства организаций эта цель не является основной. Зачем же тогда на этом направлении концентрировать усилия?

    Анализ и переговоры с заказчиком – безусловно первый приоритет, но это утверждение ничего не говорит о пользе/вреде овертаймов.

  3. Alef
    Nov 14th, 2011 at 15:55 | #3

    “Терять нам стало нечего, кроме репутации” – а разве репутация не лежит в фундаменте отношений с заказчиком?

    “Наши аргументы во время переговоров:” – ИМХО, история стала бы на порядок интереснее, если бы приводились так же аргументы заказчика

    “В результате переговоров команду увеличили, но дату оставили той же. За 10 человек согласился платить Заказчик, за 4 – мы.” – и чем же все закончилось??? Был ли проект сдан в срок? Был ли заказчик доволен проектом? Сохранилась ли репутация? Были ли другие заказы?

    “Я не зря рассказал об этих историях.”
    :) Я понимаю, что хочу невозможного, но ей-ей, так хотелось бы прочитать истории, а не ОБ историях :)

    • Nov 14th, 2011 at 23:14 | #4

      Репутация хороша и нужна, но когда нечем платить команде, то за “репутацию” готовы работать немногие.

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

      История – рассказ на пару часов. В таком формате не расскажешь всего, тут книгу нужно писать :)

  4. Nov 14th, 2011 at 17:15 | #5

    В младом возрасте видел краем глаза русаловский курс про проведения жестких переговоров. Там много было тем, примеры из фильмов брались. Довольно любопытная штука оказалась. Особенно интересно там разжевывалось психологическое давление наглого и сильного опонента. Мне это даже потом пригодилось когда меня обещали физически закопать :)

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

    p/s
    Вроде в системе дистанционного обучения прометей есть такие видеокурсы. И не стоит забывать про книги по соционике и психологии.

  5. Nov 14th, 2011 at 18:16 | #6

    Сергей, добрый день.
    Спасибо за Ваши достаточно интересные примеры.

    Хотел бы Вам предложить рассмотреть альтернативный (или, назовем, дополнительный) вывод для приведенных Вами кейсов:

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

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

    Почему именно такой вывод? Наверное, для меня это “больная” тема. Я по специфике деятельности работаю на достаточно конкурентном рынке fp-проектов (в т.ч. и тендеры)… Где все еще встречаются конкурентные предложения, в которых продажи это: “сделаем все, что хочет Заказчик в те сроки, которые он захочет, ну и конечно – дешево”, а поставки это: “что-то сделаем в тот бюджет и сроки, которые согласовали и будем упорно доказывать Заказчику, что именно это он и хотел”.
    Понятна удовлетворенность Заказчика после такого проекта…

    • Nov 14th, 2011 at 23:18 | #7

      Валерий,

      Когда контракты заключаетев Вы лично, то предусловие хорошо!
      Если контракты заключают другие люди: сейлы и директора, то ваша роль как ПМа работать с реальностями и правильно говорить с Заказчиком.

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

      НЕЛЬЗЯ верить в то, что можно получить золотую конфетку за доллар! Если Заказчик верит, то он сам себя наказывает. Вам-то зачем такие Заказчики, которые не понимают, что за хорошую работу нужно платить?

  6. Елена
    Nov 14th, 2011 at 19:21 | #8

    В «Путь овертаймов. Часть 2» был еще Высокий Руководитель.
    Хорошо бы конкретизировать —
    кто первоначально договаривался с Заказчиком о работе – сроках и прочем?
    Если Менеджер, то странный какой то он у Вас. Только влетев в овертайм, понял — что надо уметь вести переговоры. Оно конечно,хорошо что хоть когда-то понял…

    А если Большой Руководитель первоначально вел переговоры с заказчиком, то с чего вдруг при провале сроков к Заказчику пустят Менеджера передоговариваться?

    • Nov 14th, 2011 at 21:47 | #9

      Елена,

      Самый главный вопрос: А какая разница в том, кто виноват?!
      Если проект идет плохо, то из него нужно выходить! И делать это должен ПМ!

  7. Nov 15th, 2011 at 12:44 | #10

    Сергей, а можно чуток пояснить вот это: “технически мы сделали правильную оценку, но overhead (доп. нагрузка) связанная с процессом разработки и тестирования сделала все наши оценки нереальными”. Что значит “техническая оценка” (дальше по истории используется такой термин) и почему она не учитывает процесс разработки и возможные доп. нагрузки в нем?

    • Nov 15th, 2011 at 13:07 | #11

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

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

  8. Ольга
    Nov 15th, 2011 at 13:20 | #12

    Умение вести переговоры важно, особенно важно на начальном этапе переговоров, а не умение договориться, когда уже подписан договор.
    Договариваться нужно и в обычной жизни и внутри команды.
    Это бесспорно.
    Просто оба случая – это случаи плохой продажи проекта. Когда не посчитали хорошо и согласились на сумму денег, и сроки не реальные. Выходом является ведение переговоров таким образом, чтобы сроки были исполнимыми.
    Другой момент – когда договор уже подписан, тут нужно разделять риски проекта и риски компании. По моему наступил риск компании – погнались за деньгами, не запланировали, получили суд и штрафы, потерю клиента (ов).
    Ну и как третий вариант – можно конечно команду улучшить и получить результат вовремя. Для этого нужен хороший кризис менеджер, который будет лучше планировать, работы контролировать и оптимизировать, хороший архитектор, способный “выкрутиться” – сделать проще, но соответствующее требованиям и ожиданиям заказчика, хороший техлид, контролирующий, чтобы отдача от каждого участника была хорошая и регулярная. А работать по выходным – зло. Производительность снизиться уже после первых выходных, люди будут отсиживать, а не работать. В тяжелых ситуациях нужна сообразительность, а не присутствие.

  9. RRR
    Nov 15th, 2011 at 18:49 | #13

    Мда, интересная статья, жаль что правды здесь не очень много.
    Мало уметь просто договариваться, надо как минимум, иметь план на несколько шагов вперед, чтобы не оказаться победителем “у разбитого корыта”.
    Проекты часто специально затягивают и раздувают до космических масштабов, чтобы потом, успешно их преодолев, получить бесценный опыт борьбы с ветряными мельницами.
    Мало у кого хватит смелости признаться в собственном дилетантстве, но пафос в том, что если научиться правильно договариваться, то можно даже в этой ситуации для себя получить profit.
    Команда, победив путем шапкозакидательства, часто получает отрицательный опыт, который потом обязательно скажется. Самовлюбленность и самовосхищение (особенно для руководителя) своими действиями в этой ситуации приводит к отрицательным результатам вдвойне, потому что другим будет превозноситься как бизнесс активность приводящая к успеху.
    А клиент, осознав, что дальнейшая разработка ему уже не выгодна, обязательно расскажет о будущих перспективах, потому что это самый простой способ мотивировать исполнителей, потратив минимум денег. Главное вовремя это определить и работать уже “как выйти сухим из воды” вместо “как заработать компании еще больше денег”, иначе будешь везде виноват, а без виноватых, к сожалению, у нас ни одна проблема не решается.

    - С уважением, Ваш друг капитан КЭП

    • Сергей Бережной
      Nov 16th, 2011 at 12:14 | #14

      Уважаемый RRR,

      Любой навык не является самодостаточным. Даже если вы умеете быстро бегать (ну прямо очень быстро), то при выборе неправильного направления бега вы не станете чемпионом мира, и даже “третьеразрядником”.

      Почему вы решили, что навык переговоров в чистом виде РЕШИТ все пробелмы? Да не решит! Это навык, который входит в состав менеджерских скилов. Но сам по себе, он не спасет от всех бед.

      Кстат, по поводу “шапкозакидательства” и самовлюбленности: Если у ПМа обостренное ЧСВ (чувтство собственной важности) на основе спасенного проект, то это проблема ЕГО РУКОВОДИТЕЛЯ (или психиатра). Навык переговоров тут не причем :)

      Искренне ваш, друг Кэпа :)

  10. Михаил
    Nov 16th, 2011 at 11:50 | #15

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

    • Сергей Бережной
      Nov 16th, 2011 at 12:03 | #16

      Ничего странного в проблемах, которые я освещаю: Спросите любого АйТишного ПМа и увидите, что большиство (как минимум 60%) не прошло таких курсов. Я уже не говорю о ТехЛидах и других ведущих технических спецах.

      Про оценку и риски уже отвечал неоднократно, но к Вам есть предложение: если вы умеете делать 100% точную оценку и управлять всеми рисками, то обещаю взять вас на работу. С хорошей ЗП (пишите на почту)

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

Leave a comment