Comments 20
Актуальная для меня тема. Работаю в компании, где есть продажники, менеджеры проектов (на них лежит коммуникация и координирование, организационные моменты) и программисты. Необходимо закрыть этап выслушивания, анализа и перевода хотелок клиентов в таски для программистов.
Компания продуктовая, несколько проектов (SaaS). Продукты взаимосвязаны между собой и покрывают различные этапы бизнес процессов в предметной области (логистика). И по этой причине одна хотелка клиента может преобразоваться в таски для 1..n продуктов.
Пробовали системного аналитика - не взлетело. Концентрировался на одном проекте, проблемы из-за не знания предметной области. И человек до этого работал в системных интеграторах, а у нас тут аджаил. В общем сначала уходила неделя на тонну текста, потом это откладывалось, потому что кодить это полгода. И так по каждой хотелке пользователей.
Какие варианты вообще есть?
Сами думаем над следующими:
Обучение программистов предметной области
Выделенный эксперт по предметной области
Продукт овнер
Привет! Если не требуется глубокая проработка документации и разработчики готовы/могут самостоятельно проектировать решения, то напрашивается РО или хороший скилловый БА. Для быстрого аджайла системщик кажется избыточным в вашем случае
Да, программисты сейчас этим и занимаются, в целом ок. Просто работы много. Хотелось бы разгрузить.
Так а БА же не сможет в технику. Не его задача. Будет каждый раз ходить к программистам с вопросом "А можно ли так сделать?". Ну или я не доконца понимаю роль БА.
Возможно я не так понял постановку проблемы, но выслушивание клиента - это не системный анализ, потому что совмещать одно с другим достаточно трудно и замедляет работу с техникой. Уточнение желаний и перевод в таски вполне по силам для грамотного БА. Да, ему придется спрашивать определенные моменты по технике у разрабов (количество вопросов также зависит от скилла БА) и он не будет проектировать. Если нужно закрыть и то и другое, то это похоже, как раз, на фуллстек аналитика или некоего бизнес-архитектора) но его еще найти надо и стоить он будет прилично, в случае хорошей квалификации.
Может быть, вам просто взять для разговоров и для проектирования двух разных людей примерно миддл уровня? Их и найти на рынке проще будет. Или попробовать навалить РМ внешние коммуникации?
Пример задачи.
В одном из проектов есть учет по SKU (уникальный ид номенклатуры). Необходимо сделать поддержку партийного (номер партии/лота, например для товаров со сроком годности) и серийного (например серийный номер ноутбука) учета.
Или например продумать обработку бэк-ордеров (это когда заказ исполнен не полностью, и на остаток надо оформить отдельный заказ).
Тут надо знать предметную область, ее особенности. Плюс знать текущий проект и его функции, чтобы расписать на концептуальном и функциональном уровне что и где поправить и доработать. В дебри технической реализации лезть не нужно. Но нужно понимать, что есть сущности и связи между ними (что по факту уже близко к структуре БД).
Описание должно быть довольно компактным, а не на десятки страниц, как было с тем системным аналитиком. Человек должен понимать, сколько примерно делать то, что он там придумал (можно и у программистов спросить в сложных случаях). Потому что аджаил, и пользователь не будет ждать полгода. Т.е. еще нужно и уметь приоритезировать, облегчать, выделять главное.
В итоге вы встречали хоть одного системного аналитика, который рисовал структуру БД?
Проджект- менджер, скрам-масьер, систем, бизнес и прочие аналитики, а ещё продукт оунеры нужны чтоб разговаривать на совещаниях вроде?
Зависит от темы встречи и с кем говорить. Например, для встречи с бизнесом(заказчиком): системный аналитик обычно не нужен (привлекать по-ситуации), БА обычно нужен, ПМ часто не нужен (если существует РО), РО нужен, скрам-мастер не нужен. А если внутренняя встреча про разработку фичи, то набор будет другой, соответственно
Я вот тут проводил вебинар по среднестатистическому тех.процессу производства среднестатистической Информационной системы. И как раз рассматривал роль Аналитиков (разных) на каждом этапе, используя проф.стандарт.. https://www.youtube.com/watch?v=Y66GY_k_bhs
Как же утомили эти сравнения аналитика с переводчиком! Если бы в работе бизнес/системного аналитика всё сводилось к тому, чтобы перевести с бизнесового языка на технический, то никто бы в разумном уме не платил бы им такие деньги.
Однако, одна из ключевых сложностей в работе аналитика как коммуникатора заключается не в использовании разной терминологии и областях деятельности представителей бизнеса и ИТ, а в том, что эти люди по-разному мыслят, используют отличные ментальные модели.
Представим, что существует лишь проблема на уровне нестыковки языков - в таком случае компании в задачах, где не требуется айтишное решение, но нужно, например, организационное изменение, обходились бы без аналитиков.
Не нужно воспринимать "переводчик" настолько буквально) Язык - есть способ мышления, осознания и обработки/интерпретации информации, который также определяет модель восприятия реальности и процессов. Разумеется, речь идет не о банальном переводе терминов. Мне думается, что в тексте статьи это более чем понятно)
Напомните, что делает аналитик, столкнувшись с новой для себя предметной областью? Правильно - составляет глоссарий с определениями терминов и аббревиатур! Аналитик по роду своих обязанностей должен быть достаточно чётким и аккуратным в формулировках, чтобы не плодить и без того вездесущую неопределённость. Я это к тому, что "переводить" это совсем не то же самое, что "выяснять и объяснять".
На мой взгляд, перевод: "предметной области и образа мысли из одного в другой", "с идей хотелок на конкретные решения", "с языка бизнес целей на язык ТЗ и фичей для их достижения" и тп - хороший и понятный вариант объяснения. Впрочем, у каждого может быть свое мнение. Вам не понравилось это сравнение, мне понравилось. Это нормально)
Бизнес против системы: учимся различать аналитиков в теории и на практике