Managing Customer Expectations (или когда говорить “нет”)

Вот 5 минут назад обсуждал с камрадом ситуацию, которая наверное для многих знакомая – есть команда, работает на Заказчика 2недельными спринтами, 6 человекIMG_0278, соответственно сухой остаток – 480 часов рабочего времени в спринт. Вот отработали очередной спринт, посмотрели сколько отрепортали часов. Получается 628. Это означает, что рабочий день каждого увеличился примерно на 2,5 часа – это если нагрузка была распределена параллельно. Как часто нагрузка распределяется равномерно? Ага, примерно когда рак на горе свистнет. Это значит, что некоторые камрады сидели на работе по 12-14 часов. При этом – сюрприз! – Заказчик не только платит всего за 480 часов, но и еще регулярно команду “прикалывает” – мол, плохо работаете, товарищи, давайте напрягитесь, а то вот отдам вам контракт малазийцам…И так каждый спринт. Я должен принимать работу регулярно? Забудьте! 40 Hrs workweek? Ничего про это это не знаю! Команда как главная ценность? три раза ха-ха! Что в такой ситуации делать?

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

О мама дорогая, рассказать как там чудили Заказчики – так не поверите. И какие мы делали грязные хаки – сейчас просто жутко вспомнить. Тестирование оплачивали из своего кармана – так как Заказчик не платил, а без тестирования порождаемая хрень просто не работала. Работать нормально – Заказчики не хотели: хапарай по понятным причинам их вполне устраивал. Короче, по нагрузке – караул, по прибыли – самоокупаемость. И мы довольно долго так парилились – пока не обнаружили, что есть новые клиенты – которым надо побольше, и которые повменяемей, и платят регулярно. И тогда я просто расставил точки над I. Так что первый пункт плана выхода из мрачной ситуации:

Пусть у вас будет из кого выбирать – пусть у вас будет целый пайплайн Заказчиков, которых вы будете slide’n’dice по прибыльности, лояльности, объему переработок. Тогда в ответ на фразу “а не отдать ли мне контракт…” вы будете смело отвечать – “это как вам будет угодно, мы парни занятые”. Чтобы вам было из кого выбирать – вы должны быть Заказчику нужнее, чем он вам. Спокойно, это не так сложно как вам кажется – если вы делали с нуля систему последние три года, не выполняя рефакторинга и не ведя документации (Заказчик ведь настаивал что это лишнее?) – то стоимость передачи проекта от вас другой команде и связанных с этим потерь будут зверскими. Так что даже простое обозначение своей позиции (“а передайте, мы спокойно к этому относимся”) уже будет как удар поддых. Ну и третье – после обозначения своей позиции (“уважаемый, ты нам не благодетель – ты платишь, мы – работем. Не платишь – не работаем. Недовольны друг другом и не находим решение – расходимся.”) работаем по схеме Underpromise – Overdeliver. Это очень просто – Заказчику обещаем не золотые горы, а только то, что реально сделаем. И вот это – умри, но сделай. И еще шмат поверх. И в итоговом отчетет – шмат сделанный поверх обязательно выдели цветом.

Означает ли это, что ты вообще обойдешься без экстра-работы? Нет, ни за что – и если ты не круглый дурак ты не будешь брать за это денег. Но эта экстра-работа – будет выполняться не вынужденно, а добровольно, и будет четко понятно – что это твой жест доброй воли. Заказчик говорит “съэкономлю на тестировании”? Скажи ему “нет”. Заказчик говорит “давай поработай по 12 часов”? Скажи ему “нет”. Заказчик говорит “используй копипасту”? Скажи ему “нет”. Заказчик настаивает на нарушении development fundamentals? Скажи ему “нет”. И это твое “нет” – оно поможет сделать проект. “Ай-яй, мы потеряли заказчика!” Нет, вы только что избежали больших проблем – ведь у вас в пайплайне еще два десятка.

То есть если коротко – у тебя должна быть возможность сказать “нет”. Когда ты убираешь из головы дурацкую максиму “клиент всегда прав” (рекомендуется попробовать адресовать стоматологам и нейрохирургам) – вокруг открывается много интересных возможностей, и  управление ожиданиями становится простым и понятным.

З.Ы. Перед тем как сказать “нет” – 3 раза объясни почему нельзя. И вот если даже после этого не понял – это карма, как говорят японцы.

Post Author

This post was written by who has written 29 posts on Agile.by.

  • http://www.targetprocess.com firefalcon

    Вот почему я не люблю service development. Product development по сравнению с ним просто рай.

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

    В продукт девелопменте одна глобальная проблема – расстановка приоритетов 🙂

  • http://thetorch.ru/ Денис Петелин

    О!
    Строго согласен!
    Хамид Шохаджи в свое время классную статью писал про то почему нормальные люди не юзают аутсорсинг, Why outsourcing is for dummies.

  • Тимур Хащеватский

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

    Цена на открытом рынке определяестся спросом и предложением. Рынок IT-аутсорсинга открыт и глобализован. Единственный

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

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

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

    А вообще – я большой сторонник старого доброго fixed price, который конечно возможен не всегда, но когда возможен –
    снимает большинство подобных проблем.

    Теперь по поводу овертаймов. Мне сильно не понравилась история про “вот отработали очередной спринт, посмотрели сколько отрепортали часов”. PM не должен смотреть “сколько отрепортали”, PM должен оговорить с командой политику овертаймов (оплачиваемый овертайм – только с авторизацией PM), с клиентом – политику их оплаты. На месте клиента я никогда не стал
    бы оплачивать неоговоренный овертайм. На месте исполнителя – почти никогда не допущу на T&M проекте овертайм неоплачиваемый (за исключением случаев, когда необходимо исправить собственный непрофессионализм).

    2 firefalcon

    Не так однозначно. Во-первых разница в “количестве и глубине прогибов” на самом деле не между services и products development, а скорее между fix price и T&M, но и это не вся правда. Разработчикам продуктов тоже очень часто приходится прогибаться перед стратегическими клиентами, включая в продукт элементы, нужные только им, и, более того, нарушающие его концепцию. Имею в этом смысле очень богатый опыт с клиентами уровня Renault, Airbus и т.д. В конце концов всё сводится опять же к тому, у кого сильнее карта.

    Да и насчёт “рая” product development – я бы поостерёгся с оценками – за ошибки там (в отличии от services) расплачиваешься не сразу, но в стократном размере.

  • http://thetorch.ru/ Денис Петелин

    Покажи мне где там эмоции 🙂
    А у команды ПМа нет – команда обычная фриланс-команда, для них ПМ-бессмысленный оверхед. Ну и работает соответственно по любимому тобой приниципу “1 этап = объем задач = цена”. Задачи не сделали – оплаты нет. Задачи принимает заказчик -> пока заказчик не доволен – денег нет. Заказчик это понимает и пользуется для выбивания экстра-работы. А если у тебя нет смелостидругих заказчиков – с ситуацией ты ничего не сделаешь. Вот и поделился простым методом разрешения проблемы: уникальная услуга, на которую есть спрос – у тебя образуется пайплайн, а торг неуместен.

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

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

  • Тимур Хащеватский

    Ага – значит у нас не TM, а fixed price. Тогда я не пойму, откуда взялось “Заказчик не только платит всего за 480 часов”. В fixed price заказчик платит за результат. Если команда ошиблась при расчёте цены – это не проблема заказчика (в следующий раз задумаемся – не нанять ли бессмысленного оверхеда).

    И что значит “мол, плохо работаете, товарищи, давайте напрягитесь” ? Не вложились в обещанное расписание ? Опять не проблема заказчика.

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

    А вообще вырисовывается хрестоматийный пример на тему “экономия на PM и её результаты”.

  • http://thetorch.ru/ Денис Петелин

    Не, я сам смотрел – Заказчик вдумчиво прогибает под дополнительные неоговоренные фичи. И даже если б ПМ был, а сэйлс пайплайн пуст – ничего он сделает…

  • Тимур Хащеватский

    Интересно – а как клиент это мотивировал ? Просто наезжал ?

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

    А насчёт pipeline – кто ж спорит, это аксиома продаж, из категории “лучше быть богатым, но здоровым”. Но опять-таки – пироги должен печь пирожник, а сапоги чинить сапожник. Не девелоперское это дело, а sales guys этому и учить не надо – они это в первом классе проходят.

  • http://thetorch.ru/ Денис Петелин

    Ну как клиенты это обычно мотивируют? “Это же самое собой разумеется!..”
    Насчет разграничения – это да, но такой заказчик за пма платить не будет, а из общего котла – накладно.
    Вот и маются.

  • Тимур Хащеватский

    О! Что-то подобное “само собой разумеется” я и имел в виду. Я когда в далёкой молодости клепал базы данных на Access очень возмущался, что клиент считал такие вещи как поиск и отчёты “самими собой разумеющимися”. Потом до меня дошло, что прав именно клиент, потому что есть понятие стандартной эргономики и клиент вправе на неё рассчитывать. И начал включать в коммерческие предложения кроме главы Scope главу Non-Scope. И ставить все точки над ё.

    Что касается вопроса “платить за PM или нет” – на fixed price-проектах это вообще-то вопрос не к клиенту, а к исполнителю. Отказ от PM равносилен отказу от огнетушителя и аптечки в автомобиле. Молитесь, что пронесёт. Аргумент “с PM цена проекта неконкурентоспособна” рассматривать не желаю, потому что глубоко убеждён, что толковый PM свои деньги окупает с лихвой.

  • http://www.targetprocess.com firefalcon

    >>Если команда ошиблась при расчёте цены

    Для любого более менее приличного проекта команда НЕ МОЖЕТ НЕ ОШИБИТЬСЯ при расчете цены. Пока не существует методик четких эстимейтов хотя бы с точностью 5%

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

    Даже по стандарту HTML разработчики браузеров не могут сделать одинаковые поведения. А он создавался несколько лет. Что уж там говорить про обычные спеки на сервис проектах.

  • http://www.targetprocess.com firefalcon

    Кроме того я убежден что fixed price проекты выгодны только для команд не опытных. Клиент страхуется и он прав. Мало ли что они там с первого раза сделают – нафига им время обучения оплачивать.

    Если команда классная и у нее есть опыт в предметной области клиента – надо платить по часам для обеспечения нормального взаимовыгодного сотрудничества. А клиентов которые хотят наe…ть разработчиков надо нахер посылать. И наоборот тоже соответственно.

  • Тимур Хащеватский

    2 firefalcon

    C тем что не существует способа угадать цену с точностью до 5% спорить невозможно – при приличном уровне зрелости требований имеем где-то +/- 15~25% для опытных оценщиков. Более того – суперметодик, позволяющих добиться суперточности, не будет никогда.

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

    Огромное преимущество fixed price проекта – абсолютно другой уровень доверия со стороны клиента (врождённая проблема TM – отсутствие возможности адекватного контроля честности исполнителя). Он получает возможность управлять своими рисками и бюджетом. Исполнитель же принимает на себя риск, но во-первых этот риск оплачивается (в среднем – около 30% разницы в рейтах между FP и TM), во вторых мне представляется правильным, что риск принимает на себя именно тот, кто может его лучше оценить.

    Вот простой пример – допустим мы решили сделать евроремонт в квартире (определив примерный уровень требований к отделке – где паркет, где плитка и т.д.). Выбираем между двумя фирмами. В первой нам говорят “200 баксов за метр all included”. Во второй вам сообщают рейты специалистов и обещают всё считать по честному по ходу выполнения работ (сообщая при этом, что скорее всего выйдет где-то по 150). Лично я с намного большим удовольствием выберу первую. Хотя бы потому, что не смогу адекватно проконтролировать вторую.

    Полностью непротиворечивый спек разумеется написать невозможно. Хорошая практика – по согласованию с клиентом оставлять в бюджете процентов 10-15 резерва на возможные изменения (и опять же по согласованию с клиентом их расходовать). Если по каким-то причинам этот бюджет не выбран – на соответствующую сумму будут уменьшен контракт на maintenance/support.

    Ну и конечно – если уровень зрелости требований не позволяет сделать оценку с точностью хотя бы процентов 30 – от fixed price придётся отказаться. Либо, что на мой взгляд предпочтительнее, попробовать всё же (отдельным небольшим проектом – бизнес-анализ + прототипирование) провести их уточнение до приемлемого уровня. Либо шагать мелкими FP проектами – каждый раз берём кусок, который понимаем.

    Я категорически не согласен с тем, что FP выгоднее неопытным командам. Всё наоборот – неопытная команда не может сделать адекватную оценку и шанс облажаться у неё соответственно выше. Поэтому она вынуждена предпочитать TM. А вот клиент, работая с неопытной командой, должен настаивать на FP.

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

  • Pavel Veller

    Timur makes a lot of sense (you guys don’t mind english, do you?). There is only one thing I would like to add to saying “no” and guessing better estimates – Execution. This is what really matters. Not enough to be professional – must be committed. Not enough to know the right answer – must own and bear responsibility. In other words, teaching to say “no” may not do good. It’s an end-to-end execution that makes the difference. In the end, we want our “no” to have it’s “win” part on the customer side.

  • Тимур Хащеватский

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

  • http://thetorch.ru/ Денис Петелин

    Ну вот и здорово, вот и договорились 🙂