Сервисы
Denis Stebunov

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

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

Почему коммуникация так важна?

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

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

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

Значит ли это, что надо больше общаться?

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

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

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

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

Перестаньте спрашивать, кто над чем работает

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

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

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

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

Сделайте рабочий процесс прозрачным

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

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

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

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

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

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

Сделайте нерабочие дни явными для всех

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

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

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

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

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

Когда дело стопорится

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

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

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

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

В заключение

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

{ "author_name": "Denis Stebunov", "author_type": "self", "tags": [], "comments": 10, "likes": 27, "favorites": 82, "is_advertisement": false, "subsite_label": "services", "id": 185283, "is_wide": false, "is_ugc": true, "date": "Tue, 08 Dec 2020 18:14:51 +0300", "is_special": false }
0
10 комментариев
Популярные
По порядку
Написать комментарий...
1

Интересный проект!

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

Вопрос: как вы сделали видео, например, вот это https://teamplify.com/integrations/ ?
Спасибо

Ответить
1

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

Ответить
0

Понятно, спасибо.
Насчет вашего бота. Мне интересно - почему вы думаете, что если людей будет пинать бот, это будет эффективнее? Мне вот кажется, ботов все будут игнорировать - просто потому, что это человек. Менеджера попробуй проигнорируй :)

Ответить
1

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

Ответить
0

 Пол Грехэм

Ответить
1

но я рад, что на этом моменте не закрыл страницу, потому что в целом статья полезная, спасибо! :)

Paul Graham, конечно же, никакой не Пол Грэхем, а Пол Грэм.

Ответить
1

Ухты, и правда. Поправил, спасибо!

Ответить
0

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

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

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

Ответить
1

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

Ответить
1

 стандарт на число коммитов в день

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

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

Ответить

Комментарии

null