На разные проектах в разных организациях на аналитика возлагают решение совершенно разных вопросов.
Где-то достаточно написать хорошую концепцию, где-то необходимо расписывать подробным образом поведение пользователя и реакцию всех управляющих элементов. Но есть вопросы, которые лежат обычно вне компетенции аналитика.
Например, аналитик не должен решать какую цветовую гамму использовать на проекте, как должны выглядеть кнопки.
Более того, аналитик не должен принимать решения о размещении управляющих элементов на странице. Единственное, что касается аналитика - это список управляющих элементов на странице и их реакция на действие пользователя. Другое дело, что если на проекте нет дизайнера и специалиста по usability, то такие вопросы просят решить аналитика.
Также часть вопросов лежит на менеджере проекта. Например, какое-то действие должно происходить с определенной периодичностью. Если нет необходимости использования результатов этого действия в других местах, то аналитик может указать только цикл - раз в сутки, раз в неделю и так далее. Но решение о том в какое конкретное время должно происходить действие, особенно, если оно отличается от стандартных начала календарных суток, должен принимать не аналитик. Хотя здесь все зависит от деталей проекта.
Еще часть вопросов лежит вне компетенции аналитика - проектирование. Какие классы будут, как будет организована передача информации от одного объекта к другому.
Если проект очень большой, то необходимо вести учет классов и объектов, а также типов сообщений, которыми могут обмениваться объекты. Такая работа также выпадает из поля деятельности аналитика.
Отдельный вопрос про прототипирование проекта. С одной стороны, аналитику проще всего по своей документации составить действующий прототип. С другой стороны, так как "глаз уже замылен", то трудно отследить недостатки собственноручно написанной документации, поэтому, желательно отдавать прототипирование другому человеку.
Где-то достаточно написать хорошую концепцию, где-то необходимо расписывать подробным образом поведение пользователя и реакцию всех управляющих элементов. Но есть вопросы, которые лежат обычно вне компетенции аналитика.
Например, аналитик не должен решать какую цветовую гамму использовать на проекте, как должны выглядеть кнопки.
Более того, аналитик не должен принимать решения о размещении управляющих элементов на странице. Единственное, что касается аналитика - это список управляющих элементов на странице и их реакция на действие пользователя. Другое дело, что если на проекте нет дизайнера и специалиста по usability, то такие вопросы просят решить аналитика.
Также часть вопросов лежит на менеджере проекта. Например, какое-то действие должно происходить с определенной периодичностью. Если нет необходимости использования результатов этого действия в других местах, то аналитик может указать только цикл - раз в сутки, раз в неделю и так далее. Но решение о том в какое конкретное время должно происходить действие, особенно, если оно отличается от стандартных начала календарных суток, должен принимать не аналитик. Хотя здесь все зависит от деталей проекта.
Еще часть вопросов лежит вне компетенции аналитика - проектирование. Какие классы будут, как будет организована передача информации от одного объекта к другому.
Если проект очень большой, то необходимо вести учет классов и объектов, а также типов сообщений, которыми могут обмениваться объекты. Такая работа также выпадает из поля деятельности аналитика.
Отдельный вопрос про прототипирование проекта. С одной стороны, аналитику проще всего по своей документации составить действующий прототип. С другой стороны, так как "глаз уже замылен", то трудно отследить недостатки собственноручно написанной документации, поэтому, желательно отдавать прототипирование другому человеку.
