Size: a a a

Архитектура ИТ-решений

2021 January 11

AM

Artem Mitropolskiy in Архитектура ИТ-решений
Или пришла следующая фича, вопрос задать некому, на грабли опять не хочется?
источник

VI

Vladislav Isaykin in Архитектура ИТ-решений
Олег Игонин
Ну, если быть точным, то изначально всех всё устраивало была небольшая фича, которую попросили нас сделать. Что вылилось в 9 месяцев разработки, а я как СА даже не мог задать вопрос "нафига" человеку, который отвечал за процесс.
Сделали в конечном итоге намного больше и намного не того.
если у вас обратной связи нет от заказчика, то документация не поможет
источник

VI

Vladislav Isaykin in Архитектура ИТ-решений
проблема в коммуникации
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Artem Mitropolskiy
Или пришла следующая фича, вопрос задать некому, на грабли опять не хочется?
Она придёт и на грабли вставать не хочется.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Тут так принято работать. Обсудить что надо сделать могут наверху, а до тебя дойдёт только результат того, что надо сделать. При этом не будет уверенности в том, кто точно эту идею заложил.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
СА получается больше инженером, чем человеком "о коммуникации". На проектах, где у меня есть доступ к стейкхолдерам и оунерам проблемы нет.
источник

AM

Artem Mitropolskiy in Архитектура ИТ-решений
А по текущей фиче в итоге стало понятно, как ее надо было делать?
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Artem Mitropolskiy
А по текущей фиче в итоге стало понятно, как ее надо было делать?
Как надо было? Или как надо переделывать сейчас то, что мы уже наделали? Что надо сделать - понятно. Как надо сделать - это придётся решать мне (но в рамках уже понаделанного).
источник

ZL

Zlata Lupilina in Архитектура ИТ-решений
Олег Игонин
Коллеги, добрый вечер!

Сейчас я формирую список бизнес-процессов в своей компании согласно схеме Захмана. Искал примеры в сети, но везде описывается только основной посыл, но нет однозначных ответов или примеров. Скорее всего потому, что у каждой компании свой подход.
Итак вот я наткнулся на следующие проблемы:
- Как следует группировать процессы? По отделам? По документам/объектам? По направлениям? Нужно ли их группировать вообще?
- Процессы учитывают реализацию? Например, непонятно как действовать в случае, если процесс может проходить через разные интерфейсы, у которых разные оунеры. Это один процесс с несколькими оунерами и надо уточнять, какой из них за какой интерфейс отвечает? Или оунер всегда должен быть один?
- Какие данные должны сопровождать каждый процесс? Оунер, список стейкхолдеров, схема процесса, ссылки на реализацию? Или это уже перебор и нужен только оунер?
- Можно ли формировать список бизнес процессов  в RMS? RMS в моём случае имеет обязательные объекты folder-document-section-use case/procedure-requirement. Кажется, что подобная структура не подходит, хотя и позволяет повторно использовать объекты.

И в конце, возможно у кого-то будет пример списка?

Спасибо!
Как вариант группировать по системам а оунера указывать как параметр описания. Например


1. Система
   1.1 Процесс (фича) 1 -
    описание процесса (диаграмма, описание, функциональные / не функциональные требования, оунер, ссылки на описание интегрируемых систем, можно ссылки на задачи в рамках которой разрабатывался / дорабатывался процесс.)
       1.1.1 описание подпроцесса по той же логике (при наличии)
        .....
       1.2 Процесс (фича) 2
источник

AM

Artem Mitropolskiy in Архитектура ИТ-решений
Как надо было
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Zlata Lupilina
Как вариант группировать по системам а оунера указывать как параметр описания. Например


1. Система
   1.1 Процесс (фича) 1 -
    описание процесса (диаграмма, описание, функциональные / не функциональные требования, оунер, ссылки на описание интегрируемых систем, можно ссылки на задачи в рамках которой разрабатывался / дорабатывался процесс.)
       1.1.1 описание подпроцесса по той же логике (при наличии)
        .....
       1.2 Процесс (фича) 2
Кажется, что "система" для процессов не подойдёт. Прцоессы могут существовать и без системы.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Artem Mitropolskiy
Как надо было
Требования уровня бизнеса понятны. Выявлены через топа. Но как я понял, у прцоесса должен быть оунер, который находится ниже и погружён лучше.
источник

ZL

Zlata Lupilina in Архитектура ИТ-решений
Олег Игонин
Кажется, что "система" для процессов не подойдёт. Прцоессы могут существовать и без системы.
Есть процессы которые не касаются ни одной из систем?
источник

VI

Vladislav Isaykin in Архитектура ИТ-решений
Олег Игонин
Требования уровня бизнеса понятны. Выявлены через топа. Но как я понял, у прцоесса должен быть оунер, который находится ниже и погружён лучше.
а почему налажали тогда если все понятно?
источник

AM

Artem Mitropolskiy in Архитектура ИТ-решений
Можно посчитать, сколько займет сделать как надо? Чтобы была видна разница с тем, что по факту было потрачено?
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Vladislav Isaykin
а почему налажали тогда если все понятно?
Всё стало понятно через 9 месяцев.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Олег Игонин
Всё стало понятно через 9 месяцев.
Ох, шутка про беременность)
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Zlata Lupilina
Есть процессы которые не касаются ни одной из систем?
Системы могут быть заменены, при этом действия существуют вне систем (простой пример, если 10 лет назад всё это делалось на бумаге). Не стоит описывать бизнес-требования в терминологии систем, чтобы не привязывать бизнес-требования к реализации.
источник

VI

Vladislav Isaykin in Архитектура ИТ-решений
Олег Игонин
Всё стало понятно через 9 месяцев.
чет не совсем ясно
все было понятно, но потом оказалось что сделали не то
противоречие)
источник

F

Fagor in Архитектура ИТ-решений
Олег Игонин
Требования уровня бизнеса понятны. Выявлены через топа. Но как я понял, у прцоесса должен быть оунер, который находится ниже и погружён лучше.
есть кросс процессы, там не будет овнера, кроме как самого бизнеса, бизнес и есть овнер, и овнеров отдельных задач. Иногда как хореография в bpmn, которая мало где зашла. А иногда классический, но без овнера как такового, единого. Но с кучей овнеров соседних доменов.
источник