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

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

Бывает ли, что необходимость некоторых фич, которые хочет внедрить заказчик, неясна?

Более того, нет понимания итоговых цифр и метрик проекта.

Нет точного ориентира, каким уровнем качества нужно обеспечить конкретную фичу.

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

При таком отношении разработчиков часто оценивают по количеству фич.

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

Но когда компания скатывается в ускорение фич, о качестве думать некогда.

Но всегда ли команда, которая развивает свой собственный продукт, избавлена от таких проблем?

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

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

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

Под продуктовой разработкой подразумевают создание и развитие собственного IT-продукта.

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

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

Часто встречается мнение, что для аутсорса характерен проектный подход.

Есть сроки и техническое задание: в сроки нужно вписаться, ТЗ - выполнить.

От продуктовой же разработки ожидают продуктового подхода.

Но давай разберёмся на практике, так ли это?

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

Познакомиться с некоторыми из них можно на странице «Проекты, над которыми мы работаем прямо сейчас».

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

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

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

В таком случае ничего странного, что заказчик низко ценит их труд.

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

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

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

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

Но если вдруг случится беда (а беду при определённом уровне управленческого зуда можно найти всегда), виноватым окажется разработчик.

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

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

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

Тут просто нет проигрышных ситуаций.

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

Главное - как изначально распределена ответственность за будущий результат между сторонами заказчика и исполнителя.

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

Ещё три мифа об отличиях продуктовой разработки от аутсорсинга мы рассмотрим в следующей части статьи. Опубликуем её в субботу, 14 марта 2020 г. Следи за новостями ;)