4 симптома того, что при росте команды вы потеряли производительность

Привет, это Максим Павлов из KTS. Мы создаём IT-продукты для бизнеса.

Рост команды — нормальная ситуация для любого бизнеса. В статье рассказываю, как определить, что во время роста вы потеряли в скорости и как это исправить.

1. У вас один тестовый сервер

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

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

Обычно для решения этой проблемы заводят несколько тестовых серверов — по одному на каждого разработчика. Но в таком случае несколько незарелизенных (незавершенных) фичей одного разработчика все равно могут конфликтовать друг с другом.

Хорошее решение — фича-серверы (динамические окружения). С ними под каждую фичу автоматически создается отдельный адрес, где можно изолированно протестировать копию актуального сервиса с изменениями, которые касаются только конкретной фичи.

Настроить фича-серверы нужно всего один раз. Но по нашим данным, на разных проектах эта настройка может занимать от 4 до 6 месяцев, если команда никогда раньше этого не делала.

А мы — делали, поэтому можем настроить фича-серверы за 2 недели. Пишите нам в телеграм, мы проконсультируем и поможем.

2. Фичи часто переделываются, разработка простаивает

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

Проблема. Обычно чтобы расширить команду, в неё добавляют разработчиков. Как правило, один проджект-менеджер без помощи может комфортно работать с 5 разработчиками. Если их больше — начинаются проблемы.

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

Обычно, если в команде нет отдельного тимлида, для помощи менеджеру в бизнес-контекст пытаются погрузить старшего разработчика. А он может, и не хочет развиваться в этом направлении и хочет просто кодить сложные задачи. Итог — демотивация сильных разработчиков.

Хорошее решение — взять в команду аналитика. Он делает так, чтобы реализуемые фичи отвечали запросам стейкхолдеров и минимизирует переделки. А разработчики получают в работу детально поставленные задачи и думают только над их оптимальной реализацией.

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

3. Большой процент времени разработки стал тратиться на исправление багов

Большая часть команды занимается починкой сломавшегося, а не внедрением нового

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

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

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

Хорошее решение — очевидное, но на него надо решиться. Лучше всего начать процесс найма тестировщика сразу после ближайшего релиза, и вкладывать в это максимум фокуса. Тогда перед следующим релизом тестировщик уже будет что-то тестировать.

4. Дэйли митинг занимает больше получаса

На дейлике как обычно собралась толпа, общаются двое, остальные скучают

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

Влияние на производительность. Идеальный размер команды – 5-7 человек. При таком размере позитивный эффект от совместной работы перекрывает дополнительные затраты на коммуникацию. Если вы видите, что при увеличении команды время на коммуникацию ощутимо выросло — этот баланс нарушен.

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

Хорошее решение. Если уже неделю или две подряд статусы занимают больше получаса, есть смысл задуматься о том, как эффективно разделить одну команду на две независимые.

Итог

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

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

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