С одной стороны, программисты – мягко говоря не самые общительные люди на свете. Это нормально, ведь если разработчики вдруг станут разговорчивыми кто будет писать код? С другой – время одиночек прошло. Современное ПО разрабатывается командами и даже самые консервативные компании, вроде Сбербанка внедряют Agile. Agile manifest пропагандирует определенные ценности, в том числе: «Люди и взаимодействие важнее процессов и инструментов». Так что общение с коллегами – не прихоть, а потребность. Эта статья ориентирована на гибкие команды разработки: разработчиков, тим-лидов, аналитиков, тестировщиков и т.д.
Профессиональные PM вряд ли найдут здесь что-то новое. Если вы – «технарь» и хотите, чтобы вас как можно меньше отвлекали от основного вида деятельности и вам интересно при чем здесь Спарта, добро пожаловать под кат.
Деловое общение отличается от дружеских посиделок в первую очередь ориентацией на результат, а не процесс. Мы прощаемся с друзьями со словами «отлично посидели», а не «спасибо, коллеги, было эффективно». В чем измеряется эффективность общения? Брукс еще в 1975-ом заметил, что одним из важнейших препятствий для масштабирования разработки являются затраты на коммуникацию:
Если есть N программистов, то количество пар программистов равно N(N—1) / 2, то есть с ростом числа программистов затраты времени на взаимодействие растут квадратично. Поэтому начиная с какого-то N, рост числа программистов замедляет выполнение проекта.
и придал особую важность взаимодействию между разработчиками:
Чтобы предотвратить катастрофу, группы разработчиков должны взаимодействовать друг с другом всеми возможными способами. Вместо того, чтобы строить предположения по поводу реализуемой им функции, разработчик должен задавать архитектору уточняющие вопросы, поскольку предположения могут оказаться совершенно неверными. «Предположение — мать провала».
Его выводы на этот счет не только ни разу не ставились под сомнение, но и неоднократно подтверждались. Таким образом, разработчикам необходимо как можно больше общаться, для уточнения требований и ограничений, ни в коем случае не полагаясь на предположения (потому что они часто бывают неверны) и одновременно как можно меньше общаться, чтобы снизить затраты на коммуникацию, растущие квадратично, в отличие от растущего линейно выигрыша в производительности за счет добавления дополнительных членов команды разработки. На первый взгляд, перед нами явное противоречие. Однако, история знает по крайней мере один пример, когда целому городу удавалось поддерживать культуру эффективного общения.
«… Если бы кто захотел сблизиться с самым никчемным из лаконцев, то на первый взгляд нашел бы его довольно слабым в речах», предупреждал философ Сократ своих земляков, «но вдруг, в любом месте речи, метнет он, словно могучий стрелок, какое-нибудь точное изречение, краткое и сжатое, и собеседник кажется перед ним малым ребенком».».
Если бы царь Леонид был нашим современником, вероятно, он мог бы сказать что-то вроде:
Коммуникация на проекте эффективна, если занимает минимально-возможное время, необходимое для принятия качественных решений и доведения их до членов команды.
Stand-Up
Всем известно, что совещание – отличная альтернатива работе. Stand-up meeting, daily scrum или проще говоря «планерка» — единственное регулярное собрание в agile-методологиях. Ежедневно проводиться собрание всей командой, на котором каждый отвечает на вопросы:
- Что сделал вчера? (гордость)
- С какими проблемами столкнулся? (просьба помощи)
- Что сделаешь сегодня? (обещание)
Очень желательно, чтобы «стендап» проводился утром. Не слишком рано, чтобы исключить опоздания, дать участникам время на подготовку и чашечку ароматного кофе. Совершенно необходимо, чтобы все члены команды присутствовали и придерживались формального плана: ответить на три вопроса и передать слово. Проблемы следует обсуждать после и привлекать только заинтересованных лиц. В противном случае, «планерка» перерастает в стихийный базар. Оптимальное время проведения ежедневного собрания – не более 15 минут. Оптимальная численность команды – не более 7 человек. Если ваша команда больше, и вы собираетесь на час и более, скорее всего команду нужно разделить. Предложите это тим-лиду или менеджеру проекта.
Чтобы уложиться в 15 минут к «стендапу» нужно готовиться. Если вы испытываете трудности с публичными выступлениями откройте блокнот (электронный или листок бумаги) и выпишите ответы на вопросы. А затем представьте себя настоящим спартанцем и вычеркните все лишнее: междометия, деепричастные обороты, лирические отступления. Оставьте голые факты. Не допускайте двусмысленности. Если у вас проблема – не нужно ее замалчивать: четко и коротко сформулируйте и попросите помощи. Если вы думаете, что знаете, как решить, явно скажите об этом и попросите подтвердить, что ваше решение оптимально и дополнительное обсуждение не требуется. Не переусердствуйте. Номеров задачи из таск-трекера не достаточно. Ваши коллеги не помнят, что скрывается за задачей номер 100500. Стоит озвучивать название задачи.
В идеале после «стендапа» все в команде знают оперативную обстановку на проекте и продолжают заниматься своими делами. Проблемы выявляются на ранней стадии. К решению проблем привлекаются только необходимые люди. Пока все идет хорошо мы тратим на коммуникацию не более 15 минут в день и решаем все вопросы качественно. Эх, если бы всегда все шло как по маслу:)
Подробнее о лучших и худших практиках «стендапов» можно прочитать в блоге AlexanderByndyu.
Оперативное общение в течение дня
В реальном мире мы сталкиваемся с бесчисленным числом проблем. Задачу пора брать в работу, а требования еще не полны, макеты не готовы, API не задокументировано, в используемой библиотеке найден критичный баг и нужно писать в поддержку… Продолжите список сами. Как решать такие проблемы? Ответьте себе на следующие вопросы:
- Сколько человек (минимум) необходимо для решения вопроса, и кто они?
- Кого и когда следует уведомить о принятом решении?
- Какой канал коммуникации использовать?
Каналы коммуникации
В разных компаниях приняты разные стандарты корпоративного общения. Не претендуя на истину в последней инстанции, расскажу, как принято у нас.
- Личное общение / скайп, телефон: самые срочные вопросы, не требующие отлагательств или вопросы, которые не получается решить иным образом в ходе долгого времени
- Мессенджер: вопросы, требующие ответа в течение дня и не требующее принятия решений, затрагивающих других членов команды.
- Таск-трекер: вопросы, требующие ответа в течение недели и / или изменения / фиксации требований.
- Почта: оповещения, не связанные напрямую с проектной деятельностью: уход в отпуск, отсутствие по болезни, подключение нового сотрудника или уход сотрудника с проекта. Общение по почте – отдельная тема, относящаяся скорее к работе менеджера, так что не будем больше о ней.
Каналы коммуникации отсортированы в порядке скорости решения вопросов и «стоимости». Начнем с самого быстрого и «дорогого».
Личное общение / скайп, телефон
Представим ситуацию: вы уверены, что ваш коллега Иннокентий точно в курсе как решить проблему. Быстрее всего подойти к нему, похлопать по плечу и спросить: «Кеша, а у меня вот тут есть такая штуковина, как бы мне ее впендюрить так чтобы…». Скорее всего Иннокентий не будет в восторге от вторжения в его приватность. «Стендап» снова приходит на помощь. Если Иннокентий в вашей команде, «забронируйте» его сразу после планерки. Он все-равно уже отвлекся, еще 10 минут погоды не сделают.
Бывает так что Иннокентий нужен всем. Например, если собрали команду из одного опытного разработчика и трех студентов. Я считаю, что это проблема управления, а не коммуникации. Если вы – Иннокентий, разговаривайте с руководством на тему «работаю я после обеда, а до обеда по совместительству преподаю». Если вы студент, вставайте в очередь. К сожалению, до сих пор многие горе-управленцы считают, что тим-лид восемь часов пишет код, а все остальное делает как-то между делом. Если в команде архитектор и опытные программисты, но архитектор вносит правки в структуру приложения, потому что он «так видит» и не документирует, это опять-таки проблема управления, а не коммуникации. Нужно выделять достаточно времени на проектирование, документирование и консультации. Если от архитектора больше вреда, чем пользы, может и не нужен он вовсе.
У меня достаточно напряженный рабочий граффик, поэтому с определенного момента я веду публичный google calendar. Так поступают некоторые мои коллеги и знакомые.
Если вы тим-лид / тех. дир / архитектор и значительную часть времени занимают встречи, возможно, организация рабочего времени с помощью календаря будет полезна и вам.
Мессенджер
Хорошо подходит для коротких вопросов-уточнений, вроде:
- «Я заметил, что в задаче А требование В выглядит не логично, потому что в коде строчка С реализует другое бизнес-правило. Думаю, что нужно скорректировать постановку следующим образом. Это верно?»
- «Я работаю над задачей А и хочу использовать библиотеку B, но меня беспокоит факт C. Стоит ли мне использовать альтернативу и какую?»
- «Задача А просили выложить на продакшн сегодня. Думаю, что закончу через час, но мне нужно, чтобы ты провел code-review, а Василий провел регрессию. Сможешь проверить pull request к 14:00, если я отправлю его в 13:00?»
Если общение затягивается, это может говорить о том, что вы не понимаете друг друга и нужно созвониться или проблема оказалась сложнее, чем предполагалось и потребует привлечения дополнительных участников. Во втором случае, возможно, потребуется отложить вопрос или привлечь дополнительных участников.
Таск-трекер
Эффективная коммуникация в трекере требует дисциплины и определенного уровня процессов. Залог успеха – отсутствие информации, не связанной напрямую с задачей и пространных обсуждения. Трекер – не форум. Многие задачи так обрастают комментариями, что на их изучение в последующем требуются часы. Необходимо явно указывать чья реакция требуется. Если ваш трекер не поддерживает нотацию @userName, то у меня для вас плохие новости. Сообщения должны быть сформулированы максимально кратко и емко и не допускать двусмысленности. Прежде чем отправить сообщение, перечитайте его несколько раз:
- Кому оно адресовано? Укажите.
- Достаточно ли информации? Добавьте, чтобы было достаточно.
- Нет ли лишней информации? Удалите лишнее.
- Какой реакции вы ожидаете? Напишите явно.
Отдельная проблема — баг-репорты. Значительных успехов можно добиться, если не брать в работу, пока баг не будет оформлен должным образом, например:
- Окружение
- Как воспроизвести
- Ожидаемое поведение
- Актуальное поведение
Синхронная и асинхронная модель коммуникации
Личное общение и телефон – это синхронная модель коммуникации. Участники интенсивно обмениваются информацией. За счет этого вопросы получается решать более оперативно. Платой является потеря многозадачности. В момент общения все участники «заблокированы» и не могут больше ничего делать. Если единственный способ решить вопрос — часовой звонок по skype, значит придется это сделать. К счастью, чаще всего таких крайностей можно избежать. Более того, при любой возможности следует избегать синхронной модели коммуникации. Уважайте время коллег!
Письменное общение, наоборот, — асинхронно, причем таймаут почты и трекера превышают один рабочий день, а в мессенджерах, наоборот, — лимитирован рабочим днем. Представьте своего коллегу как веб-сервер, обслуживающий множество входящих запросов (обращений в мессенжеры, почту и трекер). Вы не знаете, какая нагрузка на веб-сервер в данный момент времени, но чем раньше вы отправите сообщение, тем раньше станете в очередь и если сервер не перегружен, то вы получите ответ. Учитывайте это и отправляйте запросы заранее, а не когда все горит, пропало и срочно надо! Если «сервер» не отвечает, попробуйте обратиться позднее или воспользуйтесь альтернативным каналом. Только, пожалуйста, не одновременно, иначе сервер включит защиту от DDOS и будет прав.
Автор: marshinov
