Чтение онлайн

Модель предполагала предоставление возможности стейкхолдерам «покупать» функции, которые им нужны, у функциональных команд, пока им позволяет бюджет.

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

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

Прошло несколько лет, и вот что мы видим. В 2011 году при проведении IPO акции компании предлагались по цене 16 долларов за штуку, но постепенно акционерный капитал истощался, цена акций упала до 8 долларов за акцию, и в итоге компания была продана [41] .

Годами я приводил историю этой компании как пример того, как не надо производить продукт.

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

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

Это особенно наглядный пример отсутствия продуктовой стратегии, отсутствия фокуса и в целом отсутствия продуктового лидерства.

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

При подобном подходе легко генерировать работу, но не результаты. Стивен Бангей объясняет это следующим образом:

Генерировать деятельность — это не проблема, это достаточно легко. Но эта легкость и затрудняет решение реальной проблемы. А реальная проблема в том, чтобы претворять в жизнь то, что действительно нужно, — то, что имеет значение, что будет иметь важные последствия и что приведет компанию к успеху [42] .

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

Я (Марти) сделал это в самом начале карьеры, он навсегда отпечатался в моей памяти, и я обнаружил, что данный принцип применим ко многим аспектам бизнеса в сфере технологий.

Когда я начал разрабатывать программное обеспечение в лаборатории прикладных исследований компании HP, я только что окончил колледж. То есть у меня были какие-то теоретические знания, но совсем мало практического опыта.

В то время мы работали, используя практику, которую сейчас называют парным программированием. Меня ставили в пару с более опытным инженером, и мы «совместно» писали программу. Я использовал кавычки, поскольку на самом деле большую часть работы выполнял он, а я в основном наблюдал и задавал вопросы.

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

Плюс заключался в том, что практически для любой области кода, которую мы рассматривали, было не так трудно найти способ рефакторинга для улучшения производительности. Я все время указывал туда, где мы могли бы что-то улучшить, но мой наставник неизменно говорил: «Можем, но не будем». Наконец он сказал: «Ладно, пора заняться производительностью», после чего запустил инструмент анализа производительности, который позволил замерить производительность нашего программного обеспечения; и мы смогли отчетливо увидеть, на что на самом деле тратим время.

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

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

Он заметил, что в большинстве организаций твердят о «важности производительности», поэтому каждая команда понемногу работает на эту производительность. Но подавляющая часть такой работы ничего не меняет. А там, где она могла бы на что-то повлиять, ей уделяют слишком мало целенаправленного внимания.

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

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

Есть и вполне практическая причина сосредоточиться на нескольких важных проблемах.

Большинство специалистов по разработке технологичных продуктов знают о концепции WIP-лимитирования (work in progress limits), или ограничения на незавершенное производство («Сделай больше в будущем, сделав меньше прямо сейчас»). Эта концепция особенно популярна в продуктовых командах, использующих методологию управления рабочим процессом «канбан».

Суть ее в том, что мы выполним больший объем работы (осуществим производительность), если ограничим количество задач, над которыми работает продуктовая команда в каждый конкретный момент. У большинства команд таких задач сразу несколько. При отсутствии таких лимитов работа накапливается в узких местах, и в итоге нам приходится постоянно менять контекст, из-за чего мы успеваем произвести меньше продуктов.

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

Однако если на уровне продуктовой команды она полезна, то на уровне крупной продуктовой организации абсолютно необходима.

Когда у организации в работе одновременно 20, 30 или даже 50 «первоочередных» задач, инициатив или проектов, возникает та же проблема, но только гораздо более серьезная.

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

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

Можно смело сделать вывод, что организация будет иметь больший объем завершенных критически важных работ, если сфокусируется всего на нескольких задачах одновременно.

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