Продуктовый подход в аутсорс-разработке. Закулисье работы в крупном IT-интеграторе.
Часть 1

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

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

При таком отношении разработчиков часто оценивают по количеству фич. Фактический уровень качества определяется в этом случае субъективно (по ситуации) или в зависимости от бюджета.

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

Из-за сложившихся стереотипов может казаться, что это особенность аутсорса. Но всегда ли команда, которая развивает свой собственный продукт, избавлена от таких проблем? Правда ли, что в продуктовых компаниях нет заказчика, поэтому работать там можно в расслабленном темпе, спокойнее? Обсудим в этой статье, что же такое продуктовая разработка, в чём её особенности и почему она может отсутствовать в продуктовой компании, но быть у IT-интегратора.

Под аутсорс-разработкой понимают работу по созданию софта на заказ — для внешних заказчиков.

Под продуктовой разработкой подразумевают создание и развитие собственного IT-продукта. Заказчик здесь внутренний, например это маркетинговый отдел или отдел продуктовой аналитики. Внутренний заказчик может мало чем отличаться от внешнего: он тоже требует определённого результата к определённому сроку. И ему важно, чтобы этот результат нужным образом приближал достижение его бизнес-целей.

Часто встречается мнение, что для аутсорса характерен проектный подход. Есть сроки и техническое задание: в сроки нужно вписаться, ТЗ — выполнить. От продуктовой же разработки ожидают продуктового подхода. Казалось бы, очевидно. Но давай разберёмся на практике, так ли это?

Продуктовый подход — это фокус на бизнес-целях: результат разработки должен решать конкретные задачи и быть рентабельным. «Продуктовый подход» не равно «продуктовая компания» — его вполне может применять и IT-интегратор!

Из-за сложившихся стереотипов о проектном и продуктовом подходах в среде разработчиков курсируют пять предрассудков об аутсорс-компаниях:

Расскажем на примере компании kt.team, почему эти утверждения далеко не всегда справедливы. Мы придерживаемся продуктового подхода к разработке, хотя у нас есть не только собственные продукты, но и проекты на аутсорс. Познакомиться с некоторыми из них можно на странице «Проекты, над которыми мы работаем прямо сейчас». Не всех мы можем называть открыто, со многими действует NDA (соглашение о неразглашении).

Миф об аутсорсинге

При работе на аутсорс качество оценивается субъективно, критерии качества размыты и зависят от прихоти заказчика, а требования могут меняться по пять раз в день («заказчику не угодишь»).

Миф о продуктовых компаниях

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

Реальность

Оценка качества зависит не от типа компании, а от принципов работы, принятых в ней, и от наличия объективных метрик.

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

Другое дело, когда компания позиционирует себя как партнёр по поставке IT-решений, и заказчики воспринимают её соответственно. Фичи и изменения обсуждаются совместно с учётом стратегических целей. В этом случае измерить качество гораздо проще: оно зависит от достижения целей.

Мы привыкли работать с заказчиками именно так.

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

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

Пример

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

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

Провели анализ целевой аудитории, выделили два крупных сегмента: оптовые покупатели и мамочки.

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

Миф об аутсорсинге

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

Миф о продуктовых компаниях

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

Реальность

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

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

Маркетологи скажут, что это всё они, ведь за лиды и задачи по SEO были ответственны они.

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

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

Болтливый бездельник всем всё пообещает, и, даже если его обещания выполнит кто-то другой, это будет его победа.

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

Вот только всё это с одинаковой вероятностью случается и в продуктовых, и в аутсорс-компаниях.

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

Таким образом, признание не зависит от того, работаешь ты в продуктовой компании или в аутсорсинговой. Главное — как изначально распределена ответственность за будущий результат между сторонами заказчика и исполнителя. Чтобы объективно оценивать вклад всех сторон, мы используем методику Impact Mapping. Статья об этом методе уже есть в блоге — «Impact Mapping, юнит-экономика и PDCA: грамотное управление разработкой e-Commerce».

Понравилась статья?

Подпишись на нашу рассылку — стань первым, кто узнает о наборе
на обучающие курсы, митапах и новых открытых вакансиях!