Специалисты, поработавшие много лет в IT, иногда чем-то напоминают людей преклонного возраста, которые встретившись, начинают рассказывать о наболевшем.
Так произошло и со мной, когда встретился со своим другом, работающим в IT уже с десяток лет. Мы незаметно и довольно стремительно переключились на обсуждение болячек связанных с работой. И очень быстро нашли точки соприкосновения по одной мучительной боли:
рабочие чаты.
Симптомы
Большая часть болевых симптомов у нас сошлись буквально 1 в 1:
Огромное число чатов
Общий на проект, чаты различных встреч, почти у каждой проблемы/задачи/рабочего вопроса свой чат, чаты с вопросами в личку от коллег, не говоря уже про чаты компании, стрима, профильного направления, флудилка и т.п.Постоянные и частые переключения между обсуждениями в чатах
Бесконечный поток прилетающих уведомлений и самое грустное, что до почтения сообщения у тебя полное отсутствие понимания: нужен ли ты сейчас в обсуждении или нет? А частые переключения внимания не позволяют глубоко погрузиться в решаемую тобой задачу.Неструктурированная переписка
Поток обмена информации в чате очень неструктурированный и сильно зашумлённый из-за неточности передаваемых данных в виде коротких, как правило, односложных и написанных на скорую руку сообщений. Более того, в чате могут одновременно обсуждаться несколько тем. Тема может начаться в одном чате, а затем продолжиться в другом.
Культура общения
Чат зачастую воспринимается, как неформальный способ общения, что накладывает определённую манеру общения. А закрытость переписки и добродушие коллег провоцирует некоторых сотрудников эксплуатировать этот механизм для решения своих задач. Такие сотрудники начинают делегировать свои задачи коллегам через чат как пресловутому ИИ.
И мы сошлись на том, что:
Переписка в чатах сжирает огромное количество рабочего времени.
Постоянно приходится отвлекаться и быстро переключаться между обсуждениями, поэтому вникнуть основательно в свою рабочую задачу не получается - тебя постоянно вытягивают из контекста на обсуждение других вопросов и задач.
Мы выговорились и немного полегчало, хотя это и не решило наших болей. Попрощавшись с другом, я всё ещё думал про них, словно меня задели за живое. Я перебирал проекты, в которых мне довелось поработать и везде, как под копирку, были те же самые болевые ощущения при работе с чатами, везде кроме одного...
И тут я припомнил:
А был же проект, где эти боли удалось победить.
Да, это был жаркий проект. У меня в нём от чатов не то что болело - подгорало! Да так сильно, что я рассматривал увольнение - как решение сложившихся проблем на проекте.
Но я остался и нашёл решение.
Все изменения не от хорошей жизни
На тот проект я пришёл в роли разработчика и несколько лет жил довольно беззаботной жизнью типичного исполнителя. Но вскоре моя проектная жизнь заиграла новыми красками, когда руководитель по разработке ушёл и вместо него назначили меня, как самого опытного разработчика на проекте.
Мне сразу прилетел целый ворох новых обязанностей и задач, но при этом остались задачи на разработку, хоть уже и не в таком объёме как раньше. И первые несколько месяцев всё было очень даже неплохо. Я с энтузиазмом перенимал дела и погружался в новую рабочую деятельность на проекте, пока не стал замечать:
Я катастрофически не успеваю делать свои задачи, как по руководству разработкой, так и задачи на сам коддинг.
При этом я буквально ни секунды не сидел без дела, постоянно находился в рабочем моменте, лишь отвлекаясь ненадолго по естественным нуждам: в туалет, заварить чаю и на обед.
Под давлением внутренней ответственности за свою работу и работу в целом на проекте я стал перерабатывать.
Сначала сократил свой обед, буквально до 5-10 минут, чтобы только проглотить еду и потом снова окунуться в рабочий круговорот. Потом стал задерживаться на работе и сидел до позднего вечера. И только тогда, хоть как-то, со скрипом, я стал справляться со своими рабочими задачами.
В таком режиме я проработал где-то с полгода ровно до одного случая:
Вечер, около 9. Я ещё в офисе, работаю. Звонок на мобильный. Абонент: папа. Снимаю трубку.
Я: Алло.
П: Алло. Привет.
Я: Привет.
П: У тебя всё нормально?
Я: (я заволновался после такого вопроса) Да-а. А что?
П: Ты помнишь, что у Катьки (прим. автора: моя сестра) сегодня день рождения?
Я: (меня как холодной водой окатило "Блин, забыл поздравить! А собирался же в обед позвонить!") Заработался и забыл поздравить.
П: Мы сейчас сидим за праздничным столом. Передаю ей трубку.Я скомкано поздравил любимую сестрёнку и больше извинялся, что меня пришлось вызванивать ради поздравлений. На этом звонок закончился.
Я как сейчас помню, жутко раздосадованный сел в рабочее кресло и осмотрел пустой open space офиса, а в голове только и крутилось:
- Как я мог забыть?! Если б папа не позвонил...
А затем ко мне пришло осознание:
Я уже 12 часов как на работе.
И хочется кушать... обед был уже 7 часов назад.
Силы резко меня покинули. Я тяжело выдохнул и понял, что на сегодня с работой - всё, поэтому просто заблокировал компьютер, оделся и поехал домой.
Так причём здесь чаты?
Ещё немного терпения, как раз к ним подошли вплотную.
После того случая, я понял, что вот так упахиваться, да ещё и за бесплатно - это прям вообще того не стоит. Внимание к близким людям, хорошие отношение с семьёй, здоровье - значительно дороже любой внеурочной работы.
Я начал с этим бороться: стараться уходить вовремя.
Уходить вовремя оказалось не так сложно, но моя работа снова стала накапливаться, и я задумался о том, что руководить - это не моё, ведь когда работал обычным разработчиком - у меня не было проблем, я прекрасно справлялся со своими трудовыми обязанностями. И под давлением таких размышлений передо мной встала дилемма:
Что лучше:
признаться своему руководителю, что не тяну
или просто уволиться, уйти в другую компанию на позицию обычного разработчика?
Я никак не мог решить, как поступить: мне нравился проект, ребята на нём и уходить прям совсем не хотелось, но и признаться в некомпетентности перед руководством морально было тяжело да и желания не было.
Я нашёл такой выход из этой дилеммы:
Это просто очередная задача, которую просто надо решить.
И эта "просто задача" настолько заняла меня, что я постоянно про неё думал в т��м числе до/после работы и даже на выходных. И никак не мог понять - почему я не успеваю. Ведь я буквально упахиваюсь на работе так, что вечером еле волочу ноги домой, хотя моя работа целиком состоит из умственного труда.
И тогда я не придумал ничего лучше, чем просто логировать, то чем занимаюсь в течении рабочего дня.
Примечание
Именно тогда зародилась моя профессиональная привычка: логировать свои действия на работе. Она до сих пор сопровождает меня и помогает в работе.
Через две недели логирования я провёл свой первый анализ лога и результат меня ошеломил:
ежедневно от 4 до 6,5 часов рабочего времени я трачу на коммуникации с коллегами.
порядка 30 минут в день уходит на естественные нужды (сбегать в туалет, заварить чаю/налить воды из кулера)
непосредственно на мои рабочие задачи уходит от 1 до 3,5 часов в день максимум
И вот что получается:
На планировании своих задач я исходил, что буду посвящать им весь свой 8-ми часов день, но по факту получалось от 1 до 3,5 часов день.
После этого мне стало понятно, почему я патологически не успевал делать свои задачи. И оказалось, что большую часть своего рабочего времени я трачу...
...на коммуникации с коллегами.
Беспорядочные коммуникационные связи
После того как увидел на что тратится моё рабочее время, я в первый раз обратил внимание на следующие процессы проекта:
количество информационных магистралей на проекте, их направления и скорость обмена информацией.
Например:
В нескольких общих чатах проекта ведётся не прекращающая переписка (от 2-3 до 10) людей, при чём в одном чате обсуждается сразу несколько тем с разным составом участников
Были чатики с ограниченным числом лиц по какой-то определённой проблеме/задаче
Был чатик отдела по направлениям
Много коллег писали прям в личку, причём могли писать по нескольким вопросам сразу и начиналась такая же перекрёстная переписка по нескольким темам, как в общем чатике, только в меньшем масштабе
Была ещё корпоративная почта, в неё писали в основном руководители и изредка менеджеры.
Была ещё переписка в комментариях в задачах, которой в основном пользовались менеджеры проекта.
И это только переписка!
Не говоря уже про живые встречи по проекту (планинги, дейлики и т.п.)
И посмотрев на информационные магистрали, я осознал, что на проекте царил настоящий информационный хаос, сплошные беспорядочные коммуникационные связи.
Например
Информационный поток обсуждения может прерваться в одном чате, а затем может начаться в другом чате, перекочевать из чата в комментарий в задаче, а затем снова продолжиться в чате, из обсуждения в чате может возникнуть письмо на электронную почту, которое потом закончится ответом в задаче и затем продолжится, как обсуждение в чате.
Поэтому постоянно приходится держать в голове где и с кем ты обсуждал тот или иной вопрос. И основное обсуждение по проекту было...
...в корпоративном мессенджере.
Поиск решения
Думая над тем, как уменьшить количество коммуникаций, я решил сделать классификацию своего общения. И оказалось, что от 70% до 90% моё общение с коллегами состояло из консультаций. Другими словами, люди приходят ко мне за помощью, советом, кивком "да, давайте так и сделаем" и т.п.
Одна из стратегий, которые делают в таких ситуациях - это стараться отмахиваться и соскальзывать с обсуждений везде, где только можно. Но мне, как руководителю разработки, такой вариант не подходил. И я ничего не нашёл лучше, чем взять свои логи и пойти с ними к моему руководителю.
Послушав мою боль, посмотрев логи - он на удивление сказал, что знаком с такой проблемой, ведь когда-то он был на моём месте и все писали, ходили к нему. А затем поблагодарил, что я развил такую экспертизу по проекту и получил доверие коллег, что теперь все стали ходить ко мне вместо него. С одной стороны было приятно услышать такое, но с другой - легче мне не стало. Но я получил самое главное - зелёный свет и проектное время на решение этой проблемы.
Так я стал искать решение.
Конечно, сейчас, когда я знаю решение, оно кажется мне таким очевидным и логичным, но тогда, решение нашлось далеко не сразу и мне пришлось перебрать много вариантов:
Написание документации, чтобы делегировать вопросы по функционалу ей.
Воспитание культуры общения.
Мы повесили в отделе обучающие плакаты с описанием, как обращаться с вопросом к коллеге, про ценность своего и чужого времени.Готовили лекции и проводили обучение коллег в отделе по продукту и его функционалу.
Формировали группу по проекту, которые отвечали на вопросы, чтобы хоть как-то разгрузить меня.
Даже думали вводить часы для консультаций, но отказались, так как было опасение, что это негативно скажется на работе, отношениях в коллективе и культуре общения в целом.
И в общем, из перепробованного ничего толком не помогло:
Документация - отвечала на одни вопросы, но порождала новые, плюс требовала постоянной доработки и актуализации
От плакатов получили не тот эффект, на который был расчёт. Появилась осторожность в обращении коллег, словно им приходилось делать что-то нелегальное просто обратившись к коллеге за помощью.
Подготовка и проведение лекций - занимало много времени и сил, а эффект был минимальный: у коллег возникало общее понимание, но в реальных кейсах всё равно оставалось куча вопросов.
Формирование групп-консультантов - это как горизонтальное масштабирование, но в отличии от сервисов, которые представляют собой клоны одного и тоже приложения, в группу входили разного погружения в проект люди. И всё сводилось к тому, что они либо просто, как прокси, ходили ко мне с вопросами, либо сами искали ответ, но тогда сильно просаживалась производительность по их рабочим задачам.
Решение
По всем пришедшим мне в голову решениям, я везде потерпел фиаско. Пришло отчаяние: неужели так и придётся с этим жить на проекте? И как ни странно, в этом отчаянии, уже в порядке бреда, ко мне пришла идея:
А что если перенести всё общение в issue-трекер и вести переписку в комментариях в рамках тикета (задачи).
На первый взгляд, она принципиально ничего не меняла - такое же асинхронное общение, только в комментариях в задаче. Но есть пару "но", которые я заметил, когда общался в issue-трекере с менеджерами и изредка с сотрудниками тех.поддержки и тестировщиками:
Люди в комментариях общаются по-другому чем в чате: они пишут более обстоятельно, структурировано. В то время как в чатах, люди пишут значительно менее структурировано, быстро и часто, буквально по любому поводу.
В issue-трекере обсуждение сразу идёт в чётко очерченом контексте - тикете (задаче), которая автоматически формирует отдельный поток обсуждения. И эти потоки не пересекаются между собой в отличии от чата.
Потоки обсуждения можно линковать друг с другом, а ни в одном мессенджере я не видел подобных фич.
Тебя нельзя добавить в обсуждение в задачу, как это происходит в чате, поэтому позвать тебя "на всякий случай" уже не получится. Но можно обратиться в комментарии к человеку, когда его участие действительно потребуется.
Тебе не надо выискивать историю обсуждений среди кучи других сообщений, как это происходит в чате. В комментариях к задаче только комментарии относящие к задаче.
Обсуждения в задаче остаются видны всем, даже тем кто не участвовал в них и тем, кто ещё в будущем только придёт на проект. И это правило распространяется на все задачи автоматически. В чате доступ к истории может предоставить тебе только участник чата с соответствующими правами.
В общем, эта идея показалась мне светлым лучиком света, за который я ухватился, как за спасительную соломенку, и радостный понёсся с ней к своему руководителю. Столь радикальные изменения в коммуникации проекта он воспринял с большой осторожностью, но всё же вынес мою идею на обсуждение с другими руководителями групп на проекте. Коллеги, довольно скептически отнеслись к ней и накидали мне кучу вопросов и потенциальных подводных камней (часть из них были очень даже по делу). Но я был так воодушевлён и заряжен на осуществление этой идеи (возможно, это уже был последний шанс что-то изменить), поэтому был готов работать с любыми трудностями.
И не буду тянуть, скажу - да, идея действительно сработала!
Результаты
Что было сделано:
Написан bash скрипт, который для пользователя добавлял на почтовый сервер три папки (упомянули меня, подписан, остальное) и правила фильтрации почты, которые раскладывали входящие письма с уведомлениями от issue-трекера в эти папки.
Протестирован скрипт и размещён на общем ресурсе, доступный каждому сотруднику в отделе.
Написана инструкция, как выполнить скрипт (требовалось выполнить единожды)
Составлена таблица со списком всех сотрудников и пометкой выполнен/не выполнен скрипт.
Руководителям групп проекта дано задание проконтролировать выполнение скрипта у подчинённых сотрудников.
Настроены единые уведомления на группу пользователей проекта в issue-трекере
(уведомлять при упоминании, уведомлять при подписке)Разосланы инструкции всем сотрудникам проекта, мотивация изменений и описание изменений в культуре общения по проекте.
Проведена встреча с коллегами по проекту, где ещё раз всё проговорили и объяснили, ответили на вопросы.
Сократили чаты проекта до 3-х:
- Остался общий (для уведомлений, оперативного обсуждения инцидентов на ПРОМе и уточнений в какую задачу перевести обсуждение вопроса),
- Чат уведомлений о выпуске релиза
- Чат уведомлений для MR.В личку писать не запрещается, но если обсуждение вопроса затягивается, то рекомендовалось сотрудникам выводить обсуждение в отдельный тикет (задачу).
Что изменилось:
Мои затраты на общение сократились от 40% до 60%.
Изменилась содержательная часть сообщений, она стала более структурированной и ёмкой.
После изменений, я пришёл к выводу, что чаты воспринимаются "как частная переписка" и "как лёгкий способ решить свои проблемы: достаточно просто спросить". А общение через комментарий в задачу, по видимому, воспринимается "как сделать официальный запрос", который нужно обстоятельно и структурировано написать.
Заключение
Чаты, не смотря на свою простоту использования, имеют ряд серьёзных недостатков:
Быстро превращаются в запутанную сеть коммуникационных каналов, что, в конечном итоге, превращаются в беспорядочные коммуникационные связи.
Пользователю требуется читать всю информацию в чате, чтобы классифицировать её и принимать решение о необходимости участия в обсуждении.
Высокая фрагментированность информации в рамках одного обсуждения.
Сложность поиска информации.
Ограниченность доступа к информации для участников проекта.
Общение в чатах воспринимается как неофициальное, личностное общение, что формирует определённую культуру общения с большим количеством коротких сообщений и низкой информационной содержательностью.
Простота, неофициальный стиль общения и закрытость переписки от других членов проекта может формировать нездоровую привычку у сотрудников эксплуатировать навыки опытных и квалифицированных коллег, по аналогии, как сотрудники сейчас общаются с ИИ чатами.
Отсутствует терминальность обсуждения, т.к. у обсуждения в чате нет статуса. Нельзя закрыть обсуждение в чате поставив резолюцию: решено, не требует решения, на паузе и т.п.
Сотрудник не имеет права самостоятельно определять вступать в чат или нет.
За него этот выбор делают его коллеги, которые могут добавить в чат по любой причине, например, просто "чтобы был на всякий случай".
Как итог я пришёл к заключению:
Если на проекте больше 5 человек, то использование чатов в мессенджере, как основного коммуникационного канала связи весьма неэффективно.
Поэтому как альтернативу рекомендую:
Для команд 5+ использовать комментарии в issue-трекерах, где отдельный тикет (задача) - это новый поток (thread) для обсуждения вопроса/проблемы/задачи на проекте.
Такой подход имеет ряд преимуществ:
Открытость информации для всех участников проекта, как и нынешних, так и будущих.
Автоматическая классификация обсуждения по тикетам (задачам)
У каждого обсуждения автоматически есть статус (done, pause, in process и т.п.) и возможность закрытия обсуждения с резолюцией.
Не требует чтения всей информации и есть возможность подключения только в тот момент, когда твоя помощь действительно понадобится коллегам.
Опыт показал, что люди в комментариях к задаче пишут более структурировано и ёмко нежели в чатах.
Опыт показал, что при общении в комментариях в задаче люди гораздо меньше эксплуатируют опыт и знания коллег для решения своих задач.
Значительно больше возможностей поиска информации нежели в чатах.
Низкая фрагментированность информации в рамках одного обсуждения, возможность связывать (линковать) обсуждения (тикеты) друг с другом.
Детализирует отчёты по логированию рабочего времени, т.к. вместо абстрактной задачи "Общение", сотрудники списывают время в конкретную задачу
