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

Содержание

Redirector

Как бизнес смотрит на разработчиков?

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

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

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

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

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

Мифы о продуктовой и аутсорс-разработке

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

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

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

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

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

1 требования заказчиков постоянно меняются («им не угодишь»), критерии качества размыты;

2 труд разработчиков ценен только количеством реализованного функционала;

3 аутсорс — это работа в жёстких рамках, сроки всегда ограничены («надо было вчера»), работает конвейер (есть «план выработки» и норматив на выполнение операций);

4 работать на аутсорсе скучно и трудно, а вот создание собственных продуктов компании — это креатив, фонтан интересных и уникальных задач, решать которые легко и приятно;

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

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

Итак, разберёмся, насколько справедливы стереотипы про продуктовые и аутсорс-компании в IT.

Критерии качества

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

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

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

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

Реальность

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

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

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

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

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

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

Пример

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

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

  • увеличить средний чек — на 50 %;

  • увеличить конверсию — незначительно;

  • увеличить APC (average payment count, рус. среднее число платежей за год) — до 12, т. е. перевести в режим покупки продукта по ежемесячной подписке.

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

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

Признание заслуг

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

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

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

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

Реальность

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

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

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

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

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

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

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

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

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

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

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

Другие статьи

Смотреть все

Почему нельзя просто взять и внедрить PIM-систему?

Подробнее

Почему технари против шин данных: middleware, ESB, брокеров сообщений?

Подробнее

От «спагетти» до гибкой архитектуры за 5 шагов: этапы внедрения ESB-слоя

Подробнее

Смотреть все

Мы используем файлы cookie, чтобы предоставить наилучшие возможности сайта

Ок

Ваша заявка отправлена успешно

Отправить снова

Ready to help you with your project

You'll be contacted by your personal manager