Почему скорость команды — это не всегда про людей, а про инфраструктуру
«У нас горят сроки, надо быстрее!»
«Почему вы делаете задачу уже вторую неделю?»
«Давайте подключим ещё одного разработчика — точно ускоримся».
Знакомо? Такие реплики звучат в любой проектной комнате — от стартапа до корпорации.
Но ускорить разработку давлением, криком, количеством людей или ежедневными звонками - невозможно. Это примерно как пытаться заставить бетон застыть от крика быстрее — бессмысленно, а если переусердствовать, то трещины появятся быстрее, чем результат.
Где настоящая скорость?
Разработка ускоряется не усилием, а отсутствием помех. Не когда разработчики бегут быстрее, а когда вокруг них меньше потерь — на согласование, на багфиксы, на ручные действия, на хаос в задачах.
Когда всё предсказуемо, прозрачно и автоматизировано — команда сама становится быстрее, даже если никто не «включал закись азота».
Один из самых частых источников потерь — отсутствие инженерной инфраструктуры. На бумаге может быть agile, трекеры, скрам-доски, но по факту всё разваливается.
Задачи могут быть где угодно — в Notion, в Slack, в Figma, в голове у проджекта и на стикерах рядом с ноутбуком.
Сборки делаются вручную на чьём-то локальном ноуте. CI/CD — в мечтах. Автотестов нет, архитектура пишется «как получится», ревью — формальность.
И, конечно, всё держится на «Олеге», который помнит, как деплоить через SCP и кто в прошлый раз фиксил продакшен баг.
Что работает по-настоящему
Реальное ускорение — это простая инженерная зрелость.
Когда все задачи находятся в одном месте и имеют внятные статусы. Когда есть CI/CD, и любая фича после пуша оказывается на стенде за пару минут. Когда автоматизированы тесты, деплой, и все вспомогательные процессы, и никто не держит в голове «секретные шаги». Когда есть архитектурные стандарты, и каждый новый разработчик понимает, что и как писать. Когда код-ревью не «на глаз», а по чеклисту и с пониманием ответственности.
Вот тут и появляется скорость — без натяжки, без перегруза. Просто потому, что не тратится время на мусор и ручной труд.
Один кейс
Давненько мы участвовали в проекте для крупной организации. На этапе проектирования не заложили нормального CI/CD. В результате деплой выглядел так: разработчик собирал Docker-образ локально, архивировал его, закидывал по SCP на сервер, распаковывал и разворачивал руками.
Из-за тяжёлых образов весь процесс занимал 10–20 минут. Любая мелочь — и фигачишь заново.
Вся команда занималась не фичами, а борьбой с этой инфраструктурой. В итоге срок проекта сдвинулся на три месяца. Не из-за недоработок, а потому что в самом начале все торопились, и на «инженерное» решили забить. (Почему нельзя было настроить в ходе проекта? Та хрен его знает, я тогда был разработчиком, и это был второстепенный проект у меня. Видимо на проект просто не стали тратить ресурсы)
Скорость в разработке — это не про то, как быстро вы написали фичу.
Это про то, как быстро вы смогли её собрать, протестировать, выкатить и убедиться, что всё работает.
И если на каждом шаге приходится сражаться с бардаком — никакая команда не справится быстро, сколько бы человек туда ни добавили.
(количество людей ≠ скорость)
Разработка ускоряется не когда вы просите «быстрее». А когда вы позволяете людям не отвлекаться от главного.
Если вам близки такие разборы — я делюсь кейсами в Telegram‑канале «Техдир на пальцах»: без кода, без рекламы фреймворков — только практические ошибки и выводы из них.
