Команда как продукт. Практическое руководство по созданию и управлению продуктовой командой в IT
Одной из основных задач продуктового дизайнера является глубокая проработка пользовательского опыта будущего продукта или фичи. Однако, помимо продуктовых дизайнеров, в командах могут быть и другие дизайнеры, которые занимаются созданием контента, но они обычно распределяются между проектами, продуктами, департаментами и т. д. Такие дизайнеры в основном занимаются созданием визуального контента и по необходимости привлекаются на продукт или фичу.
Также продуктовые дизайнеры занимаются проработкой клиентских путей, формированием CJM6 и проектированием будущих интерфейсов для клиентов продукта. Они работают в тесном взаимодействии с другими членами команды и всегда стремятся создать удобный и интуитивно понятный интерфейс с привычными пользователю паттернами для достижения максимально комфортного пользовательского опыта будущих клиентов. Продуктовый дизайнер является ключевым игроком в процессе разработки продукта или проекта, и его вклад в создание удобного и качественного продукта неоценим.
– — – — – — – — – — – — – — – — – — – —
Кейс: дизайнер или продуктовый дизайнер
Суть: нам неоднократно приходилось сталкиваться с очень частым кейсом: «нарисуй баннер», «сделай иконку», «сюда надо картинку придумать» и т. п., да еще и в очень короткий срок, потому что компания, оказывается, «завтра» планирует запустить какую-нибудь акцию или рекламную кампанию. Конечно же, в продуктовой команде никогда нет выделенного ресурса в виде графического дизайнера, а если такое и встречается, то это нетипичная ситуация и считай тебе повезло. Графический дизайн в компании – это обычно отдельное подразделение, ресурсы которого распределяются на все активности компании и быстро получить там специалиста, как правило, невозможно. Что происходит в таких случаях? Владелец продукта обращается к продуктовому дизайнеру и просит помочь в решении этого вопроса. Почему это плохо? Да все просто на самом деле: продуктовый дизайнер обычно занят созданием нового клиентского пути по одной или нескольким приоритетным фичам, взаимодействует с потенциальными пользователями, исследует, формирует CJM. Вторгаясь в этот процесс, ты очевидно нарушаешь его, заставляешь человека переключиться на не типичную для него работу, которую он, если сделает классно, то пожертвует основными активностями и ты проиграешь в другом месте, закрыв текущую потребность. Но это лишь вершина айсберга. Если продуктового дизайнера постоянно загружать такой работой, то он просто выгорает, как и любой другой специалист, которого заставляют работать над непрофильными задачами. Береги продуктовых дизайнеров, без них ценность твоего продукта станет намного меньше, а проверка любой гипотезы через R&D7 гораздо дороже.
Вывод: всегда используй способности продуктового дизайнера по назначению, чтобы клиентский путь твоих пользователей был максимально коротким и удобным, а графический дизайн закрывай через специальные подразделения или фриланс.
– — – — – — – — – — – — – — – — – — – —
В современном бизнесе команда разработки является ключевым элементом успеха продукта на рынке. Разработчики и тестировщики играют важную роль в создании качественного продукта. Однако, чтобы обеспечить оптимальное сочетание количества разработчиков и тестировщиков в команде, необходимо учитывать множество факторов. Оптимальное соотношение разработчиков и тестировщиков в команде зависит от контекста и множества факторов. В первую очередь, необходимо учитывать опыт всех членов команды и технологический стек в компании и в конкретной команде, так как бывает, что в больших технологических компаниях стек в разных командах может отличаться. Кроме того, важным фактором является ритм релизов, который может быть разным в зависимости от проекта. Поэтому, чтобы достичь успеха, необходимо правильно балансировать ресурсы между разработкой, тестированием и автоматизацией. Это позволит повысить качество продукта и ускорить процесс разработки, сохраняя конкурентоспособность на рынке.
Важным моментом в работе команды является нагрузка на ее участников. Особенно это касается тестировщиков, которые берут на себя ответственность за качество продукта и находятся на финальном этапе разработки, где начинают поджимать сроки релиза и остается мало времени на проверку функционала. Если на одного тестировщика выпадает слишком большой объем задач, то он может не справиться с ними и быстро выгореть. В результате ты потеряешь в команде тестировщика, а это может привести к весьма негативным последствиям.
Для обеспечения оптимального распределения ресурсов в команде и отсутствия аномальных перегрузок в команде тестирования следует начинать найм с разработчика. После найма разработчика запустится адаптационный процесс и погружение в продукт и процессы.
Когда первый код уже написан, в команде должен появиться хотя бы один тестировщик, чтобы начать тестировать первые активности разработчика. Такой подход позволяет эффективно использовать ресурсы команды и сократить время на разработку продукта, сохраняя высокое качество.
В случае, если ты занимаешься развитием или переработкой легаси-проекта с большим объемом кодовой базы и большим объемом доработок на бэкенде, то команда способна работать при соотношении один разработчик к одному тестировщику, однако если проект молодой или использует как фронт-, так и бэк-разработку, то оптимальное соотношение может начинаться от двух разработчиков к одному тестировщику до пяти разработчиков к трем тестировщикам.
Верна и обратная позиция, при которой ты нанимаешь тестировщика до появления в команде разработчиков для подготовительной работы. Она может заключаться как в написании тест-кейсов на готовый дизайн и аналитику, так и изучения инструментов и подходов по тестированию в компании, получении доступов к ресурсам и знакомства с документацией в смежных командах.
– — – — – — – — – — – — – — – — – — – —
Кейс: тестировщик или разработчик – кто первый?
Суть: мы смогли поработать как в нескольких крупных компаниях, так и в стартапах, что позволит рассказать об особенностях работы с тестированием под разными ракурсами. Начнем, пожалуй, со стартапов. Работа в стартапе характерна совмещением нескольких функциональностей в одной роли, это может быть как две, так и три роли в одном участнике, ведь задача стартапа быстро собрать MVP8 продукта и показать его конечному потребителю, чтобы проверить гипотезу и CVP, которые необходимо донести. Если собирать стартап командой, уровень которой ниже чем middle+ / senior, то шанс попасть в те самые девять из десяти погибающих стартапов становится выше, ведь правильно заложенная архитектура продукта – это залог его успешного масштабирования в дальнейшем, а если речь идет об использовании одного бэкенда для web-приложений и мобильных приложений, то ценность высококвалифицированных специалистов на ранних стадиях становится еще выше. В ситуации, когда собирается стартап, функционал тестировщика минует множество бюрократических аспектов крупных компаний, и создания большого количества артефактов от тестирования также не требуется. Это значит, что тестировщик вполне может приступать к работе только после того, как готов первый блок функциональности, который можно проверять, сверять с макетами или требованиями и заводить дефекты. Раньше, чем есть первая кодовая база, привлекать тестировщика на стартап совершенно бессмысленно, если только у вас нет лишнего бюджета или желания вовлечь тестирование в процесс пораньше.
Совсем иная ситуация в крупных компаниях, где функционал тестировщика предполагает создание большого количества артефактов, например тест-кейсы, тест-планы, генерация тестовых данных в сервисах общего пользования, получение доступов к различным ресурсам и многое другое, на что может уходить от одной-двух недель до нескольких месяцев. В таком случае совет совершенно противоположный: тестировщик необходим в команде или до начала работы, или параллельно с разработчиками.
Вывод: изучите ситуацию в команде, если команда собирается с нуля в крупной компании с множеством процессов, то найм тестировщика в начале очень поможет двигаться быстрее, если же это мелкая компания или стартап, приглашать тестировщика в команду можно чуть позднее.
– — – — – — – — – — – — – — – — – — – —
Автоматизация тестирования является неотъемлемой частью процесса разработки цифровых продуктов. Это позволяет значительно повысить эффективность и качество тестирования, а также сократить время, затрачиваемое на проверку продукта. Несмотря на то что автоматизация тестирования требует дополнительных ресурсов и времени, она является важным инструментом для достижения успеха в современном бизнесе. Одной из главных причин для автоматизации тестирования является ускорение процесса проверки функционала продукта. Вместо того чтобы проверять каждую функцию вручную, автоматические тесты могут быстро и точно выполнить эту задачу. Это позволяет значительно ускорить процесс проверки и улучшить качество продукта. Кроме того, автоматизация тестирования также может помочь выявить ошибки и дефекты на ранних этапах разработки. Это позволяет исправить проблемы до того, как они станут серьезными и приведут к задержкам в разработке или проблемам с пользовательским опытом. Однако автоматизация тестирования также требует дополнительных ресурсов и времени. Необходимо разработать и поддерживать автоматические тесты, что может занять значительное количество времени и ресурсов. Но, как правило, эти затраты окупаются в будущем, когда продукт готовится к выпуску и необходимо провести тщательную проверку функционала.
В целом автоматизация тестирования является важным инструментом для повышения качества продукта и ускорения процесса разработки. Правильное балансирование ресурсов между разработкой, тестированием и автоматизацией является ключевым фактором для достижения успеха в современном бизнесе.
Итак, мы с вами рассмотрели основную структуру продуктовой команды и теперь можем перейти непосредственно к особенностям найма каждой позиции. Найм кандидатов в продуктовую команду начинается с анализа работы в текущей команде, если она уже есть, ритма работы, нагрузки на каждое направление, ритмом и, конечно же, объемом ценности, выходящим из команды в конечного пользователя. В отличие от стартапа или сбора новой команды работа с действующей командой бывает более сложной и непредсказуемой. Разберем оба варианта.
Особенности найма в стартап или новую команду
Если говорить о новой команде или стартапе, то важно оценить ритм, в котором необходима поставка ценности бизнес-заказчику или стейкхолдеру. Если нужен агрессивный ритм, а обычно это именно так и бывает, то без специалистов с уровнем не ниже Senior просто не обойтись, ведь некогда погружать людей, тратить ресурс на обучение и адаптацию – есть конкретный скоуп задач, которые приведут тебя и твой продукт к заданной цели. Собирать команду стартапа с жесткими сроками из специалистов другого уровня практически бессмысленно, выживает всего один из десяти стартапов и срок его выхода на рынок зачастую играет ключевую роль. Стартапы, которые не требуют жестких сроков реализации, а делаются в спокойном режиме, вполне себе могут быть собраны специалистами уровня middle или middle+, но с точки зрения комплексных архитектурных решений, потенциала масштабирования продукта и его кроссплатформенности лучше иметь в команде хотя бы одного специалиста уровня senior.
Если же мы посмотрим на найм в новую команду в какой-нибудь большой компании, то ситуация тут весьма типична для сектора. Если на примете есть грамотные специалисты, то в таких компаниях, как правило, существует возможность организовать переход таких специалистов в твою команду как с рынка, так и в рамках ротаций внутри компании. Тут большой объем работы ложится на тимлида или, за его неимением, на владельца продукта. Самое время задуматься над наймом в команду хорошего тимлида, которому можно доверить такую сложную работу, как сбор и подбор команды. Сбор команды в крупной компании обуславливается множеством факторов, например бюджетом, тебе просто никто не даст собрать команду целиком из Senior-специалистов, потому что это наверняка выйдет за рамки бюджета и придется очень долго доказывать, почему ты выбрал именно такой подход, что с высокой долей вероятности наложит на тебя дополнительные обязательства в виде более быстрого запуска MVP или иных историй. Проблема тут, конечно же, кроется гораздо глубже, как только ты начнешь соприкасаться с кросс-функциональным взаимодействием, выделением или созданием инфраструктуры, то все коммиты тут же начнут быстро уезжать вправо и возникнет негатив как по отношению к тебе, так и по отношению к команде в целом – никто не любит нарушенных обещаний. Самый правильный вариант тут собирать команду из специалистов разного уровня. Например, если в продукте предполагается один продуктовый дизайнер, то, конечно же, лучше искать скилованного специалиста, а если количество разработчиков планируется около трех-пяти человек, то лучше набирать специалистов разного уровня, но всегда помнить о потенциале роста внутренних сотрудников и создании атмосферы как в команде, так и вовне ее, способствующей этому развитию.
– — – — – — – — – — – — – — – — – — – —
Кейс: джун или мидл – кто принимает решение?
Суть: был в нашей жизни очень запоминающийся кейс. Мы пришли на интервью кандидата в разработку в нашу первую большую команду. Тут, конечно, стоит отметить, что команда была и правда большая – на тот момент в ней было уже более 20 человек, включая аналитику, дизайн, разработку и тестирование. Стали общаться с человеком, разбираться в его ценностях и стремлениях, затронули несколько вопросов по технической части, несмотря на то что техническое интервью было проведено ранее. Беседа длилась больше часа, что позволило кандидату хорошо погрузиться в особенности работы нашей команды, в цели и задачи продукта, который ему предстоит развивать, а главное – была проведена оценка потенциала и желания роста и развития кандидата. Обратная связь от технического собеседования была следующая: кандидат уверенный джуниор. В процессе общения с кандидатом стало понятно, что он далеко не джуниор, а очень перспективный мидл-разработчик. Система оценок на техническом интервью в разных компаниях весьма специфическая: кто-то смотрит на опыт, количество лет на позиции, участие в энтерпрайз-проектах, а кто-то гоняет кандидата по всем особенностям и тонкостям конкретной позиции. Есть еще один важный аспект: на интервью, особенно техническом, кандидат волнуется и переживает, и его реальные знания и полученные в процессе диалога ответы очень часто отличаются. Важно помнить об этих особенностях, когда ты собираешь свою команду.
В итоге кандидата мы сразу одобрили, а буквально через месяц он уже самостоятельно реализовывал полноценную фичу и рассказывал об особенностях реализации другим членам команды, обучая их. Менее чем через год кандидат стал полноценным Senior-разработчиком и уже самостоятельно проводил технические интервью в нашей команде и с очень хорошим эффектом. Таким образом, невзирая на мнения тех, кто проводил интервью с кандидатом, пообщайся с ним сам, погрузись в особенности и взгляды будущего кандидата, расскажи о том, чем ему предстоит заниматься и какие карьерные возможности будут предоставлены ему в перспективе, явным образом мотивируя его перформить еще на входе.
Вывод: нанимая специалиста, уже на первом интервью обязательно оцени его потенциал, проработай с кандидатом вопросы о том, чем он занимался, на каком языке писал и по какой причине менял языки программирования, зачем и чего хотел добиться. Именно на этом этапе можно понять, как много усилий приложил кандидат, чтобы достигнуть своего уровня, и какие планы и цели перед ним стоят в дальнейшем.
– — – — – — – — – — – — – — – — – — – —
Особенности найма в действующую команду
Найм сотрудников в действующую команду обусловлен рядом особенностей, ведь действующая команда уже имеет свои паттерны поведения, устоявшийся ритм, выстроенные внутренние коммуникации и нагрузку. Если ты задумался о наборе сотрудников в команду, это значит, что у какого-то или каких-то направлений на текущий момент перегруз, и вовлечение в процессы нового человека неизменно повлечет за собой большую нагрузку на период включения в работу нового человека. Как правило, это занимает от одной-двух недель до месяца, после чего новый сотрудник подхватывает ритм и начинает разгружать своего наставника. В этом случае всегда очень важно, насколько люди подходят друг другу по темпераменту, жизненной позиции и целям, также немаловажен уровень человечности, поскольку именно это в дальнейшем будет влиять на то, как команда начнет перформить и как сможет разгонять свой ритм поставки ценности.
Еще на этапе воронки нужно очень внимательно рассматривать кандидатов под разными углами, ведь даже начинающий аналитик, тестировщик или разработчик может прокачаться в проекте буквально за несколько месяцев. Если у кандидата есть только базовые знания, но очень сильная тяга к знаниям, обучению, саморазвитию и росту, то такой сотрудник впоследствии может оказаться намного ценнее нанятого с рынка Senior-специалиста. Почему? Да все просто. Когда Senior-специалист приходит на новый проект, у него, по сути, два пути – просто быть разработчиком/аналитиком/тестировщиком и т. д. и заниматься развитием или созданием функционала продукта или сразу развиваться в руководящую позицию. И первое, и второе для тебя плохой сценарий, потому что срок, на который хватает такого специалиста в проекте, варьируется обычно от полугода до года. Далее создается напряжение и попытки выбрать между новым проектом или переходом в руководящую позицию. Период в несколько месяцев, безусловно, обеспечит буст развития продукта, но потом появляются другие сложности – бас фактор. Как бы странно это ни звучало, но вам всегда стоит думать над вопросом – какое количество участников моей команды, при «попадании которых под автобус» (bus factor), проект не сможет быть завершен оставшимися сотрудниками. Именно специалисты высокой квалификации оказывают влияние на этот фактор, и отключение одного, а тем более нескольких таких специалистов от продукта может нанести всему проекту колоссальный урон.
Но есть исключения: те, кто попробовал себя в управлении, возглавлял команду одного из направлений на протяжении некоторого времени и устал от этого. Как правило, переход на руководящую должность значительно снижает вовлечение специалиста в его прямые активности, например разработчик перестает писать много кода, тестировщик перестает пользоваться многими инструментами тестирования и проверять функционал на ежедневной основе. Мы заметили, что это часто приводит таких специалистов к пониманию, что они не хотят управлять, теряют основной фокус на инструментах, которым посвятили большую часть своей жизни, и они возвращаются к привычным профильным активностям без желания вновь окунуться в руководящую работу. Такие специалисты, конечно же, пробудут с тобой точно один или более лет, но это далеко не все – таких единицы.
– — – — – — – — – — – — – — – — – — – —
Кейс: круговорот специалистов в IT
Суть: при переходе из одной компании в другую нас ожидал очередной сбор продуктовой команды под ключ для создания нескольких продуктов. Символично получилось, что в эту компанию нас позвала коллега, с которой мы ранее работали вместе и она помогала создавать нам продукты для бизнеса. Сбор команды мы, конечно же, начали с аналитики и дизайна, но в этом кейсе мы расскажем про аналитика. Так получилось, что вместе с нами в предыдущей команде рос и бизнес-аналитик, приумножая свои компетенции в этой области, и первым делом мы позвали его к нам. Прошло буквально две недели и аналитик уже вышла на свою новую работу вместе с нами делать новый продукт для новых пользователей. Специалист проработал в предыдущей компании много лет и настолько проникся существующей там атмосферой, что старт работы в новой кампании, новом коллективе оказался непосильным трудом, и нам всем пришлось сделать шаг назад. Аналитик вернулся в предыдущую компанию, но уже на другой проект, а мы в это время нашли другого аналитика. Связи в наше время, да еще в таком тесном мире, как IT, конечно, многое решают. С уходящим аналитиком мы заключили джентльменское соглашение по передаче знаний, которые были собраны на протяжении почти полутора месяцев. Договоренности действовали даже после ухода специалиста из компании в течение полутора месяцев. В итоге за более чем полтора года нашей совместной работы новый аналитик очень хорошо прокачалась и при переходе с нами в новую компанию уже стала полноценным владельцем продукта с соответствующей мотивацией.
В таких случаях всегда очень важно смотреть на ситуацию не в моменте, а мыслить стратегически, ведь хороших специалистов, готовых в прямом смысле слова драться за продукт и результаты, не так много на рынке, и когда в твоем окружении начинают появляться такие люди – ты на верном пути к созданию крутой команды, готовой вместе с тобой строить новый клиентский опыт или гроухакать9 текущий продукт, выводя его на новый качественный уровень.
Кстати, чтобы завершить этот кейс, нужно рассказать о том, что сейчас оба этих человека снова работают с нами в другой компании и, конечно, в одной команде: один развивает продукт в роли его владельца, а другой возглавляет бизнес-анализ в том же продукте.
Вывод: всегда поддерживай хорошие партнерские или дружеские отношения с теми специалистами, кто в твоей команде вел продукт к достижению общих целей, что бы ни случилось.
– — – — – — – — – — – — – — – — – — – —
Прежде чем мы с тобой разберем еще один кейс, кстати, на этот раз это будет факап с наймом и последующим увольнением, хочется разобраться в отношениях к людям в крупных компаниях. Разбирать этот вопрос на уровне небольших компаний или стартапов нецелесообразно – там каждый сотрудник приносит понятную ценность, процессы легко управляются и множество проблем роста компании исключаются.
Мы поговорим с тобой как раз о большой компании, численность которой измеряется несколькими тысячами человек в области создания цифровых продуктов и сервисов. Очень важный вопрос, который хочется рассмотреть в этой главе, – это ротация сотрудников в крупных компаниях и какие подводные камни там скрываются, о которых в явном виде не говорят и не думают люди, занимающиеся пипл-менеджментом.
Итак, рассмотрим с вами следующую ситуацию. В компании поднимается приоритет по какому-то продукту и начинается агрессивный найм или замещение текущего состава команды по какой-то причине. Начинается оценка перформящих людей на разных позициях с целью произвести ротацию из менее приоритетных проектов в более приоритетные. У каждой продуктовой команды есть свой дух, своя волна и зависимости людей друг от друга, поддержка и взаимовыручка. Как только одно звено этой цепочки разрывается, это начинает инерционно накладывать одну проблему на другую. Тут появляется проблематика не только со стороны команды, но и со стороны самого сотрудника – его вырывают из привычной атмосферы и погружают в совершенно другие задачи и другую команду со своими устоями. Складывается впечатление, что человека можно просто вытащить из одной розетки и вставить в другую, снова включить и ждать, что ничего не изменится. А ведь это совсем не так. Есть разные люди со своими особенностями, которые, например, являются интровертами и уходит не один месяц, чтобы найти нужные подходы к человеку, нащупать области его максимальной вовлеченности и результативности. Периодически складывается такое ощущение, что об этих важных человеческих особенностях никто не задумывается в период ротации, так как обсуждение идет не на уровне людей, а на уровне отдельных FTE10. В чем же проблема не только для тебя, но и команды и, конечно же, компании? Да все просто, давай разберем подробнее. Человек, который долго привыкал к одной команде и как он сам, так и команда искали наилучшие точки соприкосновения друг в друге, переходит куда-то по инициативе компании. Это с высокой долей вероятности приведет к тому, что на новом месте он не уживется и уйдет, соответственно компания теряет человека, совершив очевидно недальновидный шаг. В этой ситуации команде HR придется искать уже двух человек, а командам погружать новых коллег в процессы и продукт, тратя ресурс специалистов внутри, и все это выливается в дополнительные затраты для компании, замедление развития продуктов и, как следствие, в снижение выручки или потенциальной выручки от работы продуктов.
– — – — – — – — – — – — – — – — – — – —
Кейс: нанять и уволить за три месяца
Суть: была у нас интересная ситуация, когда мы решили усилить команду в системном анализе и открыли найм на эту позицию. Это были 2019—2020 годы и тогда на рынке было сложно с хорошими системными аналитиками, которые действительно обладали хорошим и разносторонним опытом, и нам пришлось снизить ожидания от кандидата, рассмотрев уровень Middle-специалиста.