Как стать автором
Обновить

Бизнес против системы: учимся различать аналитиков в теории и на практике

Время на прочтение7 мин
Количество просмотров6.5K
Всего голосов 8: ↑4 и ↓40
Комментарии20

Комментарии 20

Актуальная для меня тема. Работаю в компании, где есть продажники, менеджеры проектов (на них лежит коммуникация и координирование, организационные моменты) и программисты. Необходимо закрыть этап выслушивания, анализа и перевода хотелок клиентов в таски для программистов.

Компания продуктовая, несколько проектов (SaaS). Продукты взаимосвязаны между собой и покрывают различные этапы бизнес процессов в предметной области (логистика). И по этой причине одна хотелка клиента может преобразоваться в таски для 1..n продуктов.

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

Какие варианты вообще есть?

Сами думаем над следующими:

  1. Обучение программистов предметной области

  2. Выделенный эксперт по предметной области

  3. Продукт овнер

Привет! Если не требуется глубокая проработка документации и разработчики готовы/могут самостоятельно проектировать решения, то напрашивается РО или хороший скилловый БА. Для быстрого аджайла системщик кажется избыточным в вашем случае

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

Так а БА же не сможет в технику. Не его задача. Будет каждый раз ходить к программистам с вопросом "А можно ли так сделать?". Ну или я не доконца понимаю роль БА.

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

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

Пример задачи.

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

Или например продумать обработку бэк-ордеров (это когда заказ исполнен не полностью, и на остаток надо оформить отдельный заказ).

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

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

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

В итоге вы встречали хоть одного системного аналитика, который рисовал структуру БД?

Каждый день до сих пор встречаю)

Я встречал

Здравствуйте.

Мы есть. Руковожу отделом из тринадцати, на данный момент, человек. Мы все умеем в ER, проектирование API, BPMN и прочие страшные аббревиатуры.

Я про БД спрашивал. А всё ваши аббревиатуры только для вас страшные. АПИ гораздо менее трудозатратно делать на лету, и в сваггере документировать.

Проджект- менджер, скрам-масьер, систем, бизнес и прочие аналитики, а ещё продукт оунеры нужны чтоб разговаривать на совещаниях вроде?

Зависит от темы встречи и с кем говорить. Например, для встречи с бизнесом(заказчиком): системный аналитик обычно не нужен (привлекать по-ситуации), БА обычно нужен, ПМ часто не нужен (если существует РО), РО нужен, скрам-мастер не нужен. А если внутренняя встреча про разработку фичи, то набор будет другой, соответственно

Я вот тут проводил вебинар по среднестатистическому тех.процессу производства среднестатистической Информационной системы. И как раз рассматривал роль Аналитиков (разных) на каждом этапе, используя проф.стандарт.. https://www.youtube.com/watch?v=Y66GY_k_bhs

Я в профессии с 2004 года. До сих пор не видела "среднестатистической ИС".

ИМХО, выморочная сущность.

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

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

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

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

Не нужно воспринимать "переводчик" настолько буквально) Язык - есть способ мышления, осознания и обработки/интерпретации информации, который также определяет модель восприятия реальности и процессов. Разумеется, речь идет не о банальном переводе терминов. Мне думается, что в тексте статьи это более чем понятно)

Напомните, что делает аналитик, столкнувшись с новой для себя предметной областью? Правильно - составляет глоссарий с определениями терминов и аббревиатур! Аналитик по роду своих обязанностей должен быть достаточно чётким и аккуратным в формулировках, чтобы не плодить и без того вездесущую неопределённость. Я это к тому, что "переводить" это совсем не то же самое, что "выяснять и объяснять".

На мой взгляд, перевод: "предметной области и образа мысли из одного в другой", "с идей хотелок на конкретные решения", "с языка бизнес целей на язык ТЗ и фичей для их достижения" и тп - хороший и понятный вариант объяснения. Впрочем, у каждого может быть свое мнение. Вам не понравилось это сравнение, мне понравилось. Это нормально)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий