Зачастую клиенты уверены, что агентство — это руки, которые выполняют задачи по техническому заданию. Мы опровергаем этот стереотип и формируем вовлечённую продуктовую команду: работаем в тандеме с менеджером продукта со стороны бизнеса, мотивируем друг друга выпускать новые функции в срок и отвечаем за результат перед пользователями и клиентом.

Команда с нуля: in-house vs outsource

Подбор релевантных специалистов in-house занимает от одного до трёх месяцев. Если на стороне клиента нет технического директора или тимлида, HR-специалистам может быть трудно оценить экспертизу кандидатов.

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

Многие крупные компании запускают MVP («минимально жизнеспособный продукт») с командой на outsource. После запуска клиент решает: собрать команду внутри, продолжить работать с агентством или отказаться от проекта. Так продуктовая компания не тратит время и деньги на поиск сотрудников и последующее увольнение in-house-команды, если MVP «не взлетит».

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

Специалист по информационной безопасности проверяет код на уязвимости. UX-райтер находит простые слова и объясняет пользователям, как работает продукт.

Чаще всего такие специалисты нужны на 20 часов, а не фултайм. В случае работы с агентством вопрос утилизации ресурсов не стоит.

Идеальная команда и где она обитает

Состав команды зависит от рынка и стека технологий. Чаще всего это команда разработки, руководитель проектов со стороны агентства и менеджер продукта со стороны клиента. Если работа идет по Scrum, то роли в команде — это Dev Team, Scrum Master и Product Owner.

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

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

Когда заказчику требуется дополнительная экспертиза по продуктовому менеджменту, мы привлекаем PO (Product Owner) со своей стороны и управляем продуктом в связке с клиентом. PO погружается в специфику бизнеса клиента, следит за метриками, строит карты пользовательских сценариев (CJM), формулирует продуктовые гипотезы и налаживает доверительную коммуникацию с клиентом.

Как агентству и клиенту взаимодействовать друг с другом

На основе опыта общения с клиентами мы выделили пять основных принципов.

1. Доверять

Проект не «взлетит», если работа будет строиться по принципу «вы — подрядчик, мы — клиент». Должна быть целостная команда.

2. Одинаково понимать продукт

У команды должно совпадать понимание продукта. Для этого должны быть общие открытые метрики продукта как для бизнеса, так и для разработчиков. Тогда всем легче понимать друг друга, двигаться в одном направлении и фокусироваться на вещах, важных для всего проекта, а не для отдельных участников команды.

3. Погрузиться в процессы компании и специфику бизнеса клиента

Например, при работе с «Леруа Мерлен» мы плотно взаимодействуем с другими отделами и работаем как целостная команда: анализируем, как улучшить продукт, проводим A/B-тесты, помогаем формировать положительный опыт взаимодействия пользователей с сайтом и так далее. Наши сотрудники присутствуют на многих мероприятиях компании и не пребывают в информационном вакууме.

4. Высадиться в офис клиента

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

5. Обеспечить прозрачность и вовлечённость

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

Как мотивировать команду на результат

У многих наших коллег есть опыт работы и в in-house, и в outsource-командах. Как показала практика, люди везде одинаковые. Команды в заказной разработке тоже хотят делать хорошие продукты, выпускать классные кейсы и гордиться своей работой.

Мотивация сильных специалистов неизменна: интересные проекты и деньги. Если проект по каким-то причинам у сотрудника «не идёт», мы переключаем его на другой. Это помогает сохранить мотивацию и оставить компетенции внутри. В агентстве можно поработать с разными проектами и технологиями. В in-house, чтобы глобально сменить проект, чаще всего нужно уволиться.

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

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

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

Как формируются KPI в продуктовой аутсорс команде

Каждый должен чувствовать себя частью команды, а команда — частью продукта. Мы формируем KPI команды и вовлекаем сотрудников в процесс работы над продуктом.

KPI можно строить на оценке качества разработки (отзывы в сторах, процент стабильности и скорость загрузки приложения) или на продуктовых метриках (всё, что хотите измерять и развивать). Таким образом вся команда вовлекается в производство качественного и нужного продукта.

Иногда мы работаем по модели частичной Revenue Share: если клиент получает добавочную прибыль, мы получаем с неё процент. Например, общая премия распределяется по команде с разными процентами в зависимости от роли или грейда.

Как работать с продуктом

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

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

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

Проверка гипотез

Можно генерировать и проверять гипотезы с помощью количественных и качественных исследований.

• Пользовательское интервью или CustDev

Выявляет «боли» и потребности аудитории. Показывает, как пользователи взаимодействуют с продуктом.

• Карточная сортировка

Позволяет узнать представление пользователей о структуре и навигации меню, каталога и фильтров.

• Онлайн- и офлайн-опросы

Помогают понять, почему пользователи «отваливаются» на каком-то этапе воронки и могут ли изменения пути пользователя повлиять на улучшение конверсии.

• A/B-тестирование

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

Мы пользуемся метриками для приоритизации продуктового бэклога (упорядоченный перечень функций, которые хотим реализовать). Например, измеряем фичи с позиции потенциальной пользы или упущенной прибыли с помощью Cost of delay. Эта метрика показывает, сколько мы потеряем в деньгах, если будем задерживать разработку какой-то функции в продукте.

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

Методологии разработки для продуктовой команды

Как правило, ПО разрабатывают по каскадной модели (она же «водопад»). Классическая схема:

• построение бизнес-модели;
• написание бизнес и системных требований;
• разработка;
• тестирование;
• релиз.

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

Это не разработка Scrum, поскольку не всегда итерация выдаёт готовый к релизу кусок продукта. Однако такой подход позволяет повысить лояльность клиента к нам как агентству. Клиент видит «обрастающий» функциями продукт и может скорректировать желаемый результат на ранних этапах.

Почему это всё ещё не Scrum, но мы уже движемся к продуктовому подходу? На данном этапе мы не тестируем продуктовых гипотез. Весь MVP — одна большая гипотеза. Но мы можем проверить Product Market fit: удовлетворяет ли продукт потребность конкретного рынка и нужен ли он пользователям.

После успешной проверки гипотез методологию разработки выбирают из следующих факторов и ограничений:

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

Методология должна решать конкретные поставленные задачи, а не создавать новые проблемы. На наших проектах мы используем разные подходы. Чаще всего это Scrum с его производными и разными подходами — Kanban и Lean.

Например, на проекте «Леруа Мерлен» благодаря Scrum процесс стал более управляемым. Мы решили сложности с приоритизацией и сроками реализации задач. Работа стала более прозрачной, а результат — прогнозируемым.

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

Встраиваем Канбан

Мы запустили Scrum, довели его до некой логической точки и провели глобальную ретроспективу по процессам. Проанализировали, что нас устраивает в текущем процессе, а что хотелось бы изменить. Так родилась идея попробовать некоторые практики Канбана и органично встроить их в существующий процесс. Решили сохранить из Scrum таймбоксы в виде спринтов и мероприятия по его планированию, ретроспективы и демо, а из Канбана взять принципы вытягивающей системы, но уместить её в спринт.

Первым изменением было условие, что теперь новая задача попадает в работу из «To do» только после того, как выполнена предыдущая задача — основа вытягивающей системы.

Далее последовала смена формата ежедневного стендапа. В Scrum, как правило, на ежедневном стендапе каждый член команды отвечает на три вопроса:

• «Что я делал с момента прошлого стендапа для достижения цели спринта?»;
• «Что я буду делать до момента следующего стендапа для достижения целей спринта?»;
• «С какими проблемами я столкнулся на пути достижения цели спринта?».

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

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

Настраиваем Jira

Следующим шагом была настройка карточек на доске в Jira, чтобы они отображали именно ту информацию, которая необходима для ежедневного стендапа:

• номер, название задачи и ответственный за неё в данный момент времени член команды;
• дедлайн (если имеется);
• дата следующего пинга;
• приоритет;
• оценка в Story Points.

Далее мы стали работать с данными.

1. В Jira был сделан кастомный дашборд, который аккумулирует данные с доски и показывает текущую загрузку каждого члена команды в соответствии с его задачами в каждом из статусов.

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

3. На основе данных из Jira строится диаграмма сгорания, которая является, как отличным моральным стимулом для команды, так и сигнализатором о наличии проблем.

4. По итогу спринта подводится статистика, в которой указывается:

1. количество задач и их оценки, взятые при планировании;
2. количество задач и их оценки, которые «влетели» по ходу спринта;
3. количество задач и их оценки, которые были выполнены по итогам спринта;
4. количество задач и их оценки, которые не были завершены по итогу спринта;
5. плановая «трудомощность» команды на спринт — Capacity и процентное соотношение закрытых задач к Capacity — Velocity.

Регулярный сбор и дальнейший анализ этих данных позволяет постоянно «держать руку на пульсе» и при принятии решений об изменении процесса отталкиваться не только от субъективных ощущений, но и от цифр.

Положительные изменения после перехода к практикам Канбана на проекте «Леруа Мерлен»

• Объём выполняемой за спринт работы вырос на 20–25%.

• Задачи теперь закрываются постепенно, а не в последний день спринта (явно отслеживается на Burndown диаграмме), так как мы не берём в работу новую задачу, пока не закроем предыдущую. Это позволило сократить средний срок доставки результатов задач стейкхолдерам на 35% (с 14 дней до 9).

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

Следующим шагом планируем внедрение таких Канбан-каденций как ежеквартальное Ревью стратегии и Собрание по пополнению. Предполагаем, что это позволит значительно сократить объём «влётов» и больше фокусироваться на стратегически важных задачах.

Вместо заключения

Когда вы работаете над цифровым продуктом в in-house команде или на outsource самое главное — это результат: тот продукт, который вы отдадите конечным пользователям. Заботьтесь о них. Выбирайте модель внутреннего взаимодействия, которая подходит именно вам. И, конечно, не забывайте о команде, которая работает над проектом, мотивируйте её и ставьте чёткие цели. Все любят, когда могут похвастаться результатом и сказать, что именно они был в команде разработки крутого проекта.