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

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

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

– — – — – — – — – — – — – — – — – — – —

Итак, мы разобрались, что владелец продукта должен быть другом в команде и никак не жестким руководителем, который навязывает команде совершенно непонятные для нее цели и способы достижения мифических результатов. Владельцы продукта в большинстве случаев относятся к продуктовым вертикалям, департаментам, отделам, все зависит от организационной структуры, принятой в компании. Как правило, есть вторая вертикаль – техническая, куда входит большая часть команды разработки. Это разработчики, тестировщики, автоматизаторы, архитекторы и другие специалисты. У технического направления есть такой же административный руководитель – техлид или тимлид в зависимости от того, как принято управлять командами разработки в каждой компании.

– — – — – — – — – — – — – — – — – — – —

Кейс: техлид и тимлид в одном лице – такое возможно?

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

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

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