Все верно, при таком количестве аналитиков руководитель переходит на C-level должностей и становится на один уровень или на n-1 уровень с СЕО. Отличие будет только в более узкой специализации, CEO условно отвечает за все, а гипотетический CSAO (chief system analysis officer) будет сфокусирован на работе аналитиков.
В общем случае у любого решения есть тот кому оно не нравится. :) Описанный подход действует когда есть большинство заинтересованное в общей цели. Если же непопулярное решение внедряется для незаинтересованного большинства, тот тут уже нужны другие инструменты и более глубокая и тонка работа с аудиторией.
В абзадце на который вы ссылаетесь приводится пример для чего может быть использован реестр бизнес-процессов. Вопрос с чего начинать проектирование ИС с БП или отдельных требований и как отдельные изменения ФТ влияют на другие требования не относится к теме этой статьи. Можем обсудить эту тему в телеграм канале @BA_SA_Arch_eduгде помимо меня еще 2000+ аналитиков с удовольствием примут участие в этой дискуссии :)
ER это тип диаграммы где, как вы сами написали визуализируются сущности и их связи между собой, бизнес-объект это частный случай сущности, модель предметной области это набор бизнес-объектов(сущностей) связанных между собой. Таким образом даже с точки зрения формальной логики нет противоречия в применении ER для визуализации модели предметной области. Если вы встречали материалы где это запрещено делать пожалуйста поделитесь ими с удовольствием расширю свой кругозор.
В сфере информационных технологий в принципе очень мало дерективных вещей и правил. Поэтому говорить про обязательность чего либо не совсем корректно. Скорее есть рекомендации. С точки зрения применения отдельных инструментов упорядочивания информации об этом можно начинать задумываться в командах 3+ человека, так как это уже группа людей в которой общение может происходить между двумя участниками и некоторую информацию нужно фиксировать, чтобы донести ее до третьего и любого другого участника команды. И как вы могли прочитать в статье: Все артефакты, про которые я рассказал, не истина в последней инстанции, не обязательность. Каждая команда сама должна решать нужен ей тот или иной инструмент или нет. А расходы на это будут разные во всех проектах, так как будут зависит, от количества артефактов, инструментов, процессов, размера команды, сложности проекта, используемых технологий и тд. и тп. И если углубляться в этом направлении, то надо оценивать не расходы, а ценность которую приносит тот или иной инструмент в отдельном проекте.
Повторюсь своим ответом из пошлого комментария: Вы воспринимаете материал, как единый подход, хотя изначально это перечень автономных инструментов, из которых каждый может выбрать то что ему нравится и подходит :) О чем и говорится в статье: Все артефакты, про которые я рассказал, не истина в последней инстанции, не обязательность. Это инструменты, которые вы можете принести в свой проект и модифицировать под себя
Новизна заключается в том, что в материале структурировано описаны инструменты, которые могут быть применены для упорядочивания работы с требованиями и документацией, собственно это и следует из заголовка. Статья не претендует на изобретение нового, она агрегирует в одном месте существующее.
поря́док - Ожидаемое, предсказуемое, правильно организованное состояние или расположение чего-либо. все приведенные инструменты, как раз и направлены на создание предсказуемого расположения информации в проекте. Да, внедрение любого структурирующего артефакта требует трудозатрат на его поддержание в актуальном состоянии, о чем тоже упоминается в статье. При этом каждая команда сама должна определять, что из приведенного инструментария ей необходимо. У кого-то вообще нет документации, а только исходных код и они отлично себя чувствуют :) Вы воспринимаете материал, как единый подход, хотя изначально это перечень автономных инструментов, из которых каждый может выбрать то что ему нравится и подходит :)
О БП и требованиях. Есть разные уровни требований. Если укрупнить то на основе бизнес-требований(БТ) мы строим бизнес-процесс(БП), далее отдельные шаги БП описываются детальными функциональными требованиями(ФТ). Все они связаны между собой явно через трассировку требований (писал о ней в предыдущей своей статье) или умозрительно в головах членов команды. Изменения могут транслироваться, как сверху вниз от БТ, через БП к ФТ, или наверх от ФТ к БП.
В разделе про модель предметной области использую термин бизнес-объект так как он лучше подчеркивает, что речь идет именно о бизнесовой (логической) модели, а не о физической (системной). Термин сущность более общий и по моим наблюдениям часто создает путаницу о чем именно идет речь, об объекте реального мира которым оперирует система или о системных объектах в базе данных.
Трассировка - это в первую очередь именно инструмент, который позволяет упростить работу с большим количеством уже имеющихся или создаваемых артефактов.
В плане наведения порядка и с чего это лучше начинать делать. Тебе подойдет мой доклад "Как навести порядок когда попал в хаос из требований и документации?" с конференции "Второй Аналитический Курултай в Центральной Азии" - которая проходила в Алмате.
Сейчас готовлю по этому докладу статью, пока можно посмотреть его запись.
Там как раз подробно рассказываю, с чего начать и с помощью каких инструментов можно наводить порядок и структурировать работу над проектом.
Если говорить про изменения самих основ бизнес/системного анализа и проектирования информационных систем, здесь конкретные тенденции пока сложно выделить.
С точки зрения инструментов, применяемых аналитиками, уже сейчас нужно начинать знакомиться с ИИ и нейросетями, понимать, как они работают и учиться ими пользоваться в повседневной жизни и находить варианты применения для рутинных рабочих задач.
Транскрибирование записи встречи с заказчиком, подготовка драфта протокола встречи, генерация изображения для визуализации, подготовка драфта описания метрики - это малая часть того, что уже сейчас можно делать с помощью ИИ и существенно ускорять процесс своей работы.
Предвосхищая популярный вопрос, что ИИ оставит аналитиков без работы - я в это не верю :)
На мой взгляд, ИИ, на текущий момент, и на ближайшем горизонте своего развития - это супер продвинутый Т9, им просто нужно научиться пользоваться.
Заинтересовал момент о квалификации аналитика и пороге вхождения в проекты с микросервисной архитектурой. В голове родился популистский слоган: "Джунам и новичкам тут нет места!" Но давайте по порядку.
Если смотреть со стороны, то аналитиков и их задачи в проекте с микросервисной архитектурой можно разделить на две роли/категории:
аналитики решения (аналитики кроссервисных задач)
аналитики сервисов
аналитики решения - работают с кроссервисными задачами, включающими интеграции, очереди, балансировки и все остальные прелести, перечисленные автором. Они должны обладать широкими знаниями технологий, опытом и глубоким пониманием системы.
аналитики сервисов - решают задачи, контекст которых локализован внутри отдельных сервисов, и для аналитика это становится просто продуктом, который имеет ряд внешних интеграций.
Таким образом, из различий в решаемых задачах, уровне компетенций и глубине знания продукта вытекает приведенный выше лозунг с небольшим уточнением: "Джунам и новичкам в решении кроссервисных задач нет места".
Обусловлено это тем, что джун, не решавший ранее никаких задач, потеряется в дебрях межсервисных взаимодействий, технологий и бизнес логики, опытный новичок на проекте так же будет плутать без глубоких знаний назначения сервисов.
Однако вопросы роста команды, вместе с ростом количества задач и текучки кадров, всегда будут актуальны, отсюда наиболее эффективным маршрутом адаптации и развития аналитиков видится их первичное привлечение к решению задач в рамках отдельных сервисов с последующим расширением кругозора на всю систему и переходом уже в разряд аналитиков решения.
Интересно услышать ваше мнение на этот счет? =)
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Все верно, при таком количестве аналитиков руководитель переходит на C-level должностей и становится на один уровень или на n-1 уровень с СЕО. Отличие будет только в более узкой специализации, CEO условно отвечает за все, а гипотетический CSAO (chief system analysis officer) будет сфокусирован на работе аналитиков.
В общем случае у любого решения есть тот кому оно не нравится. :) Описанный подход действует когда есть большинство заинтересованное в общей цели. Если же непопулярное решение внедряется для незаинтересованного большинства, тот тут уже нужны другие инструменты и более глубокая и тонка работа с аудиторией.
Именно так :) Но к сожалению не для всех это очевидно.
В абзадце на который вы ссылаетесь приводится пример для чего может быть использован реестр бизнес-процессов. Вопрос с чего начинать проектирование ИС с БП или отдельных требований и как отдельные изменения ФТ влияют на другие требования не относится к теме этой статьи. Можем обсудить эту тему в телеграм канале @BA_SA_Arch_eduгде помимо меня еще 2000+ аналитиков с удовольствием примут участие в этой дискуссии :)
ER это тип диаграммы где, как вы сами написали визуализируются сущности и их связи между собой, бизнес-объект это частный случай сущности, модель предметной области это набор бизнес-объектов(сущностей) связанных между собой. Таким образом даже с точки зрения формальной логики нет противоречия в применении ER для визуализации модели предметной области. Если вы встречали материалы где это запрещено делать пожалуйста поделитесь ими с удовольствием расширю свой кругозор.
В сфере информационных технологий в принципе очень мало дерективных вещей и правил. Поэтому говорить про обязательность чего либо не совсем корректно. Скорее есть рекомендации. С точки зрения применения отдельных инструментов упорядочивания информации об этом можно начинать задумываться в командах 3+ человека, так как это уже группа людей в которой общение может происходить между двумя участниками и некоторую информацию нужно фиксировать, чтобы донести ее до третьего и любого другого участника команды. И как вы могли прочитать в статье:
Все артефакты, про которые я рассказал, не истина в последней инстанции, не обязательность.
Каждая команда сама должна решать нужен ей тот или иной инструмент или нет.
А расходы на это будут разные во всех проектах, так как будут зависит, от количества артефактов, инструментов, процессов, размера команды, сложности проекта, используемых технологий и тд. и тп. И если углубляться в этом направлении, то надо оценивать не расходы, а ценность которую приносит тот или иной инструмент в отдельном проекте.
Повторюсь своим ответом из пошлого комментария:
Вы воспринимаете материал, как единый подход, хотя изначально это перечень автономных инструментов, из которых каждый может выбрать то что ему нравится и подходит :)
О чем и говорится в статье:
Все артефакты, про которые я рассказал, не истина в последней инстанции, не обязательность. Это инструменты, которые вы можете принести в свой проект и модифицировать под себя
Добрый день!
Начнем с самого короткого вашего комментария :)
Новизна заключается в том, что в материале структурировано описаны инструменты, которые могут быть применены для упорядочивания работы с требованиями и документацией, собственно это и следует из заголовка. Статья не претендует на изобретение нового, она агрегирует в одном месте существующее.
Согласно толковому словарю
поря́док - Ожидаемое, предсказуемое, правильно организованное состояние или расположение чего-либо.
все приведенные инструменты, как раз и направлены на создание предсказуемого расположения информации в проекте. Да, внедрение любого структурирующего артефакта требует трудозатрат на его поддержание в актуальном состоянии, о чем тоже упоминается в статье. При этом каждая команда сама должна определять, что из приведенного инструментария ей необходимо. У кого-то вообще нет документации, а только исходных код и они отлично себя чувствуют :)
Вы воспринимаете материал, как единый подход, хотя изначально это перечень автономных инструментов, из которых каждый может выбрать то что ему нравится и подходит :)
О БП и требованиях.
Есть разные уровни требований. Если укрупнить то на основе бизнес-требований(БТ) мы строим бизнес-процесс(БП), далее отдельные шаги БП описываются детальными функциональными требованиями(ФТ). Все они связаны между собой явно через трассировку требований (писал о ней в предыдущей своей статье) или умозрительно в головах членов команды. Изменения могут транслироваться, как сверху вниз от БТ, через БП к ФТ, или наверх от ФТ к БП.
В разделе про модель предметной области использую термин бизнес-объект так как он лучше подчеркивает, что речь идет именно о бизнесовой (логической) модели, а не о физической (системной). Термин сущность более общий и по моим наблюдениям часто создает путаницу о чем именно идет речь, об объекте реального мира которым оперирует система или о системных объектах в базе данных.
Привет!
Опубликовал статью о которой говорил, про структурирование требований и документации Как навести порядок в хаосе из требований и документации?
Рад, что мой опыт будет вам полезен!
Привет!
Трассировка - это в первую очередь именно инструмент, который позволяет упростить работу с большим количеством уже имеющихся или создаваемых артефактов.
В плане наведения порядка и с чего это лучше начинать делать. Тебе подойдет мой доклад "Как навести порядок когда попал в хаос из требований и документации?" с конференции "Второй Аналитический Курултай в Центральной Азии" - которая проходила в Алмате.
Сейчас готовлю по этому докладу статью, пока можно посмотреть его запись.
Там как раз подробно рассказываю, с чего начать и с помощью каких инструментов можно наводить порядок и структурировать работу над проектом.
Если будут дополнительные вопросы, пиши!
Приветствую!
Если говорить про изменения самих основ бизнес/системного анализа и проектирования информационных систем, здесь конкретные тенденции пока сложно выделить.
С точки зрения инструментов, применяемых аналитиками, уже сейчас нужно начинать знакомиться с ИИ и нейросетями, понимать, как они работают и учиться ими пользоваться в повседневной жизни и находить варианты применения для рутинных рабочих задач.
Транскрибирование записи встречи с заказчиком, подготовка драфта протокола встречи, генерация изображения для визуализации, подготовка драфта описания метрики - это малая часть того, что уже сейчас можно делать с помощью ИИ и существенно ускорять процесс своей работы.
Предвосхищая популярный вопрос, что ИИ оставит аналитиков без работы - я в это не верю :)
На мой взгляд, ИИ, на текущий момент, и на ближайшем горизонте своего развития - это супер продвинутый Т9, им просто нужно научиться пользоваться.
Татьяна, большое спасибо за интересную статью!
Заинтересовал момент о квалификации аналитика и пороге вхождения в проекты с микросервисной архитектурой. В голове родился популистский слоган: "Джунам и новичкам тут нет места!" Но давайте по порядку.
Если смотреть со стороны, то аналитиков и их задачи в проекте с микросервисной архитектурой можно разделить на две роли/категории:
аналитики решения (аналитики кроссервисных задач)
аналитики сервисов
аналитики решения - работают с кроссервисными задачами, включающими интеграции, очереди, балансировки и все остальные прелести, перечисленные автором. Они должны обладать широкими знаниями технологий, опытом и глубоким пониманием системы.
аналитики сервисов - решают задачи, контекст которых локализован внутри отдельных сервисов, и для аналитика это становится просто продуктом, который имеет ряд внешних интеграций.
Таким образом, из различий в решаемых задачах, уровне компетенций и глубине знания продукта вытекает приведенный выше лозунг с небольшим уточнением: "Джунам и новичкам в решении кроссервисных задач нет места".
Обусловлено это тем, что джун, не решавший ранее никаких задач, потеряется в дебрях межсервисных взаимодействий, технологий и бизнес логики, опытный новичок на проекте так же будет плутать без глубоких знаний назначения сервисов.
Однако вопросы роста команды, вместе с ростом количества задач и текучки кадров, всегда будут актуальны, отсюда наиболее эффективным маршрутом адаптации и развития аналитиков видится их первичное привлечение к решению задач в рамках отдельных сервисов с последующим расширением кругозора на всю систему и переходом уже в разряд аналитиков решения.
Интересно услышать ваше мнение на этот счет? =)