Жесткие переговоры в аутстафф-проектах: решаем конфликты и учимся находить компромиссы

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

А если нет? Как с этим бороться – словом и делом – рассказал в минувшую субботу РОП компании EvApps, Иосиф Фекаду, на конференции MindBrosConf во Владимире.

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

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

Если на входе все условия сотрудничества, узкие места, спорные термины были обсуждены и зафиксированы с заказчиком (не только голосом, но и в формате follow-up сообщения в чате/почте) то вы, скорее всего, будете одинаково смотреть на будущее сотрудничество. Хотя и здесь бывают редкие исключения.

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

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

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

Такую ситуация проще предотвратить при помощи правильных действий «на входе» в контракт.

Самое важное – это, конечно же, общение: синхонизируемся в понимании терминов, начиная с базовых (Fix Price, T&M, Outstaff). Как показывает практика, чаще всего возникает путаница между двумя последними понятиями, соответственно стоит заранее оговорить, что для нас аутстафф и чем он отличается от ТМ.

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

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

Дело в том, что проект может не стартовать в планируемые сроки по ряду причин (доступы не готовы, задач еще нет, ПМ не успевает и т.д.). В это время заказчик считает, что он еще не должен платить, подрядчик считает, что он уже выделил разработчика, и у него идут оплачиваемые часы, а на выходе – ссора из-за 8-24 часов, которую легко можно было предотвратить.

На практике такая проблема решается одним сообщением в рабочем чате, на которое нужно получить подтверждение от заказчика:

Если все же конфликт произошел, тому может быть 2 причины:

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

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

Кейс. «Оно того не стоит»

Мы взяли два новых проекта с новым заказчиком – один из них аутстафф на троих разработчиков, второй - написание ТЗ в фикс прайс. Прошел месяц, и мы столкнулись с нежеланием платить за аутстафф, по причине того, что разработчики сделали меньше, чем заказчик ожидал за месяц. Пока вели переговоры по этому поводу, закончили разработку ТЗ и пошли его сдавать. И снова столкнулись с нежеланием платить, по неадекватной причине: мол, этот документ маловат по объему и не может столько стоить, даже учитывая то, что он покрывает цели и задачи заказчика.

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

Решение: мы подготовили и отправили досудебную претензию, сняли команду с проекта и приступили к подготовке иска в суд. И – о чудо! Сразу после иска заказчик оплатил все выставленные нами счета в полном объеме. Заказчика мы занесли в «черный список», а сами получили полезный опыт: и так тоже бывает!

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

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

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

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

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

Если это все же случилось:

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

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

Кейс. Полмиллиона из ниоткуда

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

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

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

И снова договоренности и договоры: еще на этапе пресейла, наш МОП проговаривает с заказчиком, что о завершении проекта компания должна быть уведомлена не позднее, чем за 10 рабочих (либо 14 календарных) дней.

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

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

Дальше... правильно, фиксируем все это в договоре! У нас это делается так:

Однако важно помнить (и прописать в тексте договора):

Что делать, если мы все-таки получаем уведомление о завершении работ за один/два дня (то есть, за любое недостаточное для перестановки разработчика на новый проект время)?

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

Кейс. Хотели расстаться, а остались «навсегда»

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

Итак, что важно помнить: