Классическая схема SDLC выглядит как чистый конвейер: требования → проектирование → разработка → тестирование → деплой → поддержка. На слайдах работает. В команде из одного-двух разработчиков — почти никогда.
Причина не в том, что в малой команде «нет времени на процессы». Причина в том, что в большой команде ошибки на стыках этапов ловит кто-то другой: PM спрашивает «а ТЗ финальное?», тестировщик не пускает фичу без сценариев, тимлид ревьюит архитектуру. В команде из двух человек этих ловушек нет — и любое нарушение порядка идёт прямо в продакшн.
Поэтому стандартный SDLC малой команде нужен не меньше, а больше. Только реализация другая.
Что говорят про этапы
В разных источниках формулировки немного отличаются, но костяк сходится. AWS перечисляет планирование, проектирование, разработку, тестирование, деплой и поддержку. Atlassian добавляет анализ как отдельную фазу до проектирования. GitHub в своём guide описывает то же самое чуть иначе — но логика везде одна: сначала разбираемся, что делаем, потом как, потом делаем, потом проверяем.
Что меняется в малой команде — не сами этапы, а их вес. У стартапа из двух человек нет ресурса на отдельного бизнес-аналитика, отдельного дизайнера и отдельного QA. Эти роли никуда не деваются — их выполняют те же два человека, просто переключаясь между ними. И главная ошибка — считать, что раз ролей нет физически, то и стадий можно не разделять.
Где обычно ломается
В гайде по SDLC для малых команд автор формулирует это так: «малые команды проваливают SDLC не потому, что неопытны, а потому что копируют процессы больших компаний или вовсе отказываются от структуры». Боковые эффекты предсказуемы: кодирование, тестирование и деплой происходят одновременно, нет буфера на проверку, скрытые баги уходят в прод.
Типичные сценарии срыва процесса в малой команде:
Этапы перепрыгиваются. Вёрстка появляется до того, как утверждено ТЗ. Код пишется до того, как продумана архитектура. Релиз происходит до того, как кто-то прошёл сценарии тестирования. Это не «гибкость» и не «agile» — это технический долг, который копится молча.
Требования не замораживаются. ТЗ правится в любой момент: пока разработчик его читает, пока проектирует, пока пишет код, пока тестирует. У задачи нет фиксированной версии, относительно которой её делают.
Роли «что» и «как» путаются. Продакт пишет в задаче «использовать такую-то библиотеку» или «поменять параметры модели вот так». Разработчик объясняет, почему так нельзя, — и тратит на это больше времени, чем сама работа заняла бы.
Тестирование делает прод. Dev-окружение есть, но как площадка для систематической проверки не используется. Роль тестового стенда фактически выполняют пользователи.
Scope creep — главный убийца малых проектов
По данным Project Management Institute, около 52% проектов страдают от расползания требований. В малой команде эта цифра, очевидно, выше — потому что некому сказать «нет».
Сам механизм описал Asana в своём руководстве: «Представьте: вы работаете над проектом. Внезапно приходит просьба добавить ещё одну задачу. Она не была в исходном плане, но кажется несложной — и вы соглашаетесь. Через пару дней приходит новое письмо. И вдруг проект, вместо того чтобы двигаться по графику, отстаёт и проваливается».
В малой команде между «у меня появилась мысль» и «разработчик это делает» нет ступени осмысления. Мысль становится задачей мгновенно — с кратким заголовком, без типа, с ТЗ, разбросанным по гуглдокам, Notion и комментариям. Через месяц никто не помнит, на чём договорились.
Заморозка требований — нюансы
Очевидное решение — заморозить ТЗ после утверждения. Не всё так просто. TechTarget пишет, что жёсткая заморозка обычно ошибочна — «бизнес-потребности почти всегда побеждают над удобством команды разработки». Реальность бьёт по любой попытке зафиксировать требования намертво.
Но это аргумент не против заморозки как таковой, а против заморозки без процесса изменений. PPM Express формулирует подход через «scope freeze points» — точки заморозки, после которых изменения не запрещены, но требуют отдельной процедуры: оценки влияния на сроки, бюджет и архитектуру.
Для малой команды это работает так: после утверждения ТЗ разработчик строит по конкретной зафиксированной версии. Хочется изменить требование — это не правка в описании задачи, а новая задача или явный возврат текущей на новый круг с переоценкой. Не «по-тихому дописал в описание — а ты как-нибудь подхвати».
Без этого правила малая команда тонет в переделках. Разработчик начинает реализацию по одной версии ТЗ, версия меняется под ним, часть уже сделанной работы оказывается сделанной «не так». Проектирование, особенно влияние на смежные системы, надо делать заново.
Разграничение «что» и «как»
Скрам-гайд проводит чёткую границу: продакт отвечает за «что» и «зачем» — приоритеты бэклога, критерии приёмки, потребности пользователя. Команда разработки — за «как»: технический подход, архитектура, выбор инструментов.
В малой команде, где один человек часто совмещает обе роли, граница размывается. Это неизбежно — и одновременно опасно. Опасно потому, что «как» требует держать в голове весь проект целиком: архитектуру, стек, все кейсы, циклы разработки от макета до деплоя. Это не вопрос доверия — это вопрос когнитивной нагрузки.
Практическое следствие: технические решения принимает тот, кто понимает их последствия. Параметры моделей, структуру промптов, выбор библиотек, способ интеграции — это зона разработки. Продуктовая постановка («ИИ-инструмент должен также делать X, перестать делать Y») — зона продукта. Между этими двумя зонами не должно быть «продакт правит промпт напрямую, разработчик потом разбирается».
Что работает в малых командах
Универсального рецепта нет. Но есть набор принципов, которые подтверждаются и в исследованиях по lean SDLC, и в практических руководствах:
- Задача ≠ работа. Между «появилась хотелка» и «разработчик над этим работает» есть ступень триажа: тип задачи, источник истины, обязательные поля. Без этого трекер превращается в личный дневник одного человека.
- Один источник истины. Описание задачи — единственный канонический документ. Не три ссылки в начале и десять уточнений в комментариях. Если в обсуждении что-то меняется — правится описание, а не комментарии.
- Этапы по очереди. Вёрстка не уходит в dev отдельно от логики. ТЗ не правится в процессе разработки. На прод не катится то, что не прошло проверку на dev. Перепрыгивание этапов экономит часы здесь и сейчас, чтобы потерять дни через месяц.
- Тест на dev — по сценариям из ТЗ. Не «потыкал минуту наугад», а пройти по списку сценариев, которые должны быть в ТЗ. Если сценариев нет — это не «гибкое ТЗ», это отсутствие критериев приёмки.
- Change control вместо жёсткой заморозки. Изменения требований возможны, но не «на лету». Любая правка после утверждения ТЗ — отдельная задача с оценкой влияния.
Это не бюрократия
Главное возражение против структурирования в малой команде звучит так: «мы маленькие, нам не нужны процессы, мы быстрее без них». Это иллюзия скорости.
Каждое изменение, внесённое в обход этапов, оставляет за собой расхождение: вёрстка не совпадает с логикой, фронт расходится с бэком, поведение новой фичи противоречит поведению старой. Сумма этих расхождений — фоновый шум багов, который виден как нескончаемый поток мелких «исправил вёрстку», «исправил кнопку», «поправил текст». Стратегические работы — рефакторинг крупных контроллеров, тесты на критичные пути, аудит безопасности — откладываются годами.
Разница между «процесс» и «бюрократия» — в том, что бюрократия закрывает несуществующие дыры. Этапы SDLC в малой команде закрывают вполне конкретные: триаж не даёт хотелке мгновенно становиться задачей, утверждение ТЗ не даёт требованиям доуточняться по ходу, проектирование до разработки ловит влияние на смежные системы заранее, а не вскрывает его как баг постфактум.
Малая команда выигрывает не за счёт отказа от процесса. Она выигрывает за счёт того, что процесс минимальный — но соблюдается строго.