Много раз сталкивался с жалобами команд разработки на огромное количество онлайн-встреч, совещаний и созвонов в течении рабочего дня. Иногда аналитик, показывая календарь, полностью забитый разного рода подобными активностями, страдающим голосом вопрошал – а работать-то когда? Сегодня попробуем определиться, откуда берутся все эти созвоны, сколько времени на них планировать, и как уменьшить их количество. Поехали.
![Отвечает Елена Малышева Отвечает Елена Малышева](https://habrastorage.org/getpro/habr/upload_files/d3b/aa2/4b6/d3baa24b6d50de2b80828a40e1b0feba.jpg)
Меня зовут Султанов, и я тимлид (тяжелый вздох). Стараюсь ограждать команду от лишних созвонов. Иногда даже получается. А еще у меня есть канал, где можно обсудить эту и другие статьи. Подписывайтесь, там интересно. Наверное.
Откуда недовольство?
Люди, работающие в IT, очень горды сферой своей деятельности, ведь она, эта сфера – уникальная. Свободная, творческая, это мир без диктата и запретов, мир, где возможно всё. И именно они, то есть айтишники, решают, каким будет этот мир.
Однако, если мы посмотрим на любую другую сферу деятельности человека, то увидим там примерно то же самое. Отлично подходит автомобильная сфера – когда она только развивалась, автомобилей было немного, без преувеличения каждый автомобиль был уникальным, обслуживать и ремонтировать автомобили мало кто умел, а проектировать и подавно. И каждый из этих людей не просто считал, он физически ощущал, что автосфера – уникальна, Свободная, творческая, это мир без диктата и запретов…ну и так далее. Знакомые буковки?
Умеющим людям платили огромные деньги, к каждому их слову прислушивались, и быстро исполняли, главное, чтобы результат был. Так как работали знающие люди обычно в одиночку, максимум – имея двух-трех подручных, производственных совещаний у таких людей было немного. Задачу принял – задачу сдал. Человек, покупающий автомобиль, не сдавал никаких экзаменов, просто брал и ехал чаще всего до первого столба.
Но автомобилей становилось всё больше, конструкторские решения – всё сложнее. Появились отдельные люди, рассчитывающие процессы внутри двигателя, отдельные – проектирующие сам автомобиль (кроме двигателя), отдельные – для сборки авто, для испытаний. Появились контролирующие службы. Ну и менеджеры появились, надо же как-то координировать работу всей этой толпы. Даже отдельная профессия эксплуататора транспортного средства – водителя – тоже появилась.
И вот тогда, с увеличением количества людей, вовлеченных в процессы, резко возросло и количество часов, затрачиваемых на координацию, осуществляемую через производственные совещания.
Именно этого не могут понять современные айтишники. Сфера, еще недавно бывшая совершенно новой, развивается, наблюдается всё большее разделение труда, выделение узких специалистов. За условный «hello world» уже никто не платит, проекты сильно усложнились, на наших глазах вырабатываются типовые методы решения повторяющихся организационных и технических задач. Создаются платформы для конкретных видов деятельности. Соответственно, возникает проблема координации большого количества участников процесса, отсюда и созвоны. Как раньше, когда программист получал задачу от бизнеса, полгода в одно лицо делал аналитику, архитектуру, реализацию, тестирование, деплой, багфикс – уже не будет. Время одиночек давно позади, надо принять новую реальность.
Что есть норма, и как определить её?
Для ориентира отсылаю вас к моей давней статье, где я определяю, сколько времени команды уходит на ритуалы SCRUM. Если мой читатель ленив (а он ленив), напомню – на ритуалы уходит 15% времени команды. У кого-то чуть больше, где-то чуть меньше, но примерно так. Это недостижимый минимум, от которого следует отталкиваться.
Далее я возьму свою команду, где есть дизайнер, два аналитика, фронт, 4 бэка и тестеры, и буду считать укрупненно и примерно.
Попробуем набросать карту коммуникаций и классифицировать встречи сотрудников.
![Примерная карта коммуникаций сотрудников в команде Примерная карта коммуникаций сотрудников в команде](https://habrastorage.org/getpro/habr/upload_files/165/102/aaa/165102aaa1416d1d6919950c5df9db72.jpg)
Как видим, большая часть общения приходится на аналитика и фронт-разработчика, несколько меньше общаются бэк-разработчики которые больше всего ноют на созвоны, и тестировщики. Ну и сравнительно мало общения выпадает на дизайнера.
Теперь можно посмотреть, из чего же состоит это самое общение. Возьмем аналитика, как ключевого персонажа команды:
1. Общение с дизайнером – постановка и приемка задач. Обычно это самые длительные по времени встречи, потому что надо проходить весь дизайн и вносить коррективы. За спринт занимает примерно 6 рабочих часов.
2. Общение с фронт-разработчиком – постановка и приемка задач. Где-то 4 часа за спринт.
3. Общение с бэк-разработчиком – постановка и приемка задач. Где-то 4 часа за спринт.
4. Общение с тестировщиком – приемка и обсуждение результатов тестирования. Где-то 2 часа за спринт.
Подчеркну – тут описано общее время встреч, а не их количество. Вопросов возникает много, но обычно они решаются за 10-15 минут, не более того.
Суммируем и получаем что-то около 16 часов, то есть два рабочих дня за спринт. Это немало, потому что рабочих дней в спринте всего 10, из них 1,5 дня уходит на ритуалы SCRUM, то есть на непосредственную работу остается 6,5 дней из 10 дней спринта. Путем линейной экстраполяции получаем данные по другим участникам команды:
- дизайнер 8 часов встреч за спринт;
- фронт-разработчик 16 часов;
- бэк-разработчик 12 часов;
- тестировщик 12 часов.
Постойте, вскрикнет въедливый читатель, эти цифры конечно ужасают, сильно сокращая рабочее время, но это совсем не похоже на целые дни созвонов, на которые вобщем-то члены команды и жалуются, демонстрируя полностью забитый календарь. Как же это получается?
И тут мы переходим к явлению, которое называется «сторонние активности», они указаны сверху на схеме коммуникаций. Стрелочек нет специально, так как этим активностям подвержены абсолютно все члены команды. Делятся на две категории:
- общие созвоны, на которых надо быть в составе большой группы, иногда даже всей компанией (такие очень любят устраивать дирекция и HR, чтобы рассказать всем, как они хорошо поработали). Обычно там надо только слушать, но работать всё равно трудно;
- неформальные просьбы о помощи, консультации, поддержка соседних команд и коллег. Часто превращаются в междусобойчики, на которых люди просто общаются, без всякого результата. Некий аналог курилки на удаленке.
Что же со всем этим безобразием делать?
Если с рабочими встречами ничего не сделать, и уменьшение их как правило приводит к резкому падению качества работы, то с внешними встречами, поедающими куда больше времени, очень даже можно работать, если есть на то воля высшего руководства. А чтобы она у высшего руководства появилась, нужна длительная, продуманная и настойчивая работа тимлида.
С групповыми встречами вобщем-то легко – их нужно записывать и выкладывать в виде роликов. Кому нужно, тот посмотрит, но обычно никому не нужно, что в очередной раз подчеркивает высочайшую ценность таких встреч.
С просьбами о помощи сложнее, но тоже можно работать. Во-первых, такие просьбы должны в обязательном порядке проходить через тимлида. Во-вторых, на встрече обязательно должен присутствовать сильный модератор, чтобы не допустить их скатывания на «общение в курилке». В третьих, обязательно у каждой встречи должен быть зафиксированный результат. А в четвертых, и вобщем-то в главных, нужно систематизировать такую работу через организацию центров компетенций и межкомандного взаимодействия, где каждый может попросить помощи во вполне плановом порядке, и такую помощь получить.
А вот как правильно организовать команды, их взаимодействие и центры компетенций, обсудим в следующей статье.
![Всегда! Всегда!](https://habrastorage.org/getpro/habr/upload_files/f06/78c/bea/f0678cbea999878c33517333b8c5284a.jpg)
TIEugene
"Неправильно ты бутерброд ешь, дядя Федор..."Немного не так.Например я с утра покурил кофе, развернул IDE, отфильтровал багтрекер, спланировал работу на сегодня.
Потом согласно задачам на сегодня просмотрел код и разбил на микрозадачи.
Итого - загрузил "кеш" в моске. Оперативный кеш. Держится только в моске и только сегодня.
_Внезапно_ кому-то захотелось
потарахтетьсозвониться.Если просто "как дела, чо-как, что сделано" - неприятно, но недорого. Cache L1 улетает в Cache L2, восстановление займет покурить 1 кофе.
Если по текущим задачам - ппц. Весь кеш слетает в ноль, По итогам "поговорить" - внести изменения в задачи, пересобачить приоритеты, перепланировать текущий день, перезагрузить моск. Пара часов.
Плюс 10-15 минут, ога.
Trihlorid Автор
Это так, состояние потока нарушается, как раз планировал обсудить порядок таких мелких созвонов в следующей статье.
TIEugene
Там всё просто:
1. Созвоны не нужны. Разработчикам, по крайней мере. Все задачи ставятся в багтрекере и документации.
2. Если источник задачи не может внятно поставить задачу - ок, созвоны нужны. Раз в неделю, пол-часа, не более. Плюс письмо начальству "манагер не смог сформулировать, 2 часа потрачено в никуда".
3. "мелкие созвоны" - ну, я не знаю... "Мелкие созвоны" вышибают разработчика на пол-дня минимум. Какому-то манагеру захотелось потарахтеть - оно позвонило. Потарахтело 10 минут. И как потом доказать, что вышибло пол-дня работы? А никак. "Оно просило" - "не помню такого". Штраф.
4. Среди меня считается, что "созвон" - ни о чем. Потарахтеть можно. Только не долго и не каждый день. Все принятые задачи при созвоне должны быть зафиксированы "на бумаге" - багтрекер/электропочта. Источником беспокойства.
Trihlorid Автор
У всех всегда всё просто. А ошибки в программных продуктах из-за намеренного саботажа:))
TIEugene
Отнюдь.
Начальник: Сколько надо для решить задачу?
Разработчик: Неделя
Н: Почему так долго??? Я это нарисую за 15 минут!
Р: я нарисую за 10. Но:
- тестирование
- dev => stage => prod
- документирование
- выдержка
Н: Ой, всё... 1 день, кароч
Р: как скажете
Да, саботаж. Заказчиком.