(В оригинале - Scope is the enemy of success)

Границы проекта определяют его размер. Сколько времени, усилий и ресурсов потребуется? Какая функциональность и какого уровня качества? Насколько сложно это будет внедрить? Какой риск? Какие ограничения? Ответы на эти вопросы и определяют границы проекта. Проектировщикам нравятся большие, сложные проекты. Потенциальная награда за сложный проект может подталкивать людей искусственно раздвигать границы проекта для повышения видимой важности. Раздвигание границ – враг проекта, потому что при этом вероятность провала растет быстрее ожидаемого. Увеличение проекта вдвое может повысить вероятность провала на порядок.

Почему это работает именно так? Давайте рассмотрим несколько примеров.

• Интуиция нам подсказывает удвоить время или ресурсы при удвоении объема работы. История же говорит ("The Mythical Man-Month" by Fred Brooks), что зависимость здесь нелинейная. К примеру, команда из четырех человек потратит более чем в два раза времени на коммуникацию, чем команда из двух человек.
• Оценки оказываются далеки от реальности. Кто ни разу не сталкивался с вещами, реализовать которые оказывалось значительно сложнее, чем ожидалось?

Конечно, некоторые проекты невозможно сделать без присущей для них определенной сложности и размера. Сделать текстовый редактор без возможности ввода текста может быть и легко, только результат не будет текстовым редактором. Какие же стратегии могут помочь лучше контролировать границы реальных проектов?

• Понимание реальных потребностей. Проект должен содержать то, что перечислено в требованиях. Требования определяют функциональность и ее качество. Если требование не объяснено в терминах измеряемой ценности для заказчика, то это повод задавать вопросы. Если требование не приносит заказчику прибыли, зачем оно вообще нужно?
• Разделяй и властвуй. Ищите возможности разделить проект на несколько независимых частей. Гораздо легче управлять несколькими маленькими проектами, чем одним большим.
• Приоритет. Мир бизнеса изменчивый. Требования к большому проекту могут поменяться несколько ко времени его окончания. Важные требования обычно остаются важными и при изменении в мире бизнеса, а остальные могут измениться или даже совсем исчезнуть. Приоритизация позволит вам выпустить наиболее важные вещи в первом релизе.
• Выпуск результата как можно ранее. Очень мало людей точно знают, что именно они хотят до того, как это получат. Наверняка вы видели известную картинку, показывающую эволюцию проекта детских качелей, и помните разницу между тем, что хотел заказчик, и что было сделано реально. Переусложненный результат напоминал качели очень отдаленно, а последний кадр «что на самом деле хотел заказчик» показывает самую простую качелю из старой автомобильной шины. Если заказчик получит возможность что-то попробовать, решение может оказаться сильно проще первоначально ожидаемого. Реализация наиболее важных вещей в первую очередь даст вам важную обратную связь раньше, когда она вам больше всего и нужна.

Сторонники agile разработки ("eXtreme Programming eXplained" by Kent Beck) советуют реализовывать «самый простой вариант, который еще работает». Сложная архитектура проваливается значительно чаще, чем простая. Уменьшение границ проекта часто приводит к более простой архитектуре. Уменьшение границ – одна из эффективных стратегий для архитекта на пути повышения вероятности успеха.

Автор оригинала - Dave Quick