Comments 6
Ощущение, что автору попадались в основном суперадекватные заказчики.
уникальные бизнес-аналитики, которые вникают в бизнес-процессы заказчика, понимают, в чем его боль, знают технические ограничения, могут предлагать решения с учетом технических и организационных ограничений, могут объяснить заказчику, что розовая кнопка его не спасет. Этих аналитиков любят заказчики и любят разработчики.
И тут же далее:
— Нам нужно сгенерировать штрихкод.
— А зачем?
— Чтобы сканировать потом штрихкоды.
— А зачем?
— Чтобы пользователю искать документы в нашей системе.
— А зачем?
Хорошо если заказчик готов задуматься.
Но в 99% случаев представитель заказчика нажалуется своему руководству, что аналитик -- псих и тролль.
А если задачу ставит само руководство...
Понятно что хороший аналитик за 5 минут сможет понять степень бардака и трудозатраты на его устранение.
Но хороший сейлз, выбирая между автоматизацией бардака и наведением порядка, иногда предложит как раз автоматизировать бардак, потому что "Ачимез Гочияевич лично писал эти бизнес-процессы..."
Заказчики мне попадались разные, конечно.
И я как раз имела в виду, что приходится понимать мотивы людей, тогда даже в самой сложной ситуации на проекте и с самым сложным заказчиком можно найти какие-то варианты.
Вот вы говорите "представитель заказчика нажалуется своему руководству " - почему? Скорее всего, потому что если аналитик прав, то самому представителю заказчика либо прибавится работы, либо "прилетит" за не очень хорошее исполнение. Так? И исходя из этого уже выстраивать логику взаимодействия и предлагать решения.
Конечно, мир не совершенен и магии не существует, и мы часто ограничены предубеждениями и "так исторически сложилось", но мне хотелось рассказать, что даже в мире с такими ограничениями можно попытаться сделать лучше
IMHO, из ТРИЗ бизнес/системному аналитику (да и архитектору) полезна только страница, где описывается т.н. «девятиэкранка» — надсистема/система/подсистема в прошлом/настоящем/будущем.
Судя по тому, что в статье упоминается взаимодействие бизнес-аналитика с разработчиком и по тому что бизнес-аналитик является также «технарем», отдельного системного аналитика в описываемой картине не предполагается, а значит описываемый бизнес-аналитик так или иначе совмещает в себе эти две роли (а возможно и третью — архитектора), раз вынужден «опускаться» на уровень системы и конкретной реализации.
Как я понял из первого абзаца, статья нацелена на специалистов, только начинающих свой профессиональный путь и желающих попробовать свои силы в роли аналитика. Но как им именно поможет в этом начинании данный пост? Ведь в нём нет чётких рекомендаций, а акцент сделан на важности наличия "мягких" навыков, которые приобрести и развить без помощи со стороны крайне сложно. Единственное, что можно считать толковым советом - список литературы в самом конце, но и он выглядит весьма ограниченным и не оригинальным.
Быть бизнес-аналитиком в ИТ