Чтобы заказчик смог сделать правильный выбор в пользу сервисной или продуктовой компании для решения бизнес-задач, нужно разобраться в их особенностях и отличиях друг о друга. Какие задачи они решают и по какой бизнес-модели работают, как управляются такие команды и как взаимодействуют? Ответы на эти и другие вопросы найдете в этом материале.
Какие задачи и как решают команды
Сервисные ИТ-команды подойдут бизнесу, когда:
- имеется четкое видение того, что следует делать. Например, не нужно проверять гипотезы востребованности продукта/решения на рынке;
- есть поток разноплановых задач или уже существующий продукт, который нужно поддерживать и развивать;
- имеется потребность в реализации технологических/технических задач на постоянной основе;
- есть задачи масштабирования уже созданной команды.
В среде сервисных ИТ-команд/компаний традиционно распространены практики управления проектами (например, PMBoK), описания и автоматизации бизнес-процессов в графических и BPM-инструментах, нотации BPMN, использование helpdesk-решений.
Примеры сервисных компаний: «Ланит», Qsoft, Railsware, Pivotal Labs.
Продуктовые ИТ-команды стоит выбрать, когда:
- нет ответов на все вопросы про продукт, и нужны компетенции по проверке гипотез востребованности продукта на рынке, по созданию новой уникальной ценности продукта, помимо его технологической разработки;
- есть некое видение и комплексная задача/результат, которые дробятся на более мелкие составные задачи. При этом они должны быть реализованы в определенных границах по срокам и бюджетам.
Для продуктовых команд/компаний характерно использование таких «фреймворков» (систем) проработки аспектов продукта, как customer development, lean startup, MVP (minimum viable product) или MLP (minimum loveable product), CJM (customer journey map), JTBD (jobs to be done), HADI-циклы, сервисный дизайн и т. п.
Примеры продуктовых компаний: Microsoft, Google, «Яндекс».
Если заказчик оставляет за собой право отвечать на вопрос «Что делать», ему подойдет сервисная ИТ-команда. Она примет видение клиента в качестве вводных данных и реализует задачу/проект/продукт в нужном технологическом стеке. Отвечая на вопрос «Как делать», команда фокусируется на процессах коммуникации и delivery (доставки результата) с четкими критериями SLA (service level agreement) по качеству, срокам, бюджету, скорости реакции и т. п.
Когда нужна команда, способная ответить на оба вопроса — «Что делать» и «Как делать», применить опыт других проектов, клиентских и собственных, сгенерировать вместе с заказчиком видение проекта/продукта в режиме брейншторма, стоит обратиться к продуктовой ИТ-команде. К тому же она умеет действовать более гибко в условиях высокой неопределенности и новых вводных данных.
По какой бизнес-модели развиваются и как работают в условиях высокой неопределенности
Сервисные команды ориентируются на задачи, процессы и бюджеты заказчиков, которых они обслуживают на регулярной основе. Неопределенность компенсируется расширением пула клиентов и работой над их удовлетворенностью.
Все задачи и процессы по разработке в продуктовой ИТ-команде проходят через призму вопросов: нужно ли это пользователю, насколько А важнее Б, какое количество пользователей готовы платить за это, какой размер среднего чека и т. д. Продукты дорабатываются и развиваются итеративно — через эксперименты, получение и анализ обратной связи от рынка и от пользователей.
Сервисные ИТ-команды зарабатывают на разнице между внешним (клиентским) и внутренним рейтом (ставкой) на одного человека (разработчика/дизайнера/ маркетолога и др.), «сдают в аренду» людей из команды, их время и компетенции.
Продуктовые ИТ-команды зарабатывают на масштабировании собственных и клиентских продуктов. Также они могут работать по модели revenue share (разделение выручки/прибыли), то есть входить в долю.
Как управлять командами и мотивировать сотрудников
В сервисных командах, если говорить, например, про разработчиков, люди часто сталкиваются с потоком разнородных задач, запросов от клиентов и пользователей в формате техподдержки. Это очень востребованные задачи и процессы, особенно для крупных проектов и компаний. Но такой поток не всегда позволяет специалистам вырасти профессионально. Хотя, по моему мнению, всё зависит от человека.
Однако часто происходит «выгорание» людей от того, что они не видят осмысленного последовательного движения к результату. Такие ситуации решаются путем внутренней ротации кадров между задачами/проектами/клиентами/ролями, а также посредством обучения, обмена опытом и другими механиками.
В продуктовых командах сотрудники (разработчики, дизайнеры, тестировщики) получают определенную зону ответственности (серверная или клиентская часть, дизайн, тестирование, инфраструктура). Они развивают её в течение длительного периода времени, фокусируются на ней, презентуют и защищают перед командой, то есть отвечают за бесперебойность работы конкретного участка. Это позволяет вписать осмысленный результат в свой опыт работы и резюме, гордиться той зоной ответственности, с которой успешно справились.
У сотрудников продуктовых ИТ-команд есть возможности роста «вглубь» (в сторону специализации) или «вширь» (в направление менеджмента или совмещения нескольких ролей и экспертиз), а также обмена опытом и знаниями, накопления продуктовых «кейсов». Но и это не означает защиту от выгорания. В продуктовых командах для решения такой проблемы также применяется ротация людей между другими проектами/продуктами/направлениями, возможно и подключение к другим внешним задачам/командам/проектам.
Как происходит взаимодействие команд на практике
Сервисные и продуктовые команды принято сравнивать и противопоставлять друг другу. В реальности это могут быть состояния одной и той же компании на разных этапах своего развития.
Сервисная команда, работающая с клиентом/партнером в течение длительного срока, может стать полноценным участником проекта и ключевым ресурсом, перейдя в формат «продуктовой».
Продуктовые могут разрабатывать как собственные продукты, так и клиентские, оказывая услуги разработки, консалтинга и аналитики, сочетая таким образом сервисный и продуктовый подходы.
Крупные или смешанные компании могут совмещать оба формата в модели «виноградной грозди» с основной сервисной или продуктовой ориентацией и уклоном отдельных подразделений в какую-то одну сторону в зависимости от направления и бизнес-функции. Например, команда главной страницы поискового сервиса может быть выделена в отдельную продуктовую единицу, а команда поддержки пользователей приложения такси — в отдельную сервисную единицу.
Бизнес-заказчику важно понимать, какую задачу он решает, на какие вопросы ему нужны ответы, в какой степени неопределенности приходится действовать. И, в зависимости от этого, выбирать команды с подходящим опытом и форматом работы.
