И тогда с заказчиком можно будет разговаривать уже на языке теории систем, то есть — на уровне системных компонентов и конкретных алгоритмов, наполняющих конкретную систему.
С заказчиком никогда не придётся разговаривать на языке теории систем.
У заказчика область определения - бизнес структура и бизнес процессы в функциональных границах его бизнеса. Если бизнес заказчика не системный анализ (такое случается), то ему нет смысла (непрофильно и дорого) содержать системных аналитиков в области автоматизации его бизнеса.
Собственно, БА должен согласовать/разработать требования, а затем бизнес процессы и передать их системному (функциональному, техническому) архитектору для разработки архитектуры системы, и далее - по структуре разработке, внедрению, эксплуатации, обслуживанию. В процессе разработки, испытаний, сдачи заказчику БА должен согласовать с заказчиком, что требования выполняются и реализация процессов соответствует. Затем начинается песня о доп. требованиях.
Во-первых, мелкому менеджеру вообще нефиг что-то спрашивать у разработчика, пусть с тимлидом общается.
Во-первых, в тексте моём - "исполнитель". Это иерархия планирования - хоть "разработчик", хоть "тимлид", хоть, ну да, он сам. Непонимание работы в проекте ведёт к разговорам о "страдании хернёй" и в третьей позиции "ты так не работаешь" (гыы, а работа это?).
Во-вторых, "если спринт не закрыли", то "задавать вопросы" уже поздно.
"Дёргать" не нужно, нужно управлять. Процессы здесь, конечно, важны. Безусловно. Но. Если очевидно, что исполнитель 7,5 часов разговаривает с мамой по телефону, а 0,5 часа обедает, то бэклоги, спринты и ретроспективы здесь не помогут.
если вы видите врача явно «ублюдского» психотипа в коммерческой клинике и его там терпят долго — значит, высока вероятность, что он мог добиться этого невероятно хорошими медицинскими результатами.
оптимизация делается на математической модели от этого она не становится цифровым двойником. А вот когда в модели объекта есть данные от реального объекта тогда она станет цифровым двойником.
В "математической модели" (что бы под этим не понималось) всегда есть данные от реального объекта. Иначе эта "модель" ...эээ... имеет назначение, которое сложно себе представить.
Оптимизация по диапазонам критериев и параметров учитывает реальные диапазоны функционирования системы.
упор на автономность продуктовых команд. В целевой картине они могут самостоятельно следить за рисками и даже их выявлять, будучи погруженными в контекст и понимая свои бизнес-процессы;
Управление рисками ИБ всегда ограничивает функциональность реализации бизнес-процессов. Автономные команды не заинтересованы в этих ограничениях. Т.е., они ничего о рисках ИБ не расскажут, а уж "выявлять" ...
Двойник нужен для оптимизации. Оптимизационные модификации на двойнике в случае сложных систем существенно дешевле и быстрее. После отработки на двойнике оптимальные варианты можно тестировать на оригинале.
"Страдание хернёй" в 90% случаев происходит следующим образом.
Мелкий менеджер попросил у исполнителя график разработки. Получил. Отправил сводный график наверх. Получил ок (график не изменился). Пришёл к исполнителю, выдал ему его же исполнителя график. Исполнитель, отставив ножку в третью позу, заявил, что "он так не работает".
Моё сообщение относится к материалу статьи в том плане, что массовый набор персонала (иначе, для чего нужны "ролевые игры" с интервьюерами) всегда зависит от уровня самого интервьюера, и отобранный кандидат (в массе) выше по уровню быть не может.
Расставление оценок по шкале итервьюерами отражает уровень подготовки их самих, и в меньшей степени - кандидата. Т.е., полезно понимать, что набраны будут (в максимально благоприятном варианте) кандидаты уровня интервьюеров. Однако, этот показатель тоже недостижим. Реальная цифра - 70-80%. Подход работает при массовом найме неквалифицированного персонала.
Если же речь идёт о целевом персональном интервью для найма среднего и выше уровня, то собеседующий знает, что у него спросить и как, и шпаргалки ему не нужны.
"Механизация"/"автоматизация" массового процесса оценки чего угодно (в том числе и кандидатов на вакансии) не приводит к отбору материала выше по уровню (оцениваемому), нежели уровень самих оценщиков, сколько бы "ролевых игр" с ними не проводили.
нужны четкие меры по обеспечению безопасности таких систем или систем куда оно будет интегрироваться
Практически любая сложная разработка в каждой области является, прежде всего, разработкой оружия, а затем гражданское применение. В разработке вакцин, например - это вообще единый процесс. ИИ (кто бы и что бы под этим не понимал) таже вид вооружений.
Применения звукосочетания "магия" к процессам разработки спецификаций, техпроцессов, софта, систем и пр. используется для формирования контингента, верящего в магию.
Есть, конечно, ещё и область юмора. Однако, юмор (по большей части) служит для того же - формирование ментальной базы.
"Теория заговора" часто граничит с вопросом "как оно на самом деле?".
Этот вопрос относится к содержанию знания человека. Знание формируется только и только с наличием практического опыта, на основе которого корректируются представления (это то, что слышали, читали и пр.).
Так вот. Практический опыт в сферах, где часто возникают "теории заговора", практически доступен ограниченной группе людей, которые, собственно, и обладают знаниями в этой сфере. Остальные люди имеют только представления (в силу недоступности практики), которые могут быть весьма и весьма своеобразными, независимо от того сформированы они внешними или внутренними механизмами или их комбинацией.
С заказчиком никогда не придётся разговаривать на языке теории систем.
У заказчика область определения - бизнес структура и бизнес процессы в функциональных границах его бизнеса. Если бизнес заказчика не системный анализ (такое случается), то ему нет смысла (непрофильно и дорого) содержать системных аналитиков в области автоматизации его бизнеса.
Собственно, БА должен согласовать/разработать требования, а затем бизнес процессы и передать их системному (функциональному, техническому) архитектору для разработки архитектуры системы, и далее - по структуре разработке, внедрению, эксплуатации, обслуживанию. В процессе разработки, испытаний, сдачи заказчику БА должен согласовать с заказчиком, что требования выполняются и реализация процессов соответствует. Затем начинается песня о доп. требованиях.
Не существует "самых сложных тем", которые нужно было бы "подавать" "аудитории".
"Сложные темы" можно разрабатывать и использовать для получения результата. Результат можно "подавать" аудитории.
Во-первых, в тексте моём - "исполнитель". Это иерархия планирования - хоть "разработчик", хоть "тимлид", хоть, ну да, он сам. Непонимание работы в проекте ведёт к разговорам о "страдании хернёй" и в третьей позиции "ты так не работаешь" (гыы, а работа это?).
Во-вторых, "если спринт не закрыли", то "задавать вопросы" уже поздно.
"Дёргать" не нужно, нужно управлять. Процессы здесь, конечно, важны. Безусловно. Но. Если очевидно, что исполнитель 7,5 часов разговаривает с мамой по телефону, а 0,5 часа обедает, то бэклоги, спринты и ретроспективы здесь не помогут.
Или он зять хозяина.
Стартаперов должно быть много.
Каждому выдаётся личный гараж и коленка.
В "математической модели" (что бы под этим не понималось) всегда есть данные от реального объекта. Иначе эта "модель" ...эээ... имеет назначение, которое сложно себе представить.
Оптимизация по диапазонам критериев и параметров учитывает реальные диапазоны функционирования системы.
Управление рисками ИБ всегда ограничивает функциональность реализации бизнес-процессов. Автономные команды не заинтересованы в этих ограничениях. Т.е., они ничего о рисках ИБ не расскажут, а уж "выявлять" ...
Двойник нужен для оптимизации. Оптимизационные модификации на двойнике в случае сложных систем существенно дешевле и быстрее. После отработки на двойнике оптимальные варианты можно тестировать на оригинале.
"Страдание хернёй" в 90% случаев происходит следующим образом.
Мелкий менеджер попросил у исполнителя график разработки. Получил. Отправил сводный график наверх. Получил ок (график не изменился). Пришёл к исполнителю, выдал ему его же исполнителя график. Исполнитель, отставив ножку в третью позу, заявил, что "он так не работает".
Что такое "хайпа", я не знаю.
Моё сообщение относится к материалу статьи в том плане, что массовый набор персонала (иначе, для чего нужны "ролевые игры" с интервьюерами) всегда зависит от уровня самого интервьюера, и отобранный кандидат (в массе) выше по уровню быть не может.
Расставление оценок по шкале итервьюерами отражает уровень подготовки их самих, и в меньшей степени - кандидата. Т.е., полезно понимать, что набраны будут (в максимально благоприятном варианте) кандидаты уровня интервьюеров. Однако, этот показатель тоже недостижим. Реальная цифра - 70-80%. Подход работает при массовом найме неквалифицированного персонала.
Если же речь идёт о целевом персональном интервью для найма среднего и выше уровня, то собеседующий знает, что у него спросить и как, и шпаргалки ему не нужны.
Инструментарий - важная составляющая достижения цели. Главное - нэ пэрэпутать цель и инструмент. "Мечта" "купить машину", чтобы что?
Тема злого демона Электромонтёрика не раскрыта.
"Механизация"/"автоматизация" массового процесса оценки чего угодно (в том числе и кандидатов на вакансии) не приводит к отбору материала выше по уровню (оцениваемому), нежели уровень самих оценщиков, сколько бы "ролевых игр" с ними не проводили.
При размере проекта, начиная с нескольких сотен сотрудников, без регламентов даже узнать не получится, кто из них "со-саботажник".
Он к решению даже не присиупит.
Практически любая сложная разработка в каждой области является, прежде всего, разработкой оружия, а затем гражданское применение. В разработке вакцин, например - это вообще единый процесс. ИИ (кто бы и что бы под этим не понимал) таже вид вооружений.
В Бронксе.
Важен размер бизнеса и степень контроля зоны сбыта.
Применения звукосочетания "магия" к процессам разработки спецификаций, техпроцессов, софта, систем и пр. используется для формирования контингента, верящего в магию.
Есть, конечно, ещё и область юмора. Однако, юмор (по большей части) служит для того же - формирование ментальной базы.
"Теория заговора" часто граничит с вопросом "как оно на самом деле?".
Этот вопрос относится к содержанию знания человека. Знание формируется только и только с наличием практического опыта, на основе которого корректируются представления (это то, что слышали, читали и пр.).
Так вот. Практический опыт в сферах, где часто возникают "теории заговора", практически доступен ограниченной группе людей, которые, собственно, и обладают знаниями в этой сфере. Остальные люди имеют только представления (в силу недоступности практики), которые могут быть весьма и весьма своеобразными, независимо от того сформированы они внешними или внутренними механизмами или их комбинацией.