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

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

Откуда недовольство?

Люди, работающие в IT, очень горды сферой своей деятельности, ведь она, эта сфера – уникальная. Свободная, творческая, это мир без диктата и запретов, мир, где возможно всё. И именно они, то есть айтишники, решают, каким будет этот мир.

Однако, если мы посмотрим на любую другую сферу деятельности человека, то увидим там примерно то же самое. Отлично подходит автомобильная сфера – когда она только развивалась, автомобилей было немного, без преувеличения каждый автомобиль был уникальным, обслуживать и ремонтировать автомобили мало кто умел, а проектировать и подавно. И каждый из этих людей не просто считал, он физически ощущал, что автосфера – уникальна, Свободная, творческая, это мир без диктата и запретов…ну и так далее. Знакомые буковки?

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

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

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

Именно этого не могут понять современные айтишники. Сфера, еще недавно бывшая совершенно новой, развивается, наблюдается всё большее разделение труда, выделение узких специалистов. За условный «hello world» уже никто не платит, проекты сильно усложнились, на наших глазах вырабатываются типовые методы решения повторяющихся организационных и технических задач. Создаются платформы для конкретных видов деятельности. Соответственно, возникает проблема координации большого количества участников процесса, отсюда и созвоны. Как раньше, когда программист получал задачу от бизнеса, полгода в одно лицо делал аналитику, архитектуру, реализацию, тестирование, деплой, багфикс – уже не будет. Время одиночек давно позади, надо принять новую реальность.

Что есть норма, и как определить её?

Для ориентира отсылаю вас к моей давней статье, где я определяю, сколько времени команды уходит на ритуалы SCRUM. Если мой читатель ленив (а он ленив), напомню – на ритуалы уходит 15% времени команды. У кого-то чуть больше, где-то чуть меньше, но примерно так. Это недостижимый минимум, от которого следует отталкиваться.

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

Попробуем набросать карту коммуникаций и классифицировать встречи сотрудников.

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

Теперь можно посмотреть, из чего же состоит это самое общение. Возьмем аналитика, как ключевого персонажа команды:

1. Общение с дизайнером – постановка и приемка задач. Обычно это самые длительные по времени встречи, потому что надо проходить весь дизайн и вносить коррективы. За спринт занимает примерно 6 рабочих часов.

2. Общение с фронт-разработчиком – постановка и приемка задач. Где-то 4 часа за спринт.

3. Общение с бэк-разработчиком – постановка и приемка задач. Где-то 4 часа за спринт.

4. Общение с тестировщиком – приемка и обсуждение результатов тестирования. Где-то 2 часа за спринт.

Подчеркну – тут описано общее время встреч, а не их количество. Вопросов возникает много, но обычно они решаются за 10-15 минут, не более того.

Суммируем и получаем что-то около 16 часов, то есть два рабочих дня за спринт. Это немало, потому что рабочих дней в спринте всего 10, из них 1,5 дня уходит на ритуалы SCRUM, то есть на непосредственную работу остается 6,5 дней из 10 дней спринта. Путем линейной экстраполяции получаем данные по другим участникам команды:

- дизайнер 8 часов встреч за спринт;

- фронт-разработчик 16 часов;

- бэк-разработчик 12 часов;

- тестировщик 12 часов.

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

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

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

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

Что же со всем этим безобразием делать?

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

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

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

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