С чем у большинства ассоциируется слово «продюсер»? Что-то про шоу-бизнес, кино, про раскрутку поп-звезд. Реже — про бабло и договоры. Но уж точно не про IT. И это полностью оправдано: продюсирование как явление пришло в мир из американского кинематографа вековой давности. В современной IT-индустрии продюсеров почти нет, здесь все процессы исторически выстроились иначе.
Но времена меняются. Стартапы «на коленке» больше не взлетают, мир высоких технологий стал еще выше — теперь для создания крутого проекта нужна команда не менее крутых спецов, время гениальных одиночек закончилось. Продукты становятся сложнее, технологии с каждым часом «инновационируют». Меняются темпы разработки, сами требования к процессу. Новые пользователи Интернета уже вовсе не пользователи, а жители.
Старый дядька в потертом свитере недоуменно жмет плечами: все же работало, кэш пробовали чистить? А блондинка из бухгалтерии, разворачиваясь и устало вздыхая, бормочет вполголоса, что кэш в «прогрэссив веб аппсах» хрен просто так почистишь.
И из всей этой прелести вырастает целый пласт проектов, которые больше не подчиняются законам аутсорсинга и привычной заказной разработки. Их не спасет общительный аккаунт-менеджер, а даже самый упоротый юиксер не осилит проектирование. Зато здесь прекрасно подойдет IT-продюсер. Беспринципная сволочь, чья единственная цель — реализовать клевый продукт в обозначенных условиях.
Не каждый проект нуждается в продюсировании
Не подумайте, я отнюдь не хороню привычные всем нам и любимые профессии. Более того, я даже не говорю, что продюсирование теперь — неотъемлемая часть IT-разработки. Да, рынок неоднороден, но все проекты можно так или иначе поделить на три типа, прекрасно описанных Дэвидом Майстером (David Maister) в книге «Управление фирмой, оказывающей профессиональные услуги»:
- «Мозги» — это сложные, нестандартные проекты, в которых от исполнителя требуется поиск новых подходов и решений. Каждый такой проект сопряжен с глубоким погружением в незнакомую предметную область, каждый не похож на предыдущий (просто потому что чаще всего прямых аналогов таких продуктов еще нет).
- «Седина» — работать с этими проектами проще, хотя и здесь зачастую требуется некоторая индивидуальность. В таких проектах все более-менее известно заранее, и решает тут, по большей части, опыт исполнителей: чем больше подобных проектов за плечами, тем круче спецы.
- «Процедуры» — самые простые проекты, в которых действия по решению задач хоть и могут быть многочисленны, но просты и прекрасно описаны. Профи на таких проектах способны решать проблемы клиентов быстро и эффективно — но только если они четко попадают в довольно узкий ореол их компетенций.
И если с последними двумя («Сединой» и «Процедурами») все понятно, то проекты типа «Мозги» являются самыми рискованными. Их практически невозможно стандартизировать, технологии их реализации могут кардинально изменяться из-за одной незначительной детали, а требуемая от дизайнера глубина погружения может показаться кому-то граничащей с одержимостью.
Пару лет назад мне предложили заняться проектом по онлайн-защите интеллектуальной собственности. При всей своей кажущейся простоте, тема оказалась настолько глубокой, что я две недели изучал международное, российское и американское законодательство, прежде чем набросал первый юзкейс.
Я не зря упомянул про аккаунтов в предыдущей части. В «Мозгах» клиент ждет куда большей погруженности и вовлеченности, чем может дать обычный аккаунт-менеджер, с пучком других проектов на загривке. Если компания позиционирует себя как специализирующуюся на нестандартных решениях, если она позволяет себе выбирать клиентов и проекты поинтереснее да посложнее — и при этом общение с клиентом перекладывает на аккаунта… Мир праху таких проектов.
Продюсер !== (проектировщик || продакт)
Казалось бы, все просто. Убираем (двигаем) аккаунта, сажаем на его место (рядом с ним) грамотного продуктового дизайнера/проектировщика, даем такому дизайнеру один, максимум два проекта одновременно — и все, дело в шляпе. Ну или директора/менеджера по продукту/проекту. При чем тут вообще продюсеры и продюсирование? Что ты нам голову морочишь?
А вот тут мы подходим к самом интересному.
Компетенции
В кинематографе хороший продюсер досконально знает, чем занимается каждый работник на съемочной площадке — от «хлопушки» до фокус-пуллера. Многих он способен заменить сам, а у остальных — как минимум, оценить профессиональный уровень. Продюсер в кино планирует весь съемочный процесс, озвучку и пост-продакшн — а это, поверьте, очень и очень непросто. Он набирает команду под конкретный проект, с учетом всех его особенностей и потенциальных факапов.
И именно это позволяет ему обоснованно нести персональную ответственность за производство, за финальный продукт, за бюджеты и сроки. Часто вы встречали такое в IT? Многие из ваших знакомых дизайнеров-проектировщиков/продактов/проджектов могут похвастаться, что способны продумать проект целиком: от технической архитектуры и программной логики до детальных пользовательских сценариев? А еще — оценить все это в бабле и времени. А еще — подобрать команду, идеально подходящую для реализации? А еще — контролировать процесс хотя бы на уровне авторского надзора?
Сейчас у кого-то в голове уже возник вопрос: «А нафига? Почему это все должен делать один человек? Раньше как-то справлялись оравой, и ниче…». Так и сейчас вполне справляются. На проектах типа «Седина» или «Процедуры». Как я уже писал, в «Мозгах» требуется глубокое погружение и понимание не только пользовательских историй и технической составляющей, но и бизнеса — а без этого все то, что описано в предыдущем абзаце, тупо нереализуемо.
Не нужно знать все досконально: Senior JAVA Developer вряд ли уживется в одной голове с гуру маркетинга или UX-исследований. Для описанного выше достаточно конкретной специализации и развитых хард/софт скиллов.
Да ладно, я утрирую. В теории, продюсер может нанять системного архитектора, бизнес-аналитика, продуктового дизайнера, да тимлида широкого профиля. И с каждым из них проводить по часу в день, чтобы быть увереным, что понимание проекта у всех единое (кхе-кхе). Разработать под проект стандарт документации (общего, увы, не получится), заставить всех его вызубрить. Ну и еще что-нибудь придумать. Ах да, все эти люди еще должны любить друг друга и быть гиперответственными.
Финансы
Хороший продюсер должен понимать, как работает рынок и какую позицию на этом рынке занимает он сам. Как составить и читать финмодель (хотя бы базового уровня, без сезонности, но со страшными словами вроде EBITDA). Он должен уметь просчитать бюджет, который обласкает подрядчика и не вызовет инсульта у клиента. Он должен уметь управлять проектом и знать, что необходимо для его запуска.
Мерзкий характер
Продюсеру часто приходится произносить слово «нет». Наверное, это вообще самое частотное слово в его лексиконе. Причем адресует он его всем: разработчикам, UX-дизайнерам, маркетингу, даже клиенту. Кстати, последнему — в первую очередь, еще на этапе формирования концепции продукта (просто потому что клиент не всегда в курсе тьмы тьмущей ограничений, накладываемых законодательством, финансовыми обстоятельствами или отсутствием технологии телепортации при нынешнем уровне развития человечества).
Продюсер должен быть жестким, как шконки сибирских лагерей, и аргументированным, как решение Гаагского трибунала. Если вдруг единственным способом спасти проект в середине разработки будет увольнение собственной мамы — его курсор не должен дрогнуть.
В заключение
Можно еще много чего написать. Про некоторую душевную черствость (вкупе с развитой сознательной эмпатией), про превосходные коммуникативные навыки, про другие особенности психологии — но это уже нюансы. Статья не про то, кто такой продюсер, а — почему именно продюсирование.
Собственно, главный мой аргумент прост: это работает. Прямо сейчас, в этот самый миг кто-то из Цифровой артели Eleven фигачит шедевральную концепцию, прототип или апишку. А может, готовит бюджет или договаривается с подрядчиками. А может, с наслаждением тратит честно заработанное продюсированием.
P.S. Более подробно об IT-продюсировании рассказано в книге моего партнёра, Вадима Митякина — «Метод параноика».
