Дейли не нужны в распределенной команде

Дейли не нужны в распределенной команде

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

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

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

Дейли помогает синхронизироваться команде

"Синхронизация" не может быть целью, это инструмент. Полезный тогда, когда нужно заставить двух разработчиков делать одно дело в одно время (хронос - поняли, да?). Например, когда у вас лежит прод, и команда из QA, бэка и фронта пытается разобраться, в чем дело прямо сейчас, им нужна синхронизация. Если вы откатили сломанную версию и расследуете инцидент, вам не нужна синхронизация. Грубо говоря, синхронизация помогает тушить пожары, но если вся ваша работа строится вокруг них, то стоит найти источник возникновения проблем, а не бегать с огнетушителем каждый день.

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

Подсвечивает проблемы и помогает команде помочь их решить

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

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

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

Почему это работало в офисе?

Давайте представим, что мы все еще в офисе и у нас возник вопрос к другой команде. Для его решения мы должны:

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

Почему это бессмысленно на удаленке?

Мы говорим про распределенные команды, где все сотрудники общаются в чатах и почте, т.е. асинхронно:

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

Ежедневные блокеры - это ненормально

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

Позволяет контролировать ход выполнения задачи

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

Чем "сеньернее" разработчик, тем более красивые сказки он может придумывать в конце спринта: "я дописываю тесты...", "ревью долго шло", "было много общения в чатах", "в требованиях не учли, что..." – знакомо? И этот же человек каждый дейли исправно рапортировал: "блокеров нет, апдейтов нет. Иду по доске!".

Из этого получается забавный парадокс: дейли задумывается как контроль тех, кто избегает работы, но единственное средство контроля - это их честность, при этом честные исполнители могут работать без контроля.

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

Поддерживает дисциплину в команде

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

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

К тому же, работая в распределенной команда, может так оказаться, что ваша команда работает в разных часовых поясах. Тогда дисциплина выглядит еще смешнее - для одного дейли начинается в 10 утра, для второго в 6 утра, для третьего в 14 часов дня. Где же тут поддержка темпа работы?

Вместо того, чтобы говорить команде, КАК работать, попробуйте научиться говорить, ЧТО вы от нее ждете. Ставьте измеримые цели, давайте людям контекст, объясняйте ценность достижения цели для проекта. Попробуйте изменить в голове отношение к работе с "я продаю свое время" на "я продаю результат своей работы". Прочитайте про results-only work environment.

Хоть какое-то общение распределенной команды

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

Общение в команде - это важно, поэтому вместо того, чтобы делать вид, что вы решили проблему дейликом, попробуйте подумать, как решить проблему по-настоящему. К счастью, практик для социализации сотрудников полно: устройте random coffee, организуйте встречи в течении дня, на которой люди просто общаются, или соберите митап для шаринга знаний.

Без дейли разработчик будет видеть только свои 5 задач и не знать, что происходит в компании

Если дейли - единственный способ узнать новости компании, то вы в первобытном обществе. Письменность еще не изобретена, и все знания передаются из "уст в уста" на созвонах. Это допустимо для стартапа в 5 человек, но смертельно для крупной компании.

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

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

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

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

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

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

Это всего лишь 15 минут, тебе сложно что ли?

Предлагаю перенести дейли на 2 часа ночи. 15 минут. Сложно что ли?

Так что ты предлагаешь?

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

После перехода на текстовые дейли тебе придется:

Команда привыкла к подбиванию статуса текстом? Пора переходить к отмене этой традиции. На этом этапе будет нужно:

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

Главное - не забывать, что теперь начинается самая сложная работа лида, которую ты никак не автоматизируешь: научить команду быть самостоятельной, а себя отучить от чайка-менеджмента. Но все вложенные усилия окупятся возможностью работать в своем темпе.