Комментарии 26
Попытка, конечно, интересная, но и, как всегда, слишком короткая. В надежде на быстрый результат? Это что ж, умение важное такое — быстро что-то проговорить, и думать, что дело сделано. "Грумминг" провели? Галочку поставили? Молодцы!
А, теперь, ближе к делу.
Как ни крути, а дело в том, что да, аналитики нужны. Которые возьмут от заказчика то, что тем нужно, и дадут разработчикам то, что тем нужно. Можно ли обойтись бес посредников? Наверное, да. Но для этого должен быть готов универсальный продукт, где заказчик сам себе рисует требования. Но это уже ближе к ChatGPT, не так ли? Возможно, к этому дело и идёт. Это, ведь, ещё Дональд Кнут говорил о литературном программировании, когда можно на человеческом языке всё описать и получить на выходе готовую систему. Тогда и программисты-то не нужны: законодатели сели бы, прописал бы все правила бухгалтерского учёта, этиправила пропустили бы через аналог ChatGPT, получили бы некое СПО и, потом, установили бы это ПО на все компьютеры страны. Не так ли? Вот это, точно, была бы сказка!
Спускаемся на уровень ниже.
Кто такой системный аналитик? Это человек, который знает системы. Он владеет системной методологией. Он знает, что у этой системы может быть вот такой куцый набор функций, а вот у той — просто широчайший. Соответственно, у разных систем будет и разный состав компонентов. физическая реализация этих систем также будет различной. Но можно предложить некую общую архитектуру, куда удастся уложить и простую систему, и сложную систему. Тогда системный аналитик сможет настоять на том, чтобы перед обслуживанием заказчиков были разработаны определённые библиотеки общего назначения, покрывающие основные нужды, специальный АРМ для проектирования (в том числе, и совместного).
"Бизнес-аналитик" — это попытка уточнить понятие "системный аналитик" в том плане, что это такой аналитик, который хорошо разбирается в предметной области, но как и всякий аналитик, имеет техническое образование, поэтому способен переводить требования заказчика на язык теории систем.
Но! Заковыка и большая проблема заключается в том, что с точки зрения системного анализа, мы должны провести этот самый анализ и получить на выходе чёткую спецификацию предметной области в терминах этой самой пресловутой теории систем. (А кто-нибудь видел эту самую теорию систем в лицо, а?) И тогда с заказчиком можно будет разговаривать уже на языке теории систем, то есть — на уровне системных компонентов и конкретных алгоритмов, наполняющих конкретную систему.
То есть!
Что является результатом системного анализа? Некая общая модель, то есть — описание некой обобщённой системы на концептуальном уровне. Концептуальный уровень описывает, фактически, семейство различных моделей уже логического уровня (различного уровня сложности, с различным набором компонентов, с различающейся логикой работы отдельных компонентов), реализующих общую модель концептуального уровня. Концептуальный уровень отвечает на вопрос ЧТО (делает данная система). Логический уровень отвечает на вопрос КАК (она это делает). Разработчику сообщается именно конкретная модель логического уровня. А уже он предлагает и реализует различные модели физического уровня в рамках выбранной модели логического уровня.
Я всегда задаю вопрос на собеседованиях: если у вас 3 заказчика и они вам говорят противоположные требования к системе, что вы будете делать? По ответам всегда понятно, имеет ли кандидат реальный опыт работы БА.
Беда! Противоположные требования относятся к различным моделям логического уровня. Нельзя одновременно делать разные системы. Здесь делается принципиальная ошибка. Но на каком уровне присутствует эта ошибка? Возможно, на логическом. Значит, какой-то заказчик плохо понимает свою же область. Но это сомнительно. Значит, проблема лежит на концептуальном уровне, и имеются проблемы с формализацией предметной области.
Без конкретных примеров довольно трудно представить дальнейший ход событий. Можно представить и сценарий с возникновением трёх различных команд для работы с определённым заказчиком и дополнительной центральной командой для работы над общей частью, и сценарий с параметризацией группы компонентов и выборе учётных параметров под конкретного заказчика в момент первого запуска системы, и, даже, сценарий, где заказчику объясняют, где заказчик ошибся (вдруг, какое-то требование неуместное?).
Но! С точки зрения системного анализа, само понятие требования выглядит крайне сомнительным. Какие-могут быть новые/неизвестные требования, если мы провели системный анализ, выявили все требуемые алгоритмы? Мы должны придти к заказчику уже с готовым набором моделей логического уровня, где все потенциальные требования уже учтены, и нужно выбрать из списка ту модель, которая лучше всего подходит заказчику в данный момент. В результатах системного анализа также хранится информация о том, сколько и какая модель реализуется или трансформируется из другой модели и, вообще, трансформируема ли (а то, если трансформировать нельзя, то о чём речь?).
И тогда с заказчиком можно будет разговаривать уже на языке теории систем, то есть — на уровне системных компонентов и конкретных алгоритмов, наполняющих конкретную систему.
С заказчиком никогда не придётся разговаривать на языке теории систем.
У заказчика область определения - бизнес структура и бизнес процессы в функциональных границах его бизнеса. Если бизнес заказчика не системный анализ (такое случается), то ему нет смысла (непрофильно и дорого) содержать системных аналитиков в области автоматизации его бизнеса.
Собственно, БА должен согласовать/разработать требования, а затем бизнес процессы и передать их системному (функциональному, техническому) архитектору для разработки архитектуры системы, и далее - по структуре разработке, внедрению, эксплуатации, обслуживанию. В процессе разработки, испытаний, сдачи заказчику БА должен согласовать с заказчиком, что требования выполняются и реализация процессов соответствует. Затем начинается песня о доп. требованиях.
"Я всегда задаю вопрос на собеседованиях: если у вас 3 заказчика и они вам говорят противоположные требования к системе, что вы будете делать? По ответам всегда понятно, имеет ли кандидат реальный опыт работы БА."
А какой ответ верный?
Я бы их вместе собрала пусть (передерутся) договорятся))) Опыта у меня нет, я ток учусь. И прав тоже на Хабр нет)) Я могу пока только под свежими статьями комментировать и только под комментами других пользователей - это так дискриминационно(((.
Сейчас буду делать домашку по CRISP-DM. Попробую систематизировать не системное. Там как раз описаны ситуации когда на выходе мы получаем не то, что хотел заказчик. И по схеме в этом случае мы должны вернуться в исходную точку - к бизнес анализу. И вновь пройти все этапы от сбора данных, определения целей и методов и т.д. до оценки результата. И так по кругу, до тех пор пока Заказчик не будет удовлетворен результатом. И только после этого наступает этап внедрения.
Так что то, что Вы описываете как не системное поведение Заказчика(ов) является обычным процессом работы с данными. И даже утверждение "если трансформировать нельзя " (или реализовать "хотелки" Заказчика), тоже является частью методологии работы с данными. Системный анализ предусматривает возможность неоправданности реализации тех или иных проектов, в этом случае, в идеале, это выяснить на этапе сбора данных и первичного анализа, а не на этапе внедрения.
Согласитесь, Заказчику лучше сразу узнать, что его идеи не реализуемы или не оправданны, чем потратить месяцы на анализ и разработку, привлечь кучу специалистов, купить железо, выделить вам носителей hard scills из своей штатки и, в итоге, получить нерабочий продукт. А потом узнать, что он изначально был не реализуем.
Хороший системный аналитик данных на 50% состоит из опыта и на 50% из знаний. У меня нет ни того ни другого - я плохой аналитик. Поэтому процесс обучения в системном анализе бесконечен. Опыта недостаточно - нужно все время учиться. И если в чем то Вы перестали видеть систему, то значит пора учиться ее видеть...
Киньте помидоркой - домашку легче будет сделать))
А какой ответ верный? Я бы их вместе собрала пусть (передерутся) договорятся
На мой взгляд это самый верный ответ, в том плане, что БА должен помогать заказчикам договорится (свести их в одной переписке, комнате, чате) - т.е. занимать проактивную позицию, а не ждать финального ТЗ и не работать "с одним из них самым главным". И с другой стороны БА не должен брать на себя эту ответственность - решать и договариваться должны Заказчики. Иногда слышу варианты: я решу сам что лучше для системы и впишу в ТЗ. А потом на ПСИ сюрприз сюрприз ))
Спасибо за пояснения. У нас на работе бывают очень жаркие дискуссии и не всегда они приводят к лучшей реализации. Иногда после совместного решения проблемы только увеличиваются, иногда директор принимает решение, которое изначально не оптимально. Решение директора - реальность в которой приходится жить. Она так видит. И если коллективные решения мы можем пересмотреть после реализации, то решения руководителя безапелляционны.
заказчиков конечно может быть много, но существует Product Owner и он один.
И с другой стороны БА не должен брать на себя эту ответственность - решать и договариваться должны Заказчики
Не совсем. Если всех заказчиков слушать, будешь иметь в каждом отделе один и тотже KPI считающийся совершенно по разному. И для отелов как бы норм, а на уровне всего предприятия - это ж...па. И нормальный BA увидит это и до PO донесет мысть, что если кому-то в принципе интересно как-то от уровня отделов поднятся до цифр на уровне предприятия - то надо требования стандартизировать, и иногда в приказном порядке.
Спасибо за статью, прочитал с удовольствием!
Однако попробую кое-что дополнить в меру возможностей.
В ООП-разработке есть такое понятие "божественный класс".
Класс, который делает все и сразу.
В вашем описании БА выглядит, почему-то, как "божественный класс".
Обычно это происходит несколько иначе.
Делить СА и БА не имеет смысла, так как в крупной системе эти элементы будут плотно переплетены.
Ну либо вы раздуете штат в 2 раза и увеличите плечо согласований.
С учетом, что IT сотрудник - это дорого, то "дуть штат" заказчики не любят.
Например:
Заказчику требуется какая-то бизнес фича,
ее потребуется перевести с языка заказчика на язык разработчика.
Но прежде чем ее переводить - нужно оценить ее исполнимость, иначе есть риск того, что БА подпишется под неисполнимое в рамках бюджета задание.
Эта ошибка, кстати, встречается часто.
Более того, у каждого задания есть несколько вариантов исполнения, а значит требуется определить граничные условия.
Вот и получается, что БА должен быть немного разработчик, чтоб понимать, как это можно сделать " в теории", чтоб задать правильные вопросы.
Как это будет "на практике" - финально решит разработчик или тим лид исходя, как раз, из граничных условий.
Если же БА попробует сам спрогнозировать финальное решение на уровне кода и далее будет требовать исполнения "именно так",
то скорее всего это приведет к низкому качеству кода и сложности его поддержки.
Разработчик в 99,9% случаев напишет более оптимальное решение и выберет паттерн, который лучше соответствует задаче.
Далее потребуется зафиксировать User Flow.
И тут БА аналогично потребуется лишь на входе, так как далее задачу возьмет себе Тестировщик и Дизайнер.
Задача БА на этом этапе отрисовать каркас переходов и не более.
Как их лучше расположить и какие цвета выбрать - скажет дизайнер.
Как сделать так, чтоб никто не нажал лишнего - тестировщик.
Следом потребуется хоть как-то оценить вопрос железа.
Где будет развернуто ПО и как именно, какие есть условия по безопасности и т.п.
И опять же БА нужно задать правильные вопросы.
Однако задачей будет заниматься DevSecOps и это правильно.
Вот и получается, что БА подключается только в самом начале,
на этапе "согласования и запуска", а далее вопроса более не касается.
А если касается - значит плохо расписана спецификация и требуется уточнение.
Потому и знать БА приходится очень и очень много, но без глубины.
БА выступает в роли справочника, который сможет направить заказчика в нужное русло.
Как итог БА потребуются:
1) Хотя бы общие принципы передачи информации по сети (модель OSI).
2) Хотя бы базовое понимание разработки и принцип работы с фреймворками.
3) Хотя бы базовое понимание верстки сайтов (HTML+CSS+JS).
4) Хотя бы базовое понимание разных видов API (REST обязательно).
5) Хотя бы базовое понимание того, как ПО деплоится на сервер.
6) Хотя бы базовое понимание того, какая будет скорость ответов при том или ином решении (обязательно понимать разницу между ответами 200,300,400,500),
а самое главное почему ответ пользователям Москвы придет быстрее, чем пользователям Владивостока.
7) Хотя бы базовое понимание работы с БД.
Многие заказчики считают Excel базой данных и будут не понимать, почему нельзя использовать формулу из excel.
8) Иметь громадный уровень переговорных навыков, потому что потребуется много общаться со всеми подряд ради общей цели :)
А вот бегать и следить за правильностью исполнения - это уже к тех лиду, тим лиду, РМ-у и т.п.
У кого как принято, так сказать.
Но точно не к БА.
Недавно, кстати, комментировал схожую статью,
только она была написана от лица тестировщиков:
https://habr.com/ru/companies/samolet/articles/841906/
Предполагаю, что некоторые мои мысли оттуда будут полезны и здесь.
Цитаты:
"Попробую расписать процесс, как его вижу я со своей колокольни.
Прошу сразу камнями не закидывать, так сказать мнение автора может не совпасть с вашим.
И надеюсь, что мое видение будет вам полезно в работе.
По правильному, аналитик перед разработкой создает спецификацию того, что требуется создать.
Он создает это не просто так, а для того, чтоб разработчик мог "не думать" и делать то, что написано.
Сказано 4 ножки у табурета и высота в 2 бутылки 0.5 Кока-колы - делаем 4 ножки и высота в 2 бутылки.
Не сошлось - вопрос к спецификации.
Причем делает он ее не абы как, а подробно, детально прописывая все, что потребуется знать разработчику и РМ."
"Следом идет роль РМ, который по сути должен получить подтверждение от Заказчика, что это действительно тот стул, который имел ввиду заказчик.
"От нас точно ждут табурет? Не стул, не кресло, не скамью? Табурет?" - должен спрашивать РМ у заказчика.
Мнения разошлись - спецификация уходит обратно к аналитику.
Мнения сошлись - информация идет на уровень ниже."
"Далее начинается уровень Разработчика."
"После этого действительно наступает уровень Тестировщика."
Надеюсь, что комментарий был для вас полезен и поможет дополнить, при необходимости, статью :)
Спасибо за ссылку, всегда очень интересно, как работу аналитика представляют себе другие эксперты. Но с вами я не согласна, БА не требуется (в общем случае) понимание верстки сайтов (HTML+CSS+JS) если он работает над мобилкой. И полный перечень вашего списка любому БА не нужен.
Если БА не работает с интеграциями, имеет права не знать REST. А если понадобится - узнает и научится на верхнем уровне.
БА - точно не технарь, он на стыке. Поэтому и продуктовую часть знает (не как РО), и технологию (но не как разработчик). Скажу откровенно - я не знаю, почему формулы excel нельзя использовать в БД. Но я на 200% знаю, что я могу пойти к разработчику, узнать почему и смогу пойти и рассказать это Заказчику так, что он поймет )
почти верно, но тут "должен спрашивать РМ у заказчика" ошибка. С заказчиком по требованиям таки общается BA. Иначе PM тут будет испорченным телефоном.
Вы не учли специфику организации работ в госкомпаниях.
Очень часто бизнес-требования до ИТ команды спускаются сверху в виде ТЗ, которое вполне добротно составил бизнес-аналитик и на которое предварительно уже посмотрели ключевые айтишные персоны (тот же архитектор и рукпроекта), чтобы оценить реализуемость и бюджет. Но дальше этот артефакт передаётся на вход системного аналитика и архитектора для детального анализа требований проектирования системы.
Получается, что в силу организационной структуры и устоявшихся бизнес-процессов автоматизации деятельности крайне затруднительно тесно сплести этапы выявления потребностей и проектирования решения.
Грамотное описание задач БА. Встретишь не часто. Если коротко, то БА - это внутренний заказчик для команды разработки, который в процессе разработки должен осуществлять авторский надзор на всех этапах и помнить, что программисты народ специфический: документацию не читает, а делает так, как сам понимает. Т. е. ещё одна задача для БА: "бить по рукам программисту", чтобы делал то, что написано в проектной документации. Более подробно можно почитать в 2-х томнике А. А. Цветков. "Теория и практика бизнес-анализа в ИТ". - изд-во "Директ-Медиа". Москва-Берлин.
"бить по рукам программисту" - это я люблю. И тыкать в ненужные ему бумажки. Значит я правильно выбрала новую профессию))
Будьте аккуратны. Разработчик лучший помощник аналитика, друг и советчик. И приемщик вашей работы. С ним нужно дружить, любить его и ценить.
Иногда хочется конечно бить и даже убить, когда написанное ТЗ игнорируется полностью, а разработчик делает "как ему подсказывает здравая логика". Здесь всегда можно найти момент личного/профессионального роста: а может мое ТЗ никому не понятно? а может нужно было провести грумминг? а может нужно было рассказать что мы вообще делаем и зачем?
Мы на одной работе писали СЭД с нуля. Делали продукт почти 2 года. Через 2 года выяснили (как обычно случайно), что команда разработки не понимает, что такое Входящие, Исходящие, и вообще для чего нужна СЭД. Это был провал команды БА, до сих пор его помню (
Получается хороший БА должен быть еще немного юристом, что бы объяснить важность СЭД для заказчика? Некоторые штрафы могут быть существенны - особенно в государственных, муниципальных закупках, где СЭД применяется по закону. А прослеживаемы товары? Документы по их обороту проходят только через ЭДО, в том, числе и по части оборудования, на котором разработчики работают (Мониторы и проекторы зарубежного производства). Получается разработчики совсем не боятся кнута (штрафов)? Правильно это же не им прилетит, а Заказчику. Был случай в централизованной бухгалтерии истекли ЭЦП у нескольких учреждений в срок сдачи отчетов, а системный администратор не изготавливает новые ЭЦП - нет настроения... По-хорошему человек 2 недели не понимал. Тогда мы (ответственные за представление отчетности) собрались и пошли к нему. Сказали за непредоставление отчета - штраф 200руб. за каждого физика, их около 200. Штраф получается 40 000. Платить будешь сам. Тогда это были существенные деньги. И хоть по закону с него их вряд ли можно было взыскать, но ему хватило суток что-бы выпустить все новые эцп. А в целом у нас были хорошие отношения - просто сис. админы и правда не всегда понимают почему мы такие злые.
Бизнес аналитик это проджект менеджер + тестировщик 😂 обычно бесполезное создание которое не может донести требования заказчика до разработчика
В каждой компании этв роль как и все другие типа продакт овнера - отличается. Имхо тут нет стандартизации
Поясните, пожалуйста, один момент.
На каком этапе взаимодействия с Внешним Заказчиком подключается бизнес-аналитик?
Что бы начать работать с Заказчиком, должен быть Договор. Работа без договора - нарушение Административного кодекса, если не ошибаюсь...
То есть бизнес-аналитик подключается после заключения Договора на подготовку ТЗ и выясняет, что надо и что не надо Заказчику. БА согласует ТЗ со всеми стейкхолдепами и после этого с Заказчиком заключается Договор на разработку проекта. Или не заключается :)
Я правильно понимаю?
Спрашиваю потому что мой опыт ограничивается работой в маленьких компаниях и в основом с нетрадиционными отношениями между Заказчиком и Исполнителем :)
Спасибо за статью, с интересом прочитал, но (IMHO!) описан фулл-стек аналитик без функций системного (без проектирования системы) :) Вы ведь видите в скоупе БА работу с требованиями, документацию, приемку, так?
А кто занимается формулировкой потребностей/задач/проблем на бизнес-уровне без оглядки на то, как эти проблемы будут решаться? Кто ставит задачи на настолько абстрактном уровне, что информационная система будет рассматриваться только как одно из возможных решений?
Сказочный вопрос: кто такой бизнес-аналитик?