С чего начать системному аналитику? Начало карьеры.

Внимание! У нас сбои с почтовым сервером! Если не пришло письмо о регистрации или смене пароля напишите нам на info@techwriters.ru! 
@twriters
 obmen_soobsheniyami.pngчат для технических писателей в Telegram

 Зарегистрируйтесь
Страницы: 1
RSS
С чего начать системному аналитику? Начало карьеры., Разбираем вопросы связанные с началом карьеры системного аналитика.
 
В этой теме разберем вопросы того, как например, техническому писателю стать системным аналитиком.  С чего ему следует начать? Какие программы изучить в первую очередь? Какую литературу прочитать?
 
Почитать вот эти книги:

Рассел Акофф - О менеджменте
Вигерс - Разработка требований к ПО
Крэг Ларман - Применение UML и шаблонов проектирования


Вот хороший ответ пользователя Бормоглот c форума sql.ru :

Цитата

C чего начать? Найти работу аналитиком.
Лучше всего там где есть другие аналитики (любые) и где есть некий отлаженный процесс работы.
Начинать работать аналитиком "в одну харю" на всем предприятие тут и бывалый не всякий отважется.  :)  

Литературу читать уже по мере надобности.  :)  От того что ты полгода назад прочитал книжку умную по применению языка SADT, без боевой практической работы где нужна именно специфика SADT? мало что даст.

Можно попробовать пойти по пути любому из предложенных комментаторами  :)  через несколько итараций определить какой же путь был все таки верным  :)  

В общем клевая тема!  :)  "я бы в летчики пошел, пусть меня научат" (с)
Сколько людей столько и мнений. Мой кусочег. На истину не претендую.

Системный аналитик занимается системным анализом. В оригинале.
По факту занимается всем чем придется. За все время работы в профессии ни разу не решал одних и тех же задач в одной и той же системе. Каждая новая работа - абсолютно новые задачи в совершенно разных предметных областях.

Знания в предметной области это хорошо, но главное уметь разбираться в проблеме, систематизировать ее.
Но не надо путать эксперта в предметной области с системным аналитиком.  :)  меня на собеседованиях от этого всегда на хихи пробивает.
Если я эксперт, то почему вы не хотите взять меня главой данного управления?  :)  
А если нужен системный аналитик, почему вам не интересна моя способность системно мыслить? Если я тут все знаю думаете мне тут будет интересно?
Короче риторических вопросов может быть много. (умение задавать вопросы тоже качество системного аналитика, журналиста, следователя и т.д.)

Если я работаю аналитиком, то зачем мне опыт работы программистом?
Как опыт написание запросов под Oracle (например) научит меня системному анализу предметной области или исследованию объекта управления?  :)  
Решение задач в виде тех же ТЗ и написание запроса на SQL или любом другом языке, требуют все же повернутости мозгов несколько в разных направлениях.

UML IDEF ARIS PMBook и прочее это конечно интересно. Полезно знать теорию и инструменты чтобы можно было удобно применить или видоизменить их при решении разных задачь.
И еще одни частые грабли - это всего лишь инструмент, это не технология и порядок работы. Добавляют ли они системного мышления? Езда на велосипеде добавит?
Писать все равно приходится для программеров которые не мечтают стать аналитиками. И согласовывать все с бухгалтерией (например), а у них своя повернутость мозгов и им все равно UML 1.3 это или 2.0.

Как в итоге стать? Что почитать?
Тут не однозначно. Учишься, изучаешь какой-нибудь ERWin с BPWin, особенности учета бумаг бэк-офисом. А работать приходится с Aris или решать проблемы xml обмена в хранилищах данных коллекторских систем.  :)  )
Поэтому пока не будет конкретной работы, изучать что-то если и имеет смысл то только поверхностно.

Список может быть большим:
- Работа с требованиями (сбор, анализ, учет и т.д.)
- Подготовка ТЗ (госты и прочее)
- CASE инструменты и стандарты - UML, RR, IDEF, BPWin, Aris, ERWin
- В том числе умение работать с текстовыми редакторами типа Word или Help&Manual чтобы клевые доки получалися  :)  
- Управление разработкой
- Анализ бизнес процессов
- Системное программирование
- Простое программирование, как база знаний пригодится, + ООП
- Теория баз данных
- SQL  :)  ) без него ни куда
- Основы управления в том числе управление проектами
- Умение вести переговоры
- Различные тренировки мозга
- Стрессоусточивость (при виде всякой страшной непонятной фигни умение не теряться)
- ин.яз  :)  инглишь и другие (для мозга полезно)
- бух.учет (часто системы финансовые чтобы дебет с кредитом не путать)
- эргономика и косвенные темы
- организация собственного времени ака тайм менеджмент (без него никуда)
- ... список может быть большим, смотря чем придется занимаься. Может придется изучать теории графов и как строить карты. Или придется работать с системами предназначенными для работы с образами или ленгвистического анализа.
- или изучать в теории организацию работы промышленных предприятий если автоматизация затрагивает их.

Еще конечно же нужен мозг, но тут опять же все не однозначно. Не слишком умный - программеры засмеют, аналитик как сапер не имеет права на ошибку. Слишком умный - взвоет босс и бизнес т.к. будут рядом с таким чувствовать себя тупым.
Может нужно быть мудрым?  :)  

Аналитиков почти ни где не готовят, так что мало кто знает какие они на самом деле должны быть.
 
Отличная стать о том как стать системным аналитиком

Эту статью я хочу посвятить временами нелегкой, но увлекательной профессии ИТ-аналитика. Сам работаю более 8 лет в роли аналитика, так что постараюсь не потратить Ваше время зря.
Не стану пересказывать теорию (ее можно почерпнуть в замечательной книге Вигерса или в BABOK). Мне бы хотелось сосредоточиться на практической стороне вопроса – описать выжимку из «боевого» опыта, как своего, так и некоторых других людей, с которыми мне посчастливилось работать.

Сразу структурирую дальнейшее повествование:
  1. Короткое введение
  2. Аналитики — кто это? + техническое отступление
  3. Зачем нужны аналитики? (привет, кэп)
  4. Кто и как становится аналитиком?
  5. Что должен знать и уметь аналитик и как этому научиться?
  6. Заключение.
Некоторые из этих тем выглядят очевидными. Постараюсь капитанить по-минимуму.

Примечание из будущего:
Дописав до п. 5 я понял, что в задуманном вначале объеме материал получается слишком большой. Пятый пункт заслуживает отдельной статьи, или даже нескольких. Это дело будущего. В данном посте затрону эту тему лишь поверхностно.

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

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

Аналитики — кто это?
По большому счету в сфере ИТ можно выделить два вида их специализации:
  • Системные аналитики
  • Бизнес-аналитики (данная роль относится не только к ИТ).
Несмотря на то, что решаемые задачи и требуемые навыки у них существенно различаются, на ИТ-проектах в большинстве случаев обе эти роли объединяет в себе один сотрудник (или группа сотрудников). Разделение иногда встречается (например, обычно на проектах для финансовых организаций), но такие случаи в меньшинстве.
Формальные определения без труда гуглятся, а по сути:
  • Главные задачи системного аналитика: сбор, анализ, формализация и согласование требований к системе. Другими словами, управление требованиями на протяжении всего их жизненного цикла. Основной, хотя обычно не единственный, документ на выходе – техническое задание или его аналог. На этом остановимся подробнее ниже.
  • Главные задачи бизнес-аналитика – изучение, описание, анализ и (при необходимости) реинжиниринг бизнес-процессов. Основной документ на выходе – описание бизнес-процессов As Is (обязательно) и To Be (при необходимости).
Первый в обязательном порядке должен иметь хороший ИТ-бэкграунд. Для второго он хоть и желателен, но не обязателен. Нередко бизнес-аналитиками становятся люди с экономическим образованием. Первый должен свободно говорить на одном языке с разработчиками и с бизнес-пользователями, для второго достаточно только бизнес-пользователей.
Другими словами, можно устроиться бизнес-аналитиком на крупный проект, не особо разбираясь тонкостях ИТ (я видел такое в одном из крупных российских ритейлеров), но практически невозможно устроиться системным аналитиком, будучи неспособным общаться с конечными заказчиками (неважно, в силу недостаточной коммуникабельности или нежелания разбираться в бизнесе клиента).

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

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

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

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

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

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

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

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

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

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

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

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

Доступность информационных ресурсов, заинтересованных лиц, экспертов предметной области и технических специалистов
Для формирования полного и точного перечня требований к Системе специалисты Исполнителя должны иметь в достаточном объеме доступ:
  • ко всем относящимся к разработке ПО материалам;
  • ко всем ключевым носителям информации и лицам, обладающим требуемыми полномочиями
Во втором случае имеются в виду:
  1. заинтересованные лица
  2. эксперты предметной области
  3. лица, участвующим в согласовании и утверждении требований
  4. технические специалисты со стороны заказчика либо других подрядчиков/субподрядчиков.
На этом, пожалуй, закончим это небольшое отступление. Язык повествования получился сухой, каюсь. Но тема достаточно формализованная.

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

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

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

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

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

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

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

Заключение
Уважаемые коллеги, я буду искренне рад, если данный пост был полезен. Готов обсудить любые возникшие вопросы, или подробнее осветить, насколько смогу, заинтересовавшие темы. Если Вы с чем-то не согласны, пожалуйста, пишите. Давайте учиться. И да здравствует Lifelong learning!
 
Интересно, Product Manager= Системный аналитик?

Project manager может быть системным аналитиком?  
 
Цитата
Иван Кутейкин написал:
Интересно, Product Manager= Системный аналитик?
Нет
Цитата
Иван Кутейкин написал:
Project manager может быть системным аналитиком?
Может. Но обычно это не получается. У менеджера слишком много управленческих задач, и проводить анализ самому обычно нет времени и возможности.
Обязанность Project manager - оценить результаты анализа и принять верное управленческое решение.
 
Цитата
Иван Кутейкин написал:
Интересно, Product Manager= Системный аналитик?

Project manager может быть системным аналитиком?
Виктор прав,  это абсолютно разные специальности и области задач
 
Да, судя по статье, аналитиком быть нелегко. Но в тоже время освоение такой специальности очень увлекательно.
 
и у аналитиков достойная зарплата)
 
Также задавался этим вопросом, знаю отличное видео где  рассказывают  как начать карьеру бизнес-аналитика и раскрывают перспективы карьерного роста как в России, так и за рубежом.  
Страницы: 1
Читают тему

Рейтинг@Mail.ru