Команда как продукт. Практическое руководство по созданию и управлению продуктовой командой в IT. Михаил Михайлович Кузьмицкий

Чтение книги онлайн.

Читать онлайн книгу Команда как продукт. Практическое руководство по созданию и управлению продуктовой командой в IT - Михаил Михайлович Кузьмицкий страница 8

Команда как продукт. Практическое руководство по созданию и управлению продуктовой командой в IT - Михаил Михайлович Кузьмицкий

Скачать книгу

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

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

      Кейс: джун или мидл – кто принимает решение?

      Суть: был в нашей жизни очень запоминающийся кейс. Мы пришли на интервью кандидата в разработку в нашу первую большую команду. Тут, конечно, стоит отметить, что команда была и правда большая – на тот момент в ней было уже более 20 человек, включая аналитику, дизайн, разработку и тестирование. Стали общаться с человеком, разбираться в его ценностях и стремлениях, затронули несколько вопросов по технической части, несмотря на то что техническое интервью было проведено ранее. Беседа длилась больше часа, что позволило кандидату хорошо погрузиться в особенности работы нашей команды, в цели и задачи продукта, который ему предстоит развивать, а главное – была проведена оценка потенциала и желания роста и развития кандидата. Обратная связь от технического собеседования была следующая: кандидат уверенный джуниор. В процессе общения с кандидатом стало понятно, что он далеко не джуниор, а очень перспективный мидл-разработчик. Система оценок на техническом интервью в разных компаниях весьма специфическая: кто-то смотрит на опыт, количество лет на позиции, участие в энтерпрайз-проектах, а кто-то гоняет кандидата по всем особенностям и тонкостям конкретной позиции. Есть еще один важный аспект: на интервью, особенно техническом, кандидат волнуется и переживает, и его реальные знания и полученные в процессе диалога ответы очень часто отличаются. Важно помнить об этих особенностях, когда ты собираешь свою команду.

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

Скачать книгу