Роли и структура организации в IT-компании

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

Часто я сталкиваюсь с описанием вакансий и запросами вроде «нам нужен CPO в стартап». После вопроса сколько в стартапе людей и продуктов, выясняется что продуктов один или два, сотрудников — не более 30, а под CPO подразумевается просто опытный менеджер продукта, который должен работать руками (в то время как роль CPO — это роль стратега, управленца и ментора).

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

Такое несоответствие реальной потребности и воображаемой я встречаю повсеместно.

Корпоративные иерархии и HR-отделы оперируют набором красивых слов, и вот некоторые из них:

Значения этих слов варьируются от компании к компании, где-то случайно, где-то намеренно: «Мы называем нашу кнопку унитаза велосипедом потому что это подходит нашей компании», «Мы к этому пришли исходя из своего опыта».

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

О ролях и функциональности я и хочу поговорить ниже.

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

Отвечает за развитие технологической части компании.

Размытое определение? Уточним: — В стартапе на 10 человек CTO обычно выполняет функции тимлида, но получает красивое название по двум причинам: чтобы потешить собственное эго и в расчете на то, что в будущем он займет эту роль. Объясняется это тем, что человек отвечает не за конкретную команду, а за развитие всей технологической части сейчас и в будущем.

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

— В компании на 1000+ человек частью задач предыдущего блока (синхронизация подходов разных команд к разработке, поддержание единого стэка и архитектуры) занимается Chief Architect. Фокус CTO уходит на найм и развитие руководителей, управление техническими лидерами направлений, и ответственность за выполнение технических планов.

— В компании на 10 000+ CTO отвечает за долгосрочное техническое видение компании и выполнение стратегических планов.

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

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

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

Можно найти много определений, но мне ближе всего следующее: человек, отвечающий за техническое развитие определенного направления/проекта в работе, над которым участвует несколько технических команд. CTO направления. С ростом компании единственный способ выполнять технические планы — делегировать эту функцию от CTO. Когда над проектами начинают работать несколько технических команд, их работу надо синхронизировать, технические компетенции развивать, и эта роль становится актуальной

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

Задача тимлида — выполнить планы команды, на это завязана его мотивация. Когда в компании одна команда, тимлид — то фактически CTO, у него много свободы и ответственности.

С ростом количества людей и делением их на команды, каждая команда начинает (и должна) переживать только о своих планах. Чтобы синхронизировать их работу появляется CTO, человек который отвечает за все команды.

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

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

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

Зеркало роли CTO в продуктовой части. Если компания маленькая, то CPO по сути будет единственным менеджером продукта, а роль — это просто красивое слово.

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

Вдобавок к этому его задача — обеспечивать отбор специалистов и поддерживать уровень экспертизы среди менеджеров продукта.

Здесь тоже существуют разные интерпретации, но мы обратимся к слову Senior. Когда видишь такую приставку хочется спросить senior to whom. Очевидно, что в погоне за блестящими значками и бантиками просто опытных менеджеров продукта стали называть Senior, но если следовать логике, то старший менеджер продукта появляется, когда есть младшие.

Соответственно основной задачей старшего менеджера продукта является продуктовый менеджмент направления, где представлены несколько продуктов со своими менеджерами.

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

Здесь мы подходим к классическому квартету Product Owner / Product Manager / Product Manager / Business Owner и разделению ролей.

Менеджер продукта отвечает за стратегическое видение продукта, роадмап, анализ рынка/продукта и генерацию гипотез в соответствии с приоритетами бизнеса.

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

Ответственность разделяется соответственно: если из-за некачественных вводных владельцем продукта были приняты неверные решения — это ответственность менеджера продукта. Если были выбраны или согласованы неверные приоритеты — это ответственность владельца продукта. Если продукт оказался не востребован рынком — ответственность зависит от того, предупреждал ли менеджер продукта об этом владельца. Если владелец был предупрежден — то это его ответственность.

Менеджер проекта отвечает за реализацию бэклога в оговоренный срок и бюджет.

Отвечает за результаты капиталовложений в разработанный продукт перед советом директоров/акционерами.

Владелец продукта и бизнес-оунер — это роли, а менеджер продукта и менеджер проекта это еще и профессии.

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

Business Owner редкая роль — поскольку именно Product Owner обычно выступает со стороны бизнеса. Но в некоторых ситуациях, которые должны существовать только в больном воображении, а не реальности, появляется еще один уровень абстракции в виде человека который отвечает за продажи.

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

Недавно Scrum Inc стала продвигать альтернативное видение роли Product Owner как человека ответственного за тактическую реализацию стратегического видения менеджера продукта. Я буду придерживаться оригинальных идей Agile, а для еретиков приведу цитату преподавателя Гарвардской школы бизнеса: “I’ve trained dozens of teams who are using SAFe and I have never seen this work well.”

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

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

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

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

Подписывайтесь на мой телеграмм канал @dailykuznetsov где я публикую короткие заметки о финансах, обществе и управлении продуктами

Статью написал Иван Кузнецов, отредактировала Надежда Коротченко