Это частный случай. Если даёте определение без контекста, то сначала дайте контекст перед определением - в области разработки программных продуктов
Цель исследования — погрузиться в процесс найма, задачи и инструменты бизнес-аналитиков и узнать, какие навыки требуются специалистам в работе и при трудоустройстве
Это очень правильно, что есть формализованная цель статьи, многие про это не знают или забывают. Но тут цель совершенно непонятная и странная. Какое отношение аудитория Хабра имеет к вашему "погружению" внутри вашей компании? Ваше "погружение" - это инструмент, а не цель
Специалистов можно разделить на две группы: на «чистых»...
Во-1х, это вы очень смело рубанули. Есть разные взгляды на границы деятельности БА, в отрасли постоянно это обусуждается. Но вы, кажется, уже за всех всё решили. Во-2х, из всех возможных терминологий выбрана одна из самых трешовых - "чистые" и "не чистые"
«Чистые» работают в...
Специфика (прости, господи) "чистых" и (ещё раз прости) "не чистых" зависит не от отрасли, а от, простыми словами, внутреннего устройства каждой компании / проекта - роли, БП и т.п.
Вот чем занимаются «чистые» бизнес-аналитики:...
Странная смесь, странные формулировки. Предоставление бизнес-процессов в виде отчётов и презентаций? "Бизнес-аналитики могут вручную проверять результат" - почему вдруг вручную? какой результат (в проектах много всяких результатов). Одна и та же функциональность - про показ решений - для "чистых-грязных" преподнесена как их различие. Тут уж как-то надо договориться внутри себя. Ну и т.п.
Извините, до сути статьи уже на смог дойти, в отличие от более терпеливых коллег. Это невозможно читать
Я бы сказал, что надёжность - это как раз НФТ, а не архитектура. Это требование куда больше зависит от процесса и вашей инфраструктуры
Несколько раз прочитал. Не понял логику, что означает утверждение "надёжность - не архитектура"? А дальше - перепутаны паровоз и вагоны. Выше @funca верно сказал - " Архитектура определяется НФТ", а не наоборот. Это инфраструктура должна подчиняться требованиям надёжности и прочих НФТ. На то они и требования
Как только хочется сказать "невыгодный/выгодный", "ценности", "хорошо/плохо" - сразу отвечать на вопрос, кто акторы (чьих точек зрения будет). Иначе крайне неопределённый разговор
Тема 1: Перепутаны понятия "иррациональное" и "непознанное". Человек - абсолютно физическое существо. Как изучат, так и будет для нашего понимания 100% предсказуем. Сейчас неизучен, есть очень грубые модели, поэтому нам человек и кажется иррациональным
Задача БА - выявить цель бизнеса, когда к нему прикатывает "Мы хотим". И только потом работать с требованиями по реальным целям.
Поэтому приведённый пример с БА - это плохой БА. БА - это не передачтик между бизнесом и командой разработки. Прежде чем выкатывать требования, БА должен прогнать их по критериям. И тогда автоматом не будет этого примера.
Ок, допустим, БА промахнулся с договором через e-mail. Но дальше, если возможные решения напрямую затрагивают бизнес-процессы, то это уже вне работы СА. То, что описано в примере, обсуждается на этапе принятия решений по бизнес-процессам (см. выше, это я уже повторяюсь). И в данном случае СА это должен вернуть взад БА, чтоб тот почесал затылок и провернул ещё одну итерацию с бизнесом и командой
Спасибо за краткое изложение, но у меня повились вопросы.
Логичнее располагать вопросы аналтика иерархично. Первым напрашивается "Зачем?"
"Зачем это делать?" для СА - расширить функциональность? Если у нас есть БА, то не могу представить для СА такой формулировки. Результат БА - артефакты в виде описанных конкретных целей бизнеса и способа их достижения бизнесом - бизнес-процесс. БА говорит, что делать с бизнес-функциональностью (создать/изменить/убить, не "расширить/уменьшить"). Тогда зачем это делать СА? Чтобы заработать денег - какой вопрос, такой и ответ, потому что вопрос должен указывать на объект, а не на субъект; например, Что должен достичь СА? достичь (описанных БА) конкретных целей системы.
Microsoft теперь позиционирует Copilot как бесплатную версию своего чат-бота, которая будет доступна всем пользователям в поисковике Bing, браузере Edge и Windows, а также по собственному адресу copilot.microsoft.com
В Firefox - недоступна. И это логично, потому что в оригинале статьи нет такого, перевод неточный. Иметь свой домен и быть доступным по адресу - разная функциональность.
Я, как обыватель, ничего не понял, а что для меня, потребителя, полезного? Ну, я и так почти 2 года назад понакупал кучу китайских 2ТБ NVMe накопителей для апгрейда всех ноутов в семье. Тут что-то ёмче/круче/дешевле? И текст какой-то странный:
Так, в КНР в продаже появился 1-терабайтный накопитель ZhiTai Ti600
Упаси боже, чтоб я кого-то убеждал что-то переделывать в неизвестной мне системе. Это я пытаюсь понять логику и как оно работает через вопросы и некоторые постулаты
Просто я за то, чтобы глагол определял именно то значение, которое он имеет в своём действии. Повторюсь, под "принять" подразумевать "создать" - очень плохая практика. Ещё раз повторюсь, объект или есть, или его нет. Что такое "безликая сущность с генерализованным названием"? Это или запрос (объект!) на создание объекта-заявки, или сама заявка. Посередине не бывает. В принципе, как в ИС возможно существование "безликой сущности"?
Эктором может быть что угодно, чьё поведение выступает триггером для функциональности
Триггер - это какое-то событие. Актор - это субъект, что-то выполняющий. Триггер - это объект-событие, порождаемое субъектом (актором).
Не вижу в этом место времени как актору. В лучшем случае, актор может использовать время для чего-то. Время - ничего использовать не может. Это измерение, физическая величина. Актором может быть длина? Температура?
В примере, к сожалению, много чего напутано. Надо отделять артефакты физического мира и артефакты смоделированной ИС. Мы работаем с моделью. Актор в ИС - это не человек во всём его многообразии. Это субъект со строго определёнными свойствами. ИС ждёт от актора строго определённый набор воздействий. Всё остальное - какие у реального человека обстоятельства, какие у него там бумажки с какими-то хоть дважды бизнес-правилами - это не входит в ИС. Хотите учесть бизнес-правила? Смоделируйте компонент в ИС или внешнюю ИС, где они реализованы. На самом деле они всегда есть в ИС. Но не надо путать реализованное в ИС и артефакт внешнего мира. Учесть "обстоятельства"? Аналогично.
Я заговорился )). В примере опять не вижу никакого места времени. Только актор-человек, только актор-система, только хардкор. Актор-человек задал правила формирования объекта (от полноценной установки параметров до вырожденного в триггер правила - нажатия кнопки) - актор система понеслась выполнять действия с объектом. Если актор-человек здесь действует как объект других акторов ("обстоятельств") - нарисуйте этого актора-обстоятельство. Если это, конечно, полезно для проектирования/использования ИС. Но тут поаккуратнее, включение в модель ИС большого количества акторов сильно усложняет проектирование и поведение ИС. Идеальная модель должна включать весь физический мир вокруг нас :)). Тема границ модели, кстати, тоже важна, но это отдельный большой раздел проектирования ИС.
Так и не понял, что из этого верно:
или
Это частный случай. Если даёте определение без контекста, то сначала дайте контекст перед определением - в области разработки программных продуктов
Это очень правильно, что есть формализованная цель статьи, многие про это не знают или забывают.
Но тут цель совершенно непонятная и странная. Какое отношение аудитория Хабра имеет к вашему "погружению" внутри вашей компании? Ваше "погружение" - это инструмент, а не цель
Во-1х, это вы очень смело рубанули. Есть разные взгляды на границы деятельности БА, в отрасли постоянно это обусуждается. Но вы, кажется, уже за всех всё решили.
Во-2х, из всех возможных терминологий выбрана одна из самых трешовых - "чистые" и "не чистые"
Специфика (прости, господи) "чистых" и (ещё раз прости) "не чистых" зависит не от отрасли, а от, простыми словами, внутреннего устройства каждой компании / проекта - роли, БП и т.п.
Странная смесь, странные формулировки.
Предоставление бизнес-процессов в виде отчётов и презентаций?
"Бизнес-аналитики могут вручную проверять результат" - почему вдруг вручную? какой результат (в проектах много всяких результатов).
Одна и та же функциональность - про показ решений - для "чистых-грязных" преподнесена как их различие. Тут уж как-то надо договориться внутри себя.
Ну и т.п.
Извините, до сути статьи уже на смог дойти, в отличие от более терпеливых коллег. Это невозможно читать
Так что должны делать БА и СА?
Что, на Хабре уже и так можно?
Можно пояснить, что здесь подразумевается под "каноническим форматом" и "стандартными платформами для интеграций"? Желательно с примерами
Несколько раз прочитал. Не понял логику, что означает утверждение "надёжность - не архитектура"?
А дальше - перепутаны паровоз и вагоны. Выше @funca верно сказал - " Архитектура определяется НФТ", а не наоборот. Это инфраструктура должна подчиняться требованиям надёжности и прочих НФТ. На то они и требования
Поясните, какое отношение ваш пост имеет к содержанию новости
Как только хочется сказать "невыгодный/выгодный", "ценности", "хорошо/плохо" - сразу отвечать на вопрос, кто акторы (чьих точек зрения будет).
Иначе крайне неопределённый разговор
Тема 1: Перепутаны понятия "иррациональное" и "непознанное".
Человек - абсолютно физическое существо. Как изучат, так и будет для нашего понимания 100% предсказуем.
Сейчас неизучен, есть очень грубые модели, поэтому нам человек и кажется иррациональным
Задача БА - выявить цель бизнеса, когда к нему прикатывает "Мы хотим". И только потом работать с требованиями по реальным целям.
Поэтому приведённый пример с БА - это плохой БА.
БА - это не передачтик между бизнесом и командой разработки. Прежде чем выкатывать требования, БА должен прогнать их по критериям. И тогда автоматом не будет этого примера.
Ок, допустим, БА промахнулся с договором через e-mail.
Но дальше, если возможные решения напрямую затрагивают бизнес-процессы, то это уже вне работы СА.
То, что описано в примере, обсуждается на этапе принятия решений по бизнес-процессам (см. выше, это я уже повторяюсь). И в данном случае СА это должен вернуть взад БА, чтоб тот почесал затылок и провернул ещё одну итерацию с бизнесом и командой
Приведите пример пересечения задач СА и БА
Спасибо за краткое изложение, но у меня повились вопросы.
Логичнее располагать вопросы аналтика иерархично. Первым напрашивается "Зачем?"
"Зачем это делать?" для СА - расширить функциональность?
Если у нас есть БА, то не могу представить для СА такой формулировки.
Результат БА - артефакты в виде описанных конкретных целей бизнеса и способа их достижения бизнесом - бизнес-процесс. БА говорит, что делать с бизнес-функциональностью (создать/изменить/убить, не "расширить/уменьшить").
Тогда зачем это делать СА? Чтобы заработать денег - какой вопрос, такой и ответ, потому что вопрос должен указывать на объект, а не на субъект; например, Что должен достичь СА? достичь (описанных БА) конкретных целей системы.
Если мы тут про язык, то в чём смысл выражения?
Это какое-то устойчивое выражение? Не понимаю взаимоотношений бумажек и липового мёда
Апд. Нашёл - ГрОб
Просто скажу - не читайте этот бред. Антинаучно, последующее утверждение противоречит предыдущему и т.п. В топку
Как пример МС - наверное, хорошо. Как описание МС - ужасно
В Firefox - недоступна. И это логично, потому что в оригинале статьи нет такого, перевод неточный. Иметь свой домен и быть доступным по адресу - разная функциональность.
Я, как обыватель, ничего не понял, а что для меня, потребителя, полезного?
Ну, я и так почти 2 года назад понакупал кучу китайских 2ТБ NVMe накопителей для апгрейда всех ноутов в семье. Тут что-то ёмче/круче/дешевле?
И текст какой-то странный:
, а на фото - 2ТБ с таким же названием модели
Вот! ))
Упаси боже, чтоб я кого-то убеждал что-то переделывать в неизвестной мне системе. Это я пытаюсь понять логику и как оно работает через вопросы и некоторые постулаты
Просто я за то, чтобы глагол определял именно то значение, которое он имеет в своём действии. Повторюсь, под "принять" подразумевать "создать" - очень плохая практика.
Ещё раз повторюсь, объект или есть, или его нет. Что такое "безликая сущность с генерализованным названием"? Это или запрос (объект!) на создание объекта-заявки, или сама заявка. Посередине не бывает. В принципе, как в ИС возможно существование "безликой сущности"?
Триггер - это какое-то событие.
Актор - это субъект, что-то выполняющий.
Триггер - это объект-событие, порождаемое субъектом (актором).
Не вижу в этом место времени как актору. В лучшем случае, актор может использовать время для чего-то. Время - ничего использовать не может. Это измерение, физическая величина. Актором может быть длина? Температура?
В примере, к сожалению, много чего напутано.
Надо отделять артефакты физического мира и артефакты смоделированной ИС.
Мы работаем с моделью. Актор в ИС - это не человек во всём его многообразии. Это субъект со строго определёнными свойствами. ИС ждёт от актора строго определённый набор воздействий.
Всё остальное - какие у реального человека обстоятельства, какие у него там бумажки с какими-то хоть дважды бизнес-правилами - это не входит в ИС.
Хотите учесть бизнес-правила? Смоделируйте компонент в ИС или внешнюю ИС, где они реализованы. На самом деле они всегда есть в ИС. Но не надо путать реализованное в ИС и артефакт внешнего мира. Учесть "обстоятельства"? Аналогично.
Я заговорился )). В примере опять не вижу никакого места времени. Только актор-человек, только актор-система
, только хардкор.Актор-человек задал правила формирования объекта (от полноценной установки параметров до вырожденного в триггер правила - нажатия кнопки) - актор система понеслась выполнять действия с объектом.
Если актор-человек здесь действует как объект других акторов ("обстоятельств") - нарисуйте этого актора-обстоятельство. Если это, конечно, полезно для проектирования/использования ИС. Но тут поаккуратнее, включение в модель ИС большого количества акторов сильно усложняет проектирование и поведение ИС. Идеальная модель должна включать весь физический мир вокруг нас :)).
Тема границ модели, кстати, тоже важна, но это отдельный большой раздел проектирования ИС.