Неправильное понимание требований
Надлежащее планирование сводит к минимуму также роль одного из самых больших источников ошибок при разработке: расползание свойств. Расползание свойств — добавление первоначально не запланированных свойств — это признак слабого планирования и неадекватного сбора требований. Добавление полученных в последнюю минуту свойств (в ответ ли на давление конкурентов или по прихоти управленцев) вызывает больше ошибок в программном обеспечении, чем что-то еще.
Разработка программного обеспечения — это бизнес, в высшей степени ориентированный на детали. Чем больше деталей обсуждается и принимается перед началом кодирования, тем меньше возможностей приходится на долю случая. Необходимо планировать промежуточные отчеты и реализации проекта. Конечно, это не означает, что сопроводительная документация должна занимать тысячи страниц.
Одним из лучших проектных документов, которые я когда-либо создавал, был просто ряд бумажных рисунков или "бумажных прототипов" интерфейса пользователя. При этом мы полностью проработали каждый сценарий пользователя, сосредоточились на требованиях для продукта и подробно выяснили, как пользователи собирались выполнять свои задачи. В конце работы мы знали точно, что мы собирались поставлять и, что более важно, это знал каждый работник компании. Если возникали сомнения по поводу того, что именно происходит в данном сценарии, мы извлекали бумажные прототипы и прорабатывали сценарий снова.
В любом случае, для того чтобы реализовать должным образом свои продукты, необходимо действительно понять требования к ним. В одной компании, где я работал (к счастью, меньше года), требования к продукту казались очень простыми и прямолинейными. Однако оказалось, что большинство членов команды не достаточно хорошо понимало, что именно заказчики ожидали от готового приложения. Компания сделала классическую ошибку, решительно увеличив количество инженеров, но без достаточного обучения новичков. Как следствие, изделие запоздало на несколько, и рынок отклонил его.
В этом проекте было две больших ошибки. Первая заключалась в том, что компания не пожелала тратить время, чтобы полностью объяснить потребности заказчиков инженерам, которые были плохо знакомы с проблемной областью, даже при том, что некоторые из нас просили обучения. Вторая ошибка состояла в том, что многие из инженеров и не побеспокоились о более глубоком изучении проблемной области. В результате команда постоянно изменяла направление работ каждый раз, когда рынок предъявлял новые требования. База кода была настолько нестабильна, что потребовались месяцы для безаварийной реализации даже самых простых сценариев пользователя.
Вообще, очень немногие фирмы заботятся об обучении своих разработчиков в проблемной области, хотя именно понимание проблемной области помогает устранять ошибки, вызванные неправильным толкованием требований.
Это недостаток не только компаний. Некоторые разработчики любят думать, что они создают инструменты, предоставляющие пользователю возможность получить решение. Пример предоставления возможности для решения — интерфейс пользователя, который, хотя технически работает, но не согласуется со способом работы пользователя. Другой пример — приложение построено таким образом, что решает какую-то частную задачу пользователя, но не ориентировано на приспособление к изменению его бизнеса.
Только решение задач, а не предоставление возможности их решения делает разработчика настолько осведомленными в проблемной области, что позволяет расширить возможности программного продукта. Лучшие разработчики — не те, кто могут манипулировать битами, а те, кто решает проблему пользователя.
