Внутренне продолжаю наш спор с @andrei-danilian c созвона на тему “аналитики не нужны или их просто плохо научили”. У меня уже была попытка понять, зачем нужны системные аналитики. Там по описанию выходило, что они переводчиками работают. Давайте разберём описание чему учат в другой онлайн школе. Мне особенно нравится ход, что это курс где делают полноценного аналитика (у которого и бизнес-анализ, и системный анализ в арсенале).
Программа специализации «Профессия Системный аналитик PRO»
- Введение в профессию (3 недели)
Содержание блока:
- Кто такой системный аналитик и бизнес-аналитик, функции и задачи
- Жизненный цикл ПО, фреймворки разработки ПО
- Фреймворк для гибкой разработки продуктов Scrum
Результат:
Понимаете специфику работы системного и бизнес-аналитика, особенности работы команды и взаимодействия с ключевыми лицами
Окей, жизненный цикл у нас. Делаем ставку, что учат чему-то в рамках V-модели, с повторным проходом по “стадиям” ЖЦ.
- Бизнес-анализ и бизнес-процессы (5 недель)
Содержание блока:
- Современные подходы к БА
- Принципы BABOK
- Метрики, KPI
- Процессы AS IS
- Процессы TO BE
- Оптимизация бизнес-процессов
Результат:
Знаете как описать процесс и анализировать процесс. Умеете перекладывать требования в KPI процесса. Умеете оценить эффективность процесса и отслеживать изменения. Сможете выстроить процесс с нуля, а также оптимизировать существующий.
Тут интересно. Процесс у нас, а не система. И мы помним что “бизнес-процесс” это процесс организационный. При этом вдруг откуда ни возьмись KPI. А я-то думаю, почему метрики важнее результатов. Потому что эти метрики, у кого-то гвоздями прибиты, как показатель эффективности работы. Но допустим, здесь как будто бизнес-аналитик ходит по фирме (внимание вопрос по какой фирме, если вы например сервис делаете) и “анализирует” процессы. Как бы ищет, где плохо работает. Может он и не в фирме ищет, а в софте. Там неудобно кому-то заполнять нашу длинную форму. И вот это, что нашёл, предлагает починить. Должен бы предлагать.
- Анализ требований (5 недель)
Содержание блока:
- Типы требований: БТ, ФТ, НФТ
- Основные методы выявления требований: наблюдение, интервью, анализ документации и интерфейсов, анкетирование, рабочие группы, наблюдение, анализ легаси и UX
- Методы документирования требований: User story, use case, задачи в jira
- Прототипирование
- Описание бизнес-процессов: нотации и где они используются — BPMN 2.0, EPC, IDEF
- BPMN 2.0 (пулы, интеграции, основные понятия и построение модели верхнего уровня)
- Заинтересованные стороны
Результат:
Понимаете, что такое требования. Умеете их собирать, документировать, проверять на конфликты, приоритизировать. Знаете, как взаимодействовать с заказчиками. Умеете описывать бизнес-процессы в BPMN и различаете другие нотации
Требования само собой. Не выбраться из них. “анализ легаси” это очень интересно. Но наверно это как раз то, про что одногруппник писал “мы нашли сервис, в который разработчики не в состоянии быстро вносить изменения”. Здесь должна быть шутка, что анализировать легаси необязательно, желательно до такого состояния сервисы не доводить. Ведь легаси, это когда “всем было безразлично как пишется код”. Техдолг копился, копился, а потом вдруг у нас “big ball of mud”.
Use case у нас оказывается “документирование требований”::метод. И там дальше рисование картинок со стрелочками. По результату, кто у нас аналитик. Человек, который в состоянии поговорить с заказчиком. А потом записать текст с требованиями, и начать этот свод правил сводить между собой. Где граница, когда перестать сводить и с кем это делать непонятно. Мы помним, что системы уже большие. Не соберёшь ты по всей системе требования так, чтобы было непротиворечиво. Значит ты ограничен например, той же user story. А значит что? Значит связи с соседями не будут учтены. Синтеза нет. Про рисование ничего не буду говорить.
- Проектирование системы (1 неделя)
Содержание блока:
- Архитектура информационных систем
- Интеграции между системами
- Интеграции через SOAP-сервисы: xml, протокол soap, wsdl, xsd, soap ui
- Интеграции через REST API: протокол HTTP, принципы REST, как спроектировать RESTful сервис, работа с postman
- Основы баз данных
- SQL: структуры простых запросов, работа с таблицами, сложные объединения
- Основы языков программирования: навык чтения и понимания кода, понимание основ программирования
- Представление требований и постановка задач: виды представления требований, инструменты для представления требований, таск-трекеры
- UML:8 основных диаграмм и в чем их создавать
- Внедряете принципы предметно-ориентированного проектирования
Результат:
Понимаете архитектуру ИТ, разбираетесь в последовательности проектирования и интеграции. Умеете составлять задание на разработку, работать с SOAP и REST и БД, понимаете основы программирования, умеете читать код
Добрались до самого интересного. Я про это больше всего думала. Как будто у аналитика в голове должен быть кусок мастерства “проектирования”. Это единственное объяснение разделения труда, т.е. выделения отдельной роли от разработчика. Иначе они просто писатели. Нужен технолог. Но “1 неделя” это очень грустно. И никакого настоящего проектирования там почти нет. Про навыки программирования начальные любопытный кейс, не видела ещё ни одного СА, который может читать код. Т.е. тут скорее минималка, как у тестировщиков (SQL, postman, дернуть АПИ, найти документацию на это АПИ). Снова описать схему чего-то, спецификацию. Главный вопрос, который у меня был, что эту схему нужно “изобрести”. А не просто описать. Ответа чем аналитик её изобретает, каким мастерством, так и нет.
- Разработка, тестирование и интеграция (3 недели)
Содержание блока:
- Основы Git: основные команды Git на примере кейса, команды для работы с сервером, навык коллективной работы с версиями документации
- Языки разметки: markdown, asciidoc
- Тестирование: виды тестирования, приемочное тестирование, место аналитика в процессе тестирования, баги и постановка задач на доработку
Результат:- Понимаете основные языки разметки, умеет пользоваться Git (работа с версиями, отслеживание изменений). Понимаете этапы тестирования и приемки ИТ-продукта. Умеете оценить, насколько готовое решение соответствует требованиям заказчика
Снова приехала часть работ тестировщика и документация. Кто знает из какой версии инженерного процесса у нас “интеграции”?
- Сопровождение и утилизация (4 недели)
Содержание блока:
- Понятие сопровождения системы
- Service desk
- Понятие утилизации
- Подготовка к утилизации или замене системы
Результат:
Понимание способов поддержки и сопровождения систем (часто СА - последняя линия ТП), обновления ПО
Утилизация! И снова техподдержка и часть от тестировщиков (заведи баг, отдай на переделку).
Есть ещё один вопрос у меня, на который нет ответа. У нас в изобретении есть две части: функциональная и конструктивная. Как это выглядит в нашем софте. От бизнес анализа ожидается модель. Даже наверно модель данных и алгоритм. Потому что к сожалению или счастью я не могу как разработчик придумать как правильно считать налоги в Египте. Но проблема в том, что рядовой бизнес аналитик тоже не может. Нужен некий бизнес-архитектор. А на самом деле видимо прикладной методолог. Он изобретает модель. А уже разработчики изобретают как это технически воплотить. И спецификации на схемы в БД, разработчики в состоянии сами себе сделать. Особенно с учётом того, что работающую сходу модель сделать сложно и что-то придётся менять по ходу. Ещё одно я не могу понять. Как быстро тестировать эти модели данных. Окей, у товарищей настоящих инженеров, цифровая модель самолёта тестируется, а настоящий самолёт делается потом. У нас и модель, и воплощение цифровое. Но на самом деле, чтобы закодить что-то более-менее сложное нужно много времени. И я не могу сейчас выдумать, как тут сделать MVP. Какое-то оно по объёму и количеству возможных косяков совсем не minimal. TDD тоже тут не поможет.
