Ненависть к аутсорс-командам разработки можно сравнить только с ненавистью к строителям. Я уверен, что причины такой ненависти очень похожи: относительно низкий порог входа, при этом любой неуч с клавиатурой и мышью уже норовит назвать себя новым EPAM Systems, как и строители — ГК Самолетом.

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

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

Небольшой дисклеймер

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

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

Причина, по которой проект близится к закрытию, всегда (ВСЕГДА) достаточно тривиальна и связана с нарушением производственных циклов и игнорирования здравого смысла. Поэтому если есть ощущение, что ваш проект или проект, где вы работает в качестве аутсорс-специалиста, приближается к краху, то спуститесь с небес на землю — ваш случай не уникален. 

Когда и кому нужно брать аутсорс-команду

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

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

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

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

2. Клиент покупает «руки». Работа, которую он хочет передать, линейная и понятная. То есть исполнителю не нужно придумывать что-то гениальное и новое — только инструменты реализации, которым будет управлять внутренний сотрудник.

3. Достаточно финансов для экспериментов, но нет времени на подбор команды. Это скорее история для инвестора, когда у заказчика есть какой-то сторонний прибыльный бизнес и он решил запустить собственный проект.

Узнали себя в инвесторе? Читайте статью про то, как запускать проекты, основанные на интуиции. 

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

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

1. Fix Price – самый сложный тип договоров для всех. Сюда я рекомендую идти только в случае если и заказчик, и исполнитель имеют высокий уровень компетенций. Отлично подходит для проектов, где заказчик на 100% знает, как будет выглядеть конечный результат. 

2. Time&Material – формат почасовой оплаты. Опыт говорит, что если это стартаперский проект или линейная работа, то подобный формат всегда получается более гибким и дешевым. Потому что исполнитель в этом плане застрахован и ему не нужно накидывать в стоимость «коэффициент риска».

7 способов не уничтожить разработку

Разберем основные ошибки и мифы в головах исполнителей и их клиентов — что именно мешает эффективной синергии. 

Клиент не всегда прав

Сначала выкинем из головы раз и навсегда утверждение «Клиент всегда прав». 

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

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

Из этого принципа следует следующий.

Составляйте Product Vision и ТЗ

Игнорировать составление технического задания (ТЗ) — это самая распространенная причина факапов на проектах с аутсорсерами. ТЗ — это самая дорогая и сложная часть проекта. 

Да, я не ошибся: не разработка кода, не дизайн интерфейса, не аренда серверов — именно ТЗ является самой дорогой, важной и трудоемкой частью проекта. 

Почему так?

1. Ошибка на данном этапе имеет каскадный и накопительный характер последствий. Небольшой косяк на старте превращается в клубок неконтролируемого хаоса в конце. 

2. Документ читают все участники команды. И да, за прочтение ТЗ тоже нужно платить и закладывать на его изучение время и бюджет. Поэтому если оно будет составлено некачественно, то время специалистов и деньги заказчика пропадут даром — ждите череду созвонов для детализации и составление пояснительных документов, на которые тоже уходят часы и бюджет. 

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

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

Техническое задание  – это не пункт чек-листа запуска проекта или продукта, а инструмент синхронизации видения заказчика, исполнителя и других участников процесса. 

И перед техническим заданием, после заключения договора, заказчик должен составить Product Vision.

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

Самый лютый провал в этом ключе, который я видел — это продукт на 10 тысяч часов разработки, где вместо полноценного Product Vision была табличка эксель, где в 700+ строк (!!!) были перечислены все функциональные возможности продукта с формулировками «Регистрация через имейл», «Возможность пригласить гостя» и т.д. Не удивительно, что ребята не смогли дать грамотную оценку и за год не смогли выйти в релиз.

Если вы как заказчик без готового ТЗ нанимаете команду аутсорс-разработки, то поручите им за отдельную плату (!) составить Product Vision. Отсутствие этого документа и ТЗ увеличит срок выполнения проекта в 2 раза, а бюджет – в 3.

Составляйте договоры по этапам

Мне иногда неловко писать настолько очевидные вещи, но что поделать! Раз за разом я сталкиваюсь с тем, что договоры составляются для галочки или пытаются впихнуть все и сразу на первом этапе.

Очень часто фантазия в договорах заканчивается на уровне «когда передаем деньги», «когда принимаем результат» и различных сомнительных наказаний. При этом нет ни критериев готовности и приемки, ни уровня покрытия тестами, ни требований к безопасности. И это всегда очень больно.

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

• разработка Product Vision, 

• составление Техническое Задание, 

• составление задание на MVP, 

• создание дополнительных документов и т.д. 

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

То, что упускают практически все: отсутствие в договоре политики внесения изменений и описания алгоритма взаимодействия. При этом избегайте общих формулировок по типу «автоматический прием работы». 

Продуктовые задачи должны оставаться на стороне заказчика

Аутсорсер не любит думать. У него другая задача. Аутсорсер любит делать, при этом делать мало. Видением должен владеть заказчик. Если клиент заставляет аутсорсера думать над видением, то пусть готовится получить самое простое и быстрое, а не гениальное решение, ведь за«думалку» не платят.

Сколько раз я уже встречал, когда заказчик или его представитель не придумали, как создать ценность для пользователя или реализовать идею, и просто скинули эту задачу на разработчика или команду аутсорса. Типа, «придумай мне показатель профиля, который покажет пользователю, что у него все круто». 

Сомнительная затея, которая приведет к новым затратам.

Не ешьте слона

И снова тривиальная идея, про которую все забывают. Сначала дизайн, потом прототип, потом только разработка. И этот путь от дизайна до продукта надо проходить в рамках всех этапов разработки:
 

• Proof Of Concept — проверка концепции, которая доказывает, что продукт возможно реализовать;

• MSP — готовый к «отправке» продукт, который не завоюет сердце клиента и рынок, но даст возможность отточить технические моменты; 

• MVP — минимальный жизнеспособный продукт, с которым уже можно выходить в релиз;

• MLP — минимально привлекательный продукт, который не только выполняет свои функции, но и восхищает пользователей. 

  

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

Сначала сделайте полностью дизайн этапа Proof Of Concept, потом сделайте прототип и только потом разработайте. Потом то же самое проделайте с MSP, MVP и MLP. 

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

В больших проектах я внедряю этап «No-Code MVP». Иногда команда делает такой MVP на простом сервисе, который может настроить технический специалист, а иногда разрабатывала кликабельные прототипы на Webflow, Adalo, Bubble и т.п. У этого был ряд бонусов.

С одной стороны, большой бюджет сложно согласовать, так как заказчику необходимо зарезервировать бюджет (клиент — далеко не всегда владелец компании или акционер, чаще CTO). А так уже есть работающий и относительно дешевый прототип (трипваер), который дает полное понимание того, как будет работать продукт. Также если вы уже договорились на пред-разработку, то представителю заказчика будет легче продать аутсорс-команду ЛПР, а собственнику проще согласиться на полноценную разработку. Плюс, подобный прототип позволяет увидеть дыры в сценариях и оптимизировать продукт до старта разработки на коде.

Как засунуть слона в холодильник

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

Например, отсутствие какого-либо алгоритма внесения изменений. Возникла классная идея у стейкхолдера, которая сильно меняет логику? СРОЧНО РЕАЛИЗУЕМ! Никаких оценок последствий, планирования очередности задач, учета влияния незавершенных текущих задач – ни-че-го. 

То же касается про добавление нового функционала. Пришла идея от заказчика? Отдайте ее бизнес-аналитику. Он пусть передаст это дизайнеру. Тот посмотрит и передаст на оценку команде разработки. Потом получите одобрение от заказчика, которое необходимо зафиксировать. А когда разработаете, не забудьте потестить перед релизом демо-версии. 

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

Разделяй и оценивай

Это пункт для аутсорсеров. Процесс оценки проекта – сложная штука, требующая отдельных компетенций. Команда оценки – это специально отобранные люди, которые обучены оценивать проекты на трудозатраты.

Самая частая проблема человека, который оценивает проект, он оценивает его из позиции «А за сколько времени я бы это реализовал?», что в корне неверно. Настоящий оценщик всегда идет от вводных: какая будет документация на входе, насколько легкий на подъем заказчик, кто будет реализовывать задачи (джун, мидл, сеньор), кто и какого качества сделает ТЗ, как разделяется ресурсы и т.д. 

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

То же самое касается команды, которая занимается пред-продажей — она должна владеть специальным навыком оценки. Как я говорил выше, покупают хороший аккаунтинг, и это нужно показать на самом старте.

Не понимаете, как оценить большой проект? Ловите таблицу, которая выручала нас в этом вопросе. 

Как перестать ненавидеть друг друга

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

Почему я, будучи заказчиком, ненавидел аутсорс

Чаще я к ним относился с эмпатией, но основная моя претензия была такой: почему команда согласилась на условия, которые не смогла вывезти? Я прихожу со своей идеей, аутсорс выдвигает условия, подписываем FixPrice, а после выясняется, что команда «неправильно оценила сложность проекта». Как так?

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

При этом я знаю, что часто аутсорс-команды пытаются выехать за счет «переиспользования кода» с соседних проектов. Но это практически всегда сопровождается жирными баг-репортами, зомби-процессами и непонятными переменными, которые вызывают критические баги. 

Почему я, будучи руководителем проекта, ненавидел менеджеров по продажам 

Представьте, вы как менеджер проекта или руководитель отдела аутсорс-разработки созваниваетесь с будущим клиентом и составляете минимального верхнеуровневое ТЗ. Затем забираете его на оценку и ставите чек в 100 000 $. передаете эту оценку менеджеру продаж, чтобы он презентовал клиенту именно эту сумму. И…. Он возвращается с уже подписанным договором на 80 000$. При этом объем работ не уменьшился, а бюджет сократился на внушительную сумму. И вы с горящей пятой точкой бегаете по специалистам и пытаетесь и в бюджет вклиниться, и получить хоть какую-то прибыль. 

Почему так случается? Потому что KPI менеджеров ОП привязан к привлеченной сумме и очень редко — к прибыли. И часто я сталкиваюсь с тем, что они без предупреждения скидывают заказчику сумму ниже на 20-30%  или обещают какие-то дополнительные плюшки в виде бесплатной расширенной технической поддержки после сдачи релиза. 

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

Почему я, будучи аутсорсером, ненавидел заказчиков

Вы жену выбираете так же, как исполнителя — кто больше обещает сделать за меньшие деньги? Ставить в основной критерий отбора «стоимость работ» – это верх кретинизма. Дайте проект на оценку десяти командам и полУчите 10 разных оценок, потому что все по-разному поняли задачу (для сверки и реальной оценки, кстати, и нужен Product Vision, ТЗ и прототипы).

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

Почему команда разработки и заказчики ненавидели меня в роли руководителя проекта

А потому что мне нужно, чтобы мы оставались в рамках бюджета и целевой версии продукта. Любые изменение имеют каскадный накопительный характер последствий. Гениальная идея, даже супер-крутая, требует оценки. Если я этого не сделаю, то потом мы столкнемся с тем, что неожиданно появляются непонятные баги и косяки в архитектуре.

Я стремлюсь к статусу-кво и движению по рельсам, а не бездорожью, поэтому любое изменение я буду проверять на реальную необходимость.

Вместо вывода

Чтобы получить максимально комфортное взаимодействие друг с другом, аутсорсу и заказчику необходимо понимать задачи и цели друг друга. Очень часто они противоречат. И это нормально. Равно как и внутри команды есть противостояние ролей, в котором нужно найти баланс. Когда одного распирают идеи, другой должен напомнить: «Давай лучше выйдем в рынок, заработаем вагон денег, а потом реализуем все, что ты захочешь.»

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