Разработка на аутсорсе: довериться и не пожалеть об этом

Как контролировать команду разработки на аутсорсе?

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

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

Чаще всего проблема только в коммуникации: сложно найти точки контроля, в которых можно убедиться, что всё идёт как надо. От этого клиент нервничает, перестаёт доверять исполнителю и предлагает не всегда адекватные решения.

Один клиент WB—Tech потребовал разработчиков установить программу, которая снимала скрин с экранов каждые 30 секунд и отправляла ему на почту. Страшно представить, сколько времени он тратил на бессмысленный просмотр этих скринов.

Случай смешной, но ведь он хотел как лучше! Просто не понимал, как контролировать процесс, и предложил своё топорное решение.

Я расскажу, как WB—Tech показывает заказчику, что всё в порядке, сохраняя продуктивность команды и без лишнего контроля.

То, что вы хотите контролировать процесс, нормально. Важно докопаться до причины этого желания.

Я выделяю три вида клиентов, которые прямо спрашивают аутсорсера: «Как я буду вас контролировать?»:

1. Камикадзе. Заказчик не верит в аутсорс в принципе, но другого варианта нет. Он в панике и ничего не принимает на веру. Ему хочется стоять у вас за спиной и следить за каждым шагом.
2. Первый пилот. Заказчик верит, что на аутсорс можно отдать что угодно, но только не разработку. Ему некомфортно делегировать, даже если речь идёт об уже существующей технологии, что уж говорить об инновационном сервисе.
3. Парашютист. Заказчик понимает, что нужно расслабиться и поверить, что всё будет хорошо. Но сделать это он готов только после того, как убедится, что команда всё продумала и каждый знает, что делает. Дальше он будет подкреплять эту уверенность контрольными точками: дёрнул за кольцо — парашют раскрылся.

Я надеюсь, что вы относитесь к третьему типу, раз читаете этот текст. Даже если пока нет, это можно исправить.

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

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

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

Один из проектов, которым мы гордимся — ProAdventure. Это туристический сервис, решения которого теперь копирует вся отрасль.

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

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

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

Вернёмся к ProAdventure. Клиент пришёл к нам с готовым решением: «Хочу booking.com для экстремалного туризма».

У него уже был сайт, с которого хорошо продавались туры нескольких поставщиков. Клиент решил сделать агрегатор и увеличить доход. Но оказалось, что рынку просто не нужен один сайт с кучей туров и опций для их сравнения, сколько трафика на него ни лей. Рынку было достаточно поисковиков.

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

В WB—Tech мы обязательно формулируем понимание задачи. Нам нужно понять, зачем мы его делаем, кто на него попадёт, почему всё должно быть так, а не иначе. Клиенты часто приходят с абстрактными задачами: «Хочу сайт, хочу стартап». Нельзя хвататься за готовое решение — мыслить нужно от проблемы.

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

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

Это обеспечивает клиенту контроль.

Вы понимаете:

1. что должно получиться в итоге;
2. как реализуется каждый этап.
   

Теперь вы сможете осознанно запрашивать статус проекта по совместно разработанному плану.

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

Если вы сомневаетесь в своей компетентности в отрасли — не надейтесь, что разработчик сможет спасти дело. Вы должны быть в состоянии ответить на его вопросы и рассказать о специфике отрасли, иначе проект не склеится.

Разработчик знает, как создать работоспособный продукт. Но только клиент знает, как продавать свой товар или услугу.

Если команда обучит заказчика до старта, ответит на все его вопросы и ответственно подойдёт к пониманию задачи, будет выбрано лучшее решение. А главное, поднимется уровень компетентности клиента.

Мы готовы начать обучение: получите бесплатную первичную консультацию WB—Tech по вашему проекту.