Читать книгу Бизнес-трансформация. Как перестроить традиционную модель по законам Кремниевой долины - Марти Каган - Страница 11

Инвестиции в технологии – это создание ценности для ваших клиентов и вашей компании.

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

Для многих компаний, работающих с технологиями, инженеры являются самой крупной статьей расходов.

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

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

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

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

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

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

Неслучайно именно так работает аутсорсинг, и мы часто говорим, что если вы хотите работать с таким подходом, то наймите консалтинговую компанию: она умеет это делать лучше вас.

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

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

В продуктовой модели продуктами руководят непрерывно – они совершенствуются каждую неделю (а в сильных продуктовых компаниях – несколько раз в день), как правило, в течение нескольких лет.

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

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

Компании, производящие успешные продукты, уже много лет назад поняли, что, хотя это может показаться нелогичным, статистика очень четко показывает: чем больше вы разрабатываете и чем больше изменений вносите, тем лучше для вас – и особенно для ваших клиентов. Словом, выпускать обновления нужно как можно чаще[5].

Если вы искренне заботитесь о том, чтобы обеспечить надежный сервис для своих клиентов, гораздо проще обеспечить небольшое количество изменений и не рисковать появлением неожиданных проблем, чем сгруппировать большое количество изменений в один релиз и пытаться выпустить все сразу (в индустрии это называется «ударный» релиз).

Подчеркнем еще раз: если каждая из ваших продуктовых команд не выпускает обновление хотя бы раз в две недели, то вы не сможете заботиться о своих клиентах на необходимом уровне[6].

Кроме того, при внедрении новых возможностей необходимо следить, чтобы они функционировали – так вы будете знать, что продукт работает корректно, и понимать, как ваши клиенты используют его на самом деле. Вам также необходимо постоянно держать руку на пульсе, чтобы обнаруживать любые проблемы раньше клиентов. Для многих важных изменений необходимо продемонстрировать, что новая функция приносит необходимую пользу, прежде чем широко внедрять ее (стандартный способ это сделать – провести A/B-тестирование).

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

Заметка об Agile и Agile-коучах

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

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

Однако важно понимать, что для последовательных, небольших и частых релизов Agile-методы необязательны.

На самом деле, многие опытные продуктовые команды по всему миру освоили методику последовательного внедрения очень маленьких релизов (так называемая непрерывная интеграция и непрерывное внедрение, или CI/CD), но при этом не следуют никаким формальным Agile-процессам или методам.

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

Будем откровенны, поскольку этот момент крайне важен. Если ваша компания по-прежнему выпускает релизы ежегодно, ежеквартально или даже ежемесячно, то неважно, сколько Agile-ритуалов вы соблюдаете и сколько у вас трудится так называемых Agile-тренеров. Это не Agile ни в каком значении слова, вы упускаете все преимущества этого метода и не работаете на пользу своих клиентов и собственного бизнеса.

Многие компании потратили миллионы долларов на переход к Agile-процессам в надежде, что именно это и означает трансформацию, но значимых результатов как не было, так и нет. Если это ваш случай, то мы уверены, что вы разочарованы до глубины души.

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

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