• Путь овертаймов. Часть 3. Две истории решения проблемы через переговоры с заказчиком.

    Posted on November 14th, 2011 Александр Орлов 2 comments

    Переработки – это хорошо или плохо? Почему они случаются, как ситуация выглядит с разных сторон – этому были посвящены первые два выпуска сериала Сергея Бережного об овертаймах (часть 1, часть 2).

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

    Сергей Бережной “Две истории переговоров с заказчиком об овертаймах”

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

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

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

    —————–

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

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

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

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

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

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

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

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

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

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

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

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

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

    Резюме

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

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

    ·         Есть основания говорить о переносах сроков проекта или изменении объемов работ

    ·         Процесс работы требует пересмотра (организация процесса разработки, тестирования, управления требованиями, …)

    ·         Срабатывают риски или возникают неучтенные изменения

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

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

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

     

    2 responses to “Путь овертаймов. Часть 3. Две истории решения проблемы через переговоры с заказчиком.”

    1. “мы отправляем к Вам своего человека на переговоры”. http://www.youtube.com/watch?v=U2C5b95tnhA

    2. :) ) Отличный переговорщик этот Брюс Уиллис!

    Leave a reply

    You must be logged in to post a comment.