В вашей матрице чётко видно, что Продукты это про Discovery/Presentation, а ПМ - это про Execution/Production/Delivery. Главное полномочие ПМ - возможность распоряжения ресурсами (расходования бюджета)
Т.е. у вас, получается, кроме этапа "приёмки требований" есть ещё отдельный этап "приёмки ЧТЗ", где можно уточнить и поправить? Здорово (не везде так)!
Не увидел в перечне артефактов "требований". Получается, что вы их "перемалываете" в готовые схемы данных? Или, например, у вас отдельный шаг согласования требований перед этапом разработки ЧТЗ? Или требования указаны наряду с другими UC (например, в формате user story)?
Какой подход к внешней документации (описания протоколов интеграции разрабатываемой системы и т.п.)?
Ну и плюс непонятно, как производится разработка алгоритмов и баз данных (физической модели) - у вас аналитиков есть эксперты по используемым системам/технологиям (что бы понимать их ограничения). Или тут речь о том, что бы избавить исполнителей разработчиков от именования сущностей и т.п. ?
Аналогично. Вообще, методика PERT , насколько я знаю, подразумевает формирование сетевого графика работ. И, соответственно, этапы работ привязываются к ресурсам (хотя бы к их классам). А вот что дальше делать, было бы здорово узнать.
А разве космическое излучение не по одной штуке прилетает (т.е. одна сработка детектора)? Или всплеск сработок означает, что где-то рядом с датчиком происходит каскад ядерных реакций и от многих из них ионизирующие частицы прилетают в детектор?..
Замечали ли вы сигналы без очевидных причин (к примеру, всплеск сработок, когда прибор лежит дома)? От чего такие сигналы могут быть? В авто по дороге провезли источник? Сосед собирает рентгеновскую установку?
В итоге, как звонили без маркировки со спамом, так и звонят. Особенно с пулов Билайна (969). Полез смотреть, как с этим бороться - а никак, т.к. штрафов или каких-то санкций за отсутствие маркировки нет. Получается возня с ней была имитацией бурной деятельности...
В вашей табличке, насколько я понял, владельцы процессов - это сеньоры, при этом за назначение дублёров они не отвечают. Как им поступать, если им в дублёры назначают сотрудников с недостаточными скиллами или мотивацией (см. также комментарии предыдущих ораторов на эту тему)?
Если важна заменяемость, почему бы не перенести владение процессом к руководителю этих сеньоров (и пусть они выполняют процессы по очереди/по расписанию дежурств (см. также замечание выше про улучшение процессов исполнителями)?
...
Вообще, приведённые примеры странные - кажется, что они не про "выстреливший" bus factor, а про управление компетенциями/ресурсами:
Ушел единственный DevOps-инженер, который знал конфигурацию отказоустойчивости кластера. Кластер упал при обновлении, подняли только через 36 часов.
Т.е. кто-то "не зная броду" (не изучив предварительно систему и не придумав плана действий) и не "подстелив соломки" (не расписав планов отката) полез и был допущен шатать кластер? Кажется, что проблема в выборе соответствующего сотрудника (либо в манипулятивном принуждении его к действию несмотря на его активные возражения).
Специалист по Oracle уволился, не передав доступы к мониторингу.
Если мониторинг на bare metal, то неспособность получить креды - это признак низкой квалификации SRE, а если в облаке или в среде со специализированной защитой - признак плохой работы техдира/ИБ.
Новая команда поддержки не могла найти документацию по старому сервису.
А старую куда дели? Судя по слову "команда", этот пример - точно не про bus factor...
Инженер заболел, но только у него был договор с подрядчиком на оборудование.
Контекст данного кейса маленький. Но инженер в данном случае, получается, был не только инженером (а неким аналогом биг босса, умеющим в инженерию), либо, опять же, вопрос к руководству/ИБ.
А как он сделает это без таск трекера (выкинуть которые предлагает обсуждаемая статья)? Или вы предлагаете, что бы исполнители не парились тем, что есть вообще какие-то задачки, а делали бы то, что им скажет начальник?
Я правильно понимаю, что вы можете достичь тех же целей, которых достигает производственная система, которая навела вас на мысль написать данную статью, но с меньшими ресурсами?
Тогда было бы здорово написать статью "как". Как конкретно нужно поставить работу? Как вы убеждаете руководство, что "добудете медведя" быстрее и с меньшим количеством охотников, чем ваш конкурент (при том что до этого был опыт охоты на других животных - на условных уток или зайцев)?
«какую проблему пользователя мы решили» и «какой бизнес-метрике это помогло»
Я правильно понимаю, что вы предлагаете делать только то, что заметит пользователь или стейкхолдер, а остальное (всякую рутину типа фиксов уязвимостей с малым матожиданием ущерьа) не делать?
Существенная доля путаницы в этом вопросе - из-за того, что многие воспринимают назначение сроков и планирования - каждый по своему.
Кому-то надо понять, влезет ли задача в доступные ресурсы. Кому-то надо заранее договариваться об условной рекламе на ТВ и т.д. Кто-то боится, что если ошибешься в меньшую сторону, то наругают при не попадании. Кто-то - что накинут ещё задач..
Поэтому решать вопросы планирования не имеет смысла без предварительного формулирования "зачем"
А какого рода алгоритмы сейчас можно делать над FHE? Только комбинации And и Xor? Можно ли скрывать сами алгоритмы от вычислителя? Что насчёт условий или циклов (и соответствующих проблем типа подверженности к timing attack)? Массивы или адресная арифметика?
В вашей матрице чётко видно, что Продукты это про Discovery/Presentation, а ПМ - это про Execution/Production/Delivery. Главное полномочие ПМ - возможность распоряжения ресурсами (расходования бюджета)
Спасибо!
Т.е. у вас, получается, кроме этапа "приёмки требований" есть ещё отдельный этап "приёмки ЧТЗ", где можно уточнить и поправить? Здорово (не везде так)!
Не увидел в перечне артефактов "требований". Получается, что вы их "перемалываете" в готовые схемы данных? Или, например, у вас отдельный шаг согласования требований перед этапом разработки ЧТЗ? Или требования указаны наряду с другими UC (например, в формате user story)?
Какой подход к внешней документации (описания протоколов интеграции разрабатываемой системы и т.п.)?
Ну и плюс непонятно, как производится разработка алгоритмов и баз данных (физической модели) - у вас аналитиков есть эксперты по используемым системам/технологиям (что бы понимать их ограничения). Или тут речь о том, что бы избавить исполнителей разработчиков от именования сущностей и т.п. ?
Главное, что бы это не была гадость вроде протомолекулы (телепортированной с 3i/Atlas, например).
Звучит как выступление Капитана Очевидности.
Для начала хотя бы узнать ответ на вопрос "сколько задач последовательно/навалом", и в каких "попугаях" это "сколько" измерять...
А что такое "архитектура второго уровня" в контексте приведённого письма?
Аналогично. Вообще, методика PERT , насколько я знаю, подразумевает формирование сетевого графика работ. И, соответственно, этапы работ привязываются к ресурсам (хотя бы к их классам). А вот что дальше делать, было бы здорово узнать.
Не надо уточнять "в главной ветке, а в какой ? В develop?"
Основная причина - это ситуация, описанная в армянской сказке про кучу шапок из одной шкурки. И предотвратить её малореально...
Там, если что, такое выводится только при открытии со смартфона. С десктопа обещают доступ через браузер.
Либо пассивный залог для форт-подобных языков:
5 6 складывается вСтроку выводится
А разве космическое излучение не по одной штуке прилетает (т.е. одна сработка детектора)? Или всплеск сработок означает, что где-то рядом с датчиком происходит каскад ядерных реакций и от многих из них ионизирующие частицы прилетают в детектор?..
Замечали ли вы сигналы без очевидных причин (к примеру, всплеск сработок, когда прибор лежит дома)? От чего такие сигналы могут быть? В авто по дороге провезли источник? Сосед собирает рентгеновскую установку?
В итоге, как звонили без маркировки со спамом, так и звонят. Особенно с пулов Билайна (969). Полез смотреть, как с этим бороться - а никак, т.к. штрафов или каких-то санкций за отсутствие маркировки нет. Получается возня с ней была имитацией бурной деятельности...
В вашей табличке, насколько я понял, владельцы процессов - это сеньоры, при этом за назначение дублёров они не отвечают. Как им поступать, если им в дублёры назначают сотрудников с недостаточными скиллами или мотивацией (см. также комментарии предыдущих ораторов на эту тему)?
Если важна заменяемость, почему бы не перенести владение процессом к руководителю этих сеньоров (и пусть они выполняют процессы по очереди/по расписанию дежурств (см. также замечание выше про улучшение процессов исполнителями)?
...
Вообще, приведённые примеры странные - кажется, что они не про "выстреливший" bus factor, а про управление компетенциями/ресурсами:
Т.е. кто-то "не зная броду" (не изучив предварительно систему и не придумав плана действий) и не "подстелив соломки" (не расписав планов отката) полез и был допущен шатать кластер? Кажется, что проблема в выборе соответствующего сотрудника (либо в манипулятивном принуждении его к действию несмотря на его активные возражения).
Если мониторинг на bare metal, то неспособность получить креды - это признак низкой квалификации SRE, а если в облаке или в среде со специализированной защитой - признак плохой работы техдира/ИБ.
А старую куда дели? Судя по слову "команда", этот пример - точно не про bus factor...
Контекст данного кейса маленький. Но инженер в данном случае, получается, был не только инженером (а неким аналогом биг босса, умеющим в инженерию), либо, опять же, вопрос к руководству/ИБ.
А как он сделает это без таск трекера (выкинуть которые предлагает обсуждаемая статья)? Или вы предлагаете, что бы исполнители не парились тем, что есть вообще какие-то задачки, а делали бы то, что им скажет начальник?
Я правильно понимаю, что вы можете достичь тех же целей, которых достигает производственная система, которая навела вас на мысль написать данную статью, но с меньшими ресурсами?
Тогда было бы здорово написать статью "как".
Как конкретно нужно поставить работу? Как вы убеждаете руководство, что "добудете медведя"
быстрее и с меньшим количеством охотников, чем ваш конкурент (при том что до этого был опыт охоты на других животных - на условных уток или зайцев)?
Я правильно понимаю, что вы предлагаете делать только то, что заметит пользователь или стейкхолдер, а остальное (всякую рутину типа фиксов уязвимостей с малым матожиданием ущерьа) не делать?
В смысле, задачу можно было решить только сверхурочно? Почему бы время на неё не учитывать в рамках задачи?
Существенная доля путаницы в этом вопросе - из-за того, что многие воспринимают назначение сроков и планирования - каждый по своему.
Кому-то надо понять, влезет ли задача в доступные ресурсы. Кому-то надо заранее договариваться об условной рекламе на ТВ и т.д. Кто-то боится, что если ошибешься в меньшую сторону, то наругают при не попадании. Кто-то - что накинут ещё задач..
Поэтому решать вопросы планирования не имеет смысла без предварительного формулирования "зачем"
А какого рода алгоритмы сейчас можно делать над FHE? Только комбинации And и Xor? Можно ли скрывать сами алгоритмы от вычислителя? Что насчёт условий или циклов (и соответствующих проблем типа подверженности к timing attack)? Массивы или адресная арифметика?