«Первое, что нужно сделать — признаться разработчикам»: как найти общий язык с айтишниками без технического бэкграунда

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

Опытом преодоления таких проблем с журналисткой Highload поделилась продакт-менеджер сайта поиска работы  Jooble Анна Дзегилевич в продолжении интервью. Далее — ее прямая речь.

Как найти общий язык с айтишниками в пределах компании

1. Продакт-менеджер Jooble Анна Дзегилевич

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

2. Выстроить коммуникацию: разработчику очень важно понимать, зачем мы взяли в работу ту или иную инициативу, или фичу, какое влияние она будет иметь на пользователей, чтобы он осознавал, что пишет не просто еще один кусок кода, который будет висеть на сайте, пока мы когда-то его не удалим.
3. Очень важно показывать результаты работы: не просто «вот ваша фича на продакшне», а результаты какого-то A/В-тестирования, объяснение, почему этот тест зашел, либо почему мы будем его убирать из нашего кода. По моему опыту, это делает весомый вклад в мотивацию, в вовлечение команды в процесс создания продукта под пользователя.
4. Вовлекать команду в разработку идей. Не просто как продакт-менеджер приходить и говорить: «Вот, я написала техническое задание, мы это делаем. Все, вперед, в разработку». Нужно приходить к разработчикам на стадии идей с драфтовым вариантом и спрашивать, что они думают по этому поводу. Часто у ребят  хороший уровень экспертизы для того, чтобы объяснить какие-то корнер-кейсы (проблема, возникающая при превышении нормальных параметров — прим.) , которые я или дизайнер могли не учесть при проработке фичи. Они чаще всего знают, как можно сделать продукт лучше, вовлечение помогает нам найти с ними общий язык и сэкономить время.
5. Мне помогает раз в квартал проведение one-to-one (встреч один на один — прим.) с разработчиками. Это не классическая персональная встреча, как у прямого тимлида либо руководителя. Я спрашиваю, как разработчикам работается со мной, понимают ли, куда идет продукт, спрашиваю видение специалиста. Не все готовы давать фидбек  на ретроспективе, но можно получить его на персональных встречах.

Что делать, если команда разработчиков на аутсорсе

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

Я была в такой ситуации в начале моего опыта работы — было сложно, и я не сказала бы, что отношения с разработчиками складывались замечательно. Мне кажется, мы могли бы лучше делать продуктовые решения в плане фич, предусматривать наши недоработки, ошибки продуктовых команд, продумывать проблемы, о которых мы не знали или забыли. Потом все это «всплывало» на продакшне и нужно было переделывать, из-за этого процесс разработки затягивался. На то, что мы могли сделать за месяц, уходило 2-3 месяца.

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