IT-рекрутмент. Как найти лучших специалистов, когда все вокруг горит - Егор Яценко

канбан были унаследованы от подхода, разработанного на заводе Toyota в 1950-х годах. Особенности этой методики заключаются в том, что разработка визуализирована: разделена на задачи, этапы их выполнения маркируются специальными отметками. Количество работ, производящихся одновременно, ограничено. Измеряется и оптимизируется время на выполнение одной задачи.

Extreme Programming, XP. Если описанные выше методологии применимы не только в разработке ПО, то XP — это подход, созданный специально для IT-бизнеса. Его идея проста: взять лучшие практики из других гибких подходов и довести их до экстремально высокого уровня. Например, в рамках данной методологии используется парное программирование: два разработчика на одной машине пишут одну фичу и регулярно (раз в несколько минут) меняются местами. Когда один пишет код, второй его анализирует.

Здесь возникает вопрос, как соотносятся Agile и Scrum. Мне очень понравился ответ, который я увидел где-то на просторах Facebook: примерно так же, как газировка и кока-кола.

Важно понимать, что далеко не во всех компаниях внедрен чистый Scrum или Kanban. Зачастую компания пишет, что работает по скраму, когда у них тупо итерационная разработка, а все прочие условия скрама не соблюдены. Кроме того, на рынке появляются всякие гибридные варианты, которые создают компании. Тот же Сберджайл, например (думаю, не стоит объяснять, в какой компании он применяется, да?).

Развитие гибких систем разработки привело к появлению таких специалистов, как, например, Agile Coach (аджайл-коуч) и Scrum Master (скрам-мастер). Они знают, как создавать, запускать и выстраивать процесс гибкой разработки. Причем их функционал в основном не технический: их сильная сторона — soft skills, за счет чего они становятся одновременно и преподавателями (обучают технологии гибкой разработки), и фасилитаторами (облегчают общение внутри команды), и специалистами по устранению системных препятствий на пути к реализации и продвижению продукта, и выполняют много других функций, благодаря чему проект «едет» в соответствии с принципами Scrum или Agile.

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

Глава 9

Управление в IT

Итак, мы разобрали методологии, по которым разрабатывается продукт. Есть те, кто будет следить за соблюдением канонического скрама, но есть ведь и те, кто будет непосредственно управлять процессами, да? Давайте рассмотрим тему, которая вызывает много сложностей у рекрутеров: Product— и Project-менеджеры. Чтобы понять суть этих специальностей, давайте определимся с разницей между проектом и продуктом.

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

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

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

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

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

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

Именно Product-менеджер собирает требования к продукту (или работает в этом вопросе в паре с аналитиком), распределяет задачи в бэклоге и принимает стратегические решения по продукту (какую фичу мы будем делать, а какую нет).

Для работодателя, который ищет кандидата на эту позицию, может быть важно, чтобы у того был аналогичный опыт работы, например, в b2b— или b2c-сфере. Также Product-менеджер может иметь в «анамнезе» позицию UI/UX-дизайнера или, возможно, даже разработчика (это реже).

Ну и конечно, Product-менеджер часто отвечает за финансовые показатели продукта, за различные финансовые цели: как количество пользователей продукта вырастет на такой-то процент, как увеличить прибыль по тому или иному каналу.

На job-бордах также можно встретить Product marketing manager. Это как раз те, кто занимался маркетинговым позиционированием продукта. Частично функционал с обычными продакт-менеджерами у них может быть схожим, но это все-таки люди, которые заточены на продвижение продуктов.

Project manager, или менеджер проекта (PM — читать «ПиЭм»), — это специалист, который фокусируется на процессе реализации проекта. Он координирует команды и отвечает за сроки. Его задача — разбить проект на задачи, оценить существующие ресурсы и ограничения и, исходя из этих знаний, спланировать все активности по проекту. То есть определить, кто что делает, выставить адекватные сроки и скоординировать команду так, чтобы она работала максимально эффективно.

Его главная цель — воплотить идею заказчика в установленный срок, используя существующие ресурсы.

Как видите, Product-менеджер должен обладать бо́льшим набором навыков, чем Project-менеджер. Первый из них более глубоко погружен в разработку самого продукта, он имеет влияние на его развитие, принимает бизнес-решения и вовлекает маркетинг. А второй отвечает за то, чтобы проект достиг своей цели, и выполняет административные функции.

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

Кроме того, в гибких подходах к разработке (Agile) чаще всего нет места Project-менеджеру: эта специальность в большей степени относится к каскадной разработке. А как раз роль Product-менеджера характерна для гибких подходов. Хотя, опять-таки, все зависит от каждого конкретного случая. Наш рынок, к сожалению, сложно грести под одну гребенку и жестко структурировать, поэтому на нем порой появляются очень странные детеныши разных подходов.

Product owner, или владелец продукта, — еще одна руководящая должность, пришедшая из скрама. Этот специалист отвечает за продукт на уровне команды. Его цель — донести до нее видение продукта целиком, ответить на все «почему?», «зачем?» и «как?», прописать пользовательские истории, приоритезировать и почистить бэклог.

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

Общаясь с кандидатами-продактами, нам, конечно, стоит обратить внимание на то,