2021-07-20 11:04:22
Недавно я писал про участившиеся из-за удаленки случаи параллельной работы на несколько компаний. Эта тема вызвала много живых дискуссий как в комментариях к посту, так и в личке. Поэтому я решил поделиться своими мыслями, что с этим делать и как идентифицировать проблему.
Я сразу пропускаю жестяковые варианты из мира микроменеджмента наподобие «решите сами за разработчика сколько времени ему нужно на задачу» или «грузите всех задачами х2 и некогда будет голову поднять даже». Будем говорить об адекватных вариантах из мира командной работы, где команда сама оценивает свою работу и планирует итерации.
Начнём с наиболее простого способа. Я давно являюсь большим сторонником оценки задач на планировании итерации в идеальных часах с учетом фокус фактора и уровня синьорности конкретного разработчика. Это даёт возможность в конце итерации сравнить реальную работу конкретного человека относительно командных оценок.
Командные оценки лишены якорнинга, поэтому могут неплохо служить базисом для сравнения. Для подсчета потраченного на задачи времени не нужно даже логирования времени в таск менеджмент системе. Достаточно просуммировать командные оценки по доведённым до DONE задачам, сделанным конкретным человеком.
В результате, если предполагалось в плане, что человек сделает задач в итерации на 40 идеальных часов, а он регулярно делает на 20-25, то это отличный повод поговорить. Такой подсчёт не является метрикой, но даёт неплохую диагностику. В результате разбора ситуации вы можете узнать о факторах, замедляющих разработку, неучтенной работе или действительно выявить проблему с недоработкой.
Чтобы дополнить картину, можно использовать статистику контрибьюшена из вашей системы контроля версий, а также статистику прохождения ревью кода. Обычно эти инструменты добавляют полезных диагностических данных к разговору. Например, если синьор девелопер по 2 дня проходит ревью и при этом на нем в это время нет других задач, то это очень странно.
Вторым очень действенным способом является парная работа над задачей. В рамках парной работы гораздо тяжелее отвлекаться на сторонние вещи, а уж на вторую работу подавно. Ну и снова таки, можно на практике увидеть что мешает эффективно работать конкретному человеку. В рамках парных сессий можно выявить реально очень большие проблемы, которые никто открыто нигде не поднимал, даже на ретроспективе.
Ну и последним способом, самым правильным на мой взгляд, является вынесение проблемы на ретроспективу. Но тут нужно быть очень аккуратным. Ведь на ретроспективе нужно избегать обвинений и поиска виноватых, а в незрелой команде в это легко скатиться для такого рода проблем.
Надеюсь, описанные способы натолкнут вас на какие-то полезные мысли и принесут практическую пользу. Напоследок пара советов от капитана очевидность:
- любая работа в итерации должна делаться по задаче в таск менеджмент системе;
- поддержку лучше выделять на ротирующихся дежурных;
- митинги, отпуска, обучение и другие активности нужно учитывать в планировании;
- без адекватного Definition of Done сложно что-то вообще измерять.
1.9K views08:04
X
