Планирование спринта, приоритизация, постановка задач разработчикам, передача в тестирование. В некоторых командах это постоянные этапы жизненного цикла разработки фич. Однако в 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 лет, подумайте над тем, чтобы переосмыслить свой профиль. Это скорее всего приведет вас к большему доходу.

Для стейкхолдеров: нанимайте меньше разработчиков, нанимайте дорогих разработчиков. Это окупается невероятно.

Если вы сами разработчик: вам ближе формат «один дорогой, но автономный», который ведёт фичу от звонка с бизнесом до метрик после релиза, или модель «я пишу код, а остальное — не моя зона ответственности»? Почему?