Мы формируем свою аудиторию

Евгений
37 лет

Лид аналитиков

Карта компетенций:

Аналитика, создание документации и описаний, аналитика требований и формирование ТЗ для разработки. обучение и адаптация аналитиков, поиск новых типов нотаций, способов описаний ТЗ и фреймворков

68

20

10

часов в неделю посвящает работе. Часто работает в выходные и вносит изменения в систему, чтобы не "сломать" инфраструктуру

минут в день готов уделить на тщательное изучение межсетевых экранов

минут в день готов уделить на звонок и общение с менеджером

В подчинении

Количество пользователей в компании

8

человек

Входит в ТОП-руководителей компании, формирует ФОТ и влияет на затраты следующих процессов разработки:
аналитика, архитектура, разработка, операционные расходы типа technical

300-500

человек

Трассировка всего на все

Параллельная правка модели

Обсуждения модели в визуальном редакторе

Мониторинг выполнения задач, статистика выполнения, отображение текущего состояния задач (для вывода пользователю).

Как обучить новому решению аналитиков, разработчиков и оркестрировать их задачи между собой

Java Script

Json-запросы

GitHub User

habr reader

поиск софта

Понимает основные процессы в компании

сделать систему визуализации бизнес-процессов в корпорации

draw.io

bpmn

DSL

маппинг юскейсов/систем надо трейсить по расписанию

4+1 architectural view model
ArchiMate (моделирование структур)

Мне нужно, чтобы продукт регулярно дорабатывался.

BPMN - для описания бизнес-процесса. Причем иногда шлюзами жертвуешь, что бы схема не получилось слишком громоздкой. Далее один БП декомпозируется на ветки или блоки функциональности с помощью диаграммы UseCases. Условия, ветки и событии отражаются в описании конкретного UseCases.

archimate все-таки про моделирование структур, в стандарте архимейт прямо сказано : хотите описывать детально процессы - используйте bpmn

Теоритически знает нотации и умеет работать с ними

Техпис

Организует обучение

Не разработчик, но страмится к этому

Стартовый событие, стандартный блок, два шлюза - и/или, пара нативных промежуточных события время/сообщение (последнее можно упростить), конечное событие + событие ошибки. Можно пулл прикрутить, но это далеко не всегда надо.

Этой упрощённой нотацией можно описать и без проблем понимания обсудить с заказчиком в 90% случаев.

Зачастую проблемы встречаются следующие:
1. Чрезмерное усложнении схемы
2. Перегрузка схемы элементами
3. Смешение разных артефактов
4. Плохое пониманием нотации и небольшой опыт
5. Неправильный выбор необходимого уровня детализации
6. Непонятные названия событий и неподписанные разветвления

А так, нотация BPMN не особо то отличается от каляк-маляк на салфетке.

Лично у меня классифицированы три уровня BPMN:
1. Для простых смертных
2. Для себя (здесь можно делать сложные схемы, чтобы понять как и что работает, а потом их выводить в субпроцессы, смешение разных артефактов на первых парах - короче это инструмент проектирования, чтобы ничего не забыть и выявить недостатки в схеме и процессах).
3. Для небожителей с BPMS

-------------------
Примерно так
1) Если использовать "разработчиками" как средство конфигурирования какого-то существующего инструмента (например Comunda, всякие online-CRM типа Битрикс и т.п.), то, кажется, нормально.

2) Если как средство описания и согласования с бизнесом требований - то скорее нет. Бизнесу и экспертам в доменной области лучше показывать "сценарии", а не "процессы". Сложная нотация отвлекает от главного, поэтому тут перегруз артефактами BPMN может сыграть злую шутку.

Я пробую примерить BPMN для визуализации технологического процесса, пусть для примера это будет оформление кредитной заявки: стадии прохождения, какие компоненты/системы задействованы, какие сервисы и в каком порядке вызываются

мониторинг версионности с помощью UI

Список конкретных артефактов, необходимых для документирования архитектурных и технических решений.


Может есть какой-то шаблон для структуры документации. Конечно бизнес логику тоже надо будет как-то фиксировать, но это позже (или нет?).

Хранить все будем в конфлюенсе. Может сразу полезные плагины посоветуете.

Несложная горизонтальная масштабируемость.

динамическая модель бизнес-процесов

Поддержка нескольких редактирующих процессов одномоментно

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

Что он думает о том, каким должен быть продукт

Что он ищет и ожидает от продукта

И на каждого пользователя приходится 3 устройства:
1 рабочий комп, Домашний ноут, 1 рабочий телефон

Решение, которое поддерживается, которое не исчезнет вместе с его вендором.

Цель - дать возможность сотрудникам разобраться в безумно сложных БП???? и сделать множество перекрестных ссылок (процессы включают другие подпроцессы и тд)

Диаграммы поведения вполне удобны, вот диаграммы структуры - уже не очень

С одной стороны, слабо формализованные подходы к работе больше применимы для схем с минимумом уровней вложенности подрядчиков. С другой, заказчику не интересно, что там у подряда внутри.