Планирование спринта, приоритизация, постановка задач разработчикам, передача в тестирование. В некоторых командах это постоянные этапы жизненного цикла разработки фич. Однако в 2025 году конкуренция как между компаниями, так и между разработчиками требует иного подхода.
Нужно ли планировать этапы работ, делать приоритизацию, тестировать фичи? Безусловно да. Должны ли эти этапы быть обязательными в SDLC? На мой взгляд, нет.
Фича, которая занимает квартал и вовлекает 5-6 человек в одной компании, может быть сделана за две недели одним разработчиком в другой. Это не выдумка. Это реальность, которую я наблюдал при смене компаний. И разница в подходах к разработке объясняет эту пропасть в эффективности.
Что не так с текущим подходом
Проблема enterprise-подхода
В некоторых enterprise до сих пор смотрят на разработчиков как на священных коров. И чтобы не заставлять их общаться с бизнесом, который "не знает, что хочет", нанимают специальных людей, которые должны взять на себя эту работу и предоставить хорошо структурированные требования. Далее, после разработки, разработчик передает задачу в тестирование. А как иначе? Мы же не можем тратить драгоценное время разработчика на то, чтобы тыкать кнопки в интерфейсе. Более того, разработчик может уйти в другую компанию, если его что-то не устроит. Кому это надо?
Задача проходит тестирование, часто не с первого раза. Но в итоге доходит до релиза. Все счастливы.
Затем оказывается, что сделано не совсем то, что хотел бизнес. И да, возможно, это вина самого бизнеса — что он неправильно это сформулировал. Кто виноват? В такой системе — аналитик. Для разработчика и тестировщика это не их зона ответственности. Сказали переставить с 2 пути на 3 — переставили.
Время потеряно, ожидаемого бизнес-результата нет. Вся эта цепочка начинается снова. Но не сразу. Ведь уже есть другие задачи в работе. Нужно время. Возможно, доработки следует перенести на следующий квартал, так как в этом квартале уже нет "ресурса разработки".
10-20 лет назад все переходили на agile. Но видимо, перешли не до конца.
Почему это критично
Конечно, описанное выше — это экстремальный случай. Часто разработчики и тестировщики могут поинтересоваться адекватностью требований у аналитика. И даже предложить их изменение. То есть в реальности ситуация не такая тяжелая.
Однако я намеренно привел экстремальный случай, который до сих пор наблюдал в некоторых enterprise-компаниях. Такие компании неизбежно проигрывают конкурентам в гибкости и скорости. Поэтому давайте теперь противопоставим этой ситуации идеальную, на мой взгляд.
Каким должен быть современный разработчик
Ключевые характеристики
Итак, каким должен быть современный разработчик?
Понимает бизнес-область не намного хуже бизнеса.
Интересуется тем, что делают конкуренты
Как продуктом пользуются пользователи
На чем мы зарабатываем
Какие перспективы есть у проекта
30-минутного звонка с заказчиком достаточно, чтобы начать разработку MVP, v0, прототипа.
Для этого ему не нужен аналитик. Он отлично понимает предметную область сам.
Не нужен дизайнер. Дизайн можно поправить в v1.
В ходе беседы он задает важные вопросы. Результатом звонка может быть полное переосмысление того, что изначально хотел сделать заказчик.
Решает, как тестировать свою фичу.
Тратит некоторое время на прохождение базовых user stories e2e вручную.
Покрывает автотестами там, где это целесообразно.
Привлекает дополнительные ресурсы для тестирования, если это необходимо. Причем это не обязательно могут быть тестировщики. Для важных фич можно попросить команду устроить 30-минутный стресс-тест.
После релиза мониторит бизнес-метрики и собирает фидбек от пользователей.
Находится в постоянном контакте с бизнесом и пользователями. Собирает обратную связь через различные каналы: формы обратной связи, звонки с пользователями (где это возможно), анализ бизнес-метрик адаптации фичи. Проактивно спрашивает у пользователей, попробовали ли они новую фичу и какие недостатки видят. Решает совместно с бизнесом, какие оптимальные следующие шаги.
Самостоятельно анонсирует фичу.
Программист берет на себя коммуникацию с пользователями о новых возможностях продукта. Он может записать короткое демо-видео, где покажет, как работает новая функция и какие проблемы она решает. Отправить понятное сообщение в корпоративный чат или создать пост в базе знаний компании. Написать краткую инструкцию для поддержки, чтобы они могли правильно рассказывать пользователям о новинке. Такой подход позволяет донести информацию быстрее и точнее, поскольку разработчик лучше всех знает технические детали и особенности реализации.
Постоянно инициирует новые проекты (bottom-up culture).
В идеале (если это позволяет культура), у него должно быть право самостоятельно принимать решение о приоритетах и возможности начать работу над проектом без апрува бизнеса. При этом он несет ответственность за свое решение — такую же, какую нес бы бизнес.
Почему это выгодно всем
Это идеальный сценарий, который не всегда осуществим. Но к этому сценарию, на мой взгляд, нужно стремиться. Причем всем. Почему?
Разработчик становится действительно полезным и ценным для стейкхолдеров. Для него это означает повышенную компенсацию.
Стейкхолдеры получают гораздо более динамично развивающийся продукт. Команду, в которой вместо испорченного телефона появляется возможность созвониться и обсудить человеческим языком любой аспект бизнеса.
Я также не утверждаю, что в таком подходе неизбежно пропадает необходимость в других ролях. Аналитики и тестировщики могут заниматься стратегическим анализом и долгосрочной надежностью продукта, а не исполнять роль передатчика требований.
Это работает на практике
Реальный опыт: цифры не врут
По собственному опыту, команды, в которых разработчики перестают быть техническими гиками, которые пишут функции и модули, а становятся T-shaped специалистами, в десятки раз эффективнее команд с четким разделением функциональных ролей. Самое интересное, что это НЕ приводит к деградации качества продукта.
В течение своей карьеры разработчика мне иногда доводилось менять компанию. Когда я переходил из компании, где разработчики имеют первый профиль, в компанию с ярко выраженным вторым профилем, я наблюдал фантастическую ситуацию.
Аналогичные фичи в первой компании занимают квартал и вовлекают 5-6 человек. А во второй занимают две недели и вовлекают только одного разработчика.
Это звучит как фантастика. Причем самое забавное, что разработчик второго профиля может стоить всего на 50% дороже разработчика первого профиля. Но за счет более быстрых релизов и отсутствия необходимости вовлекать кучу дополнительных людей, стоимость разработки таких фич сокращается в десятки раз.
Два совета
Из всего вышесказанного вытекают два совета.
Для разработчиков: если вы до сих пор верите, что умение писать код (пускай очень хороший и быстрый код) — это то, за что вы будете востребованы на рынке в следующие 10 лет, подумайте над тем, чтобы переосмыслить свой профиль. Это скорее всего приведет вас к большему доходу.
Для стейкхолдеров: нанимайте меньше разработчиков, нанимайте дорогих разработчиков. Это окупается невероятно.
Если вы сами разработчик: вам ближе формат «один дорогой, но автономный», который ведёт фичу от звонка с бизнесом до метрик после релиза, или модель «я пишу код, а остальное — не моя зона ответственности»? Почему?