Функциональность
Функциональность — это степень возможностей, обеспечиваемых системой.
Одна из самых трудных проблем, с которой сталкивается руководитель проекта, — определение достаточной функциональности. Всегда существует желание добавлять в систему все новые и новые свойства. Такое желание известно на языке индустрии как фичеризм (featurism).
Его последствия плачевны для внутренних проектов, где давление исходит от разных групп пользователей внутри одной и той же компании. Они еще хуже для коммерческих продуктов, испытывающих давление, например от журналистских сравнительных обзоров, представляющих чаще всего таблицу, включающую одновременно свойства разных конкурирующих продуктов.
Расширение свойств системы приводит к двум проблемам, одна сложнее другой.
Более простая проблема — потеря непротиворечивости, которая может возникнуть при добавлении новых свойств, затрагивающих простоту использования. Известно, что пользователи жалуются, что все украшения новой версии продукта делают его ужасно сложным. Однако таким комментариям не стоит слишком доверять. Новые свойства не возникают из ничего: в основном они возникают из спроса пользователей, других пользователей. Что для меня выглядит ненужной безделушкой, может для вас быть необходимым свойством.
Каково же решение проблемы? Необходимо снова и снова работать над состоянием всего продукта, пытаясь привести его в соответствие с общим замыслом. Хороший программный продукт основывается на небольшом количестве сильных идей. У него может быть много специальных свойств — все они должны быть следствиями основных положений. «Великий план» должен быть виден, и в нем всему должно отводиться свое место.
Более сложная проблема — слишком большое внимание к одним свойствам в ущерб другим качествам системы. В проектах часто встречается ошибка, ситуация, которую описал Роджер Осмонд в виде двух возможных путей работы над проектом:
Нижняя кривая описывает фичеризм: в лихорадочной погоне за дополнительными свойствами теряется нить общего качества. Завершающая фаза такого проекта, предполагающая общую корректировку всех свойств, может быть долгой и напряженной. Если под давлением пользователей или конкурентов Вы вынуждены выпустить продукт достаточно быстро, результат может повредить Вашей репутации.
Осмонд предлагает (верхняя кривая) во время создания проекта поддерживать на высоком постоянном уровне качество всех факторов, кроме функциональности. Никаких компромиссов по надежности, расширяемости и прочим факторам: Вы просто отказываетесь от добавления новых свойств до тех пор, пока Вас удовлетворяют существующие.
Этот метод трудно осуществить в повседневной практике из-за упомянутого давления, но он в конечном итоге дает более эффективный процесс создания качественной программной системы. Может возникать вопрос: «Достаточно ли это хорошо?», но не будет стоять вопрос: “Будет ли это работать?”
Как знает любой читатель, который возглавлял проект создания программного обеспечения, легче одобрить такой совет, чем его использовать. Но каждый проект должен стараться следовать подходу, соответствующему лучшей кривой Осмонда.
| Простота использования | Прочие факторы |