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