Один из самых распространенных антипаттернов начинающих аналитиков — Сферический конь в вакууме. Так можно назвать требования, которые предлагает аналитик в проекте.
Суть проблемы — требования никак не учитывает целевую архитектуру системы. Часто требования детально описывают то что есть в системе и то чего там практически невозможно реализовать. Мастерски обходят спорные моменты или то что надо указать подробнее.
Почему эта проблема возникает? Начинающий аналитик не задумывается над тем как, кто и на чем это будет делать. Но даже подозревая неладное — он не знает специфики системы.
Что может усугубить проблему:
- Аналитик начинает сам читать популярную литературу на тему
- Аналитик смотрит на другие похожие по его мнению системы или брать за основу наработки друга с другой платформы
- Аналитик просит о помощи коллег из команды и получает твердый конечно-потом / семинар будет в следующем году / покликай сам-там
Что может помочь снизить риски:
- Системное ознакомление с платформой. Да, нужно время и усидчивость
- Изучение гайдов для архитекторов и для пользователей (так вы разберетесь что система умеет и какой обычный опыт в нее вложен)
- Изучение гайдов по Usability и паттернам для архитекторов (крутые платформы такими штуками обладают)
- Изучение списков технологических ограничений платформы, минимальных требований, типичных архитектур
- Быстрые беседы с гуру за 0.5 пива (тогда вы узнаете какую херню приходится втюхивать заказчикам архитектору)
- Несколько качественных лекций архитекторов платформы
- Проведение обучения с компетентными коллегами
