Роли и структура организации в IT-компании. Я никогда не думал, что мне придется писать такой текст осенью 2021 года, но это сэкономит мне много времени, потраченного на повторение одного и того же в различных видеоинтервью.
Я часто встречаю описания вакансий и запросы типа "нам нужен CPO в стартап". После вопроса о том, сколько у стартапа людей и продуктов, выясняется, что продуктов один или два, сотрудников не более 30, а под CPO подразумевается только опытный менеджер по продуктам, которому приходится работать руками (в то время как роль CPO — это роль стратега, менеджера и наставника).
Рекрутеры впадают в холодный пот от поиска, а заинтересованные стороны кричат о CPO и "почему его еще нет". А когда CPO найден, оказывается, что он вообще не решает текущих задач компании, потому что, например, не привык работать вручную.
Повсюду я вижу этот разрыв между реальными потребностями и воображаемыми.
Корпоративные иерархии и отделы кадров оперируют горсткой красивых слов, и вот некоторые из них:
- Менеджер по продукции
- Менеджер по продукции
- Старший менеджер по продукции
- Старший владелец продукта
- Менеджер по продукции
- Руководитель проекта
- Владелец продукта
- CTO
- CIO
- Технический лидер
- Руководитель группы
- Архитектор
- Менеджер PMO
- Главный архитектор
- Руководитель проекта
- Владелец бизнеса
Значение этих слов варьируется от компании к компании, где-то случайно, где-то намеренно: "Мы называем нашу туалетную кнопку велосипедом, потому что она подходит нашей компании", "Мы пришли к этому из опыта".
Напомню, что психически больные люди до сих пор любят использовать слова, противоречащие словарным определениям. Велосипед может называться туалетной кнопкой, но это не значит, что у него есть колеса и педали. Большинство проектов, в зависимости от их масштаба, имеют набор установленных ролей. Роль может называться разными именами, роль могут выполнять несколько человек, но каждая роль имеет свою собственную функциональность.
Роли и функциональные возможности — это то, о чем я хочу поговорить ниже.
Некоторые из приведенных выше определений — это терминология из Agile, говорите вы. Но Agile только определил существующие роли, поэтому независимо от того, есть у вас Agile или нет, ничего не изменится.
Как работают программисты: Структура IT команды
Отвечает за развитие технологической части бизнеса.
Расплывчатое определение? Для уточнения: — В стартапе, состоящем из 10 человек, технический директор обычно является лидером команды, но ему дают этот модный титул по двум причинам: чтобы поднять его или ее эго и в расчете на то, что в будущем он или она возьмет на себя эту роль. Причина в том, что этот человек отвечает не за конкретную команду, а за развитие всего технологического отдела сейчас и в будущем.
— В компании, состоящей из 100 человек, технический директор отвечает за техническую часть продуктового плана компании, развивает компетенции технического отдела, синхронизирует усилия по разработке различных команд и вносит вклад в устойчивость технической части бизнеса.
— В компании с численностью более 1 000 человек часть задач предыдущего подразделения (синхронизация подходов к разработке различных команд, поддержание единого стека и архитектуры) выполняет главный архитектор. CTO фокусируется на найме и развитии руководителей, управлении руководителями технических направлений и отвечает за реализацию технических планов.
— В компании, насчитывающей более 10 000 человек, технический директор отвечает за долгосрочное техническое видение компании и выполнение стратегических планов.
Эта роль имеет смысл в сложных продуктах, когда начинают возникать проблемы несогласованности команд, появляются несовместимые или трудно совместимые архитектуры, разрастаются стеки и подходы к решению одних и тех же проблем.
Отвечает за синхронизацию подходов различных команд к решению проблем, выбор технического стека для решения проблем, поддержание и передачу знаний об архитектуре систем.
Эта роль имеет смысл в нетехнологических компаниях, которые работают над готовыми решениями с обширной сетевой/железной инфраструктурой, или в крупных технологических компаниях с обширной сетевой/железной инфраструктурой. Отвечает за устойчивую работу сетевой/железной инфраструктуры, процедуры ее обслуживания, наем и развитие персонала, ответственного за эту инфраструктуру.
Можно найти много определений, но мне ближе всего следующее: человек, ответственный за техническое развитие направления работы/проекта с участием нескольких технических групп. Направление CTO. По мере роста компании единственным способом реализации технических планов становится делегирование этой функции от технического директора. Когда несколько технических команд начинают работать над проектами, их работу необходимо синхронизировать, развивать технические компетенции, и эта роль становится важной
Руководитель технической группы. Отвечает за реализацию планов на уровне команды, организацию работы команды, подбор и развитие членов команды, развитие технической части проекта (проектов), над которым работает команда, в соответствии с правилами компании.
Работа лидера команды заключается в реализации планов команды, и его/ее мотивация связана с этим. Когда в компании есть только одна команда, руководитель команды фактически является техническим директором и имеет большую свободу и ответственность.
Когда количество людей растет и они делятся на команды, каждая команда начинает (и должна) беспокоиться только о своих собственных планах. Чтобы синхронизировать их работу, появляется технический директор — человек, который отвечает за все команды.
Со временем отдельные области разделились, и техническому директору стали помогать техлидеры и архитектор. Роль технического директора сосредоточена на людях и стратегии, архитектор отвечает за синхронизацию подхода к разработке, а техлидеры отвечают за реализацию конкретных планов.
Цели спускаются от технического директора к техническим руководителям, а затем к командам. Задачи архитектора отделены от "выполнения планов" и сводятся к обеспечению единого подхода к разработке решений архитектурных задач. Мандат архитектора заключается в наложении вето на технические решения, а основная задача — своевременная разработка решений, согласованных с другими командами и при этом не противоречащих планам продукта/проекта.
Для ясности: технический директор нанимает менеджеров, участвует в определении целей проекта, отвечает за координацию и выполнение планов, а также за стратегическое техническое развитие. Архитектор создает стратегическое архитектурное видение и следит за тем, чтобы команды не нарушали его при реализации своих планов.
Зеркальное отражение роли технического директора на стороне продукта. Если компания небольшая, CPO, по сути, будет единственным менеджером по продукту, а роль — просто красивое слово.
Конечно, фразу Chief Product Officer можно трактовать как угодно — роль единственного менеджера по продукту включительно, он главный менеджер по продукту, нет никого важнее. Но на самом деле эта роль существует в крупных компаниях с различными продуктами и командами, когда необходимо синхронизировать видение продукта различными менеджерами по продуктам, чтобы они не разрывали продукт на части, пытаясь достичь своих целей.
Кроме того, в его обязанности входит обеспечение отбора специалистов и поддержание уровня квалификации среди менеджеров по продуктам.
Кто есть кто в IT компании. Структуры и роли.
Здесь тоже есть разные толкования, но мы обратимся к слову старший. Когда вы видите такой префикс, вам хочется спросить, кому принадлежит старший. Конечно, в погоне за блестящими значками и бантиками они стали называть опытных менеджеров по продуктам старшими, но если следовать логике, старший менеджер по продуктам появляется тогда, когда есть младшие.
Поэтому основная роль старшего менеджера по продукту заключается в управлении продуктом в области, где существует несколько продуктов и их собственные менеджеры.
Такой роли не существует. У продукта есть владелец. Является ли он старшим или младшим, не имеет никакого влияния на продукт и его разработку. Владельцы продукта не подчиняются друг другу; владелец продукта — это роль, а не должность.
Здесь мы приходим к классическому квартету Владелец продукта / Менеджер продукта / Менеджер продукта / Владелец бизнеса и разделению ролей.
Менеджер по продукту отвечает за стратегическое видение продукта, дорожную карту, анализ рынка/продукта и генерирование гипотез в соответствии с требованиями бизнес-профессионалов.
Владелец продукта отвечает за определение приоритетов бэклога и итогового результата для бизнеса. Вы не найдете "владельца продукта" в организационной схеме. Владелец продукта — это, как правило, представитель бизнеса или клиентской стороны, который несет прямую ответственность за продукт. Например: владельцем продукта "автоматизация бухгалтерского учета" может быть финансовый директор, поскольку он согласовывает дорожную карту с менеджером продукта "автоматизация бухгалтерского учета".
Ответственность распределяется соответствующим образом: если владелец продукта принял неверные решения из-за плохого вклада, ответственность несет менеджер продукта. Если были выбраны или согласованы неправильные приоритеты — ответственность несет владелец продукта. Если на продукт не было рыночного спроса — ответственность зависит от того, предупредил ли менеджер продукта владельца или нет. Если владелец был предупрежден, то ответственность несет владелец.
Менеджер проекта отвечает за выполнение проекта в согласованные сроки и в рамках бюджета.
Он несет ответственность за результаты инвестиций в разработанный продукт перед советом директоров/акционерами.
Владелец продукта и бизнес-менеджер — это роли, а менеджер продукта и менеджер проекта — это также профессии.
В небольших командах роли владельца продукта, менеджера продукта и руководителя проекта обычно возлагаются на одного человека. По мере роста команды и продукта эти роли разделяются.
Владелец бизнеса — это редкая роль, потому что именно владелец продукта обычно выступает на стороне бизнеса. Но в некоторых ситуациях, которые должны существовать только в болезненном воображении, а не в реальности, есть еще один уровень абстракции в виде человека, который отвечает за продажи.
Например, есть владелец продукта для точек продаж, который общается с предприятиями по всему миру. Есть менеджер по продуктам терминалов для точек продаж, который разрабатывает продукт. Кроме того, есть бизнес-менеджер из Мексики, который отвечает за развитие бизнеса в этом регионе. Он не оказывает прямого влияния на бэклог, но отвечает за бизнес-показатели в регионе и общается с владельцем продукта.
Недавно компания Scrum Inc начала продвигать альтернативное видение роли Владельца продукта как человека, ответственного за тактическую реализацию стратегического видения менеджера продукта. Я буду придерживаться оригинальных идей Agile, а для еретиков процитирую профессора Гарвардской школы бизнеса: "Я обучил десятки команд, использующих SAFe, и никогда не видел, чтобы это работало хорошо".
Хорошее название для менеджера по продуктам. Иногда используется, когда в одном продукте работают несколько менеджеров по продуктам, и один из них немного старше остальных.
В проектных компаниях это лицо, ответственное за выполнение всех проектов компании, альтернатива CPO в продуктовых компаниях с одним отличием: если в продуктовых компаниях в центре внимания находятся продуктовые команды и их планы, а CPO просто "разбивает битвы" и синхронизирует планы, то в проектных компаниях менеджер проектного офиса отвечает за работу всего проектного офиса. Если какой-либо продукт в портфеле CPO не взлетает, ответственность несет менеджер этого продукта. Если один из проектов не удался — за это отвечает руководитель проектного офиса.
Это хорошее название для руководителя проекта. Иногда используется, когда у продукта есть несколько менеджеров проекта, и один из них немного важнее других.
Надеюсь, что эта краткая шпаргалка окажется полезной и поможет вам в поиске людей, подходящих под ваши задачи.
Подписывайтесь на мой канал @dailykuznetsov, где я публикую короткие заметки о финансах, обществе и управлении продуктами
