Рубрика «бизнес-анализ» - 3

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

Анализ – это процесс, при котором мы представляем изучаемый объект в виде множества его частей (изучаем различные конструкции, на которые можно разложить изучаемый объект).

Синтез — это обратная «сборка» объекта.

Утверждается, что чувство понимания достигается, когда, сделав разборку объекта (анализ), а затем его сборку (синтез), — субъект получает непротиворечивый результат. В той же статье я отметил, что стандарты, как правило, нацелены на описание только одного направления мышления — анализа, но совершенно игнорируют второе направление – синтез.

Моделирование конструкций. Требования к моделлеру - 1
Игнорирование процесса синтеза приводит к тому, что мы теряем способность делать проверку результатов анализа и начинаем мыслить шаблонами. Например, если нас спросить, из чего состоит велосипед, то довольно быстро найдется «правильный» ответ. Но если спросить: "Частью чего является велосипед?", – мы сильно затруднимся с ответом.
Читать полностью »

→ Первая часть тут

Анализ и описание процессов

автоматизированный бардак Следующим пунктом бизнес-анализа является описание бизнес процессов. На этом этапе, обычно, рисуют, так называемые диаграммы бизнес-процессов «As is». И вот тут-то всех и поджидают проблемы, что называется, на ровном месте. Самая большая проблема в том, что за деревьями не видно леса. Так же, как и при описании бизнес-целей, зачастую народ увлекается описанием того, как все работает прямо сейчас. При этом редко кто задается целью разобраться, а насколько текущие процессы вообще соответствуют тому, как все должно быть? Все наверняка знают одно из правил автоматизации: «автоматизируя бардак — мы получаем автоматизированный бардак, и ничего более». Так вот, чтобы не строить очередной «скайнет», который всех уничтожит, необходимо понять — «а как же все вообще должно функционировать?». И это очень интересная задача.
Читать полностью »

С чего все началось

Пребывая в «творческом отпуске», имею в своем распоряжении некое количество свободного времени, которое могу потратить на «общественно полезный труд». Потому, если бизнес-анализ Вам интересен, прошу ознакомиться с мыслями по этому вопросу:

Читающий песик

Итак, целью статьи является показать, чего ожидают и в чем нуждаются пользователи результатов работ бизнес-аналитиков. По сути, статья писалась не только для бизнес-аналитиков, но и для тех, кто вынужден пользоваться результатами их труда. И чтобы не просто «читать и материться», а иметь возможность объяснить, чего же они пропустили или не учли в своей работе
Читать полностью »

Для создания модели предметной области сначала строится модель наших представлений. Описание наших представлений содержится в метамодели (например, в нотации BPMN). Метамодели, в свою очередь, строятся на основе мета-метамодели. Однако, наши представления имеют очень непростую структуру, которая до сих пор не имеет формального описания. Поэтому построение метамодели и мета-метамодели сильно затруднено. Попытку описать эту структуру предприняли греки, когда придумали основы логики. Способы нашего мышления изучали математики, когда столкнулись с парадоксами, пытаясь построить основы своей науки. Казалось бы, прогресс есть, но по какой-то причине, остановившись на формальном описании инструментов логического вывода, математики не сделали попытку применить полученные наработки к моделированию нашего мира (наверно, потому что для них – это прикладная задача, не вызывающая интереса).

Трудности на пути создания «универсальной» метамодели для моделирования предметных областей - 1

В итоге те принципы, на основе которых создаются нотации и языки моделирования предметных областей, выбираются разработчиками относительно произвольно. Понятно, что созданные таким образом языки моделирования имеют достаточно ограниченную область применения. Эту область должны были бы описать создатели языка, но разработчики, как правило, это требование игнорируют.
Читать полностью »

Облака незаметно стали важной частью современного IT. Еще несколько лет назад облачные платформы были диковинкой, которую было интересно потрогать, но попробовать реализовать самостоятельно – сложно и дорого. И это касалось даже крупных организаций.

Чего ждать от облачного рынка в ближайшие пять лет? - 1

О возможности простого создания гибридных или частных облаков даже речи не было. В чем секрет? Давайте разбираться.
Читать полностью »

Сценарии как инструмент аналитика, и как они помогают работать с требованиями - 1

«Директор небольшой брокерской фирмы Юрий сидел в офисе, который он арендовал в модном коворкинге вместе со своими немногочисленными сотрудниками. Компания последнее время показывала очень хорошие результаты. Престижное экономическое образование позволило самостоятельно построить успешную компанию, а вот как обезопасить основной капитал – базу клиентов – от участившихся хакерских атак собственными силами Юрий не знал. Своим сотрудникам Юрий доверял, но они часто работали из дома, из кафе, да и местный администратор Илья не вызывал доверия, наверное из-за бороды и черной футболки.
Читать полностью »

image Аналитик — арбитр между бизнесом, проектированием и разработкой, который периодически смещается в ту или иную сторону, но при этом удерживает процесс создания мобильного продукта в поле здравого смысла. Он обеспечивает коммуникацию между всеми участниками процесса, транслируя знания от одной группы в другую, чтобы выдвинутые гипотезы и принятые впоследствии решения были обеспечены достаточным количеством информации.

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

Если про передачу требований от уровня бизнеса к системному уровню сказано немало и выработался определенный инструментарий, то вот какие артефакты использовать для взаимодействия и передачи знаний между бизнесом, аналитиком и UX-проектированием — вопрос открытый. Этой темой я продолжаю цикл статей по бизнес-анализу в мобильной разработке.
Читать полностью »

Когда стоит привлекать бизнес-аналитика в проект - 1

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

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

Дело в том, что у каждой роли — свои цели и области ответственности. Если PM или QA-менеджер вынужден, кроме основных обязанностей, брать на себя управление требованиями, из-за нехватки времени или квалификации в области бизнес-анализа что-то можно упустить. В результате может возникнуть неправильное понимание ожиданий заказчика, некорректная имплементация, неоправданные затраты времени и денег на переделывание функциональности и повторное тестирование. В итоге — срыв сроков и неудовлетворенный заказчик.

Конечно, такие проблемы возникают не во всех проектах, где нет выделенных бизнес-аналитиков. И в каждом случае нужно принимать во внимание множество факторов. Мы решили понять, какие индикаторы могут подсказать, что надо задуматься о привлечении бизнес-аналитика. Для этого сотрудники центра компетенции по бизнеc-анализу DataArt провели опрос ключевых менеджеров компании и получили наиболее распространенные признаки.
Читать полностью »

Зачем вообще нужны бизнес аналитики

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

Бизнес-аналитики в Agile — зачем, почему, как - 1
Читать полностью »

Приветствуем вас, люди!

Мы — компания «Центр информационных технологий», создаем инфраструктурные решения и высокотехнологичные программные продукты, поддерживающие глобальные государственные инициативы в Российской Федерации и странах Евразийского экономического союза.

В этой статье я поделюсь с вами некоторыми мыслями о том, откуда люди приходят в бизнес-анализ.

Откуда берутся бизнес-аналитики? - 1

В компании «Центр информационных технологий» отдел бизнес-анализа появился будто бы из ниоткуда. Собрали в нем несколько системных аналитиков и сказали, что теперь мы бизнес-аналитики и должны бизнес-анализировать процессы. Это не в укор руководству, просто занимать бизнес-анализом программистов показалось еще более странно, а потребность в таких специалистах была уже на лицо.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js