Иногда аналитика привлекают на пресейловой фазе проекта. В этот момент скорее всего есть некоторые бизнес требования, которые аналитику предлагают просмотреть. В наших реальностях бывает несколько сценариев, а иногда и комбинация нескольких вариантов сразу:
-
- Требования писал аналитик предварительно выбранного поставщика, и это не вы
[blockquote] Требования будут написаны достаточно качественно и структурированно. Но, очевидно, подчеркивать особенности определенной платформы а также приверженность к той или иной архитектуре решения. Будет заметно влияние отличной от вашей архитектуры. В целом таки требования будут достаточно качественные, однако местами могу создавать определенные сложности из-за явного крена в конкретную архитектуру. [/blockquote]
-
- Требования писал заказчик, полный ноль в написании требований
[blockquote] Непередаваемый почерк прыжка из гиперпространства в микроскопические детали, неполное перечисление функций, формулировки требующие дешивровки, очевидные технологические ляпы. Старые добрые пользовательские требования. Обязательно найдете «и т.д», «и т.п.», «реализовать не менее трех отчетов», «несколько форм», «автоматизировать все бизнес процессы по …» [/blockquote]
-
- Требования заказчик стырил с предыдущей работы
[blockquote] Сразу видно, что требования хорошо и долго прорабатывались — но очевидно что их делали под абсолютно конкретную технологическую платформу и явно обновляли по ходу другого проекта. Это видно по очень специфической терминологии документа, высоким уровнем детализации [/blockquote]
-
- Требования кромсал специалист по заточкам со стороны вашего конкурента
[blockquote] Как правило, специалисты по заточкам выбирают несколько стратегий. Стратегии могут быть скомбинированы. Одна из стратегий — это мимикрирование под глупого заказчика. Умело составленная череда требований с плохой и размытой формулировкой созданы так, чтобы не дать вам точно определить рамки проекта или заложить бомбы для вашей дисквалификации. Другая стратегия — это плотный набор очень специфических требований под определенный технологический стек — как правило, это явно видно. Третья стратегия — это ставятся абсолютно нереальные сроки при достаточном уровне детализации (это значит что к началу тендера уже более половины системы сделали) [/blockquote]
Идентификация признаков по одному из типов ситуации — это первое что должен сделать аналитик. Аналитик должен передать данную информацию ответственному за пресейл.
