Павел Кондратьев

Руководитель проектов в ГК Юзтех

Введение

Здравствуйте, меня зовут Павел Кондратьев, и я руководитель проектов. 

Начинал работу в небольшой компании, создавая кросс-платформенные и нативные мобильные приложения на Kotlin/Swift и веб-сервисы на Yii2, пока не перешел в ГК Юзтех, где веду самые разные проекты на .NET/Vue.JS в мультивендорных командах.

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

Проблематика

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

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

Общение — это про обмен сообщениями и чувствами для установления и поддержания межличностного контакта с собеседником, а коммуникация — про специфический обмен информацией, которое направлено на передачу информации, где важна точность.

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

Таким образом мы выводим главную проблему в коммуникации — потеря данных.

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

Каналы связи

Что выбрать в качестве канала связи, мессенджер, почту или ежедневные синки? Зависит от типа обсуждаемых задач, но правил всего два — скорость общения и ведение коммуникации только в одном канале связи.

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

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

При онбординге нового участника команды сокращается погружение, поскольку даёт возможность быстрого обращения за информацией (текущее общение, история сообщений, поиск по сообщениям). 

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

Шина

Наверное, все представляют интеграционную шину, когда любой источник и потребитель подключен к общему каналу связи. Информация передаётся в этот канал связи и из него забирается.

Метод организации каналов связи по принципу шины зарекомендовал себя годами практики. Организовывая коммуникацию команды на старте проекта или на любом этапе подключения к нему, я всегда ввожу одно общее правило — в личных сообщениях технически значимую информацию не обсуждаем. 

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

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

Фиксация значимой информации

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

Также из стопроцентного must have наличие в документации на проекте страницы, которая содержит всю важную технически значимую информацию по проекту. 

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

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

Парафраз или давайте повторим задачу

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

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

Правила обращения

“Надо закрыть окно” и “Паша, открытое окно создает сильный сквозняк, закрой его сейчас”.

Чувствуете разницу?

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

<Обращение> + <вводная информация> + <призыв к действию/призыв к бездействию>

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

Ну и всё это не работает без следующего пункта.

Обратная связь и квитанция

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

“Квитанция” — такое смешное, но такое важное слово.

Квитанция — это в первую очередь про строгую отчётность. Когда вы сдаёте одежду в химчистку, подтвердить тот факт, что вы вообще кому-то что-то отдавали можно только с помощью квитанции. Квитанция используется в авиации и у военных, многие из нас слышали в фильмах или играх “Roger that” = “Вас понял”. Это всё — о квитанции и это та форма обратной связи, без которой управлять процессами нормально не получится.

Отсутствие такой обратной связи порождает эффект “болота” и является благодатной почвой для развития “синдрома студента”. 

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

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

Ведь если вы никогда не просили вам отвечать, этого могут никогда и не начать делать. Даже если прочитали.

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

Эскалация

Эскалация — это повышение приоритета у обращения.

Эскалация бывает двух видов:

1. Горизонтальная

2. Вертикальная

Горизонтальная эскалация — меняет канал связи на тот, у которого более высокий отклик:

• Написали коллеге в почте, но через пару часов нет ответа, а ответ аффектит выполнение важной задачи? Используйте чат. 

• Через час нет ответа в чате? Позвони по телефону или сходите в другой отдел ножками.

Вертикальная эскалация — меняет ответственного:

• Написал разработчику другой команды, но он некомпетентен или затягивает с ответом? Напишите его лиду.

• Лид не отвечает? Используйте контакты аккаунта или технического директора.

• И так по цепочке, пока вопрос не эскалируется на того, кто в состоянии повлиять на сложившуюся ситуацию.

Виды эскалации легко комбинируются между собой, думаю, это очевидно.

Но самое главное — умение грамотно использовать эскалацию настраивает всех участников процесса на оперативную отдачу информации, поскольку достаточно быстро сложится понимание, что вы всё равно добьётесь ответа. Так ли нужно для этого ждать, чтобы позвонили “сверху”? 

Кстати, на самом деле, “сверху” вам будут благодарны, поскольку станет понятно, что вы хотите быстро и эффективно решать поставленные перед вами задачи. Почему бы не помочь?

Заключение

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

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

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

Если есть желание, можете поделиться, что вы используете при выстраивании коммуникации на проекте?