Материал входит в серию статей о build vs buy в HRTech.

Я бы выделил три спорные для себя роли в команде: Project / Delivery Manager, Tech Lead и Аналитик. Сами по себе эти роли не спорны. Наоборот, соответствующие компетенции полезны и нередко необходимы. Вопрос в другом: всегда ли под них нужен отдельный человек?

Project / Delivery Manager / Scrum Master. Здесь я объединяю роли, отвечающие за организацию работы внутри команды и за поставку результата. Чем сложнее внешняя среда — процессы, согласования, зависимости, ожидания менеджмента, — тем больше у этой роли реальной работы и тем выше ценность выделенного человека.

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

Tech Lead. У появления роли Tech Lead обычно есть несколько предпосылок. Первая — слабая техническая экспертиза у отдельных участников команды на фоне отсутствия сильного экспертного сообщества в ресурсном пуле. Тогда этот дефицит компенсируют выделением отдельного эксперта внутри команды. Вторая — ситуация, когда senior-разработчик перерастает свою текущую позицию, и для того чтобы удержать его внутри компании, под него фактически создают новую роль.

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

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

Отдельная проблема этой роли в том, что часто непонятна сама граница ответственности. Это всё ещё tech, и человек должен непосредственно участвовать в разработке? Или это уже lead, и его основная задача — координировать, направлять и принимать технические решения? На практике эта размытость регулярно создаёт путаницу и по ожиданиям, и по зоне ответственности.

И, наверное, самый плохой сценарий — когда из отличного senior-разработчика получается слабый Tech Lead. В этом случае команда теряет сильного разработчика, но при этом не получает полноценного лидера.

Системный и/или бизнес-аналитик. Как для практикующего Product Owner, это, пожалуй, одни из самых противоречивых ролей в команде.

С одной стороны, вместе с UX/UI-дизайнером это одни из главных помощников Product Owner в развитии продукта. Часто его единомышленники. Без их участия при работе над большим продуктом очень быстро перестаёт хватать времени: просто в сутках уже недостаточно 24 часов. Особенно если в компании действует производственный framework, который жёстко регламентирует состав и объём документации, разрабатываемой командой.

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

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

Читайте полную версию https://dzen.ru/a/ae-ooaiLEzJN5gYz