О требованиях к продукту

О требованиях к продукту


Каковы самые распространенные требования клиента к покупаемой услуге или продукту? Конечно, это сроки и качество. Но если срок это вполне определяемый период времени, обусловленный составом работ, то качество - понятие более эфемерное, связанное с соответствием услуги или продукта ожиданиям и требованиям заказчика.

Качественными могут быть и ядерная боеголовка, и обычный цветной карандаш. Только, если качественный карандаш должен во-первых, хорошо писать, во-вторых, писать именно выбранным цветом, в-третьих, не ломаться, то качественная боеголовка должна абсолютно точно и эффективно поражать намеченную цель.

В чем отличие качества программных продуктов "Капелла" и ядерной боеголовки или карандаша? На самом деле - ни в чем, как бы странно это не звучало. Наши продукты точно также обладают вполне измеряемым "качеством", сформулированном в виде требований заказчика на этапе разработки проектной документации.

Любой грамотный аналитик скажет, что требования к разрабатываемой системе должны быть проработаны и описаны на нескольких уровнях:

1. Бизнес-требования ("требования руководства") - описание "высоких" целей и задач системы, границы и контекст ее использования, общая роль в бизнесе клиента
2. Сценарии обслуживания ("требования пользователей системы") - описание автоматизируемых бизнес-процессов
3. Функциональные требования (требования разработчиков") - детализированное описание всех условий и алгоритмов работы функциональностей системы
4. Нефункциональные требования ("требования вообще") - дополнительные описание и ограничения качественных характеристик системы

Выделенные уровни позволяют с одной стороны "спускаться" от общего к частному, сохраняя последовательность и корректность, а с другой стороны зафиксировать требования от разных слоев населения smile;) представителей заказчика.

Именно поэтому этап проектирования системы - это время тесного сотрудничества исполнителя с заказчиком, требующий плотной работы с обеих сторон. И именно поэтому бизнес-аналитика часто называют "свой среди чужих", а собственные разработчики и "чужой среди своих". smile:) Так как именно от аналитика зависит каким образом и какие конкретные требования заказчика будут закреплены в проектной документации, что и обуславливает в конечном итоге удовлетворенность клиента.

Потому что, если разработанная в результате система не будет соответствовать изложенным требованиям, то вы уже никогда-никогда не сможете убедить заказчика в высоком качестве продукта, иными словами "карандаш будет сломан раньше,чем начнет писать." smile:)

Однако, не менее важно и отношение заказчика к проектированию системы. Совершенно недопустимо, как легкомысленное согласие со всем, что предлагает разработчик ("жираф большой - ему видней"), так и закапывание в мелкие детали собственных бизнес-процессов и перестройка их "на ходу" и "по-живому", несмотря на сопротивление собственных сотрудников.

Ни один исполнитель не сможет до конца предугадать бизнес-логику заказчика, как бы он к этому не стремился. Аналитик всегда выступает только в качестве эксперта-консультанта и может:

- помочь в формализации и усовершенствовании бизнес-процессов,
- рекомендовать наиболее эффективных решения,
- сформулировать требования заказчика к системе.


Поэтому идеальный заказчик - это всегда заказчик, который имеет, пусть не самые формализованные, но объективно "выстраданные" требования к разрабатываемой системе, а также готовность к поэтапному внедрению.

Таким образом, качественная система - это прежде всего система, удовлетворяющая всем описанным требованиям, а хорошо проработанные требования - это залог успеха всего проекта.

Поделитесь информацией