Почему не у всех получится делать продукты
Битва адептов продуктовой разработки и сотрудников аутсорсинговых компаний не утихает и утихать, по-моему, не собирается. Логические аргументы в ход уже идут редко, и споры между двумя группами IT-специалистов (разными по размеру, но одинаково важными) все больше напоминают споры между фанатами Apple и поклонниками Samsung. Наверное, ничего плохого в этом нет. Но я вместо того, чтобы признаваться в любви к одному из подходов, постараюсь оперировать фактами.
Когда-то я был соучредителем продуктовой компании и успел набить много шишек. Потом работал в аутсорсинге и в принципе постоянно переходил между компаниями двух типов в поисках золотой середины между подходами. Сейчас я почти год наблюдаю за интегрированной направленностью в DataArt, возглавляю системный переход к продуктовому подходу в разработке и хотел бы рассказать именно о нем.
Статью я написал по мотивам выступления на киевском IT Talk — это серия внутренних конференций DataArt, на которые мы, впрочем, часто приглашаем всех желающих. Я физически не мог вместить в доклад всех фактов, которые подтверждают его основные тезисы. Но все-таки надеюсь, что этот текст покажется достаточно убедительным.
Мечты о продуктах
Начнем с того, что украинское сообщество разработчиков сформировано аутсорсингом, в нем до сих пор занято подавляющее большинство программистов. Но плох тот солдат, который не мечтает стать генералом, и плох тот айтишник, который не собирается однажды написать собственный продукт и стать миллиардером. Ну или в крайнем случае миллионером. Это естественное, нормальное желание.
Почему все мечтают о своих продуктах? Мой любимый пример объяснения — классическая ошибка выжившего. Историю пишут успешные люди, которым часто просто повезло. Признавать этого они не хотят и видят за успехом только свой упорный труд. Продукт дает нам масштабирование и быструю прибыль. Поэтому все хотят создать аналог снэпчата. Кстати, если при этом уточнить, сколько читателей статьи этим сервисом пользуется, думаю, процент окажется не таким уж большим. Это полезный штрих к вопросу о потребностях подростков и шансах создать что-то стоящее именно для них.
Аутсорсинг — сервисный бизнес, который всегда масштабируется только размером. Рост здесь нужен, чтобы обработать в десять раз больше клиентов. Иногда для этого нужно в 10 раз больше людей, а иногда и в 12, поскольку масштабирование здесь нелинейное. Впрочем, для разработчика главное не это.
Основных мотиваторов, которые делают работу в продуктовой компании более привлекательной, два: деньги и известность. Программисту веселее небрежно заметить, что он сотрудник Facebook, чем объяснять, как здорово ему заниматься аутсорсинговым проектом. Сами по себе сервисные компании крайне редко бывают знаменитыми, а с удачным продуктом вполне возможно разделить успех. Неважно, насколько интересной или скучной будет работа самого разработчика, участвовавшего в его создании.
В сервисных компаниях чувство принадлежности и сопричастности результатам работы в принципе развито намного слабее. На потребности в нем держатся внутренние стартапы и инкубаторы, поскольку мечты о продуктах разработчиков не оставляют.
Готовность номер один
Если мы хотим перевести сервисную компанию на продуктовый подход, то должны понимать: это другой, новый для нас бизнес. Теперь для команды будут работать другие мотиваторы, и требования к пониманию бизнеса для инженеров тоже изменятся. Осознать, как созданный вами продукт зарабатывает деньги для заказчика, должны все — от руководства компании и проджект-менеджеров до разработчиков и QA.
Представьте, что приходите к владельцу любого бизнеса — скажем, он продает кофе с машины. Спросите его, сколько он зарабатывает, скольких клиентов обслуживает ежедневно, каков средний чек, каковы операционные и внезапные рисковые расходы. На все эти вопросы у него наверняка есть ответы. Когда он решит завести еще несколько машин, то передаст эти знания дальше и будет требовать понимания этих моментов от других. Их же должны принимать во внимание все, кто работает над продуктом — на основании этих показателей принимаются решения о его дальнейшей судьбе.
Отношения между инженерами и бизнесом строятся по-разному. Аутсорсинговые компании обычно прокладывают между ними множество слоев из управленцев, ограждая разработчиков от необходимости думать о бизнес-аспектах. Продуктовый подход ставит их на передний край общения с потребителями ПО — на другом полюсе, максимально далеко от традиционной сервисной модели, работает Booking, где вообще нет тестеров и менеджеров, принимающих решение «релизить или нет».
Новую фичу здесь можно доставить одним движением. Не то чтобы у них не было людей, способных все завалить, просто код сначала уходит в ротацию AB-тестов с миллионами вариантов. Основной параметр — конверсия заказов. Если она у заказов с новой фичей выше, робот начинает наращивать трафик. Если ниже — робот ее из ротации убирает, а автор получает письмо: «Спасибо, твоя идея провалилась». Так бизнес-показатели становятся мерой принятия решений. Вы ведь знаете, что бездействие часто оказывается лучшей стратегией, чем написание никому не нужных фич.
Критерии успеха
Теперь представьте себе, что вы владелец или CEO компании с теми самыми кофемашинами. По каким-то причинам вы решили передать на аутсорсинг разработку IT-системы для ваших кофеен. Какую информацию вы должны передать исполнителям, чтобы бизнес оставался эффективным? Business vision и Target audience: кто покупает у вас кофе, где места с высокой проходимостью. А также показатели, сигнализирующие, что продукт нужно подстраивать или менять. В данном случае таким показателем будет среднее количество покупок в день. Эксперименты можно ставить очень быстро: провести на месте целый день, учесть погодные условия. Казалось бы, не надо быть ни Эйнштейном, ни Коперником.
Для того, чтобы разработка этого продукта для кофеен была успешной, нам нужно ответить на два ключевых вопроса:
- Кто и как сможет определить, успешен проект или нет?
- Кто будет спрашивать, успешен ли проект?
Если в сервисной компании зачастую нет людей, способных ответить на два этих самых важных вопроса — продуктового подхода в ней нет. Справедливости ради: ответить на них и в продуктовых компаниях могут не всегда. Но это неправильно — именно в таких случаях на сцене появляется любимый всеми тип проджект-менеджера. Тот самый, который любит высчитывать не совсем понятные показатели: сравнивает цену одной «Таврии» с ежемесячным потреблением электроэнергии и т. д. Это не очень сложно, а при известных усилиях позволяет довольно долго выглядеть умнее.
Кофемашины и продажа кофе «на колесах» — операционный бизнес, работающий по понятным схемам. В IT мы занимаемся созданием инновационных бизнес-продуктов. По крайней мере, нам с вами приятно думать, что каждый раз мы производим что-то новое. Но передавать точное представление о бизнес-показателях нам не менее, а может быть, и более важно. Пока в большинстве компаний, на мой взгляд, эта функция никем не закрыта.
Проблему усугубляет то, что у большинства продуктов, которые мы создаем, цикл обратной связи очень длинный. С кофе все более или менее понятно здесь и сегодня. В больших онлайн-играх цикл обратной связи уже значительно длиннее. Пользователи не уходят моментально, если им стало скучно. Они начинают аккуратно отсеиваться, и падение сначала выражается в долях процента. И вам надо понять: это сезонное явление, связанное с внешними факторами, или дело в вашей ошибке? А все исправить вы в лучшем случае сможете месяца через полтора, а то и через три или даже шесть.
Аутсорсинговые компании прекрасно следят за технической частью, но следить за бизнесом они очень часто не умеют. При этом большинство клиентов, которые обращаются к ним, не имеют прямого отношения к IT. То есть на самом деле тоже не очень-то представляют, как следить за собственным высокотехнологичным продуктом с точки зрения бизнеса. Когда они собираются вместе — проблем не избежать.
Погружение в бизнес
Ничего плохого в том, чтобы самостоятельно не делать продуктов, нет. Аутсорсинг — чистое и честное занятие. Другое дело, что только посмотрев на свой проект с позиции продукт-менеджмента, можно понять: оптимальное решение может лежать и за пределами разработки ПО. Более того, такие решения высоко ценятся в продукт-менеджменте.
По собственному опыту я знаю, что когда создаешь ПО, то больше всего ценишь архитектуру, надежность, функциональность и т. д. Когда создаешь продукт, больше всего начинаешь ценить время. Как правило, проджект-менеджер считает работу законченной, когда задачи закрыты, а нужные показатели качества достигнуты. Для продукт-менеджера критерии качества сводятся к бизнес-показателям. Оказавшись на его месте, понимаешь, зачем в программу MBA входят финансы или маркетинг.
Выводы
Переход к продуктовой разработке выглядит привлекательно прежде всего потому, что открывает выход на глобальный рынок. Если предлагаешь готовый IT-продукт, покупателю неважно, где ты его создал: в Украине, Кении или Китае. Если твое предложение — сервис, есть целый ряд ограничений: языковой барьер, часовые пояса и т. д.
Аутсорсеры давно успели подготовить хорошую технологическую базу. Но этот задел оказывается как плюсом, поскольку компании располагают подготовленными инженерами, так и минусом — поскольку привыкли решать все проблемы через производство софта. И чем больше ваш коллектив, тем сложнее будет изменить привычный для коллег подход.
Делать продукты, не понимая бизнеса, невозможно. И если вы претендуете на его производство, вам придется научить этому всех тех, кого вы планируете занять в продуктовой разработке. Чтобы общее наследие не слишком давило на тех, кому придется при этом радикально перестроиться, размещать акселераторы обычно советуют в отдельных офисах. Физическое отделение от традиционной компании здесь действительно может помочь.
