Олег, спасибо за статью. Кажется, что системное мышление, это довольно редкая компетенция у специалистов в продуктовых командах, что в ходе работы может прмвести к, так скажем, недопониманию внутри команды. Вопрос - как решаете эту проблему (если она, конечно, имеет место) - у вас безоговорочный авторитет или пользуетесь чем-то особенным для представления проблем и их решений с т.з. системного мышления, чтобы команда их поняла и приняла?
Ссылка на статью для чайников - это не вам в укор, это первое, что попалось в гугле:) Так что прошу прощения, если зацепил.
То что для проектирования систем нужно ее описание более комплексное, чем дает BPM-схема процесса - без сомнений. Но вины BPMN тут нет. Даже не представляю, как только с помощью схемы процесса можно проектировать какие-то решения.
Предложенная информационная модель подходит для структурирования предметной области при ее исследовании, но и ее, как мне кажется, будет недостаточно для проектирования системы.
Я бы добавил к ней таблицу сценариев использования со ссылками на элементы модели. Так в модели появится некоторая динамика и понимание последовательности смены состояний и отношений ее элементов.
1. в открытых источниках огромное количество информации о том, как правильно «описывать бизнес-процессы» с помощью нотации, но ничего нет о том, как затем использовать «правильные описания бизнес-процессов»;
Во-первых, в такой формулировке - это проблема открытых источников, а не нотации. Вы например также не пишите как с использовать правильно описанные смены состояний в ваших категориях. Во-вторых, о том как использовать BPMN-модель процесса, вам смогут рассказать бизнес-аналитики (например, при их оптимизации и автоматизации) или разработчики систем BPMS, где автоматизируются последовательности выполнения задач и проверки условий. Из своей практики, описание БП хоть в какой нотации используется для того, чтобы показать бизнесу где дыры в ответственности или чтобы сам бизнес получил формализованное представление своих процессов. На этой же схеме, например, можно очертить границы проекта автоматизации.
2. нет примеров, как на основании информации, переданной через схему, можно принять какое-то решение, или что-то спроектировать, или решить какую-то конкретную управленческую или техническую задачу;
Это расширение первого вопроса. Можно просто погуглить "оптимизация БП BPMN".
3. если схема BMPN считается некоей моделью, и она служит основанием для набора свойств проектируемого программного комплекса, то должны быть примеры однозначного сопоставления элементов этой модели с конкретными свойствами или элементами программы, но таких примеров тоже нигде нет;
Вы делаете предположения, за которое BPM-схема не отвечает. Она отвечает за то, чтобы графически отобразить бизнес-процесс. Не свойства системы, не ее свойства, ни элементы программы, а то какая последовательность действий, распределение их между участниками этого процесса и условий позволит прийти к результату бизнес-процесса.
4. если BMPN является инструментом для решения определенных задач, то должна была бы сохраниться история появления такой проблемы, которую нельзя было решить другими имевшимися средствами моделирования, а также сведения о том, чего именно не хватало для решения проблемы, и, соответственно, изначально сформулированные требования к новому инструменту, однако, ничего подобного в открытых источниках не найти.
Что BPMN, что UML и пр. создаются не добрым и светлым сообществом, а большими софтверными компаниями или консорциумами. Они, главным образом, преследуют свои цели - автоматизацию процессов в своих больших компаниях, продажу ПО для проектирования ПО, использующих конкретную нотацию. При этом всячески давят конкурентов. И иногда просто не остается выбора, какую нотацию или какое ПО для проектирования выбрать.
UML - это эхо эпохи CASE-средств от IBM, когда в 90х решили, что программисты не нужны и проектирование бизнес-ПО можно отдать на откуп менеджерам/аналитикам, которые расставили бы элементы нотации в нужном порядке. Но не задалось.
BPMN - это визуализация языка BPEL (Business Process Execution Language) от Microsoft и IBM. Язык описывал оркестрацию веб-сервисов, к нему решили прикрутить визуализатор и получилась нотация. А вот тут задалось, пользуемся (почти) всем айти:)
Проектировать ПО/системы на основании только BPMN это бесперспективно. Но тут опять же вагон подходов в т.ч. в плане нотаций - от нотации "стрелочки и квадратики" до C4 и пр.
Плюс свой отпечаток накладывает все еще популярный Agile, при применении которого, наличие обширной документации с описанием "полноценно смоделированного последовательного перехода между состояниями системы" имеет меньший приоритет. Во многом поэтому умирает UML.
По итогу, BPMN крутая штука, если использовать ее по назначению и не добавлять ей новых смыслов. Она потому и простая в освоении нотация, потому, что в ней многого нет. А то, что есть позволяет решать некоторые задачи. Поэтому я все-таки не стал бы отказываться от нее.
Марина, то что вы написали о работе аналитика больше похоже на работу секретаря для разработчика - сходи поговори с заказчиком, запиши, что он хочет, передай разработчику, зафиксируй, что сделал разработчик. И это не похоже на хоть сколько-нибудь сложную интеллектуальную аналитическую деятельность, за которую нужно платить деньги и которая необходима в каком-либо подходе при разработке ПО.
Различия системного и бизнес-аналитика, это как минимум разное количество страниц в соответствующих профстандартах. а как максимум, они не посредники - бизнес-аналитик выстраивает и оптимизирует бизнес-процессы, а системные аналитики проектируют ПО.
У вас, судя по тексту, сложилось некорректное понимание функциональности аналитиков. Надеюсь, подготовка к написанию книги поможет расставить все на свои места.
Спасибо за статью не про найм и обучение аналитиков:) Но по тексту есть много вопросов у вас в тексте ядерная каша из всего или вам нужно было выговориться.
Вы описываете опыт на конкретном предприятии, но при это по тексту постоянно есть указания на тренды, общие сложившиеся практики и пр. Для того чтобы определять тренды, моды нужно проводить исследования. Не нужно делать безосновательные выводы о том, кто, как и зачем применяет agile, какие-либо инструменты и пр.
3 года назад все делали маппинги - а теперь нет? Пропали задачи по интеграции со сторонними системами? 5 лет назад все говорили бизнесу что делать? За его-то деньги? Серьезно? Кто эти "все"? Это грубое обобщение.
По тексту много грубых логических выводов. Почему документация должна стать артефактом agile? В манифесте написано - "Работающий продукт важнее исчерпывающей документации". И это вопрос приоритетов. Если команда, которая делает рабочий продукт не успевает документировать, значит документирование нужно вывести за контур примменения agile. Например, техписы или аналитики могут описывать работу фичи/микросервиса уже после релиза, вне зависимости от спринтов команды разработки.
Agile - это методология для команды размером около 6-8 T-shaped специалистов, самоорганизованной, вовлеченной и пр. В ней нет такого понятия, как показывать пальцем на аналитика, который во всем виноват. Agile вообще не предполагает наличие аналитика. Решение вырабатывает команда и каждый знает и принимает это решение. И судя по тексту и комментариям, на вашем предприятии неправильно применяют agile методологии (как, в общем-то и во многих местах). Отсюда и проблемы.
Корпоративные словари и классификаторы - это очень плохая практика. Ведение словаря и его поддержание в актуальном виде - это дорого и приносит примерно ноль прибыли. Составление словаря - это задача для стажера, для которого временно нет работы, чтобы он пополнил свой словарный запас. Та проблема, о которой вы пишите словарем не решается. Разным словам присущи одинаковые значения - это называется синонимами. И это нормально для языка. А вот то, что аналитики не выявляют эти синонимы при проектировании - это проблема недостаточного погружения в домен.
За последний год грань между системными аналитиком и солюшн архитектором стала практически неразличимой. - это не потому, а потому что сложилась неправильная практика называть инженера/архитектора решений системным аналитиком.
Текст сам по себе плохо вычитан, в нем много ошибок.
Не Bitbucked, а Вitbucket. От слова bucket - ведро, изображение которого можно видеть на логотипе.
Много цитат. Они создают впечатление псевдоэрудированности. Подчеркну - впечатление.
Как можете заметить, вопросы не относятся к сути поста из названия. Я бы вообще только эту суть и оставил. Возьму ваши подходы работы с микросервисами на заметку.
Все мы разные, всеми нами движет разная мотивация для разных видов деятельности. У кого-то мотивация для работы это деньги, для другого интересные задачи, у третьего - свобода выбора решения задачи и отсутствие тотального контроля, кому-то важно соблюдение work/life balance, кому-то нужно общение и тимбилдинги и т.д.
С течением времени эти "мотиваторы" могут меняться: взял ипотеку - важны деньги и чтобы своевременно и в оговоренных суммах, появились дети - "можно, пожалуйста, я буду работать не по графику?" и т.п.
Задача руководителя или специалистов HR, если они хотят удерживать кадры - периодически выявлять эти мотиваторы у сотрудников и предпринимть соответствующие этим мотиваторам действия.
Да, возможно, основной мотивацией будут деньги и это как-то нужно будет решать (плановые индексации, премии и пр.). Но коллектив коллективу рознь, где-то проблемы с деньгами уже решены.
В посте описаны примеры, когда систематически предпринимаются неправильные действия, потому что "ну, корпоративы и тимбилдинги у всех и мы будем также". Ну, а в свою очередь систематически неправильные действия это результат непрофессиональной работы ответственных лиц.
Если мотиваторы не выявляют, а работать с этим конкретным работодателем хочется - надо ему об этом сказать. А дальше как пойдет:)
Есть внутренние заказчики, которые обладают необходимой экспертизой в предметной области, могут просмотреть аналоги решений, могут составить требования и обосновать их. И мало того, они еще спросят реализацию этих требований при приемочном тестировании и не примут работу, если вдруг кто-то решил их изменить.
Мне попадались внятные заказчики, я потому и ставлю под сомнение применение этих "заблуждений" на всех аналитиков.
Куча крутых продуктов создают команды грамотных специалистов без аналитиков. Я сам будучи аналитиком порой не понимаю, зачем меня принимают в команды, которые и так хорошо решают задачи. Приходится их покидать.
Сейчас роль аналитика трактуют настолько широко от команды к команде, что я пока прихожу к выводу, что так называемым "аналитиком" закрывают дыры в грамотности специалистов и заказчиков и коммуникациях между ними из-за низких требований, предъявляемых этим специалистам. И это не затрагивая деления на бизнес- и системных аналитиков - там вообще беда с пониманием.
Кажется, статью стоит назвать "Топ заблуждений об аналитиках в Surf_studio". Ваши примеры очень частные и каждый из них может быть опровергнут.
Почему проектный менеджер не может опросить заказчика и выявить требования на достаточном уровне? Для этого не требуется каких-то сверхъестественных методик и можно сэкономить зарплату на аналитика.
Также - если заказчик самостоятельно внятно составил свои требования, которые понятны команде разработчиков, QA и дизайнеров, то зачем тратить деньги на аналитика?
Разработчики - это не операционисты для "написания кода". Они должны хотя бы поверхностно вникнуть в предметную область и куда глубже в объектную модель, в потоки данных и пр. и по итогу спроектировать решение. Они в любом случае будут анализировать требования и синтезировать решение. Аналитик в этом их не заменит.
Интересно, чем в момент применения этих принципов бизнес-аналитиком занимаются лидеры инициативы: проектный менеджер, Product Owner, Product Manager? И еще интересно сколько они при этом зарабатывают и сколько "полезности" приносят в рамках инициативы.
See The Whole - Product Owner, как, в общем и написано в описании принципа - должны принимать активное участие лидеры инициативы.
Think As a Customer - так должна думать вся команда, при планировании.
Analyze To Determine What Is Valuable - аналогично, проверять беклог должна вся команда при планировании. Понимать смысл требований - тут вообще без комментариев.
Get Real Using Examples - это должен делать Product Owner.
Understand What Is Doable - это делаяет вся команда и это очень похоже на принцип Analyze To Determine What Is Valuable.
Stimulate Collaboration and Continous Improvement - опять же это либо PO, либо некий "скрам-мастер-фасилитатор и тп.". Я себе плохо представляю как БА приходит в аджайл-команду (саморганизованную, готовую к изменениям, работе с заказчиком и пр.) и начинает всех стимулировать к работе и взаимодействию. Этим точно бизнес-аналитик должен заниматься?
Avoid Waste - это всех касается.
К автору статьи претензий нет. А вот к пониманию IIBA необходимости бизнес-аналитика в agile-команде есть вопросы.
Про тему черного ящика было бы очень интересно прочитать - это не самая освещаемая тема, но по моему опыту довольно актуальная. Это, кстати, одна из причин появления аналитика в компании - разобрать и задокументировать работу продукта, который дорос до некоторой точки, когда команда, которая его разрабатывала начинает меняться и не знает как она работает и, главное, почему она работает именно так:)
Про профстандарт системного аналитика - в нем СА как раз вменяется работа с бизнес-процессами. Он там вообще довольно универсальным профессионалом получается.
А вот нужность аналитиков - это холиварная тема:) Мое непопулярное мнение и ваш двукратный опыт не оставляют мне шансов, поэтому оставлю его пока при себе:)
Заголовок кажется кликбейтным. Статью кидают в разные чаты TG и ожидал увидеть какими методами аналитики вскрывают и описывают черный ящик, а в итоге про это пара предложение.
Тема о том кто такой бизнес-аналитик, а кто такой системный уже вроде как не холивар т.к. есть профстандарты на обоих.
Самое интересное, что решения вы разрабатываете вроде как по "водопаду" - этапы один за другим и в релиз. А почему такая же методика не применяется при принятии решения о найме 18 (!) аналитиков. т.е. вы пишите, что сначала их наняли, а потом начали думать - кто они и зачем мы их наняли. Плюс, ни разработка, ни QA не знали об этом т.е. потребности в аналитиках вроде как и не было. Ведь правильней сначала выявить требования, а потом закрыть их. Разве нет?
Подобную ситуацию, когда идет беспощадный найм аналитиков встречаю уже не первый раз и не могу понять в чем причина. Это, видимо, какой-то странный ответ на бурный рост компании и попытка освоить бюджет на ИТ, а после уже оправдать эти траты. Часто вижу непонимание разрабов, зачем им работать с аналитиком.
Еще про черный ящик - вся бизнес-логика ПО как правило, описана в коде. О том, что написано в коде, можно только догадываться смотря в БД или играясь с API. Я хочу сказать, что системный аналитик, как сотрудник, который должен разбираться в работе системы должен уметь читать код и знать технологический стек и, как мне кажется, не все, указанные для возможного перехода в аналитики, смежные специалисты обладают такими навыками.
Я уже чуть более 5 лет и бизнес-, и системный аналитик. Видимо, наступила какая-то стадия рефлексии о профессии и своем месте в ней:) И последнее время прихожу к выводу, что СА/БА это лишнее звено в профессиональном коллективе и затычка для дыр в коммуникациях и знаниях в непрофессиональном - где заказчики не могут внятно и грамотно изъясняться и составлять требования, а разрабам стало можно не погружаться в предметную область и проблемы бизнеса.
Олег, спасибо за статью. Кажется, что системное мышление, это довольно редкая компетенция у специалистов в продуктовых командах, что в ходе работы может прмвести к, так скажем, недопониманию внутри команды. Вопрос - как решаете эту проблему (если она, конечно, имеет место) - у вас безоговорочный авторитет или пользуетесь чем-то особенным для представления проблем и их решений с т.з. системного мышления, чтобы команда их поняла и приняла?
Ссылка на статью для чайников - это не вам в укор, это первое, что попалось в гугле:) Так что прошу прощения, если зацепил.
То что для проектирования систем нужно ее описание более комплексное, чем дает BPM-схема процесса - без сомнений. Но вины BPMN тут нет. Даже не представляю, как только с помощью схемы процесса можно проектировать какие-то решения.
Предложенная информационная модель подходит для структурирования предметной области при ее исследовании, но и ее, как мне кажется, будет недостаточно для проектирования системы.
Я бы добавил к ней таблицу сценариев использования со ссылками на элементы модели. Так в модели появится некоторая динамика и понимание последовательности смены состояний и отношений ее элементов.
Предпосылки кажутся некорректными:
Во-первых, в такой формулировке - это проблема открытых источников, а не нотации. Вы например также не пишите как с использовать правильно описанные смены состояний в ваших категориях. Во-вторых, о том как использовать BPMN-модель процесса, вам смогут рассказать бизнес-аналитики (например, при их оптимизации и автоматизации) или разработчики систем BPMS, где автоматизируются последовательности выполнения задач и проверки условий. Из своей практики, описание БП хоть в какой нотации используется для того, чтобы показать бизнесу где дыры в ответственности или чтобы сам бизнес получил формализованное представление своих процессов. На этой же схеме, например, можно очертить границы проекта автоматизации.
Это расширение первого вопроса. Можно просто погуглить "оптимизация БП BPMN".
Например, вот как это делается https://bpmn2.ru/blog/optimizacia-bizness-processov
Вы делаете предположения, за которое BPM-схема не отвечает. Она отвечает за то, чтобы графически отобразить бизнес-процесс. Не свойства системы, не ее свойства, ни элементы программы, а то какая последовательность действий, распределение их между участниками этого процесса и условий позволит прийти к результату бизнес-процесса.
Что BPMN, что UML и пр. создаются не добрым и светлым сообществом, а большими софтверными компаниями или консорциумами. Они, главным образом, преследуют свои цели - автоматизацию процессов в своих больших компаниях, продажу ПО для проектирования ПО, использующих конкретную нотацию. При этом всячески давят конкурентов. И иногда просто не остается выбора, какую нотацию или какое ПО для проектирования выбрать.
UML - это эхо эпохи CASE-средств от IBM, когда в 90х решили, что программисты не нужны и проектирование бизнес-ПО можно отдать на откуп менеджерам/аналитикам, которые расставили бы элементы нотации в нужном порядке. Но не задалось.
BPMN - это визуализация языка BPEL (Business Process Execution Language) от Microsoft и IBM. Язык описывал оркестрацию веб-сервисов, к нему решили прикрутить визуализатор и получилась нотация. А вот тут задалось, пользуемся (почти) всем айти:)
Проектировать ПО/системы на основании только BPMN это бесперспективно. Но тут опять же вагон подходов в т.ч. в плане нотаций - от нотации "стрелочки и квадратики" до C4 и пр.
Плюс свой отпечаток накладывает все еще популярный Agile, при применении которого, наличие обширной документации с описанием "полноценно смоделированного последовательного перехода между состояниями системы" имеет меньший приоритет. Во многом поэтому умирает UML.
По итогу, BPMN крутая штука, если использовать ее по назначению и не добавлять ей новых смыслов. Она потому и простая в освоении нотация, потому, что в ней многого нет. А то, что есть позволяет решать некоторые задачи. Поэтому я все-таки не стал бы отказываться от нее.
Марина, то что вы написали о работе аналитика больше похоже на работу секретаря для разработчика - сходи поговори с заказчиком, запиши, что он хочет, передай разработчику, зафиксируй, что сделал разработчик. И это не похоже на хоть сколько-нибудь сложную интеллектуальную аналитическую деятельность, за которую нужно платить деньги и которая необходима в каком-либо подходе при разработке ПО.
Различия системного и бизнес-аналитика, это как минимум разное количество страниц в соответствующих профстандартах. а как максимум, они не посредники - бизнес-аналитик выстраивает и оптимизирует бизнес-процессы, а системные аналитики проектируют ПО.
У вас, судя по тексту, сложилось некорректное понимание функциональности аналитиков. Надеюсь, подготовка к написанию книги поможет расставить все на свои места.
Спасибо за статью не про найм и обучение аналитиков:) Но по тексту есть много вопросов у вас в тексте ядерная каша из всего или вам нужно было выговориться.
Вы описываете опыт на конкретном предприятии, но при это по тексту постоянно есть указания на тренды, общие сложившиеся практики и пр. Для того чтобы определять тренды, моды нужно проводить исследования. Не нужно делать безосновательные выводы о том, кто, как и зачем применяет agile, какие-либо инструменты и пр.
3 года назад все делали маппинги - а теперь нет? Пропали задачи по интеграции со сторонними системами? 5 лет назад все говорили бизнесу что делать? За его-то деньги? Серьезно? Кто эти "все"? Это грубое обобщение.
По тексту много грубых логических выводов. Почему документация должна стать артефактом agile? В манифесте написано - "Работающий продукт важнее исчерпывающей документации". И это вопрос приоритетов. Если команда, которая делает рабочий продукт не успевает документировать, значит документирование нужно вывести за контур примменения agile. Например, техписы или аналитики могут описывать работу фичи/микросервиса уже после релиза, вне зависимости от спринтов команды разработки.
Agile - это методология для команды размером около 6-8 T-shaped специалистов, самоорганизованной, вовлеченной и пр. В ней нет такого понятия, как показывать пальцем на аналитика, который во всем виноват. Agile вообще не предполагает наличие аналитика. Решение вырабатывает команда и каждый знает и принимает это решение. И судя по тексту и комментариям, на вашем предприятии неправильно применяют agile методологии (как, в общем-то и во многих местах). Отсюда и проблемы.
Корпоративные словари и классификаторы - это очень плохая практика. Ведение словаря и его поддержание в актуальном виде - это дорого и приносит примерно ноль прибыли. Составление словаря - это задача для стажера, для которого временно нет работы, чтобы он пополнил свой словарный запас. Та проблема, о которой вы пишите словарем не решается. Разным словам присущи одинаковые значения - это называется синонимами. И это нормально для языка. А вот то, что аналитики не выявляют эти синонимы при проектировании - это проблема недостаточного погружения в домен.
За последний год грань между системными аналитиком и солюшн архитектором стала практически неразличимой. - это не потому, а потому что сложилась неправильная практика называть инженера/архитектора решений системным аналитиком.
Текст сам по себе плохо вычитан, в нем много ошибок.
Не Bitbucked, а Вitbucket. От слова bucket - ведро, изображение которого можно видеть на логотипе.
Много цитат. Они создают впечатление псевдоэрудированности. Подчеркну - впечатление.
Как можете заметить, вопросы не относятся к сути поста из названия. Я бы вообще только эту суть и оставил. Возьму ваши подходы работы с микросервисами на заметку.
Все мы разные, всеми нами движет разная мотивация для разных видов деятельности. У кого-то мотивация для работы это деньги, для другого интересные задачи, у третьего - свобода выбора решения задачи и отсутствие тотального контроля, кому-то важно соблюдение work/life balance, кому-то нужно общение и тимбилдинги и т.д.
С течением времени эти "мотиваторы" могут меняться: взял ипотеку - важны деньги и чтобы своевременно и в оговоренных суммах, появились дети - "можно, пожалуйста, я буду работать не по графику?" и т.п.
Задача руководителя или специалистов HR, если они хотят удерживать кадры - периодически выявлять эти мотиваторы у сотрудников и предпринимть соответствующие этим мотиваторам действия.
Да, возможно, основной мотивацией будут деньги и это как-то нужно будет решать (плановые индексации, премии и пр.). Но коллектив коллективу рознь, где-то проблемы с деньгами уже решены.
В посте описаны примеры, когда систематически предпринимаются неправильные действия, потому что "ну, корпоративы и тимбилдинги у всех и мы будем также". Ну, а в свою очередь систематически неправильные действия это результат непрофессиональной работы ответственных лиц.
Если мотиваторы не выявляют, а работать с этим конкретным работодателем хочется - надо ему об этом сказать. А дальше как пойдет:)
Есть внутренние заказчики, которые обладают необходимой экспертизой в предметной области, могут просмотреть аналоги решений, могут составить требования и обосновать их. И мало того, они еще спросят реализацию этих требований при приемочном тестировании и не примут работу, если вдруг кто-то решил их изменить.
Мне попадались внятные заказчики, я потому и ставлю под сомнение применение этих "заблуждений" на всех аналитиков.
Куча крутых продуктов создают команды грамотных специалистов без аналитиков. Я сам будучи аналитиком порой не понимаю, зачем меня принимают в команды, которые и так хорошо решают задачи. Приходится их покидать.
Сейчас роль аналитика трактуют настолько широко от команды к команде, что я пока прихожу к выводу, что так называемым "аналитиком" закрывают дыры в грамотности специалистов и заказчиков и коммуникациях между ними из-за низких требований, предъявляемых этим специалистам. И это не затрагивая деления на бизнес- и системных аналитиков - там вообще беда с пониманием.
Кажется, статью стоит назвать "Топ заблуждений об аналитиках в Surf_studio". Ваши примеры очень частные и каждый из них может быть опровергнут.
Почему проектный менеджер не может опросить заказчика и выявить требования на достаточном уровне? Для этого не требуется каких-то сверхъестественных методик и можно сэкономить зарплату на аналитика.
Также - если заказчик самостоятельно внятно составил свои требования, которые понятны команде разработчиков, QA и дизайнеров, то зачем тратить деньги на аналитика?
Разработчики - это не операционисты для "написания кода". Они должны хотя бы поверхностно вникнуть в предметную область и куда глубже в объектную модель, в потоки данных и пр. и по итогу спроектировать решение. Они в любом случае будут анализировать требования и синтезировать решение. Аналитик в этом их не заменит.
Интересно, чем в момент применения этих принципов бизнес-аналитиком занимаются лидеры инициативы: проектный менеджер, Product Owner, Product Manager? И еще интересно сколько они при этом зарабатывают и сколько "полезности" приносят в рамках инициативы.
See The Whole - Product Owner, как, в общем и написано в описании принципа - должны принимать активное участие лидеры инициативы.
Think As a Customer - так должна думать вся команда, при планировании.
Analyze To Determine What Is Valuable - аналогично, проверять беклог должна вся команда при планировании. Понимать смысл требований - тут вообще без комментариев.
Get Real Using Examples - это должен делать Product Owner.
Understand What Is Doable - это делаяет вся команда и это очень похоже на принцип Analyze To Determine What Is Valuable.
Stimulate Collaboration and Continous Improvement - опять же это либо PO, либо некий "скрам-мастер-фасилитатор и тп.". Я себе плохо представляю как БА приходит в аджайл-команду (саморганизованную, готовую к изменениям, работе с заказчиком и пр.) и начинает всех стимулировать к работе и взаимодействию. Этим точно бизнес-аналитик должен заниматься?
Avoid Waste - это всех касается.
К автору статьи претензий нет. А вот к пониманию IIBA необходимости бизнес-аналитика в agile-команде есть вопросы.
Про тему черного ящика было бы очень интересно прочитать - это не самая освещаемая тема, но по моему опыту довольно актуальная. Это, кстати, одна из причин появления аналитика в компании - разобрать и задокументировать работу продукта, который дорос до некоторой точки, когда команда, которая его разрабатывала начинает меняться и не знает как она работает и, главное, почему она работает именно так:)
Про профстандарт системного аналитика - в нем СА как раз вменяется работа с бизнес-процессами. Он там вообще довольно универсальным профессионалом получается.
А вот нужность аналитиков - это холиварная тема:) Мое непопулярное мнение и ваш двукратный опыт не оставляют мне шансов, поэтому оставлю его пока при себе:)
Заголовок кажется кликбейтным. Статью кидают в разные чаты TG и ожидал увидеть какими методами аналитики вскрывают и описывают черный ящик, а в итоге про это пара предложение.
Тема о том кто такой бизнес-аналитик, а кто такой системный уже вроде как не холивар т.к. есть профстандарты на обоих.
Самое интересное, что решения вы разрабатываете вроде как по "водопаду" - этапы один за другим и в релиз. А почему такая же методика не применяется при принятии решения о найме 18 (!) аналитиков. т.е. вы пишите, что сначала их наняли, а потом начали думать - кто они и зачем мы их наняли. Плюс, ни разработка, ни QA не знали об этом т.е. потребности в аналитиках вроде как и не было. Ведь правильней сначала выявить требования, а потом закрыть их. Разве нет?
Подобную ситуацию, когда идет беспощадный найм аналитиков встречаю уже не первый раз и не могу понять в чем причина. Это, видимо, какой-то странный ответ на бурный рост компании и попытка освоить бюджет на ИТ, а после уже оправдать эти траты. Часто вижу непонимание разрабов, зачем им работать с аналитиком.
Еще про черный ящик - вся бизнес-логика ПО как правило, описана в коде. О том, что написано в коде, можно только догадываться смотря в БД или играясь с API. Я хочу сказать, что системный аналитик, как сотрудник, который должен разбираться в работе системы должен уметь читать код и знать технологический стек и, как мне кажется, не все, указанные для возможного перехода в аналитики, смежные специалисты обладают такими навыками.
Я уже чуть более 5 лет и бизнес-, и системный аналитик. Видимо, наступила какая-то стадия рефлексии о профессии и своем месте в ней:) И последнее время прихожу к выводу, что СА/БА это лишнее звено в профессиональном коллективе и затычка для дыр в коммуникациях и знаниях в непрофессиональном - где заказчики не могут внятно и грамотно изъясняться и составлять требования, а разрабам стало можно не погружаться в предметную область и проблемы бизнеса.