Улучшаем коммуникацию между разработчиками и менеджерами

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

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

• Недостаточное понимание бизнес-целей;
• Размытые или недостаточно четко донесенные требования;
• Нереалистичные сроки или ожидания;
• Ошибочное предположение, что фронт работ может быть определен заранее;
• Неудачное планирование;
• Слишком много или слишком мало людей задействовано в проекте;
• Неинформативная отчетность о ходе выполнения проекта;
• Плохое управление рисками;
• … и так далее.

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

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

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

Когда разработчики знают, что им скоро придется отвлечься, им сложно начать делать что-то серьезное. Пол Грэм написал отличную статью по этому поводу — Maker’s Schedule, Manager’s Schedule (есть также перевод на русский).

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

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

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

Поэтому мы научили нашего бота Teamplify следить за этим:

Teamplify подключается к вашему таск-треккеру (Jira или Trello), и если обнаруживает, что непонятно, над чем разработчики сейчас работают, вежливо напоминает им об этом в Slack или электропочтой. Такие уведомления стараются быть ненавязчивыми и принимают во внимание все виды нерабочих дней, то есть не побеспокоят ваших коллег во время их отпуска. Но об этом чуть позже.

Сегодня почти каждая команда разработчиков пользуется как минимум какой-то версией этих средств для совместной работы:

• Хостинг кода — например, GitHub или GitLab;
• Таск-треккер — Jira, Trello или другие;
• Чат — многие команды используют Slack;
• Софт для видеоконференций — Zoom и аналогичные.

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

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

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

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

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

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

Именно поэтому мы добавили в Teamplify поддержку всех видов нерабочих дней. Они видны на вышеупомянутом Командном Календаре, а также присутствуют в виде уведомлений в Slack или на электронную почту:

Даже если люди пропускают уведомления о надвигающемся отпуске или больничном и обращаются в Slack к тому, кто сейчас недоступен, Teamplify вежливо напомнит им об этом:

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

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

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

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

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

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