Курс системный аналитик pro с нуля

Этой статьёй я открою серию материалов про управление требованиями на разных этапах проекта.  Уже больше 10 лет я работаю в IT и успела побывать бизнес аналитиком, системным аналитиком и руководителем проектов. Также я выступаю в роли ревьюера на курсе «Системный аналитик». 

Я попробую развеять эти сомнения на примере учебного проекта, в рамках которого:

• мы рассмотрим уровни детализации требований, на пяти фазах жизненного цикла проекта,

• подберем инструменты анализа требований разных типов,

• попробуем заменить тяжеловесную документацию (ТЗ, SRS) на сочетание Wiki и таск-трекера. 

Разбираться будем на учебном примере вымышленного банка DBT, с использованием бесплатных инструментов: Yandex Tracker, Yandex Wiki. 

Исходные данные проекта

Deep town bank — высокотехнологичный банк, я буду использовать сокращённое название DTB. Для поддержания работы DTB выстроили внушительную IT-архитектуру,  в которой есть клиентские мобильные и web-приложения, несколько сотен серверных приложений. 

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

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

Инициация

Фаза инициации — первая фаза цикла, на которой прорабатывают концепцию проекта и продукта, определяют ресурсы и примерные сроки реализации.
Этой фазе характерен высокий уровень неопределённости. 

• Заказчик приблизительно понимает, что ему нужно, пока требования только формулируются. 

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

Задачи аналитика на этом этапе нацелены на определение границ проекта. Возможная выгода от проекта ещё не определена, её может и не быть, а на первичный анализ нужно потратить время (как минимум аналитика и заказчика). Чтобы минимизировать возможные убытки, нужно тратить на первичный анализ минимально возможное количество времени.

Задачи аналитика на фазе инициации:

1. Определить бизнес-проблемы и бизнес-цели.

2. Сформировать список заинтересованных сторон.

3. Сформулировать верхнеуровневые пользовательские и функциональные требования.

4. Сформулировать варианты реализации.

1. Определяем бизнес-проблемы и цели 

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

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

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

Представим, что мы выступаем в роли full stack (совмещаем роли бизнес- и системного) аналитика DTB-банка, которому пришло сообщение от руководителя отдела развития клиентского сервиса.

«Нам нужно, чтобы несколько клиентов могли пользоваться одним счётом. Нужно прикинуть, сколько времени займёт разработка. Там не сложно, можно просто привязывать разные карты к одному счёту».

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

Если воспринять этот запрос как требования, которые нужно реализовать в любом случае, есть риск потратить время команды разработки и при этом раскрыть банковскую тайну клиентов, нарушить требования ПОД/ФТ и внести ненужные изменения в архитектуру системы. А потом ещё поддерживать работу никому не нужного функционала. Мы не получим выгоды и понесём убытки из-за потраченных ресурсов. Описание плохое, но, к сожалению, именно этот формат часто используют на практике.

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

Как выявить бизнес-требования, или «Пять почему»

Чаще всего бизнес-требования выявляют с помощью интервью заказчика и применения метода «Пять почему». Аналитик общается с заказчиком и задаёт ему вопросы: «Почему?», «Зачем?», «С какой целью?», «Кому это нужно?»,  пока не сформулирует измеримые цели доработки. 

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

Карточка запроса на изменение

Перечень персон, пользователей общего счета

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

Чтобы оценить, чьи бизнес-проблемы нужно решать сначала, собираем запросы в одном месте — реестре запросов на изменение. В нём фиксируем:

• Приоритет (важность, срочность) реализации 

• Статус (открыт, первичный анализ, оценка, отклонён, в работе, завершён)

• Оценка. Плановые трудозатраты на внесение изменений или оценка стоимости изменений

Важно понимать отличие реестра запросов на изменение от плана проекта, бэклога (baclog) или дорожной карты продукта (road map). Реестр содержит список пожеланий на изменения, детализированных до уровня бизнес-целей. Достигнуть бизнес-цели можно разными способами: доработкой одного или нескольких продуктов, запуском нового проекта или изменением плана существующего проекта. А может, вообще не потребуется участие разработчиков.

Реестр запросов на изменение можно вести в документе Exсel, в Google Sheets, Miro и даже на физической доске с помощью стикеров. Выбор зависит от:

• количества заинтересованных лиц,

• количества сотрудников на удалённой работе,

• списка инструментов, уже используемых в компании.

Для стартапа с командой до 10 человек, которые находятся в одном помещении, оптимальный способ — физическая доска. Можно не тратить время на настройку сложной системы работы с реестром, а лично обсуждать сами изменения. 

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

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

2. Формируем список стейкхолдеров

Заинтересованные лица, стейкхолдеры (stakeholder), или лица, принимающие решения, — это люди, на которых влияют результаты проекта. Они инициируют проект, согласовывают детали, бюджет, принимают и оценивают результаты. Стейкхолдеры могут влиять на проект, например, вносить коррективы или отказаться его принимать. 

Стейкхолдеры бывают внутренние и внешние. 

• Внутренние — сотрудники компании, которые задействованы в проекте, в нашем примере это: заказчик, спонсор проекта, команды разработки и сопровождения.

• Внешние — все, кто может повлиять на проект за пределами компании. В нашем примере это: государственные органы, которые регулируют деятельность DTB, клиенты DTB, которые формируют мнение о продукте, СМИ и конкуренты, которые наблюдают за проектом. 

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

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

Хотя функционал таск-трекера позволяет создавать таблицы в описании задачи, таблицу со списком заинтересованных лиц лучше разместить в Wiki. С формирования списка стейкхолдеров начинается процесс анализа. Описывать и хранить все артефакты анализа в описании задачи таск-трекера будет неудобно. 

Создадим страницу на Wiki, в названии которой указывается номер и имя запроса на изменение. Добавляем ссылки на запрос на изменение и его вложения. Можно встроить запрос на изменение как iframe, чтобы все исходные данные были перед глазами.

Далее мы будем фиксировать всю информацию на этой странице, в том числе и список заинтересованных лиц. В итоге анализа у нас получится мини-ТЗ или SRS, описанные на одной странице в Wiki.

3. Формулируем верхнеуровневые пользовательские требования

Пользовательские требования основываются на бизнес-требованиях и описывают, какие возможности должны быть реализованы, чтобы достичь бизнес-цели. 

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

Способ выявления требований зависит от продукта, который нужно создать.

• Если нужно оптимизировать или автоматизировать существующие бизнес-процессы, подойдут опросы и интервью текущих участников процесса, наблюдение за текущей работой. Требования могут быть зафиксированы в виде диаграммы бизнес-процессов (bpmn-диаграмм) и сценариев использования (use case, use case diagram).

• Если у продукта есть аналоги на рынке, можно изучить ранее реализованные системы и документацию к ним.

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

Учитывая особенности задачи, можно составить следующий план выявления требований:

1. Анализ документации на смежные сервисы, которые участвуют в процессе работы со счетами клиентов банка.

2. Мозговой штурм со стейкхолдерами поможет выявить пользовательские требования, характерные для работы с «Общим счетом».

В запросе на изменение указано, что пользователь работает с общим счётом так же, как с любыми другими. Это требование неполное, противоречивое, и его невозможно протестировать. Но мы можем взять за основу самый простой основной сценарий открытия счёта и расписать последовательность действий пользователя, с учетом, что счётом будет пользоваться несколько клиентов:

Выделяем классы эквивалентности на основании имеющихся данных, получаем следующие классы:

1. Точка входа: мобильное приложение iOS (для физ. лиц и для юр. лиц), мобильное приложение Android (для физ. лиц и для юр. лиц), web-приложение (для физ. лиц и для юр. лиц).

2. Владелец счёта: физическое лицо, юридическое лицо, резидент, нерезидент.

3. Тип счёта: текущий, расчётный, кредитный, вклад, овердрафт, номинальный.

4. Валюта счёта: национальная валюта, иностранная валюта.

5. Пользователи счёта: физическое лицо, юридическое лицо, резидент, нерезидент.

6. Операция со счётом: открытие, закрытие, пополнение (наличные, безналичные), списание (наличные, безналичные), установка лимитов, просмотр выписки, подключение уведомлений об операциях, отключение уведомлений об операциях, закрытие счёта, добавление пользователя счёта, удаление пользователя, настройка ограничений для пользователей.

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

Получаем следующий список: 

1. Точка входа: мобильное приложение iOS (для физ. лиц и для юр. лиц), мобильное приложение Аndroid (для физ. лиц и для юр. лиц), web-приложение (для физ. лиц и для юр. лиц).

2. Владелец счёта: физическое лицо, юридическое лицо, резидент, не резидент.

3. Тип счёта: текущий, расчетный, кредитный, вклад, овердрафт, номинальный.

4. Валюта счёта: национальная валюта, иностранная валюта.

5. Пользователи счёта: физическое лицо, юридическое лицо, резидент, не резидент.

6. Операция со счётом: открытие, закрытие, пополнение (наличные, безналичные), списание (наличные, безналичные), установка лимитов, просмотр выписки, подключение уведомлений об операциях, отключение уведомлений об операциях, закрытие счёта, добавление пользователя, удаление пользователя.

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

Фиксируем договорённости в разделе «Резюме встреч». Можно фиксировать результаты сразу после встречи письмом на почту, но доступ к нему будет не у всех. Поэтому лучше фиксировать договоренности в Wiki, а в письме направлять ссылку на страницу.

У нас появились первые границы проекта, и теперь можно приступить к детальному изучению сценариев работы с текущим счётом физического лица. Самый быстрый способ — провести интервью с аналитиком, ответственным за сервис «Текущий счёт ФЛ». 

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

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

Документация сервиса по работе с текущими счетами содержит пользовательские и функциональные требования и бизнес-правила. На основании ранее выявленных бизнес-правил мы добавили на диаграмму сценарии просмотра условий использования счёта, проверки комплаенс (Compliance).

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

Проведённый ранее анализ позволит аналитику:

1. Составить список участников мозгового штурма на основании списка стейкхолдеров.

2. Следить за тем, чтобы участники встречи не сильно отклонялись от повестки на основании списка вариантов использования.

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

4. Составить шаблон для документирования выявленных в процессе мозгового штурма требований. 

Одним из способов документирования требований может стать карта пользовательских историй. В ней — пользовательские активности, задачи и истории. Основой карты — диаграмма сценариев использования. Уже сейчас на диаграмме можно выделить сценарии верхнего уровня: открытие счёта, управление пользователями, управление картами, которые станут пользовательскими активностями. И сценарии, которые детализируют верхнеуровневые: добавить пользователя, удалить пользователя, отозвать приглашение — они могут стать пользовательскими задачами или пользовательскими историями. 

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

Результаты мозгового штурма также нужно зафиксировать в Wiki  

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

3. Формулируем варианты реализации

Теперь нужно разобраться, какие части системы нужно доработать, — необходимо описать функциональные и системные требования. Мы помним, что время на анализ на стадии инициации ограничено, нет необходимости детально расписывать все требования. 

Вариант реализации — это краткое описание необходимых доработок с детализацией до названия подсистемы и краткой формулировки необходимых доработок.

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

В нашем случае можно описать следующий вариант реализации:

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

Мы не будем детально углубляться в методы оценки стоимости доработки — это зона ответственности менеджера. Хотя аналитик часто выполняет и эту часть работы, потому что он детально погрузился нюансы проекта.

Представим, что у нас есть оценка стоимости реализации проекта в человеко-часах.

Подводим итоги

После первичного анализа запроса на изменения у нас есть следующие данные:

• Описание (цели, бизнес-задача/проблема)

• Инициатор (заказчик) и список стейкхолдеров

• Приоритет (важность, срочность) реализации

• Статус (открыт, первичный анализ, оценка, отклонён, в работе, завершён)

• Краткий вариант реализации

• Оценка. Плановые трудозатраты на внесение изменений или оценка стоимости изменений

• Общее представление о необходимых ресурсах

Исходя из этих данных, менеджеры могут принять решение о целесообразности реализации проекта:

• Если потенциальная выгода от решения бизнес-задачи/проблемы превышает затраты на его реализацию, то проект имеет смысл.

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

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

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

Вряд ли кто-то из стейкхолдеров будет детально изучать составленные аналитиком артефакты, оценивая возможности реализации проекта. Требования не будут оценивать на полноту и противоречивость. Это не значит, что написанное в Wiki было сделано напрасно. 

На стадии инициации артефакты от аналитика — это скорее инструменты для выявления и анализа требований, чем их документирования. А если проект перейдёт на стадию планирования, составленные аналитиком артефакты станут отправной точкой для детального анализа требований и помогут составить план проекта. 

Я работала системным аналитиком, до курсов, но хотела немного расширить и упорядочить свои знания.
Я уже проходила курс Системный аналитик. Basic. Мне понравилось и я захотела продолжить обучение, поэтому пошла на курс «Системный аналитик. Advanced»
Мне понравились лекции и практические занятия.
Курсы мне помогли упорядочить знания, т.е. цели я достигла.

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

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

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

Курс помог систематизировать знания, а также узнать много нового.
Наконец разобралась в проектировании API, что очень нужно по работе.
Получила повышение на текущем месте с позиции Бизнес-аналитика до позиции Системного аналитика

Спасибо большое за образовательный курс! Мне действительно он помог стать более компетентным системным аналитиком. Узнал очень много нового и необходимого для моей профессии. Все преподаватели огромные молодцы!

Данный курс нацелен на людей, которые уже в системной аналитике и хотят прокачаться.
На момент покупки курса в системной аналитике была уже примерно года полтора-два, грейд Middle. Хотелось структурировать и углубить знания и прокачаться до Middle+. Курс объемный, включает в себя практически весь скоуп работ системного аналитика и даже немного больше.
Домашек много, проверяются они тщательно, это понравилось — много практики для закрепления материала.
Среди плюсов так же отмечу что преподавательский состав довольно сильный, чаще это ведущие аналитики на действующих проектах, поэтому знания были не дистилированные, а с примерами из реальной жизни.
Вывод по курсу такой: отлично подойдет для действующих аналитиков уровня Junior+ и Middle- которые хотят структурировать информацию и заполнить какие-то пробелы в знаниях. На выходе Middle+ сходу не получится — надо все тут же обкатывать на реальных кейсах, но наверно всегда так. Я видела курсы для СА от других платформ и Otus мне показался по наполнению и организации куда лучше остальных, перечислять платформы не буду — вы и так их все знаете)
Рекомендую!

Я давно работаю в системной аналитике (общий стаж аналитики (бизнес и системной) 15 лет). Но системная аналитика так развивается, что самостоятельно следить за всеми практиками я уже не смогла. На платформе OTUS курс построен следующим образом: разные блоки ведет определенный преподаватель. Лекции в форме вебинаров. На каждой лекции вы получаете не только сухую теорию, но и обсуждение вопросов и, самое главное, случаев из практики. Это действительно оказалось очень полезным.
В конце каждого блока теории мы выполняли Домашние задания. Хочу сказать, что это не просто тесты или ответы на теоретические вопросы — это именно практическое применение теории в работе. Домашнее задание проверяют не просто, ставя зачет, но и задают вопросы, можно также обсудить проблемные моменты, которые трудно даются в понимании. Обратная связь на высшем уровне.
По итогам обучения пишется курсовая работа (вспомним диплом ))). Действительно большой труд. Но, если вы справитесь — вы будете по-настоящему собой гордиться, и еще раз усвоите пройденный материал.
На каждой лекции также предлагается дополнительный материал для изучения, и не просто книги, но и различные статьи.
Говорить про этот курс можно много, но коротко моё мнение — курс отличный, всем аналитикам советую его пройти

Этот курс — реально рабочая история, я приобрел необходимые навыки, нащупал где зоны развития, заготовил с десяток книг, которые нужно прочесть. Но! Реально пришлось попотеть. Это не будет ни легкой прогулкой, ни просто обученеим. У меня в Омске занятие начиналось в 11 вечера и заканчивалось в час ночи =) Курсовую нужно писать не за день, у меня ушло на курсовую три полных дня, раскачка и набор высоты отдельно. Атмосфера на курсе рабочая. Темп хороший: с августа до марта время пролетело незаметно. Все преподаватели терпели нашу коллективную медлительность, помогали в ошибках в домашках, отмечу очень придирчивое отношение в домашках. Да, это — в итоге оказалось фактором того, что в темах, где было понятно плохо — пришлось слушать лекцию раза три и делать домашку тоже раза три, итерациями испарвляя ошибки, допущенные тк не все сразу становилось понятным и встраивалось. Но все это как раз и называется — встраивание навыков.
#Спасибо учителям
Всем преподавателям и кураторам, службам бэкофиса — низкий поклон, и отдельное спасибо Иннокентию, он настоящий лидер и тащит многое на себе. Мое почтение. Я очень хорошо знаю что значит, когда у тебя в подписи письма указано Lead Analyst
#Полученные резульаттаы
Пока курс шел — я на работе решал задачу по модернизации легаси монолита, так между делом я нашел в нем две грубые архитектурные ошибки, спроектировал и защитил проект на модернизацию, распилили мы этот монолит на микросервисы меньше чем за год — продукт заработал, сейчас нас ожидает миграция на несанционный стэк, далее исправить отсекающие уязвимости ИБ и мы готовы к промэксплуатации, надеюсь =). Курс был отличным способом отвлечься, верить в себя и фигачить как не в себя. Рекомендую!

Летом 2022 года задалась вопросом поиска очучения по системному анализу для повышения грейда до Сеньера. Наткнулась на Отус и курс «Системный аналитик. Advanced», изучила программу и поняла, что аналогов на рынке нет.
Курс оказался еще более полезным, чем я предполагала.
Программа построена по типу проработки требований для реальных проектов, поэтому все полученные знания можно сразу применять в работе.
Много пеподавателей, которые являются дествующими аналитиками в самых крупных компаниях на рынке. Дают интересную теорию и приводят примеры, с которыми сталкивались в реальных проектах.
На протяжении всего обучения необходимо выполнять домашние задания, которые проверяют кураторы и дают развернутую обратную связь.
Обучение проводится в вечерние время, при этом мне было удобнее смотреть в записи, т. к. есть возможность где-то ускорить, а где-то остановить или отмотать назад.
Записи всех занятий сохраняются и преподаватели дают все презентации. В общем времени на обучение и выполнение ДЗ достаточно, преподаватели и кураторы идут на встречу и готовы увеличивать срок сдачи заданий.
В конце обучения есть возможность написать и защитить итоговый курсовой проект на заданную тему или выбрать свою.
По итогам обучения выдается сертификат и УПК.
Я очень довольна этим обучением! Для тех, кто застрял в мидлах будет отличным толчком в развитии!
Искренне благодарю организаторов, преподавателей, кураторов и администраторов за знания, помощь, поддержку и комьюнити.

Рекомендую данный курс для тех, кто хочет улучшить свои навыки в бизнес и системном анализе. Ожидания от курса оправдались в 100кратном размере. Деньги потраченные за курс, стали самым лучшим вложением в проф. развитие за последние 5 лет. Благодаря навыкам полученным на курсе я уже повысила свой доход и позицию в компании. Но все таки самое главное это знания, которые я получила. Огромная благодарность учителям, организаторам и всем причастным к курсу. Отдельно хочется выделить подачу материалов: все очень грамотно, по сути и много практики. Понравилось, что прислушиваются к потребностям учеников. Везде и всем рекомендую курс. Даже провела краткий обзор данного курса для аналитиков своей компании.

Замечательный курс: очень сильные и отзывчивые преподаватели, структурированная программа обучения, оперативная обратная связь, доступная и лаконичная подача информации, много дополнительной литературы.
С большим удовольствием проходила курс.
Он позволил мне систематизировать и усовершенствовать уже имеющиеся знания и навыки, получить новые практические знания и мотивацию на их применение, да и просто расширить горизонты.
Хочу выразить огромную благодарность преподавателям. Они профессионалы своего дела, искренне делились своими знаниями и опытом, очень доходчиво и лаконично доносили материал, давали исчерпывающую обратную связь по домашним заданиям.
Отдельно хотела бы отметить Евгения Путилина и Анну Вязанкину! Мои фавориты!:)
Успехов и процветания ОТУСу! Спасибо, что делаете нас умнее!

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

Добрый день,
Всё понравилось, огромная разница с курсами где дают текст\видео материал, а потом как-то проверяют домашки (как тренажер-времяжор яндекса).
Основная ценность для меня — информация от том как оно устроено по уму (и вообще бывает) в других компаниях.
По темам всё вроде подобрано грамотно, единственный вопрос вызвал блок по базам данным, уж больно он насыщенный, и подозреваю коллегам у которых не было опыта с БД — было совсем уж сложно.
Рекомендации по курсу:
1) Проверить описание домашек
То что написано в презентации урока или озвучивает преподаватель, очень часто расходится с описанием в личном кабинете в ДЗ.
2) Вести какой-то общий (эталонный) проект на всех, наполняя его по мере прохождения.
3) Вывести отдельно список литературы даваемый на занятиях, чтобы было в одном месте

Я начал карьеру системного аналитика с 2016 г. в Санкт-Петербурге. У меня было подходящее образовательное направление «Бизнес-информатика» и опыт в проектировании и разработке DWH. В аналитику порекомендовал пойти знакомый front end разработчик, сказав, что я умею «копать» предметную область. Сейчас я работаю системным аналитиком в аутсорсинговой компании
При выборе курса я ориентировался на тематику, которая мне была интересна, как аналитику. Ориентировался я на «Проектирование API», «Проектирование архитектуры», «CI/CD». Дополнительными факторами послужили следующие:
Доступная цена курса, опытные преподаватели, наличие на курсах домашних заданий (из них можно выстроить собственное портфолио), удобный график занятий – 2 раза в неделю.
В сравнении с другими курсами структура тем и лекций охватывала весь аналитический цикл
В обучении понравилось:
Домашние задания, которые проверяют опытные преподаватели. Помимо формальной проверки в процессе общения я получал от каждого из них профессиональный опыт и обтачивал свой же подход к работе. Как результат, мои аналитические артефакты стали более выверенными;
Открытость преподавателей к обсуждению. С некоторыми даже ненадолго созванивался, чтобы прояснять конкретные вопросы;
Сколько бы я раз не опаздывал, а домашние задания всегда проверяли 🙂
Структура курса и охват аналитических знаний и навыков;
Возможность просматривать и пересматривать лекции – что весь материал навсегда остается с нами;
Групповые комнаты на практикумах.
Хотелось бы дополнить курс бОльшей линейностью. и глоссарием. Также, как мне показалось, одним из негласных запросов коллег был бизнес-анализ. Хотелось больше поупражняться в выявлении требований Заказчика.
 
Что мне дало обучение?
a.      Отточил текущие навыки, расширил свой кругозор
b.     Получил отзыв о домашних заданиях – для меня это очень важно. Хотел посмотреть, как мою работу видят другие эксперты и что они больше ценили у меня в домашках. Так я увидел свои сильные и слабые стороны
c.      На текущем месте работы вырос грейд с middle до middle+ (в компании каждые полгода мониторят soft и hard-skills)
d.     Увеличил свой оклад на 33%, более активно «крою» ипотеку:)
e.      На текущем месте работы привлекли к проведению технических интервью соискателей на должность системного аналитика

Это очень хороший, глубокий и подробный курс, который всесторонне знакомит с аспектами работы системного аналитика.
Курс скорее не для тех, кто только начинает, хотя для них он тоже будет полезен, курс скорее для тех, кто уже как-то сталкивался с системной аналитикой при решении различных рабочих задач и теперь хочет подробнее понять как решать их эффективнее и как системная аналитика помогает в их решении.
Курс разложен на блоки. Каждый блок логически перекликается с остальным и есть четкая road map: информация, даваемая на каждом следующем шаге, органично ложится на ту информацию, которая была дана на предыдущих.
Курс насыщенный, классный. Про некоторые вещи я узнал именно здесь, хотя с системной аналитикой связан довольно давно, а еще на некоторые удалось взглянуть с других сторон.
Очень чувствуется то, что преподаватели — практики. И информация, которую они дают, очень хорошо ложится на практическую деятельность: уже во время прохождения курса в своей основной работе удалось внедрить несколько вещей, о которых говорилось на самом курсе.
Ну и на занятиях любые вопросы приветствуются, сами занятия идут до того момента, пока будет дан весь материал (даже если это может выходить за временной диапазон). Т.е. если вы хотите получить информацию, то тут в этом курсе вы ее точно получите.