Можно сравнить это с ремонтом дома на продажу и для себя. В первом случае достаточно просто переклеить обои. Это быстро, дешево, а когда стены начнут шататься, это будет головная боль нового владельца.
Неслучайно именно так работает аутсорсинг, и мы часто говорим, что если вы хотите работать с таким подходом, то наймите консалтинговую компанию: она умеет это делать лучше вас.
Но в продуктовой модели такой способ работы слишком затратен в плане времени и денег, и, что еще важнее, он почти никогда не обеспечивает тех инноваций, что нужны вашим клиентам и вашей компании.
Вот почему трансформация начинается с изменения способа разработки. А это значит, что нужно переключить внимание с проектов на продукты.
В продуктовой модели продуктами руководят непрерывно – они совершенствуются каждую неделю (а в сильных продуктовых компаниях – несколько раз в день), как правило, в течение нескольких лет.
Вы можете менять работу команд, добавляя новые возможности, получая дополнительную прибыль, снижая операционные расходы или решая любые другие задачи, стоящие перед компанией. Но, как правило, команда продолжает вкладываться в продукт до тех пор, пока компания не решит прекратить расширение и не перейдет к поддержанию текущего дохода, либо пока не будет принято решение о полном прекращении выпуска данного продукта.
В этой модели непрерывного развития вам нужны небольшие, бесплатные и надежные средства выпуска.
Компании, производящие успешные продукты, уже много лет назад поняли, что, хотя это может показаться нелогичным, статистика очень четко показывает: чем больше вы разрабатываете и чем больше изменений вносите, тем лучше для вас – и особенно для ваших клиентов. Словом, выпускать обновления нужно как можно чаще[5].
Если вы искренне заботитесь о том, чтобы обеспечить надежный сервис для своих клиентов, гораздо проще обеспечить небольшое количество изменений и не рисковать появлением неожиданных проблем, чем сгруппировать большое количество изменений в один релиз и пытаться выпустить все сразу (в индустрии это называется «ударный» релиз).
Подчеркнем еще раз: если каждая из ваших продуктовых команд не выпускает обновление хотя бы раз в две недели, то вы не сможете заботиться о своих клиентах на необходимом уровне[6].
Кроме того, при внедрении новых возможностей необходимо следить, чтобы они функционировали – так вы будете знать, что продукт работает корректно, и понимать, как ваши клиенты используют его на самом деле. Вам также необходимо постоянно держать руку на пульсе, чтобы обнаруживать любые проблемы раньше клиентов. Для многих важных изменений необходимо продемонстрировать, что новая функция приносит необходимую пользу, прежде чем широко внедрять ее (стандартный способ это сделать – провести A/B-тестирование).
Вы можете возразить, что на ваш тип продукта это не распространяется или что ваши клиенты сами просят обновлять продукт пореже, но в главе 18 «Разработка продукта» мы обсудим причины, по которым постоянные обновления нужны и вам, и вашим пользователям, а также обозначим принципы, на которых строится этот способ работы и механизмы этой работы.
Заметка об Agile и Agile-коучах
Вы почти наверняка слышали об Agile. Основная причина, по которой многие компании перешли на Agile-процессы за последние 20 лет, заключается в том, что эти методы должны были создать давление на продуктовые команды и заставить их перейти на последовательные, небольшие и частые релизы.
Переход на небольшие и частые релизы и впрямь может потребовать значительных инвестиций – в основном в тестирование и автоматизацию внедрения. Но компании, которым удалось при помощи методов Agile перейти к релизам не реже чем раз в две недели, увидели реальную пользу для себя и своих клиентов.
Однако важно понимать, что для последовательных, небольших и частых релизов Agile-методы необязательны.
На самом деле, многие опытные продуктовые команды по всему миру освоили методику последовательного внедрения очень маленьких релизов (так называемая непрерывная интеграция и непрерывное внедрение, или CI/CD), но при этом не следуют никаким формальным Agile-процессам или методам.
Напротив, есть организации, которые тратят много времени и денег на Agile-коучей, на ритуалы, роли, методы и процессы, но итогом этих значительных инвестиций по-прежнему остаются ежеквартальные продукты и связанные с этим неудобства для клиентов.
Будем откровенны, поскольку этот момент крайне важен. Если ваша компания по-прежнему выпускает релизы ежегодно, ежеквартально или даже ежемесячно, то неважно, сколько Agile-ритуалов вы соблюдаете и сколько у вас трудится так называемых Agile-тренеров. Это не Agile ни в каком значении слова, вы упускаете все преимущества этого метода и не работаете на пользу своих клиентов и собственного бизнеса.
Многие компании потратили миллионы долларов на переход к Agile-процессам в надежде, что именно это и означает трансформацию, но значимых результатов как не было, так и нет. Если это ваш случай, то мы уверены, что вы разочарованы до глубины души.
Но на самом деле, независимо от того, подняли вы флаг Agile или нет, каждую продуктовую команду необходимо довести до уровня, когда она сможет выпускать частые, небольшие, надежные релизы не реже чем раз в две недели.
Если ваши сотрудники не могут этого выполнить, придется привлекать опытных руководителей, инженеров или настоящего тренера по разработке продукта, чтобы показать им, как это сделать.
Глава 8. Меняем алгоритм решения проблем
Разработка, тестирование и внедрение – важный процесс вне зависимости от того, какой продукт вы решили создать, однако многие компании идут по пути простого наращивания функций.
Они превратились в настоящий конвейер по производству функций, но при этом не видно ни их ценности для клиентов, ни благотворного влияния на бизнес.
На самом деле в большинстве современных компаний доля по-настоящему прибыльных функций и проектов в «дорожных картах» удручающе мала. Большинство отраслевых аналитиков оценивают их в диапазоне от 10 до 30%.
Если вы сравниваете список возможностей, которые нужны вашей компании, с тем эффектом, который они приносят, и не чувствуете ожидаемой отдачи, то пришла пора менять алгоритм решения проблем.
Все дело в том, что эти продуктовые команды настроены на обслуживание стейкхолдеров, а не на то, чтобы приносить пользу клиентам в прибыльном для бизнеса русле.
Руководство и стейкхолдеры видят каждый свои специфические рабочие потребности и составляют список функций и проектов, которые, по их мнению, помогут выполнить обязательства перед бизнесом. Они передают эти приоритеты продуктовым командам, которые затем должны предоставить «дорожную карту» продукта с указанием сроков и результатов.
Почему же лишь немногие из этих функций приносят желаемую прибыль?
Дело в том, что каждая из этих функций – это потенциальное решение какой-либо проблемы. Это может быть проблема клиентов – например, они не могут понять, как эффективно применять ваш продукт. Или это может быть проблема компании – например, поддержка продукта обходится вам слишком дорого.
В рамках модели функциональной команды каждая функция из «дорожной карты» продумывается дизайнером этой команды, а затем создается инженерами этой команды. Но за то, принесет ли эта функция пользу вашим клиентам или компании, отвечает тот, кто попросил включить ее в «дорожную карту».
Как правило, это стейкхолдер, который осознает свои собственные потребности, но не обладает глубоким пониманием фоновых технологий, столь важных для технологических продуктов, и едва ли имеет роскошь постоянного личного общения с пользователями и клиентами о том, что их волнует и какие задачи им нужно решить.
