Продуктовые vs проектные команды

Я планировал написать эту статью еще два года назад, сразу после публикации “Продуктовые vs. Фиче-команды”. Тогда мне казалось, что мне следует развить центральную смысловую линию в статье про разницу между продуктовыми и проектными командами, но в действительности это была попытка выдать желаемое за действительное.

Я по-настоящему хотел верить, что больше нет необходимости продолжать приводить доводы в пользу того, что проектные команды неэффективны. Ровно так же, как когда верил, что никто не будет голосовать за откровенное мошенничество, или что люди будут опираться на научные данные в вопросах, касающихся их здоровья, или что Facebook будет всегда поступать правильно. К сожалению, самовнушение не способно изменить реальность.

Мой партнер по компании Silicon Valley Product Group (SVPG) и соавтор книги EMPOWERED: Ordinary People, Extraordinary Products Крис Джонс недавно поделился со мной, что он все еще сталкивается с проектными командами, но я не желаю верить, что это до сих пор распространенное явление. Дело совсем не в том, что я не писал о проблемах, возникающих в проектных командах, просто многие из тех статей написаны уже более десяти лет назад, и мне очень хотелось верить, что мы это все уже прошли.

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

Однако по сути разница между продуктовой и проектной командой в ответственности. В одном случае команда берет ответственность за ключевые результаты для бизнеса (“outcome” — метрика бизнес-эффекта, дает возможность измерить полученную ценность для компании и клиентов); а в другом команда занимается поставкой проекта, фактических результатов (“output” — метрика результата фактических действий; числовые измерители результата задач, шагов или действий, предпринятых для создания ценности).

На жаргоне метода Lean Startup (“Бережливый стартап”), продуктовая команда долговечна, она живет долго (обычно минимум 1-2 года). Проектная команда, напротив, существует на протяжении жизни проекта. Поэтому проектные команды иногда связывают с понятием “pool model”: инженеры привлекаются к работе над проектом в течение, например, недели, месяца или двух, а после окончания работы над проектом возвращаются обратно в пул, откуда их переназначат в какую-то другую область. Самый большой миф о проектной команде заключается в убеждении об эффективности такого подхода, якобы потому что каждый инженер “полностью задействован” на наиболее важном проекте в данный момент.

Если вы работаете над чем-то тривиальным, например, созданием веб-сайтов, тогда да. Но я никогда не работал с компанией, создающей тривиальные вещи.

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

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

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

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

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

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

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

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

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

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

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