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

Как в такой ситуации не сдаться, не расслабиться и найти способ приносить результат с первых дней? Есть несколько простых, но не всегда очевидных идей, которые мне помогли.

Делать максимум из того, что возможно прямо сейчас.

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

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

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

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

Закрывать смежные компетенции.

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

У меня получилось временно закрыть пробел в системном/бизнес анализе, хотя до Кошелька я никогда не писала технические спецификации и документации. 

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

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

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

  Итак, что может помочь продакту, который полез не в свою профессиональную область?

• Найти специалиста для ревью. Хорошо, если это будет человек внутри компании. Хорошо, если таких ревьюеров в начале будет несколько. Мне помогали старший продакт, технический инженер и разработчики.

• Найти готовые примеры выполненных работ и сделать так же. Например, у нас в Кошельке есть пространство Confluence, где у каждой команды хранится документация фичей, над которыми они работали. Я брала самые подробные спецификации и описывала собственные по их примеру и структуре. Если такой базы данных нет, можно поспрашивать у знакомых (и незнакомых) аналитиков какие-то универсальные шаблоны, которые используются в их командах. Они подскажут, в какую сторону копать. Лучше не бояться спрашивать и переспрашивать у коллег. Уточнить задачу, попросить о помощи. Это поможет не накосячить.

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

Разделить ответственность с другими членами команды.

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

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

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

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

Однако позже на ретро мы отметили, что нам было легче работать от того, что каждый знал полный контекст задач. В совместной работе каждый член команды за счет своих уникальных навыков может сделать вклад в процесс дискавери и вовремя задать нужные вопросы, которые позволят уточнить оценку и одновременно обеспечить definition of ready и definition of done перед бизнес заказчиками.

Искать людей в команду всегда и везде.

… Пусть новые знакомые на вечеринке сразу узнают, какой ты душный.

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

По данным HR, почти 50% разработчиков в Кошельке пришли по рекомендациям друзей, которые тоже работают у нас. Например, наш Android-разработчик раньше работал с лидом направления, а сейчас уже сам пригласил в Кошелёк backend-разработчика и QA. В поиске особенно помогает премия за приглашенных знакомых.

Привлекать людей внутри компании.

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

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

Процесс получился такой: 3 менеджера и 2 тестера раз в неделю приоритезируют задачи в бэклоге и оценивают, сколько влезает в спринт. Разработчики заполняют обязательное поле «‎Рекомендации для QA»‎, а ещё мы объединяем смежные задачи через feature toggle и тестируем их за один подход, чтобы облегчить жизнь загруженным QA. Отсутствие тестирования внутри команды всё ещё не дает точно оценить емкость спринта, но позволяет двигаться по задачам и не так значительно отставать от сроков. Да, мы не всегда попадаем в релизы. Как кажется, эту проблему можно будет решить только, когда QA появится в каждой команде. И мы к этому стремимся.

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

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