4 симптома того, что при росте команды вы потеряли производительность
Привет, это Максим Павлов из KTS. Мы создаём IT-продукты для бизнеса.
Рост команды — нормальная ситуация для любого бизнеса. В статье рассказываю, как определить, что во время роста вы потеряли в скорости и как это исправить.
1. У вас один тестовый сервер
Проблема. Тестирование фич на одном сервере может казаться нормальным на первых этапах проекта, когда фичи касаются его разных частей и не противоречат друг другу. Но со временем они начинают наслаиваться и конфликтовать между собой.
Влияние на производительность. Команде приходится тратить время на то, чтобы договориться — кто и когда занимает тестовый сервер и распутывать конфликтующие фичи. Но в какой-то момент из-за большого количества конфликтов сервер просто ломается.
Обычно для решения этой проблемы заводят несколько тестовых серверов — по одному на каждого разработчика. Но в таком случае несколько незарелизенных (незавершенных) фичей одного разработчика все равно могут конфликтовать друг с другом.
Хорошее решение — фича-серверы (динамические окружения). С ними под каждую фичу автоматически создается отдельный адрес, где можно изолированно протестировать копию актуального сервиса с изменениями, которые касаются только конкретной фичи.
Настроить фича-серверы нужно всего один раз. Но по нашим данным, на разных проектах эта настройка может занимать от 4 до 6 месяцев, если команда никогда раньше этого не делала.
А мы — делали, поэтому можем настроить фича-серверы за 2 недели. Пишите нам в телеграм, мы проконсультируем и поможем.
2. Фичи часто переделываются, разработка простаивает
Проблема. Обычно чтобы расширить команду, в неё добавляют разработчиков. Как правило, один проджект-менеджер без помощи может комфортно работать с 5 разработчиками. Если их больше — начинаются проблемы.
Влияние на производительность. Когда в команду приходят новые разработчики, времени у менеджера не становится больше, поэтому в работу идут менее детально описанные задачи. А чем менее детально они описываются, тем в большем количестве задач у разработчиков могут возникнуть разночтения. В итоге увеличивается количество переделок и объем работы менеджера.
Обычно, если в команде нет отдельного тимлида, для помощи менеджеру в бизнес-контекст пытаются погрузить старшего разработчика. А он может, и не хочет развиваться в этом направлении и хочет просто кодить сложные задачи. Итог — демотивация сильных разработчиков.
Хорошее решение — взять в команду аналитика. Он делает так, чтобы реализуемые фичи отвечали запросам стейкхолдеров и минимизирует переделки. А разработчики получают в работу детально поставленные задачи и думают только над их оптимальной реализацией.
Как понять, что менеджеру нужен аналитик я уже подробно рассказывал.
3. Большой процент времени разработки стал тратиться на исправление багов
Проблема. Когда команда небольшая, менеджер успевает и прорабатывать требования, и ставить задачи разработчикам, и проверять качество их реализации. Как только команда увеличивается, времени на все эти активности становится меньше.
Влияние на производительность. Когда времени у менеджера становится меньше и задачи формулируются и тестируются более поверхностно, разработчики пропускают всё больше багов. По итогу разработчикам приходится все больше времени закладывать на их исправление.
Очевидное решение – найм тестировщика. Но его постоянно откладывают из-за срочных релизов, которые занимают все время команды. В итоге, если релиз близко — не остается времени на погружение тестировщика, а после релиза найм как будто не так уж и горит.
Хорошее решение — очевидное, но на него надо решиться. Лучше всего начать процесс найма тестировщика сразу после ближайшего релиза, и вкладывать в это максимум фокуса. Тогда перед следующим релизом тестировщик уже будет что-то тестировать.
4. Дэйли митинг занимает больше получаса
Проблема. Scrum guide говорит о том, что ежедневный митинг должен занимать не больше получаса. Если вы обсуждаете только то, что нужно обсуждать на этом митинге, но все равно выходите за рамки получаса, значит ваша команда слишком большая.
Влияние на производительность. Идеальный размер команды – 5-7 человек. При таком размере позитивный эффект от совместной работы перекрывает дополнительные затраты на коммуникацию. Если вы видите, что при увеличении команды время на коммуникацию ощутимо выросло — этот баланс нарушен.
Обычно команды замечают, что что-то не так, когда статусы переваливают за час. Но разделить команду в такой момент уже слишком сложно.
Хорошее решение. Если уже неделю или две подряд статусы занимают больше получаса, есть смысл задуматься о том, как эффективно разделить одну команду на две независимые.
Итог
При масштабировании команды производительность будет падать, если ничего не предпринимать.
Чтобы удержать скорость команды на хорошем уровне или увеличить: можно развивать процессы, а можно подтянуть инструментальную часть, связанную с ограничениями единого тестового сервера.
Если хотите ускорить разработку за счёт тестирования на независимых серверах под каждую фичу — пишите в телеграм.
Коллеги, как вы классно оформили материал, вау! От этого и полезная информация воспринимается легче и проще.
Спасибо, очень старались:)
Подписывайтесь на телегу, чтобы не пропустить новые серии сериала про японских котов https://t.me/ktsdaily :)
Хотел бы еще добавить, что найма специалистов не достаточно. Можно нанять тестировщика, аналитика, лида и менеджера, но без описанных воспроизводимых процессов команда не начнет работать эффективно и предсказуемо.
Например, не достаточно нанять тестировщика, чтобы уменьшить количество багов. Еще нужно зафиксировать структуру баг-репортов, чек-листов тестирования, прописать ответственность.
Найм аналитика не уменьшит количество итераций переделывания задач, если команда не следует какому-либо стандарта описания требований, и т.д.
Чтобы команда вовремя всё успевала, нужно не только снять с менеджера лишнюю нагрузку, но и бронировать время под планирование с актуализацией оценок и плана, а также делать это планирование прозрачным для всей команды, чтобы обо всех ограничениях и сроках знал каждый участник.
Короче, не только найм, но и процессы важны.
Без дополнительных людей никакое описание процесса не поможет.
Если команда выросла и менеджер не успевает нормально ставить задачи, то даже если будет согласованный чек-лист описания задач, времени на их подробную постановку это не добавит.
Тоже самое и с тестированием - при отсутствии у менеджера времени на подробное тестирование, если задачи не смотрел выделенный тестировщик, их качество будет хуже, чем если он их посмотрел
Статья была не про то, как сделать работу команды более эффективной и предсказуемой, а о том, за счет чего растущие команды теряют в скорости и как это поправить:
— внедрить тестирование в ветках
— нанять тестировщика
— нанять аналитика
— разделиться на подкоманды
Симптомы это хорошо, а как лечить симптоматику?
В каждом симптоме описал, почему такое происходит и как это решить :)
Даже специально жирным выделил "хорошее решение" :))
Добрый, кроме развития процессов и подтягивания инструментальной части, производительность и качество можно существенно улучшить через анализ и развитие профессиональных навыков, выстраивая индивидуальную траекторию корректировки навыков по отклонениям.