Разработка сайта/лендинга/интернет-магазина по модели fixed price по методологии каскадной модели waterfall, то есть с готовым техническим заданием и фиксированной сметой — это, конечно, разработка внешними ресурсами, но в контексте данного материала аутсорс-разработкой не считается.
Что считаем разработкой на аутсорсе
Кейс решения задач и реализации проектов без конкретного технического задания и вне конкретных сроков (впрочем, контракт может быть ограничен неким периодом, например, в год или т.п.).
Это тот случай, когда можно было бы нанять людей в штат, но было решено использовать внешнюю команду по ряду причин:
- отсутствия внутри экспертизы для управления командой;
- отсутствия экспертизы для найма и удержания такой команды;
- необходимость вывести команду и приступить к задачам в сжатые сроки;
- просто нежелание нанимать в штат непрофильных основной деятельности сотрудников.
Другими словами, выделенная команда из 4 разработчиков, 1 менеджера и 1 аналитика за 2,5 млн. рублей в месяц — это аутсорс-разработка. Контракт по ежемесячной поддержке/развитию интернет-магазина на условных 100 часов в месяц по 3000 руб/час — это тоже разработка на аутсорсе. В рамках такого контракта для бренда можно сделать промо-страницу к новому году, например. Получается, регулярность и длительность отношений — это то, в чем подрядчик мотивирован, и является главной отличительной особенностью в контексте этого материала.
Управление взаимодействием «заказчик + подрядчик»
Администрирование процесса работы с подрядчиком, по большому счету, состоит из трех этапов:
- Поиск и подбор подрядчика, релевантного вам.
- Сохранение и развитие отношений, пока это подходит всем.
- Своевременное прекращение, когда пора заканчивать.
Поиск и подбор. Самое важное — выбрать подрядчика, релевантного вашим задачам и уровню компании (масштабу, объему, и т. д). В некоторых случаях вам подойдет небольшой digital-продакшн, ориентированный на личные отношения (аккаунтинг) первых с первыми. В другом сценарии вам будет комфортно, когда юридические отделы с двух сторон договорятся между собой, и все будут следовать строгим процессам на уровне middle-менеджеров. Лучшее, что можно сделать, чтобы все испортить: нанять подрядчика не по рангу в ту или иную сторону. Будут или перегружать вас бюрократией и процедурными ритуалами, или, наоборот, не будут понимать, что вы от них хотите при банальном запросе акта сверки.
Главное искать там, где есть, а там где нет — не искать
Определите критерии для подбора подрядчика, которые важны вам и по вашему мнению сделают сотрудничество комфортным для всех, и исходя из этого сформируйте некий портрет компании-подрядчика для дальнейшего подбора. Когда образ подрядчика понятен, то дело за малым. Главное искать там, где есть, а там где нет — не искать.
Например, веб-студии и агентства собраны в отраслевых рейтингах или передаются из рук в руки по рекомендациям, крупные it-интеграторы и частенько имеют хороший тендерный отдел и мониторят площадки и ведут активную работу на клиентских мероприятиях и конференциях, а хорошие разработчики ПО на уровне hardware & software вообще непонятно где. Они вроде бы есть, но про них мало, кто знает.
Когда подрядчик найден. Часто первое, что происходит после подписания документов — это формальная встреча-знакомство участников команды с обеих сторон. Редко, когда эта встреча является содержательной, и все атрибуты взаимодействия «вытачиваются» далее в процессе.
Но можно провести kick-off встречу с пользой, и помимо формального знакомства обсудить все возможные «правила игры»:
- зафиксировать зоны ответственности подрядчика и клиента;
- раскрыть все ожидания от работы с двух сторон и обсудить;
- проговорить, как нужно работать, чтобы сотрудничество продолжалось и, напротив, после чего его точно придется прекратить.
Проведение обстоятельной установочной встречи и обсуждение всех правил игры позволит пропустить этап «прощупывания красных линий» и приведет к конструктивному взаимодействию с двух сторон.
Задача любого подрядчика в аутсорс-разработке — как можно дольше сохраниться в проекте, приносящем прибыль. Для этого нужно, чтобы все были довольны и видели плюсы от этой работы с обеих сторон. В первую очередь, конечно, со стороны заказчика. Тут не особо стоит вопрос «мы выбираем или нас выбирают» и на самом деле все очевидно — выбирает клиент.
Несколько правил для долгосрочной работы
Выделим три основных:
- Контроль уровня удовлетворенности заказчика. Регулярные (раз в 3 месяца) опросы по удовлетворенности (CSI) позволяют держать руку на пульсе отношений и не пропустить момент, когда необходимо действовать и что-то менять.
- Следование парадигме клиентского сервиса. В разных компаниях разные понятия о клиентском сервисе. Будет лучше, если эти нормы будут зафиксированы и все участники проекта будут следовать установленным правилам, понимая, зачем это нужно. Очень часто мнение о ресторане складывается из манеры общения официанта.
- Отстаивание границ собственных интересов (подрядчика). Это любимое. И оно вовсе не противоречит клиентскому сервису, потому что сервис — это не про любые хотелки. Это про безусловное уважение, вовлеченность и заинтересованность подрядчика, но не любое желание.
В проекте со временем будут появляться новые участники, которые не стояли у истоков сотрудничества. Они будут прощупывать границы возможностей, манипулировать, требовать и усложнять. Важно, чтобы вы понимали и отстаивали границы собственных интересов в проекте, потому что иначе проект обязательно перейдет в стадию прекращения отношений (перестанет быть интересным/комфортным/выгодным одной из сторон).
Еще раз: проект не закончится, если вы назначите корректировочный созвон с новым менеджером клиента, и грамотно расскажете ему, что не все местоимения применимы к сотрудникам вашей команды и тон общения в проектном чате не совсем подходящий. Однако, если этого не сделать,то за 3-4 месяца вся команда клиента (в том числе руководство) сформирует ошибочное мнение о команде-подрядчике, наблюдая только за вершиной неподобающей коммуникации в проектом чате (и не присутствуя на детальных встречах и звонках).
Когда пора заканчивать. Не будем рассматривать ситуации, когда окончание сотрудничества неизбежно по условиям контракта/закупки, или когда клиент принципиально меняет подрядчиков раз в 6-9 месяцев «чтобы не расслаблялись».
Заканчивать нужно тогда, когда кто-то бескомпромиссно перерос сложившиеся отношения и у переговоров не остается шансов.
Иногда подрядчик вырастает из заказчика, и сложившиеся процессы и ценообразование теряют всякий смысл. Еще чаще клиент в процессе роста и развития формирует все большие требования к процессам, объему, ассортименту услуг. Тогда у подрядчика не остается шансов поспеть за таким развитием. В любом случае при прекращении сотрудничества необходимо стремиться к формату win-win, даже если это не кажется очевидным.
А вы пользуетесь услугами подрядчиков?