{"id":13651,"url":"\/distributions\/13651\/click?bit=1&hash=f7cfbb8b6e89a6860896847fedf521c070634cb4a2f3761412b8a5dec5116157","title":"\u041a\u0430\u043a \u0432 \u043f\u044f\u0442\u044c \u0440\u0430\u0437 \u0443\u0432\u0435\u043b\u0438\u0447\u0438\u0442\u044c \u043f\u0440\u043e\u0441\u043c\u043e\u0442\u0440\u044b \u0442\u043e\u0432\u0430\u0440\u043e\u0432 \u043d\u0430 \u00ab\u0410\u0432\u0438\u0442\u043e\u00bb","buttonText":"\u041a\u0430\u043a?","imageUuid":"3e26061f-357a-5423-93fa-3abe53bf272a","isPaidAndBannersEnabled":false}
Альфред Столяров

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

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

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

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

Иосиф Фекаду
Руководитель отдела продаж, EvApps

Иосиф имеет 10-летний успешный международный опыт в продажах и создании/управлении эффективными коммерческими отделами. Участвовал в создании отдела продаж в EvApps с нуля.

Лучше предотвращать, чем лечить

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

  • экономит деньги (а также нервы и трудозатраты)

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

  • не формирует ошибочных ожиданий у обеих сторон

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

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

Аутстафф на фултайм – это выкуп заказчиком у подрядчика разработчика под свое управление на полный рабочий день (40 ч. в неделю/8 ч. в день) на срок не менее 2 месяцев. Вы обеспечиваете необходимый для такой загрузки объем задач; простой из-за отсутствия задач и ожидания обратной связи должен быть оплачен.

  • не ведет к испорченным отношениям с заказчиком

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

  • не провоцирует репутационные риски и потери

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

Проблема №1. Заказчик "смешивает" форматы работы и отказывается оплачивать отработанные часы

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

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

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

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

Словом, ВСЕ должно быть в договоре!

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

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

Тема: Подключение к проекту нового middle PHP разработчика

Дата: 27.07.21 Оплачиваемые часы с 13:00.

Разработчик: Иванов Иван Иванович

Рейт: 2500

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

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

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

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

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

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

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

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

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

Проблема №2. Нашего разработчика хотят схантить или… уже схантили!

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

Без предварительного письменного согласия Исполнителя не вступать в прямые договорные отношения (как по трудовым, так и по гражданско-правовым договорам) со специалистами Исполнителя, а равно привлекать специалистов Исполнителя косвенно, в том числе, с использованием третьих лиц в качестве посредников, в течение срока действия настоящего Договора, а также в течение 5 (пяти) лет с момента истечения его действия. В случае неисполнения данного Заказчик обязуется выплатить Исполнителю неустойку в размере, равном 500 000 рублей. Данное условие распространяется не только в отношении специалистов Исполнителя, прекративших работу с ним, но и в отношении специалистов, прекративших отношения с Исполнителем в течение 3 лет по завершении действия настоящего Договора.

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

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

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

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

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

  • ведем жесткие переговоры с менеджером, далее – с собственником и топами; обосновываем свое резко отрицательное отношение к хантингу.

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

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

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

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

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

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

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

Проблема №3. Нарушение сроков отключения разработчика от проекта крепко бьет по карману компании

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

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

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

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

Любая из сторон имеет право досрочно отказаться от исполнения настоящего Договора или приостановить оказание услуг, письменно уведомив об этом другую сторону не позднее, чем за 10 рабочих дней до момента отказа или приостановления. При этом Заказчик, в случае несоблюдения указанного срока для отказа или приостановления оказания услуг обязан возместить Исполнителю расходы исходя из следующей формулы:

Р = С х Пр х РД,

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

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

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

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

  • Идем в переговоры с заказчиком, напоминаем про договоренности, если забыл – показываем пруфы.
  • Ссылаемся на договор, требуем соблюдать его условия.
  • Подсказываем, как можно поступить для того, чтобы безубыточно для себя соблюсти договоренности (переставить программиста временно на другой проект, доделать что-то на действующем проекте и т.д.)

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

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

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

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

  • регулярный менеджмент - ключ к предотвращению конфликтных и спорных ситуаций;
  • переговоры - это круто, но всегда храните переписку и пруфы: как говорится, "они могут быть использованы против вас в суде" - или за вас, что гораздо важнее!
  • все, о чем договорились, заносите в договор и отстаивайте свое право на подписание с заказчиком договора по своей форме;
  • смело отстаивайте свои интересы, но помните о репутации - никому не нравится ассоциироваться со скандалами и конфликтами.
0
Комментарии
Читать все 0 комментариев
null