В наш век расцвета консьюмеризма потребителю предоставляется все больше товаров и услуг на любой вкус и кошелёк. На этой волне не менее развитым становится и сектор B2B-услуг. Это позволяет управленцам компаний аутсорсить всевозможные сферы деятельности своих компаний как никогда прежде. Продуктовая ИТ-компания – не исключение.
Если 50-100 лет назад запуск компании был невозможен без значительных капитальных затрат, то сейчас это не так. Предпочтение отдается бизнес-моделям с низкими капитальными затратами, что снижает риски инвесторов предприятия. Такие бизнес-модели становятся возможными как раз вследствие развития сектора B2B-услуг. Именно развитый сектор B2B-услуг позволяет закупать второстепенные компетенции в минимально необходимом объеме и без капитальных вложений.
Следствием этого становится соблазн аутсорснуть вообще все и оставить себе лишь доступ к клиенту. Если мы продуктовая ИТ-компания, то это значит, что мы и продукты свои разрабатываем силами подрядчиков. На бумаге все красиво: заплатили подрядчику за работу, а дальше просто продаем продукт и наслаждаемся жизнью. По факту если такой схематоз и может сработать, но в каких-то идеальных ограниченных условиях. Таких как нетрудно догадаться в реальности не бывает от слова совсем.
В целом же подобный подход несет в себе ряд взаимосвязанных проблем, которые мы рассмотрим далее.
Проблема: аутсорсинг ключевых компетенций
Аутсорсинг хорош для того, что по-английски называется “undifferentiated heavy lifting” – аспекты работы, которые не относятся к конкурентным преимуществам компании. По сути это азбучная истина для любого современного предпринимателя. Управленческой ошибкой же является некорректная классификация разработки продукта как второстепенной компетенции для продуктовой компании.
Казалось бы это логично: мы знаем своего клиента и понимаем какой продукт ему нужен – это в идеале. Зачем нам как компании лезть в такую сложную область как разработка софта и нарабатывать компетенции в ней? На рынке полным полно компаний, которые специализируются в разработке и сделают нам продукт по нашим лекалам.
Я уже писал ранее о том, в чем заключается владение современной информационной системой. Функциональность и некоторые нефункциональные атрибуты качества, которые лежат на поверхности – например, базовая производительность – условно легко проверить. А вот моменты скрытые без соответствующей экспертизы проверить не выйдет, а они важны в долгосрочной перспективе. При этом мотивация подрядчика заниматься этими вещами невелика. Это классика агентской проблемы.
Долгосрочный успех продукта зависит от наличия разработки как ключевой компетенции. И это не зависит от того внутренняя у нас разработка или же аутсорсинг.
Проблема: замедленное развитие продукта
Сделать продукт идеальным с первого раза пожалуй невозможно. А это значит, что со своим подрядчиком мы не на одну итерацию. И хорошо еще если с одним и тем же. Переход проекта от подрядчика к подрядчику их собственными силами точно не скажется хорошо на его качестве. Переход условно “без потерь” возможен, но требует планирования, подготовки и компетенции. Этого у нас нет и не планировалось ведь мы аутсорсим “технические детали”.
Наша итерация начинается составлением ТЗ, согласованием стоимости и сроков. Заканчивается она приемкой и вполне вероятно переделками. Вместо фокуса непосредственно на создании ценности для клиентов мы занимаемся формальными вещами для защиты собственных интересов в отношениях с подрядчиком. Гибкость наша тоже под большим вопросом, ведь требуется повторное согласование ТЗ, стоимости и сроков по любому нетривиальному изменению требований.
Частично эту проблему можно решить если работать с подрядчиком в подходе time & material. Но этому подходу свойственны свои проблемы. И снова оптимально наличие разработки как собственной ключевой компетенции для адекватного контроля работы подрядчика в этом случае.
Проблема: размытие ответственности и контроля
Задача подрядчика – сделать как написано ТЗ, пройти приемку и получить свои деньги. Прямой задачи решить нашу бизнес-проблему у него нет. Это наша задача сделать так, чтобы содержание ТЗ было максимально направлено на решение бизнес-проблем.
Отсюда ответственность за результат размазывается и появляется соблазн обвинять друг друга в недостатках (ТЗ или продукта). При этом отсутствие собственной технический экспертизы в большинстве случаев так же не позволит решить на 100% задачу соответствия ТЗ проблемам бизнеса.
Не менее важен тот факт, что подрядчик – это отдельное юрлицо, прямого контроля над которым у нас нет. Подрядчик управляет своими ресурсами так, как считает нужным и далеко не факт, что оптимальным для нашего проекта образом.
Решение: эксперты в штате
Продуктовая ИТ-компания, тебе нужны технические эксперты в штате, и точка! Более того, они должны быть мотивированы долгосрочным успехом компании. Именно такое сочетание позволяет уверенно решить все обозначенные выше проблемы.