Дисциплины > Системный Анализ и Требования
Что должен, а что нет, писать системный аналитик
Kavalsky:
На просторах работодателей бывают волшебные вакансии в которых в должность СА входит пресейл, работа с базами данных (Знание SQL), тестирование и даже кодирование.
Все это понятно для маленьких проектов и фирм, но хотелось бы разобраться по существу, как должно быть.
Поправьте меня если я не прав.
Аналитик должен описывать:
Прецеденты, Функц. треб., Биз. треб., Пользов. треб.
Аналитик НЕ должен описывать :
Нефункц. треб., тестовые сценарии, классы, интерфейсы и реакции системы (кроме Пользов. треб.), модель БД, код и т.п.
Как должно быть:
Аналитик - Описывает как хочет работать Заказчик
Пишет"Пользователем могут быть Коля, Вася. Петя. они могут создать документ с такими ... атрибутами"
Архитектор - архитектуру системы, на чем она будет, с какой БД, какими паттернами и проч концепт.
Тим-лид - Описывает КАК ДОЛЖНА РАБОТАТЬ СИСТЕМА что должны накодировать программисты.
Пишет "По нажатию кнопки Создать создается объект документ типа Договор. Сохраняется в БД в таблице Договора. Пользователь может редактировать документ, может не редактировать, у него такие-то инструменты, ограничения документа по следующим атрибутам, если они не заполнены выдается ошибка, редактирование может окончится удалением документа в случае ... И Т.П."
Тестировщики - тест кейсы на основе прецедентов.
ИТОГО:
Аналитик не придумывает какой аллерт должен выскочить при неправильном заполнении полей, если об этом его не попросил Заказчик. Не придумывает типы переменных , длину переменной лучше конечно указывать аналитику. Не придумывает кнопки, их расположение и функционал, интерфейс и прочь кроме указания пожеланий клиента.
На выходе аналитика (опционально, от проекта) три документа:
1. ТП - границы проекта, бизнес цели задачи и прочее предпроектное обследование результат работы всей команды пресейла. Может быть больше или меньше напичкано инф.
2. Прецеденты - они же ВИ со ссылками на требования.
3. Функциональные, бизнес, пользовательские требования, пронумерованные. Их управление, изменение, трассировка, и проч по желанию.
А уже из п. 2 и 3 тим-лид пишет постановки программистам, а те код.
Григорий Печенкин:
Это всё возможно в идеальном мире, где, кроме аналитика, есть архитектор, тим-лид, а также менеджер продукта, менеджер проекта, тест-менеджер, тестировщик, юзабилист, дизайнер, технический писатель, программисты разных мастей и т. п. Плюс маркетологи (которые точно знают, зачем они нужны) сэйлы, пресэйлы, внедренцы, юристы, евангелисты...
При этом у каждого есть свой чётко очерченный круг обязанностей (которые он знает, что немаловажно), внедрённые, документированные и отлаженные бизнес-процессы (в которых каждый тоже знает своё место, обязанности и ответственность).
В реальной жизни я таких компаний никогда не встречал, и не знаю никого, кто их видел или хотя бы о них слышал.
Поэтому аналитику практически всегда приходится совмещать несколько ролей и брать на себя столько ответственности, сколько он сможет унести.
Denis Beskov:
Никто никому ничего не должен, если ранее не принял на себя этих обязательств.
Но если человек может делать что-то, о чем не договаривался и не делает, хотя это могло бы помочь команде, то для него это не очень хорошо статегически
kas:
Аналитик не придумывает какой аллерт должен выскочить при неправильном заполнении полей, если об этом его не попросил Заказчик -- а если аналитик продуктовый и заказчика нет? Получается, что "нет системы - нет проблемы" :)
davvol:
--- Цитата: Kavalsky от 26 Февраля 2013, 22:44:40 ---Как должно быть:
Аналитик - Описывает как хочет работать Заказчик....
....Аналитик не придумывает какой аллерт должен выскочить при неправильном заполнении полей, если об этом его не попросил Заказчик.
--- Конец цитаты ---
Вот эти две фразы очень настораживают.
Они предъявляют очень высокие требования к Заказчику, как к постановщику задачи. В реальности же заказчики разные и влиять мы на это не можем.
Мое глубокое убеждение, аналитик должен не описывать "как хочет работать заказчик", а описывать "то что на самом деле нужно заказчику". По крайней мере стараться. Выявление требований - это на мой взгляд самый важный этап в работе (хотя конечно это мое личное мнение)
Заказчик может много о чем не попросить и умолчать, потому что сам считает:
1. Ну это же само собой разумеющееся! Все это знают!
2. Ну вы же умные, вам виднее.
Еще возник вопрос, почему аналитик не должен заниматься нефункциональными требованиями и реакциями системы?
Это может быть тесно связано с предметной областью, а кто в ней должен разобраться? Не тимлид же.
К тому же если этими моментами не занимается аналитик, то несоответствие с представлениями в голове заказчика всплывает только в момент горькой интеграции.
Навигация
Перейти к полной версии