Comments 9
Есть ощущение, что вы под наведением порядка понимаете усиление бюрократии и рост издержек на поддержание этой бюрократии. Вы же не первый на этом пути, правда? уроки прошлого вас ни на какие мысли не наводят?
*
Вы написали: " А также, изменяя какой‑то бизнес‑процесс, мы сможем увидеть, на какие артефакты нужно обратить внимание и какие требования нужно переосмыслить. " Можете пояснить? А то выглядит так, что царит БП, а требования переосмысляются под него. Я всегда полагал, что БП выстраивается под требования заказчика. А у вас требования вроде как вторичны.
*
Вы говорите о ER-диаграммах - но используете любые термины кроме того, что в названии. Е - это entity, сущность. Соответственно, ваша таблица "шаблона описания бизнес-объекта" - это перечень атрибутов сущности. Можете пояснить, почему вы отошли от модели "сущность-связь" в сторону бизнес-процессов?
*
Усиление бюрократии неизбежно по мере усложнение проекта и расширения его команды. Вы ведь не рекомендуете ваш подход для команды из РП, аналитика и разраба? Можете обозначить какие-то измеряемые параметры, после превышения которых имеет смысл имплементировать ваш подход?
*
Вы не оценили степень новизны вашего материала. В чем ваш оригинальный вклад?
Добрый день!
Начнем с самого короткого вашего комментария :)
Новизна заключается в том, что в материале структурировано описаны инструменты, которые могут быть применены для упорядочивания работы с требованиями и документацией, собственно это и следует из заголовка. Статья не претендует на изобретение нового, она агрегирует в одном месте существующее.
Согласно толковому словарю
поря́док - Ожидаемое, предсказуемое, правильно организованное состояние или расположение чего-либо.
все приведенные инструменты, как раз и направлены на создание предсказуемого расположения информации в проекте. Да, внедрение любого структурирующего артефакта требует трудозатрат на его поддержание в актуальном состоянии, о чем тоже упоминается в статье. При этом каждая команда сама должна определять, что из приведенного инструментария ей необходимо. У кого-то вообще нет документации, а только исходных код и они отлично себя чувствуют :)
Вы воспринимаете материал, как единый подход, хотя изначально это перечень автономных инструментов, из которых каждый может выбрать то что ему нравится и подходит :)О БП и требованиях.
Есть разные уровни требований. Если укрупнить то на основе бизнес-требований(БТ) мы строим бизнес-процесс(БП), далее отдельные шаги БП описываются детальными функциональными требованиями(ФТ). Все они связаны между собой явно через трассировку требований (писал о ней в предыдущей своей статье) или умозрительно в головах членов команды. Изменения могут транслироваться, как сверху вниз от БТ, через БП к ФТ, или наверх от ФТ к БП.В разделе про модель предметной области использую термин бизнес-объект так как он лучше подчеркивает, что речь идет именно о бизнесовой (логической) модели, а не о физической (системной). Термин сущность более общий и по моим наблюдениям часто создает путаницу о чем именно идет речь, об объекте реального мира которым оперирует система или о системных объектах в базе данных.
Так что же в начале? курица или яйцо? Вы же написали, что после изменения бизнес-процесса нужно переосмысливать требования. Так под какие же детальные функциональные требования вы строили БП? которые потом немедленно стали переосмысливать?
*
А из названия и атрибутов сущности непонятно, о чем она? Вы либо не упоминайте "ER", либо не игнорируйте общепринятое.
*
Что с расходами на эти мероприятия? и размерностью проекта, когда это становится обязательным.
*
Так вы систематизируете известные подходы для создания рабочей концепции. Это хорошо. Но об этом надо упоминать, иначе ваш текст выглядит попыткой изобрести колесо, нет?
В абзадце на который вы ссылаетесь приводится пример для чего может быть использован реестр бизнес-процессов. Вопрос с чего начинать проектирование ИС с БП или отдельных требований и как отдельные изменения ФТ влияют на другие требования не относится к теме этой статьи. Можем обсудить эту тему в телеграм канале @BA_SA_Arch_eduгде помимо меня еще 2000+ аналитиков с удовольствием примут участие в этой дискуссии :)
ER это тип диаграммы где, как вы сами написали визуализируются сущности и их связи между собой, бизнес-объект это частный случай сущности, модель предметной области это набор бизнес-объектов(сущностей) связанных между собой. Таким образом даже с точки зрения формальной логики нет противоречия в применении ER для визуализации модели предметной области. Если вы встречали материалы где это запрещено делать пожалуйста поделитесь ими с удовольствием расширю свой кругозор.
В сфере информационных технологий в принципе очень мало дерективных вещей и правил. Поэтому говорить про обязательность чего либо не совсем корректно. Скорее есть рекомендации. С точки зрения применения отдельных инструментов упорядочивания информации об этом можно начинать задумываться в командах 3+ человека, так как это уже группа людей в которой общение может происходить между двумя участниками и некоторую информацию нужно фиксировать, чтобы донести ее до третьего и любого другого участника команды. И как вы могли прочитать в статье:
Все артефакты, про которые я рассказал, не истина в последней инстанции, не обязательность.
Каждая команда сама должна решать нужен ей тот или иной инструмент или нет.
А расходы на это будут разные во всех проектах, так как будут зависит, от количества артефактов, инструментов, процессов, размера команды, сложности проекта, используемых технологий и тд. и тп. И если углубляться в этом направлении, то надо оценивать не расходы, а ценность которую приносит тот или иной инструмент в отдельном проекте.Повторюсь своим ответом из пошлого комментария:
Вы воспринимаете материал, как единый подход, хотя изначально это перечень автономных инструментов, из которых каждый может выбрать то что ему нравится и подходит :)
О чем и говорится в статье:
Все артефакты, про которые я рассказал, не истина в последней инстанции, не обязательность. Это инструменты, которые вы можете принести в свой проект и модифицировать под себя
>>> Начинать можно с чего угодно.
Думаю, тут суть любого проекта по избавлению от хаоса :)
Понравилось "Как внедрить шаблон чего-либо". Хороший подход как работа с сопротивлением при внедрении непопулярных решений
В общем случае у любого решения есть тот кому оно не нравится. :) Описанный подход действует когда есть большинство заинтересованное в общей цели. Если же непопулярное решение внедряется для незаинтересованного большинства, тот тут уже нужны другие инструменты и более глубокая и тонка работа с аудиторией.
Спасибо, полезно. Буду использовать
Как навести порядок в хаосе из требований и документации?