Что делает бизнес-аналитик каждый день

Короткое введение

Сухих формальных определений и другого подобного рода материалов по системному и бизнес-анализу на просторах Интернет хватает, так что не стану повторяться. Так же ни в коем случае не собираюсь и пересказывать содержание книги «Путь аналитика. Практическое руководство IT-специалиста».

В последнее время описываемой области знаний уделяется весьма скромное внимание. Выражается это в самых разных вещах. Например, до сих пор нет стандарта де-факто на профессию «Системный аналитик». Конечно, есть Международным институт бизнес-анализа (International Institute of Business Analysis, IIBA) со своим BABOK и собственной системой сертификации. Но широкой полулярностью (как, например, PMI/PMBook в дисциплине управления проектами) они не пользуются, особенно в России.

https://www.youtube.com/watch?v=ytdevru

К слову, в настоящее время создается российское отделение IIBA. Не буду рекламировать, но все желающие могут легко найти соответствующую группу в LinkedIn.

Так же число книг по IT-аналитике заметно меньше, чем по другим IT-дисциплинам (буду рад ошибиться по данному вопросу — возможно, какие-то важные книги в этой области прошли мимо меня). Даже на Хабре статьи непосредственно по аналитике за последние пару лет можно пересчитать чуть ли не по пальцам одной руки (1, 2, 3, 4). Ну да имеем что имеем. В конце концов, все в наших руках.

Зачем нужен бизнес-аналитик

В техническом плане системная аналитика бизнеса состоит в том, чтобы максимально точно описать сложившуюся ситуацию, установить все явные и неявные связи, выявить проблемные точки, увидеть имеющиеся перспективы, сформулировать требуемые улучшения, предложить механизмы внедрения этих новшеств. Если же говорить о глобальных задачах в контексте интересов всего предприятия, то можно выделить следующие направления:

  • Снижение затрат при (как минимум) сохранении качества. Эксперт должен подумать – каким образом устранить нерациональные расходы, внедрить более экономные технологии, уменьшить процент брака.
  • Улучшение собственно качества. Здесь взгляд аналитика обращается на конечный результат всей деятельности фирмы, то есть на продукты или услуги. Все ли клиенты и партнеры довольны продукцией и существующими схемами взаимодействия? Каково реальное восприятие организации на рынке? Не устаревает ли продукт, не отстает ли по каким-то параметрам от конкурентных аналогов?
  • Формулировка первостепенных проблем. Одним из итогов аналитической работы становится список недостатков, которые организации необходимо устранить, если она не хочет потерпеть крах или остановиться в своем развитии.
  • Стандартизация требований. Все найденные решения должны получить четкое описание и быть в доступной форме изложены в будущих регламентах, должностных инструкциях, памятках иных внутренних документах. Выводы должны быть донесены не только до руководства и отдельных менеджеров, но и до каждого сотрудника, который имеет то или иное отношение к упоминаемым бизнес-операциям.  

Бизнес-аналитика

Формально бизнес-анализом может считаться ручной сбор информации, составление схем, графиков и таблиц, их последующее сравнение и формулирование выводов. Но в наши дни разработан IT-инструментарий со множеством функций, позволяющий проделывать эти действия гораздо быстрее, точнее и с учетом всех профессиональных стандартов.

В описываемой сфере существует немало информационных платформ, автоматизирующих сбор данных, их классификацию и построение наглядных схем. Популярные платформы на основе OLAP-кубов позволяют выстраивать схемы и графики на основе любых имеющихся данных, демонстрируя зависимость одного показателя от другого.

Иными словами, благодаря современному инструментарию специалист может за минуту получить информацию, например, о зависимости продаж определенного вида товаров в определенном магазине от сезона, дня недели и стоящих в смене продавцов. Каждый профессионал выбирает какую-то одну платформу, которая подходит для его подхода и для его заказчиков. Но обязанность хорошего специалиста – на достаточном уровне ориентироваться во всех основных системах.

Изначально аналитика активно применялась в IT, потому что именно игроки этого рынка раньше всего осознали важность информации в современном мире. Но сегодня это осознание пришло уже фактически во все области человеческой деятельности. Крупные компании начали одна за другой открывать вакансии бизнес-аналитика.

Переводчики третьей версии BPM CBOK (Business Process Management Common Body of Knowledge) обратили внимание на неоднозначное восприятие слова «бизнес» в русском языке. Английское Business переводится как «дело» и охватывает все сферы, в которых люди осознанно и долговременно работают над реализацией неких целей.

Но в Россию это слово пришло на волне коммерциализации, в связи с чем до сих пор можно услышать мнение, что «нашей организации не нужна бизнес-аналитика, потому что мы не занимаемся коммерцией». Однако на самом деле аналитика бизнес-процессов применима в некоммерческих и государственных структурах для обоснования принимаемых решений.

Бизнес-анализ включает:

  • Сбор и интеллектуальную обработку данных;
  • Стратегический анализ деятельности и определение ключевых направлений развития;
  • Построение целевой архитектуры предприятия;
  • Управление процессами для достижения желаемых показателей;
  • Исследование предметной области и формулирование требований к разрабатываемым информационным технологиям.

Базовые познания в бизнес-аналитике – пожалуй, неизбежное условие управления любым предприятием в информационном мире. Каждый менеджер должен ежедневно и ежечасно понимать, какая ситуация сложилась на текущий момент внутри организации, как это соотносится с общим положением дел на рынке, какие изменения необходимо произвести и каким образом это можно сделать.

Получить новую профессию можно в формате дополнительного образования.

Например, в ВШБИ НИУ ВШЭ он применяется на программе второго высшего образования «Управление информационными технологиями в бизнесе» и на программах профессиональной переподготовки «Операционная эффективность бизнеса и совершенствование», «Информационная бизнес-аналитика». 

Бизнес-аналитик — это человек, который стоит между бизнесом и командой разработки. Он собирает и выявляет требования к будущему продукту или функционалу, а затем переводит их на понятный для инженеров язык.

Обязанности BA в команде могут варьироваться, но на всех проектах и во всех вакансиях бизнес-аналитика указаны 4 основные функции.

  1. Управление требованиями: их выявление, подготовка и детализация, разделение запросов на требования и «какие-то не очень важные хотелки».
  2. Стратегический анализ: во многих компаниях BA вместе с ТОП-менеджментом работает над стратегией развития компании и проекта, поскольку знает продукт лучше всего.
  3. Проектирование решений: подготовка документации и, порой, создание прототипов. Все, чтобы придумать и донести до команды, каким образом решения будут разработаны и имплементированы.
  4. Управление продуктом: коммуникация с дизайнерами, инженерами, стейкхолдерами, бизнесом и Product Owner-ами.

Заказчик идет к своему другу, по совместительству бизнес-аналитику, пожаловаться на программиста. Далее диалог между заказчиком и бизнес-аналитиком.

Заказчик: Вот ты мне скажи, ЧТО ТУТ НЕПОНЯТНОГО? Взять и сделать точно такой же сайт, неужели так сложно повторить?Бизнес-аналитик (грустным голосом): Ну, вообще-то, я на стороне программиста. Непонятно в твоем запросе совершенно все. Сейчас докажу. Давай вместе посмотрим, что именно тебе нравится в этом сайте.

https://www.youtube.com/watch?v=ytcopyrightru

Здесь есть кнопка «Сравнить», она тебе нужна?Заказчик:Нет, не нужна.Бизнес-аналитик:У этих ребят на сайте отдельная страница для доставки и еще одна — для оплаты, тебе точно нужно 2 верстать, или можно доставку и оплату объединить в одну страницу?Заказчик:Можно совместить, мне и правда 2 страницы нечем заполнять.

Этот кейс показывает, насколько по-разному можно рассматривать один и тот же продукт (в данном случае сайт). Выходит, BA — тот человек, который может спасти проект от «сделали, но не то». Поэтому привлекать бизнес-аналитика лучше до того, как команда столкнется с проблемами в коммуникациях с заказчиком.

Кажется, будь у заказчика технический бэкграунд, это могло бы решить все вопросы. А вот и не угадали. Подкованные в техническом плане заказчики вместо того, чтобы сфокусироваться на составлении ТЗ, могут начать рассказывать команде, что и как делать, не обладая достаточной экспертизой в сфере. Или, хуже того, начинают писать код и отстаивают его имплементацию в проект.

Есть и третий тип проблем в коммуникациях — когда то, каким заказчик видит продукт, сильно отличается от того, что команда считает оптимальным решением бизнес-потребности. Бизнес-аналитик в подобных ситуациях выступает своего рода рефери и объединяет лучшие предложения из двух вариантов, попутно аргументируя изменения для обеих сторон.

Постойте, но это больше похоже на работу Project Manager-а, разве нет?В каком-то смысле так и есть. Не во всех компаниях выделены отдельные люди на обе роли, а с требованиями работать нужно в любом случае. Однако, в средних и больших проектах и у бизнес-аналитика, и у PM-а работы хватает на целый день (еще и с овертаймами).

Давайте опишем обычный день, за который бизнес-аналитик успевает выполнить все свои базовые функции. Конечно, так проходят далеко не все будние BA. В зависимости от текущих задач и стадии развития проекта, меняется количество времени, работа бизнес-аналитика адаптируется, но в идеальном мире без горящих дедлайнов расписание BA может выглядеть следующим образом.

В отдельных случаях, коммуникация с командой может занимать чуть ли не весь день. В идеальном расписании за эти 2 часа BA отвечает на вопросы, когда что-то непонятно и участвует в обсуждении проблемных ситуаций.

Бывают случаи, когда в работу берут на первый взгляд легкую задачу, а в ходе выполнения оказывается, что есть технические ограничения, и утвержденное ранее решение займет сильно больше времени.

BA организовывает митинг, на котором поясняет команде изначальную бизнес-потребность, и спрашивает, может ли команда предложить решение, которое займет меньшее количество времени и ресурсов. Если оптимальное решение находится, то бизнес-аналитик изменяет требования. Нет — самое время «порадовать» клиента новостью.

Краткое техническое отступление

Давайте сознательно прервем повествование и остановимся на самих требованиях. Что касается видов, атрибутов, характеристик, подходов к сбору и оформлению требований – пожалуй, большего «бардака» сложно найти. Состав и содержание документов с требованиями существенно различаются (взять, к примеру, наш ГОСТ и RUP, и имхо это не сравнение пушки и рогатки).

Что делает бизнес-аналитик каждый день

Набор атрибутов требований так же в каждом подходе приводится свой, часто весьма неоднозначный (например, в BABOK). В довершение, часто путают результаты этапов анализа и проектирования, заставляя исполнителей включать в аналитические документы финальный вид диаграммы классов и полную схему БД (об этом ниже).

Не претендуя на истину в последней инстанции или какое-то ноу-хау (примерно то же написано в Википедии), сформулируем два ключевых способа классификации требований.

По уровню:Бизнес-требованияСамые высокоуровневые требования, которые определяют цели создания ПО. Примерами таких требований могут быть достижение 20%-го сокращения издержек или повышение качества управления (например, за счет возможности оперативного формирования отчетности).Данные требования обычно описываются в отдельном документе — «Видении проекта» (Vision) или «Бизнес-требованиях», который так же включает определение основных ролей будущих пользователей Системы и перечисление ее основных сценариев использования. Если такого выделенного документа нет, то часто все это включается в техническое задание или его аналог.

Требования пользователейОни определяют набор пользовательских задач, которые должна решать Система, с описанием сценариев решения данных задач. Требования пользователей обычно представляются в виде перечисления вариантов использования Системы и взаимосвязей между ними (как правило, в виде Use-case диаграммы языка UML).

Сами варианты использования описывается в виде составляющих их последовательностей действий со всеми возможными пред/постусловиями и ветвлениями. Часто описание является текстовым (эта тема хорошо описана в книге Алистера Коберна ” Современные методы описания функциональных требований к системам “).

Функциональные требованияДетально описывают все элементы функционала, который должен быть непосредственно реализован в Системе, чтобы обеспечить возможность выполнения всех сценариев использования, описанных в Требованиях пользователей. Функциональные требования являются наиболее детализированными. Они описывают, в том числе, входные/выходные данные и их проверки, алгоритмы обработки данных и элементы пользовательского интерфейса (без дизайна).

Как правило, данные требования оформляются в виде отдельного документа («Технического задания» и т.д.). В этом же документе детализируются сценарии использования Системы (Требования пользователей), к которым обычно и привязываются функциональные требования.Пример функционального требования: «По клику на кнопке {amp}lt;Кнопка А{amp}gt; на форме {amp}lt;Форма Б{amp}gt; должно отображаться модальное диалоговое окно, содержащее {amp}lt;Содержание окна{amp}gt;».

По типу:Функциональные требованияОписывают непосредственно функционал, реализуемый Системой (пример приведен выше в описании классификации требований по их уровню в пункте «Функциональные требования»);

Нефункциональные требованияОписывают характеристики системы и ее окружения, а так же накладываемые ограничения.Примерами нефункциональных требований могут служить ограничения на поддерживаемые разрабатываемой Системой аппаратные платформы и операционные системы, а так же требования к производительности, к безопасности и т.д.

Что делает бизнес-аналитик каждый день

Примечание:Как видно из описания, приведенного выше, функциональные требования – это категория требований как по их уровню, так и по их типу. К сожалению, в настоящий момент сложилась именно такая неоднозначная терминология (по опыту многих проектов и нескольких работодателей). Если у вас есть другие подходы, пожалуйста, поделитесь.

https://www.youtube.com/watch?v=upload

Последовательность работ и их результатовСледует четко различать результаты этапов анализа и проектирования. На этапе анализа формируются требования к Системе.Все детали реализации Системы определяются уже на следующем этапе – этапе проектирования. Таким образом, в случае необходимости включить в «Техническое задание» модель базы данных Системы или диаграммы классов нужно понимать, что в этом случае:

  1. Произойдет смешивание в одном документе результатов различных типов работ, выполняемых разными людьми (аналитиком и архитектором);
  2. Срок сдачи технического задания будет увеличен, т.к. для его завершения потребуются некоторые результаты этапа проектирования.
    Результаты этапа проектирования эффективнее оформлять в отдельном документе, описывающем архитектуру Системы.

Однако некоторые отступления, такие как включение в «Техническое задание» спроектированных макетов интерфейса (без дизайна/оформления), допустимы, т.к. выполняются теми же людьми, которые разрабатывают само техническое задание.

Порядок сбора самих требований:

  1. Сначала выявляются цели создания Системы (бизнес-требования). Может сложиться впечатление, что фиксация данных требований не является обязательной для разработки. Но в этом случае у Исполнителя не будет возможности контролировать соответствие разработанной Системы тем целям, для которых она создавалась, а так же – возможности устанавливать семантические зависимости между целями разработки системы и сценариями ее использования;
  2. Далее определяются роли пользователей Системы (как людей, так и других программных систем). После этого выявляются и описываются сценарии использования Системы каждой из данных ролей. Так формируются Требования пользователей.
  3. Далее разрабатывается полный набор требований к функционалу Системы таким образом, чтобы данный функционал позволял выполнить все сценарии, описанные в Требованиях пользователей. Так же фиксируются ограничения для Системы и параметры среды ее функционирования.

Отсутствие дублирования в описании требованийКлючевым моментом управления требованиями является отсутствие дублирования, т.е. каждое требование должно быть зафиксировано только в одном документе и только в одном месте данного документа. Отступление от данного принципа приведет как к серьезному увеличению трудозатрат на поддержку данных документов, так и к неизбежному нарушению их целостности (т.к.

для сложно программной системы учесть все нюансы всех новых требований параллельно во всех документах является сложной и ресурсоемкой задачей).В случае необходимости, вместо дублирования описаний требований необходимо использовать ссылку на оригинал данного описания. Это позволит как учесть взаимосвязи между требованиями, так и избежать описанных выше проблем.

Управление изменениямиПри разработке современных программных систем часто требуется внести изменения в требования уже по окончании этапа анализа. Здесь важно, чтобы стороны понимали и принимали следующие принципы:

  • Исполнитель понимает, что требования не всегда могут быть сформулированы Заказчиком полностью и корректно на начальных стадиях проекта. Соответственно, изменения в требованиях по ходу проекта допускаются.
  • Заказчик понимает, что изменение требований влечет за собой увеличение трудозатрат и сроков сдачи продукта.

Доступность информационных ресурсов, заинтересованных лиц, экспертов предметной области и технических специалистовДля формирования полного и точного перечня требований к Системе специалисты Исполнителя должны иметь в достаточном объеме доступ:

  • ко всем относящимся к разработке ПО материалам;
  • ко всем ключевым носителям информации и лицам, обладающим требуемыми полномочиями

Во втором случае имеются в виду:

  1. заинтересованные лица
  2. эксперты предметной области
  3. лица, участвующим в согласовании и утверждении требований
  4. технические специалисты со стороны заказчика либо других подрядчиков/субподрядчиков.

На этом, пожалуй, закончим это небольшое отступление. Язык повествования получился сухой, каюсь. Но тема достаточно формализованная.

Зачем нужны аналитики? (привет, кэп)

До сих пор от некоторых разработчиков (хотя сейчас уже очень редко) можно услышать, что аналитики (равно как руководители проектов, менеджеры по продукту и т.д.) не только не вносят полезный вклад в дело, но и просто «мешаются под ногами». Лезут, понимаешь, со своими процессами, бумажками и прочей бюрократией — не дают простому девелоперу спокойно работать (смайл).

Излишняя бюрократизация конечно зло, но реализовать большой проект «на коленке», да еще усилиями специалистов лишь одного профиля в современном мире нереально. Никто не оспаривает важную роль разработчиков, но будут ли они продавать, оформлять кучу сопутствующей документации, пытаться понять своеобразный язык заказчиков и т.д.? Позволю себе предположить, что вряд ли многих из них это заинтересует.

К слову, если бы все вышеназванные товарищи (аналитики, менеджеры и т.д.) были бы обычными дармоедами, их бы в нашем мире жесткой конкуренции не нанимали в таких количествах и не платили бы им таких денег. Оговорюсь только, что речь идет об Enterprise-проектах. Создать успешное мобильное приложение и заработать на нем понятные деньги сейчас (пока еще?

  • Выслушать заказчика. Иногда уже это бывает непросто – некоторые способны говорить часами буквально ни о чем, и не всегда легко удается перевести общение в конструктив. Тут ключевым является навык активного слушания.
  • Понять иногда «птичий» язык заказчика и сформулировать его требования понятным языком, полно и без противоречий. Т.е. превратить поток сознания клиента в набор формализованных требований.
  • В некоторых случаях, когда заказчик «сам не знает, чего хочет», предложить оптимальное решение или «подвести» к нему самого заказчика;
  • Проанализировать влияния новых требований на существующую архитектуру и функционал. Здесь часто будут полезны консультации архитектора.
  • Задокументировать требования в виде документа или набора документов в требуемом виде. Затем согласовать их и утвердить.
  • Завести талоны в системе такс-трекинга и в дальнейшем отслеживать их нелегкую судьбу. Завести может и архитектор или dev. lead по ТЗ, но чаще это делает аналитик.
  • Осуществлять верхнеуровневый контроль соответствия реализованного функционала требованиям.
  • Управлять изменениями требований.
  • Осуществлять все взаимодействие с заказчиками по вопросам требований.
  • Часто – участвовать в сдаче продукта заказчику.

Так же аналитиков частенько «припахивают» к не совсем профильным для них задачам, вроде участия в тестировании, внедрении и разработке пользовательской документации. Бороться с этим или смириться – по большому счету личное дело каждого. Более интересной, хоть и тоже не совсем профильной активностью является участие в пресейлах. Кстати, часто эта деятельность бывает весьма увлекательной и развивающей (хотя и чрезвычайно затратной по времени).

Кто и как становится аналитиком (по трудовой)?

Если после прочтения статьи вам показалось, что бизнес-анализ может стать следующей ступенью вашего карьерного роста — это хорошая идея. Даже если после обучения вы передумаете менять работу, знания бизнес-анализа существенно повысят вашу стоимость на рынке.

Чтобы вырасти в бизнес-аналитика, нужно:

  1. Понять роль бизнес-аналитика в своей компании, так как задачи от проекта к проекту могут сильно отличаться.
  2. Определить свои текущие компетенции и сравнить с матрицей компетенций BA. Иногда, одна компетенция (к примеру, хороший английский) может стать решающей.
  3. Выделить недостающие компетенции и пройти по ним обучение.
  4. Овладеть основными техниками и методиками BA. Внедрять полученные техники в работу и отслеживать результаты.
  5. Подать резюме на junior позицию с сопроводительным письмом. Важно написать, почему вы хотите работать в этой компании и почему они должны вас взять: что вы для этого сделали, какие курсы прошли и что умеете. Не бойтесь вместе с резюме подавать тестовые проекты, которые делали в процессе обучения — они станут отличным примером вашей первой работы.

Кому-то рабочий день бизнес-аналитика покажется скучноватым, кто-то решит, что это — работа мечты (спокойней, чем у проектных менеджеров, но, все равно много коммуникации и влияния на результат). В любом случае, знания бизнес-анализа с каждым днем становятся все более востребованными на рынке, поэтому, если вы хотите развиваться в IT, стоит прокачаться в работе с требованиями.

Чистых бизнес-аналитиков, вовлеченных в ИТ-проекты, не так много. В большинстве случаев их задачи выполняют системные аналитики. И признаюсь, у меня нет репрезентативной выборки, чтобы судить, откуда они берутся.

Что же касается системщиков, просто по опыту: стать аналитиком «сразу» (без опыта предыдущей работы в сфере ИТ) обычно нельзя. По крайней мере, за все время моей работы мне не удалось встретить ни одного такого человека. Видимо это из-за того, что как требования к кандидату, так и ответственность, изначально велики.

На практике, в аналитиков часто вырастают успешные тестировщики и, иногда, технические писатели. Так же нередко аналитиками становятся разработчики: кто-то из-за того, что понял, что разработка – это не его, кто-то действительно хочет быть аналитиком, для кого-то это лишь более короткий путь в ПМ-ы.

Из кого получается хороший BA

В бизнес-анализ можно прийти как со стороны бизнеса, так и со стороны разработки. Сильные BA получаются из технических писателей, поскольку они понимают, как именно формируется хорошая документация. Из бизнеса в BA вырастают менеджеры, экономисты и даже ребята из команды поддержки, поскольку они разбираются в болях и потребностях клиента.

https://www.youtube.com/watch?v=ytcreatorsru

Роль BA в компании могут выполнять разные специалисты.

Sales Manager Специалист по продажам — первый, кто начинает выявлять требования и понимать, что же хочет клиент. Опытные сейлзы прокачивают необходимые навыки BA, чтобы грамотно собрать первую информацию о предполагаемом продукте.
Account Manager Аккаунт менеджер знает много о продукте и пожеланиях клиента, так что может сориентировать заказчика, куда развиваться.
Product / Project Manager В рамках работы PM-ам приходится доносить требования до команды и управлять ими, поэтому на более-менее серьезном проекте не обойтись без знаний бизнес-анализа.
Тим лид или самый опытный разработчик Девелопер может выполнять роль BA, если заказчик обладает хоть какой-то технической компетенцией. Эта модель чаще всего встречается в аутсорсинге.
QA инженер Тестировщик понимает, что именно команда должна разрабатывать. В ходе тестирования QA составляет тест-кейсы и эти кейсы — чуть ли не единственная документация, по которой работает команда в отсутствие BA. Это не лучшая практика, но, тем не менее, она имеет место быть. Кстати, QA-специалистам достаточно нескольких месяцев, чтобы освоить дополнительные техники необходимые для BA и уйти в бизнес-аналитику.
UI / UX дизайнер Дизайнеры много коммуницируют с клиентами и работают с обратной связью. Они могут рассказать команде, что и как должно работать. Поскольку дизайнер не разбирается в разработке, роль BA на таких проектах делится между дизайнером и командой.
Scrum master, Scrum team Если команда работает по модели Agile, эти специалисты могут брать на себя роль BA.

Что должен знать/уметь аналитик и как этому научиться?

Читавшие упомянутую выше книгу «Путь аналитика. Практическое руководство IT-специалиста», особенно те коллеги, которые только начинают свою карьеру в ИТ, наверняка

прифигели

несколько удивились тому объему знаний и умений, которые автор предлагает освоить несчастному читателю. Если вкратце, то следуя данной книге, аналитик должен освоить весь накопленный человечеством опыт в данной области со всеми методологиями, техниками и инструментами, а заодно и в максимальной степени обладать всеми положительными личными качествами, присущими человеческим существам.

На мой скромный взгляд, там все-таки описан некий сферический аналитик в вакууме идеал, к которому можно (но не факт, что нужно) стремиться. Фанатичное стремление овладеть сразу всеми знаниями и навыками приведет, разве что, в Кащенко. Готов поспорить на бутылку Talisker 16 y.o., (с кем-нибудь одним, а то же, неровен час, найдутся Шелдоны (смайл)), что в природе нет ни одного человека, полностью соответствующего продвигаемому в книге образу (со всем описанным набором знаний и навыков), включая самого автора книги.

Однако, как я уже упоминалось во вступлении, знания и навыки аналитика и способы их приобретения – тема очень большая. И чтобы не раздувать этот пост, не буду пытаться осветить ее здесь подробно. А в если в двух словах, то конечно стоит иметь представление:

  • о жизненном цикле ПО;
  • о нескольких ключевых методологиях разработки (waterfall, RUP, что-то из Agile, лучше бы Scrum, для гос. заказчиков – ГОСТ 19 (на программы) и 34 (на автоматизированные системы));
  • об основах системного анализа (Вигерс отлично подойдет);
  • о нотациях и инструментах проектирования и моделирования (самые востребованные на рынке, пожалуй: Sparx Enterprise Architect и Rational Rose; и UML/Aris/IDEF0 и IDEF3);
  • о теории реляционных БД;
  • и т.д.

О необходимости владеть в совершенстве Word-ом или его аналогом даже не пишу (смайл). А вот о необходимости владеть хотя бы одним инструментом для проектирования макетов интерфейсов, стоит упомянуть. Выделенные интерфейс-дизайнеры – редкость, так что эта работа часто «падает» на аналитиков. Здесь кроме очевидного Visio могу посоветовать простой и удобный Evolus Pencil.

https://www.youtube.com/watch?v=ytaboutru

Плюс, некоторые личные качества, такие как ответственность, коммуникабельность и внимание к деталям, действительно стоит «прокачивать». Для этого есть специальные техники.

Поделиться:
Нет комментариев

Добавить комментарий

Ваш e-mail не будет опубликован. Все поля обязательны для заполнения.

×
Рекомендуем посмотреть
Adblock detector