От проектов к продуктам
Разговор о культуре продукта может казаться оторванным от жизни, но она ежедневно влияет на каждого сотрудника. Чтобы попытаться воплотить эти принципы в жизнь, приведем пример очень распространенной ситуации «до и после».
В старых моделях часто все сводилось к тому, чтобы разработать проекты к определенным датам.
Понятно, откуда это берется, ведь от ИТ-отдела постоянно требуют, чтобы конкретные функции и проекты были реализованы как можно быстрее.
Проблема в том, что такой подход игнорирует реалии продукта, работающего на основе технологий.
Проекты — это, как правило, большие, медленные и дорогостоящие попытки получить какой-то результат к определенной дате. Вам приходится решать, насколько большой должна быть команда, и прикидывать, сколько времени займет работа. Затем нужно выбить финансирование, после чего вы неизбежно узнаете, что проект потребует больше сил, чем вы предполагали, а его выполнение превращается в настоящее испытание.
Большинство усилий уже не направлены на создание ценности, а просто призваны получить на выходе хоть какой-то продукт. Затем, когда он наконец-то внедрен, сотрудники не могут проводить циклы отладки и улучшения, потому что чаще всего разбегаются по следующим заданиям. Никто не берет ответственность за результат, и все выводы и инсайты, полученные в ходе работы, скорее всего, будут потеряны.
Здесь сразу несколько негативных явлений:
Обычно требуется несколько последовательных итераций, пока вы не добьетесь необходимых результатов, но полученного финансирования редко хватает более чем на одну попытку. А если и удается возобновить его, то, как правило, на несколько кварталов позднее.
Вам нужно, чтобы люди чувствовали реальную ответственность за технологию и результаты, но, когда сотрудников привлекают только на время проекта, они не чувствуют себя хозяевами данного участка работы и у них мало стимулов для создания чего-то значимого.
В описываемом сценарии речь идет о разработке функций и проектов, о которых просят ключевые специалисты других направлений, вместо того чтобы позволить вашей продуктовой команде, особенно разработчикам, изучить текущие технологические возможности. В результате инновации в проектах — явление крайне редкое.
Поскольку команды создают только то, что им нужно для данного проекта, никто не беспокоится о долгосрочных последствиях этой работы и об оптимизации базовой технологии, отчего быстро накапливается технический долг.
Кто берет на себя ответственность за достижение необходимого результата? Чувство ответственности обычно размазано между несколькими специалистами разных направлений, а в итоге наиболее вероятно, что все стрелки переведут на команду данного проекта и обвинят ее в плохо сделанной работе.
А вот в продуктовой модели вы фокусируетесь на продуктах и результатах.
Продуктовая команда фокусируется на бизнес-результатах, таких как снижение уровня оттока, ускорение роста или любые другие KPI, соответствующие вашей ситуации, и она же постоянно работае
Бизнес-трансформация. Как перестроить традиционную модель по законам Кремниевой долины
·
Джон Мур