Из содержания статьи получается, что бизнес-аналитик - это такой посредник в коммуникациях между заказчиком и разработкой, который еще анализирует и разруливает "ситуации", а сбор-анализ-формализация требований и рисование UML - это так, между делом. Ну-ну...
Настоятельно рекомендую вашим аналитикам внимательно почитать книгу "Software Requirements" от Microsoft (которая, к слову, указана в списке полезных материалов) и больше не вводить людей в заблуждение.
В подкасте мы рассказывали именно про наш опыт бизнес-аналитики, понятное дело, что он варьируется от компании к компании.
Действительно, формализация требований, описание схем — это важная часть нашей работы, но, как показала наша личная практика, хороший бизнес-аналитик умеет понимать, при решении какой задачи необходимо уделить больше времени коммуникации, сбору требований и общению, а при решении какой нужно больше проектирования и формализации требований.
Этап коммуникации важен, так как именно на нём можно закрыть часть вопросов, которые потом не придется описывать в требованиях и уточнять. Принцип Парето в действии 🙂
В книге Вигерса (Разработка требований к программному обеспечению) об этом тоже говорится.
Из содержания статьи получается, что бизнес-аналитик - это такой посредник в коммуникациях между заказчиком и разработкой, который еще анализирует и разруливает "ситуации", а сбор-анализ-формализация требований и рисование UML - это так, между делом. Ну-ну...
Настоятельно рекомендую вашим аналитикам внимательно почитать книгу "Software Requirements" от Microsoft (которая, к слову, указана в списке полезных материалов) и больше не вводить людей в заблуждение.
Главная книга это ‘завоевывать друзей’ или другие рекомендации SMM менеджера )))
В подкасте мы рассказывали именно про наш опыт бизнес-аналитики, понятное дело, что он варьируется от компании к компании.
Действительно, формализация требований, описание схем — это важная часть нашей работы, но, как показала наша личная практика, хороший бизнес-аналитик умеет понимать, при решении какой задачи необходимо уделить больше времени коммуникации, сбору требований и общению, а при решении какой нужно больше проектирования и формализации требований.
Этап коммуникации важен, так как именно на нём можно закрыть часть вопросов, которые потом не придется описывать в требованиях и уточнять. Принцип Парето в действии 🙂
В книге Вигерса (Разработка требований к программному обеспечению) об этом тоже говорится.