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

Кіру не тіркелу пікір қалдыру үшін