Пусть девелопер говорит

Пусть девелопер говорит

30 июня 2017

  • Автор: Мэри Ротарь

  • Сложность:

  • Время: 3 мин

Коммуникации в команде — странный предмет. Они вроде есть, а вроде и нет.

Пусть девелопер говорит 0
Часто ли вам приходилось страдать от того, что кто-то забыл записать задачу и она потерялась после утреннего митинга? Или не взятые у заказчика доступы законсервировали работу на целую неделю?

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

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

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

Спойлер: Бесит разработчиков почти всё. В особенности, их бесит, когда вы что-то обещаете заказчику, не разбираясь в том, что вы говорите. Например, озвучиваете, что на выполнение задачи уйдёт 2 дня, когда в действительности потребуется неделя.

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

То, чего нет в JIRA — в принципе не существует

Вопрос: как часто PM-ы приходят с техническими вопросами и готовы ли вы им все объяснять и рассказывать?

— приходят, спрашивают, но у них быстро пропадает интерес.

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

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

Вопрос: Какие навыки самые важные для PM-а джуниора?

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

—  умение правильно выстроить коммуникации. PM должен знать за что отвечает каждый разработчик и следовать принципам 3-х Н: «Не тяни, Не ной, Не тупи». Есть задача — объясни. Начинающий PM должен не бояться задавать вопросы. При этом, в ответ нужно быть готовым увидеть кислую мину.

Есть 2 состояния разработчиков, к которым нужно быть готовым PM-у:

1. Блин, какой ты тупой

2. Ты что, самый умный?

— джун PM должен быть коммуникабельным. Он должен понимать, что он часть команды и он задаёт тон.

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

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

Пусть девелопер говорит 1

 

Какие знания необходимы менеджеру проекта

Во второй части мероприятия Ярослав Ротарь рассказал о том, какими техническими знаниями должен обладать менеджер проекта.

Пусть девелопер говорит 2

Что PM должен знать о разработчиках:

  • Они  умные
  • Они милые
  • Они добрые
  • Они отзывчивые
  • Они всегда готовы помочь

Что должен знать PM о технической стороне проекта?

по мнению разработчиков

 

  • Как хранятся данные (от куда они берутся на сайте, как доставляются по сети, кто за это отвечает)
  • Как пишется и из чего состоит фронт (фреймворки, типы верстки)
  • Как деплоится (Cl, clouds)
  • Что такое HTTP протокол и JSON формат
  • Какая разница между языками программирования, когда какой применять (язык запросов, язык разметки, язык программирования для бэка/фронта)
  • Всегда помнить про доступы
  • Обеспечивать все необходимое окружение, и не только программное, иногда «быть нянькой»
  • Знать базовый процесс разработки программных приложений той сферы, в которой реализовывается проект
  • Умение «гуглить» и находить ответы там, где все уже сдались
  • Огромное желание вовлекаться во все, что касается проекта
  • И не менее большое желание проталкивать и пушить нужные проекту решения

Что должен знать PM о технической стороне проекта?

по мнению PM-ов

 

  • Понимать технические требования к своей команде на проекте
  • Понимать требования к технологиям на проекте как от команды так и от Заказчика
  • Особенности работы при интеграции с третьесторонними сервисами
  • Базовые владение системами контроля версий
  • Знание лучших практик процесса программной разработки (TDD, XP)
  • Знание и умение донести необходимость культуры программирования (code review, рефакторинг, комментирование, стандарты кодирования)
  • Умение читать и описывать бизнес-логику в технической документации
  • Владение базовыми основами тест-менеджмента
  • Понимание узких мест при работе с hardware
  • Умение найти и правильно использовать необходимые инструменты для аналитики проекта (Google Analytics, Flury, HostTracker)
  • Не бояться кода и не бояться делать что-то руками
  • Понимание принципов хранение исходных файлов проекта (хостинг, сервер)

Эти списки обширные и могут немного напугать новичков, но не стоит бояться. Помните: идеальными менеджерами не рождаются — ими становятся.

Мэри Ротарь

CEO и Co-Founder в IAMPM 10 лет опыта в маркетинге и управлении продуктами. Вывела на рынок более 50-ти проектов в роли консультанта, работала как Product Manager в SaaS, Gaming и EdTech нишах. Вырастила лабораторию Нетехнического IT-образования IAMPM из хобби в международный бизнес.