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

ЧЕТКО ПРОГОВАРИВАТЬ С КОЛЛЕГАМИ ВАШИ ОБЯЗАННОСТИ ПО УПРАВЛЕНИЮ ПРОЕКТАМИ

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

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

АКТУАЛИЗИРОВАТЬ И ПРИОРИТИЗИРОВАТЬ БЭКЛОГ

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

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

ВЫДЕЛЯТЬ ЭТАПЫ И РАССТАВЛЯТЬ КОНТРОЛЬНЫЕ ТОЧКИ

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

Если говорить в общем, то определить, какой процент крупного проекта выполнен, крайне сложно. Принцип Парето гласит, что написание последних 20 % кода занимает 80 % времени. Именно поэтому так важно разбивать работу на этапы – пока команда не дойдет до четко обозначенной контрольной точки, представить, сколько еще осталось сделать, очень трудно.

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

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

ПИСАТЬ ХОРОШИЕ ОТЧЕТЫ О ХОДЕ РАБОТ

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

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

Как правило, отчет о ходе работ включает в себя ответы на следующие вопросы:

1. Идет ли проект по плану? Страшновато признаваться, что проект идет не по графику или вовсе остановлен. Но намного хуже говорить, что все в порядке, когда на самом деле это не так. Вы будете выглядеть нечестным и потеряете доверие.

2. Что произошло за последнее время? Сделайте акцент на ключевых достижениях и важных изменениях. Заодно можно отпраздновать завершение каких-то промежуточных этапов вместе с командой.

3. Что дальше? Обсудите следующий этап работы и цели, которые необходимо выполнить.

4. Существуют ли какие-либо проблемы или риски? Заранее проинформируйте стейкхолдеров о своих опасениях и дайте им возможность оказать вам помощь.

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

КОНТРОЛИРОВАТЬ РАБОТУ КОМАНДЫ

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

• Они застряли на одной задаче и просто топчутся на месте.

• Они не согласны с распределением задач и не хотят ничего делать.

• Они взялись за новое задание, не закончив старое.

• Они непрестанно совершенствуют и шлифуют результат, вместо того чтобы сдать работу как можно быстрее.

• Они поставили какие-то другие обязательства выше задач, приоритетных для вас.

• Задание оказалось более сложным, чем предполагалось.

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

СОВМЕСТНОЕ РЕШЕНИЕ ПРОБЛЕМЫ

Однажды топ-менеджер по продукту Саир Бакл (Sair Buckle) заметила, что один из инженеров-сеньоров выполняет задачи медленнее, чем обычно. Она не стала делать выводов о том, что он просто не укладывается в график, и отправила ему неофициальное сообщение с просьбой рассказать о том, как он планировал свою работу.

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

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

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

КОРРЕКТИРОВАТЬ ПЛАНЫ ПО МЕРЕ ИЗМЕНЕНИЯ СИТУАЦИИ

Вспомните один из самых популярных вопросов на собеседовании: «Что вы будете делать, если ваша команда начнет отставать от графика?» Если не вдаваться в подробности, то как на собеседовании, так и в реальной жизни вы можете предложить три рычага, на которые можно надавить в данной ситуации:

• Добавить в проект больше людей.

• Перенести дату запуска.

• Сократить объем.

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

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

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

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

ДЕЛИТЬСЯ НАКОПЛЕННЫМ ОПЫТОМ С КОЛЛЕГАМИ

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

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

Лучший способ поделиться успешными наработками, в особенности для IC[59]59
  IC (individual contributor, индивидуальный контрибьютор) – сотрудник без менеджерских обязанностей, который глубоко разбирается в своей области и способен в одиночку внести серьезный вклад в продукт. – Примеч. ред.


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

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

БУДЬТЕ НА СВЯЗИ

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

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

Если вы с командой работаете в разных помещениях, полезно время от времени подходить к людям и интересоваться, как идут дела (старясь при этом не отвлекать их от текущих занятий). Работая удаленно, вы можете переписываться с коллегами в чате, когда у них есть на это время. Иногда может оказаться, что они обдумывают какой-то вопрос или застряли на решении проблемы, но даже не догадываются о том, что вы можете им в этом помочь.

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

СОКРАТИТЕ ЗАВИСИМОСТИ

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

Иногда зависимости стратегически полезны. Например, Apple в день запуска новой версии iOS с новыми возможностями API хочет иметь несколько приложений, которые смогут сразу ее использовать.

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

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

ОПТИМИЗИРУЙТЕ РЕСУРСЫ КОМАНДЫ

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

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

• Ограничения по дизайну: выбирайте сложные инженерные проекты, ориентированные на производительность и масштабируемость. Проводите A/B-тесты как можно раньше.

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

• Ограничения по разработке: сосредоточьтесь на стратегии.

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

УЛУЧШАЙТЕ ПРОЦЕССЫ ВНУТРИ КОМАНДЫ

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

Используйте свои навыки работы с продуктом, чтобы оценить, хорошо ли выстроены процессы в вашей команде. Как сами сотрудники оценивают свой прогресс? Довольны ли они качеством своей работы? Что их больше всего напрягает? Что нужно, чтобы запускать продукты на 50 % быстрее?

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

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

Установите ПО для управления проектами

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

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

Применение подобных программ важно по нескольким причинам:

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

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

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

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

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

Используйте демонстрации как побуждающий фактор

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

Демонстрация – отличный способ побудить людей к действию. Чтобы ее провести, команде необходим рабочий код (или почти законченный дизайн, если речь идет о дизайнере). Если все знают, что пятница – день демонстрации, то у каждого есть мотивация привести свою работу в подобающий вид к этому дню. И в четверг вечером можно увидеть бурную деятельность – люди наверстывают то, что не успели сделать за неделю.

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

Установите специальные дни для проработки пропущенных моментов

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

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

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

• Внутренние инструменты: совершенствование внутренних инструментов и процедур многократно увеличивает скорость работы команды.

Если назначить отдельный день для каждого из этих вопросов, то можно добиться значительного прогресса. Запланируйте для своей команды или всего подразделения «охоту за багами» (bug bash), «дни шлифовки» (polish week) или «неделю ускорения процессов» (grease week)[60]60
  «Дни шлифовки» – это время, в течение которого команды фокусируются на мелких, ориентированных на клиента доработках, а «неделя ускорения процессов» предназначена для улучшения работы внутренних инструментов. Более подробно об этом можно узнать на страницах https://blog.asana.com/2012/10/polish-week/ и https://blog.asana.com/2013/07/grease-week-at-asana/.


[Закрыть].

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

ВЫЯВЛЯЙТЕ И СМЯГЧАЙТЕ РИСКИ

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

Для каждого риска нужно разработать план мероприятий по его снижению.

• Как понять, является ли риск реальной проблемой? Вы можете провести проверку концепции или юзабилити-тест.

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

• У вас есть запасной план? Используйте дерево решений, чтобы заранее распланировать действия на случай возникновения проблем. Например, если вы беспокоитесь о негативной реакции клиентов, можно подготовить документ с соответствующими вопросами и ответами.

Выявление рисков на ранней стадии повышает качество продукта и точность сроков реализации вашего проекта.

СПОСОБСТВУЙТЕ УЛУЧШЕНИЮ КАЧЕСТВА И СКОРОСТИ РАБОТЫ ПРОДУКТОВЫХ КОМАНД

Достаточно ли быстро действуют ваши продуктовые команды и эффективны ли они? Лидеры по продукту могут многое сделать, чтобы ускорить работу команды и улучшить качество продукта.

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

Вы можете выявить несколько проблем.

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

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

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

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

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

Ваш вклад в решение этих проблем многократно повысит эффективность ваших команд.

УЧИТЫВАЙТЕ ВОЗМОЖНОСТЬ ПАРТНЕРСТВА И ПРИОБРЕТЕНИЯ КОМПАНИЙ

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

Илай Лернер (Ely Lerner), ответственный за интеграцию двух приобретенных компаний в Yelp, предлагает постоянно сотрудничать с отделом корпоративного развития и держать их в курсе волнующих вас проблем. Встречи с потенциальными партнерами могут оказаться очень ценными, даже если партнерство не принесет ожидаемых результатов, поскольку они дают вам новый взгляд на отрасль.

Покупка активов подразумевает как высокую прибыль, так и большой риск. В большинстве случаев компании терпят неудачу, но некоторым самым успешным брендам удалось преуспеть после приобретений: PayPal, YouTube и Instagram – лишь некоторые из них.

Лернер дал два совета относительно интеграции приобретенной компании в существующий бизнес:

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

ОСНОВНЫЕ ВЫВОДЫ

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

• Не думайте, что кто-то другой отвечает за управление проектом: лид-инженер может взять на себя многие процессы управления проектами, но не всегда. Уточните, за какие вопросы вы должны отвечать, по мнению команды. Если никто не захочет взять управление в свои руки, это придется сделать вам.

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