Один дорогой разработчик или шесть дешевых: простая математика
Краткое резюме
Крупные компании теряют гибкость и скорость из-за устаревшего подхода к разработке ПО. Современный разработчик должен хорошо понимать бизнес-область и быть более автономным в работе.
В некоторых командах планирование спринта, приоритизация, постановка задач разработчикам и передача в тестирование — это привычные этапы разработки функций. Однако в 2025 году конкуренция между компаниями и разработчиками диктует необходимость нового подхода.
Безусловно, планирование этапов работ, приоритизация и тестирование функций необходимы. Но должны ли эти этапы быть обязательными в жизненном цикле разработки программного обеспечения? На мой взгляд, ответ отрицательный.
Например, функция, на которую в одной компании уходит квартал и которая вовлекает 5–6 человек, в другой может быть выполнена одним разработчиком за две недели. Это не вымысел, а реальность, которую я наблюдал при смене компаний. Разница в подходах к разработке объясняет такое различие в эффективности.
**Проблема enterprise-подхода**
В некоторых крупных компаниях разработчики всё ещё рассматриваются как «священные коровы». Чтобы не заставлять их общаться с бизнесом, нанимают специальных людей для сбора требований. После разработки задача передаётся в тестирование, ведь время разработчика слишком ценно, чтобы тратить его на тестирование интерфейса. Более того, разработчик может уйти в другую компанию, если его что-то не устроит.
Задача проходит тестирование, часто не с первого раза, и доходит до релиза. Все довольны. Но потом выясняется, что сделано не совсем то, что хотел бизнес. В такой системе виноватым оказывается аналитик, а разработчик и тестировщик не несут за это ответственности.
Время потеряно, ожидаемого бизнес-результата нет. Цепочка начинается заново, но не сразу, так как есть другие задачи в работе. Доработки могут перенести на следующий квартал из-за отсутствия «ресурса разработки».
Хотя описанная ситуация — это крайний случай, она всё ещё встречается в некоторых крупных компаниях. Такие компании неизбежно проигрывают конкурентам в гибкости и скорости.
**Каким должен быть современный разработчик?**
Современный разработчик должен:
* понимать бизнес-область не хуже представителей бизнеса;
* интересоваться действиями конкурентов;
* знать, как пользователи пользуются продуктом;
* понимать, на чём компания зарабатывает;
* видеть перспективы проекта.
Тридцатиминутного звонка с заказчиком достаточно, чтобы начать разработку минимально жизнеспособного продукта, версии 0 или прототипа. Для этого разработчику не нужен аналитик.