Одну и ту же задачу можно решить разными способами. Одна и та же потребность пользователя может быть реализована в системе десятком разных способов. Каждый из них будет иметь свои плюсы и минусы.
Задача аналитика состоит в том, чтобы:
- Понять цель, для которой проектируется система;
- Понять какими способами этой цели можно достичь;
- Понять плюсы и минусы каждого способа и выбрать оптимальный.
Как проверить, что аналитик решил эту задачу хорошо? Задать ему вопрос: «Почему ты предлагаешь делать именно так?».
Плохие варианты ответов:
- ❌ Мне так сказали
- ❌ Мне кажется, что надо так
- ❌ Молчание 😶
Такой ответ может являться проявлением того, что:
- Аналитик не понял, в чем цель создания системы и как устроен автоматизируемый процесс.
- Возможно, выявлены не все требования, и пробелы в них заполняются «фантазиями» на тему.
- Аналитик не систематизировал источники требований и плохо в них ориентируется. Создаётся ложное ощущение «кажется» — где-то видел, кто-то говорил, и на этом ощущении проектируется решение.
- Нехватка времени или опыта, в итоге экономия на качественной работе с источниками требований. Требования пишутся «под диктовку Заказчика».
«Фантазия» — требование,которое не имеет основания в виде запросов от пользователей, нормативных документов или фактически наблюдаемого поведения. «Фантазия» формируется из опыта и знаний, которые были получены в другом контексте. Например, в другом проекте для другого заказчика.
«Кажется» — ложное ощущение, что основание у требований есть, только не получается найти их источник или аналитик к нему не обращается, т.к. «точно помнит, что там написано».
Фантазии допустимы при проектировании, если аналитик осознанно к ним прибегает или заказчик пришёл за консалтингом. В таком случае фантазии становятся гипотезами. При этом важно понимать как гипотеза будет проверяться и что будем делать, если она окажется ложной.
Чем хочется закончить этот пост. Вне зависимости от грейда и опыта, чаще задавайте себе вопрос: «Почему я предлагаю именно такое решение?». И будет больше качественных и обоснованных требований в ваших спецификациях. Удачи!
Добавить комментарий
Для отправки комментария вам необходимо авторизоваться.