Эффективное взаимодействие Product Manager либо Product Owner с командой разработки приведет к более слаженной работе, поможет избежать конфликтов, токсичности и недосказанности. Анна Дзегилевич, Product Manager сайта поиска работы Jooble рассказала о том, как идти в одном направлении с командой и какие шаги смогут улучшить процесс работы над продуктом.
Бывают проекты, на которых нужно сделать задачи быстро, за два дня, но на практике это бывает невозможно. И дело не в сложности работы, а потому что есть недоразумения и конфликты внутри команды. Часто подобные проблемы возникают, если команда не знает ценности продукта, стратегические цели компании. Еще одна ошибка заключается в отношении Product Manager к разработчикам как тем, кто лишь пишет код, а их — к продакту как человеку, что дает задачу. Важно эти грани смыть, каждого с маленьких лодок посадить на одной большой корабль и пустить всех плыть в одном направлении. С единой миссией – мы вместе создаем продукт и ценность для нашего клиента.
Общаясь с коллегами, я отметила для себя, что подобные проблемы работы в команде встречаются нередко. А так как в ходе работы у меня получалось вовлекать команду, чтобы мы все шли в одном направлении, то захотелось поделиться информацией – как минимизировать затраты на ненужные вещи, а сфокусироваться на донесении ценности клиенту. Для этого можно предпринять несколько шагов:
Начинать с «почему»
Для слаженной работы команды нужна общая цель. Поэтому важно до каждого участника донести контекст и смысл работы: вектор развития компании, ее цели и видение продукта. Для себя я выделила правило: сначала смысл и большая идея, потом техническая задача.
Не стоит приходить к разработчику с четко выписанным техническим заданием. Лучше доносить контекст – рассказать куда идет компания, почему, какая ее цель, какое видение продукта и цель команды. Чтобы донести понимание, зачем мы делаем то, что делаем важно обозначить роль команды в компании.
Например, в Jooble мы часто вводим продуктовые и стратегические изменения. И если мы ранее фокусировались на том, чтобы вовлекать пользователей на страницы поиска, а сейчас переключились на пользовательский онбординг. То будет неверным просто дать команде новую задачу, важно объяснить нашу новую цель – помочь «синим воротничкам найти работу за 24 часа». Так команда поймет изменения контекста, нашей задачи и мы сможем обсудить, как это лучше реализовать, перед началом работы. Так у человека формируется понимание влияния его работы на продукт.
Показывать цикл разработки продукта
Важно приносить задачи команде на ранних этапах, в формате идеи, которая требует реализации. В первую очередь, потому что это поможет сразу понимать – возможно ли сделать так, как задумано. Также у разработчиков есть знание корнер кейсов, которые помогут при описании задачи. Например, каким должен быть экран, когда неверно введен пароль и тд. Это более удачный подход, нежели после месяца работы, юзер-тестов, ресерча, понять, что сделать задачу невозможно, по ряду причин.
Имеет значение и методы постановки задач. Например, принцип «Сэндвича с тунцом» — это о разных подходах к прописыванию задач. То, как мы составляем задачи влияет и на вовлечение команды, и на конечный результат. Мы можем максимально описать команде, как приготовить сэндвич с тунцом, прописав процессы до мелочей. А можем показать контекст шире и объяснить, что нам нужен перекус в горы. Тогда окажется, что сэндвич с тунцом не будет лучшим решением, ведь он портится без холодильника. В случае объяснения контекста, мы даем шанс команде внести свои коррективы в финальное решение, получаем фидбек, улучшаем план работы и вовлекаем всю команду в решение задачи.
Показывать разработчикам цикл развития продукта
Повлияет на продукт и ознакомление разработчиков с результатами тестов, мнениями пользователями. Это поможет прорабатывать новые гипотезы и понимать команде, основываясь на данных, почему, мы удаляем код или развиваем что-то дальше. После ознакомления с результатами юзер-тестов мы имеем некий прототип и работать команде становиться легче, уходят недопонимания в дальнейшей работе.
Вовлекать разработчиков в пользовательские интервью
Разработчику важно знать общий портрет пользователя. Тогда мы можем делать максимально простые решения, понятные нашей аудитории. На своём опыте могу сказать, что ситуация написания кода командой «вслепую» встречается очень часто. Когда нет понимания аудитории своего продукта, то возможно создание слишком сложных решений, не релевантных для пользователя.
Искренне принимать и поощрять обратную связь на продуктовые решения
Ранее, если я слышала фидбек разработчика, то могла принять его в штыки. С опытом я начала понимать, что отклик профессионала важен. Моменты отмеченные им, часто являются теми, что мы изначально не предусмотрели. В дискуссии рождается достойный продукт для пользователя. И правильность коммуникации в команде важна и влияет на скорость принятия финального решения.
Интересоваться тем, как технически устроено приложение/сервис
В продакт-сообществах временами возникает дискуссия: «Должен ли продакт знать техническую составляющую?». Единого мнения нет, но исходя из моего опыта, технические знания улучшает и взаимодействие с командой разработки, и дает верхне уровневое понимание работы продукта и взаимосвязи. Также важно говорить с командой на одном языке, используя понятную всем терминологию.
К примеру, когда ты начинаешь работать с новым продуктом, процесс существенно тормозится, если нет базовых знаний о нем, тогда ты не понимаешь в целом – можно что-то внедрить или нет. Мне приходилось по началу дергать коллег и узнавать элементарные вопросы. Для онбординга это нормально, но если так продолжается очень долго, то процесс разработки может затянуться на неоправданно долгий срок.
Проводить 1-2-1
Личные встречи не очень распространена между Product Manager и командой разработки, но в моей практике это помогает и влияет на результат. 1-2-1 — это регулярная встреча, цель которой: узнать ожидания и впечатления сотрудника; помочь коллеге в повышении эффективности его работы; получить обратную связь. Личная встреча помогает решить конфликты, выровнять ожидания, наладить доверительные отношения, договориться о правильном взаимодействии друг с другом, понять, в каком направлении двигается человек.
Если я знаю, как человек хочет развиваться, то отдаю ему соответственно определенные задачи, чтобы помочь в этом. Синергия личных целей и целей компании прямо влияет на качество продукта.
Как проводить такие встречи? Какие пункты стоит обсудить?
Интро
Поинтересуйтесь как у человека дела, что сейчас тревожит. Можно спросить: «Что чувствуешь сейчас? О чем мысли?» — помогает настроиться на продуктивное обсуждение, дать динамику и определить горячую тему для встречи.
Ревью предыдущей встречи
Если это не первый 1-2-1, то с прошлой встречи нужно проговорить успехи, это один из важнейших пунктов для разговора. Например, ранее договорились улучшить процесс коммуникации и сверяемся стало ли лучше.
Синхронизация по направлению движения
Обсуждаем понимание стратегии и видения, роли в стратегии, сверяем ожидания, так как они могут меняться с процессом развития команды и взаимодействия.
Обратная связь члену команды
Даем фидбэк на работу человека, оцениваем результативность нашего взаимодействия.
Обратная связь от члена команды
Спрашиваем фидбэк на свою работу, что стоило бы улучшить, какие моменты огорчили или порадовали.
Персональное развитие
Поинтересуйтесь, куда двигается и развивается человек. Важный момент, спросить: «Чем я могу тебе помочь, чтобы ты мог(ла) этого достичь?». Например, коллега хочет подтянуть SQL и можно человеку дать задачи, которые будут ему помогать это сделать. Также, бывали случаи, когда коллега хотел больше подтянуть понимание продукта и разработки флоу и мы вместе работали над задачами от их инициализации и до конца.
Итоги
В конце мы просуммируем, о чем поговорили и обсуждаем дальнейшие шаги, если такие имеются (не в плане трекинга задач, а в плане взаимодействия).
Эти 7 шагов не являются истиной в последней инстанции и могут подойти не всем командам, но использование, хотя бы нескольких, поможет стать менеджером лучше, для своих коллег. Построить более доверительные отношения, выйти на открытый диалог с другими участниками команды и конструктивно коммуницировать.
Автор: Анна Дзегилевич, Product Manager сайта поиска работы Jooble
