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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поиск и найм команды

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

Аналогичная ситуация наблюдается и в разработке. Фулстек-специалисты, обладая широким спектром знаний и навыков, часто имеют свои сильные и слабые стороны в одном из направлений разработки. Например, фулстек-разработчик может быть более компетентен в backend-разработке, нежели в frontend-разработке, или наоборот. Важно понимать, что каждый член команды имеет свои уникальные навыки и экспертизу, которые могут принести значительную пользу проекту.

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

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

Кейс: системный и бизнес-аналитик в одном лице

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

Именно тут и кроется распыление активностей в аналитике. Если быстро перейти к проработке системной аналитики, не уделив должного внимания самому процессу, то впоследствии это превращается в ряд доработок после обсуждения с владельцем продукта или проведением внутреннего демо для бизнес-заказчика. А все потому, что не учтены специфические нюансы бизнеса и, как следствие, процесс, дальнейшее описание работы системы и ожидаемый после разработки результат являются ложными. К сожалению, такие вещи несут под собой не только double costs для команды и компании, но и сильно увеличивают time to market для критических для бизнеса фичей. А теперь представьте ситуацию: в Сибири появился новый логистический хаб, куда свозят товары крупнейшие поставщики из Китая или других стран. В ритейл-компаниях появляется задача оптимизации логистики до конечных клиентов, которая учитывает изменение маршрутов с учетом наличия ассортимента на новом складе. Если поддержку такой бизнес-фичи затянуть, то конкуренты, оптимизировав доставку раньше, смогут снизить цены на товары в своих интернет-магазинах и, как следствие, для тебя и твоей компании это будет потеря GMV[3 - GMV – Gross Merchandise Value – общий объем оборота товаров.] и просадка по остальным бизнес и продуктовым показателям.

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

Вывод: лучше не комбинировать в одном специалисте две или более функций, если ты не находишься в стартапе с максимально коротким сроком на его запуск и являющийся по сути проверкой идеи CVP[4 - CVP – Customer Value Proposition – ценностное предложение покупателя.] для конечного клиента.

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

В процессе разработки продукта или проекта одной из важнейших ролей является дизайн. Домен дизайна включает в себя несколько ролей, которые в разных компаниях могут отличаться друг от друга. Одной из ключевых является продуктовый дизайнер. Он является членом продуктовой команды и занимается проработкой пользовательского опыта, не занимаясь при этом «рисованием картинок», баннеров и других креативов. Продуктовый дизайнер всегда находится в тесном взаимодействии с владельцами продукта или CPO[5 - CPO – Chief Product Officer – «Директор по продукту».], бизнес-аналитиками и другими членами продуктовой команды.

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

Также продуктовые дизайнеры занимаются проработкой клиентских путей, формированием CJM[6 - CJM – Customer journey map – карта пути клиента.] и проектированием будущих интерфейсов для клиентов продукта. Они работают в тесном взаимодействии с другими членами команды и всегда стремятся создать удобный и интуитивно понятный интерфейс с привычными пользователю паттернами для достижения максимально комфортного пользовательского опыта будущих клиентов. Продуктовый дизайнер является ключевым игроком в процессе разработки продукта или проекта, и его вклад в создание удобного и качественного продукта неоценим.

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

Кейс: дизайнер или продуктовый дизайнер

Суть: нам неоднократно приходилось сталкиваться с очень частым кейсом: «нарисуй баннер», «сделай иконку», «сюда надо картинку придумать» и т. п., да еще и в очень короткий срок, потому что компания, оказывается, «завтра» планирует запустить какую-нибудь акцию или рекламную кампанию. Конечно же, в продуктовой команде никогда нет выделенного ресурса в виде графического дизайнера, а если такое и встречается, то это нетипичная ситуация и считай тебе повезло. Графический дизайн в компании – это обычно отдельное подразделение, ресурсы которого распределяются на все активности компании и быстро получить там специалиста, как правило, невозможно. Что происходит в таких случаях? Владелец продукта обращается к продуктовому дизайнеру и просит помочь в решении этого вопроса. Почему это плохо? Да все просто на самом деле: продуктовый дизайнер обычно занят созданием нового клиентского пути по одной или нескольким приоритетным фичам, взаимодействует с потенциальными пользователями, исследует, формирует CJM. Вторгаясь в этот процесс, ты очевидно нарушаешь его, заставляешь человека переключиться на не типичную для него работу, которую он, если сделает классно, то пожертвует основными активностями и ты проиграешь в другом месте, закрыв текущую потребность. Но это лишь вершина айсберга. Если продуктового дизайнера постоянно загружать такой работой, то он просто выгорает, как и любой другой специалист, которого заставляют работать над непрофильными задачами. Береги продуктовых дизайнеров, без них ценность твоего продукта станет намного меньше, а проверка любой гипотезы через R&D[7 - R&D – Research and development – исследования и разработка.] гораздо дороже.

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

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

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

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

Для обеспечения оптимального распределения ресурсов в команде и отсутствия аномальных перегрузок в команде тестирования следует начинать найм с разработчика. После найма разработчика запустится адаптационный процесс и погружение в продукт и процессы.

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

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

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

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

Кейс: тестировщик или разработчик – кто первый?

Суть: мы смогли поработать как в нескольких крупных компаниях, так и в стартапах, что позволит рассказать об особенностях работы с тестированием под разными ракурсами. Начнем, пожалуй, со стартапов. Работа в стартапе характерна совмещением нескольких функциональностей в одной роли, это может быть как две, так и три роли в одном участнике, ведь задача стартапа быстро собрать MVP[8 - MVP – Минимально жизнеспособный продукт – продукт, обладающий минимальными, но достаточными для удовлетворения первых потребителей функциями.] продукта и показать его конечному потребителю, чтобы проверить гипотезу и CVP, которые необходимо донести. Если собирать стартап командой, уровень которой ниже чем middle+ / senior, то шанс попасть в те самые девять из десяти погибающих стартапов становится выше, ведь правильно заложенная архитектура продукта – это залог его успешного масштабирования в дальнейшем, а если речь идет об использовании одного бэкенда для web-приложений и мобильных приложений, то ценность высококвалифицированных специалистов на ранних стадиях становится еще выше. В ситуации, когда собирается стартап, функционал тестировщика минует множество бюрократических аспектов крупных компаний, и создания большого количества артефактов от тестирования также не требуется. Это значит, что тестировщик вполне может приступать к работе только после того, как готов первый блок функциональности, который можно проверять, сверять с макетами или требованиями и заводить дефекты. Раньше, чем есть первая кодовая база, привлекать тестировщика на стартап совершенно бессмысленно, если только у вас нет лишнего бюджета или желания вовлечь тестирование в процесс пораньше.

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

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

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

Автоматизация тестирования является неотъемлемой частью процесса разработки цифровых продуктов. Это позволяет значительно повысить эффективность и качество тестирования, а также сократить время, затрачиваемое на проверку продукта. Несмотря на то что автоматизация тестирования требует дополнительных ресурсов и времени, она является важным инструментом для достижения успеха в современном бизнесе. Одной из главных причин для автоматизации тестирования является ускорение процесса проверки функционала продукта. Вместо того чтобы проверять каждую функцию вручную, автоматические тесты могут быстро и точно выполнить эту задачу. Это позволяет значительно ускорить процесс проверки и улучшить качество продукта. Кроме того, автоматизация тестирования также может помочь выявить ошибки и дефекты на ранних этапах разработки. Это позволяет исправить проблемы до того, как они станут серьезными и приведут к задержкам в разработке или проблемам с пользовательским опытом. Однако автоматизация тестирования также требует дополнительных ресурсов и времени. Необходимо разработать и поддерживать автоматические тесты, что может занять значительное количество времени и ресурсов. Но, как правило, эти затраты окупаются в будущем, когда продукт готовится к выпуску и необходимо провести тщательную проверку функционала.

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

Итак, мы с вами рассмотрели основную структуру продуктовой команды и теперь можем перейти непосредственно к особенностям найма каждой позиции. Найм кандидатов в продуктовую команду начинается с анализа работы в текущей команде, если она уже есть, ритма работы, нагрузки на каждое направление, ритмом и, конечно же, объемом ценности, выходящим из команды в конечного пользователя. В отличие от стартапа или сбора новой команды работа с действующей командой бывает более сложной и непредсказуемой. Разберем оба варианта.

Особенности найма в стартап или новую команду