В вашей табличке, насколько я понял, владельцы процессов - это сеньоры, при этом за назначение дублёров они не отвечают. Как им поступать, если им в дублёры назначают сотрудников с недостаточными скиллами или мотивацией (см. также комментарии предыдущих ораторов на эту тему)?
Если важна заменяемость, почему бы не перенести владение процессом к руководителю этих сеньоров (и пусть они выполняют процессы по очереди/по расписанию дежурств (см. также замечание выше про улучшение процессов исполнителями)?
...
Вообще, приведённые примеры странные - кажется, что они не про "выстреливший" bus factor, а про управление компетенциями/ресурсами:
Ушел единственный DevOps-инженер, который знал конфигурацию отказоустойчивости кластера. Кластер упал при обновлении, подняли только через 36 часов.
Т.е. кто-то "не зная броду" (не изучив предварительно систему и не придумав плана действий) и не "подстелив соломки" (не расписав планов отката) полез и был допущен шатать кластер? Кажется, что проблема в выборе соответствующего сотрудника (либо в манипулятивном принуждении его к действию несмотря на его активные возражения).
Специалист по Oracle уволился, не передав доступы к мониторингу.
Если мониторинг на bare metal, то неспособность получить креды - это признак низкой квалификации SRE, а если в облаке или в среде со специализированной защитой - признак плохой работы техдира/ИБ.
Новая команда поддержки не могла найти документацию по старому сервису.
А старую куда дели? Судя по слову "команда", этот пример - точно не про bus factor...
Инженер заболел, но только у него был договор с подрядчиком на оборудование.
Контекст данного кейса маленький. Но инженер в данном случае, получается, был не только инженером (а неким аналогом биг босса, умеющим в инженерию), либо, опять же, вопрос к руководству/ИБ.
А как он сделает это без таск трекера (выкинуть которые предлагает обсуждаемая статья)? Или вы предлагаете, что бы исполнители не парились тем, что есть вообще какие-то задачки, а делали бы то, что им скажет начальник?
Я правильно понимаю, что вы можете достичь тех же целей, которых достигает производственная система, которая навела вас на мысль написать данную статью, но с меньшими ресурсами?
Тогда было бы здорово написать статью "как". Как конкретно нужно поставить работу? Как вы убеждаете руководство, что "добудете медведя" быстрее и с меньшим количеством охотников, чем ваш конкурент (при том что до этого был опыт охоты на других животных - на условных уток или зайцев)?
«какую проблему пользователя мы решили» и «какой бизнес-метрике это помогло»
Я правильно понимаю, что вы предлагаете делать только то, что заметит пользователь или стейкхолдер, а остальное (всякую рутину типа фиксов уязвимостей с малым матожиданием ущерьа) не делать?
Существенная доля путаницы в этом вопросе - из-за того, что многие воспринимают назначение сроков и планирования - каждый по своему.
Кому-то надо понять, влезет ли задача в доступные ресурсы. Кому-то надо заранее договариваться об условной рекламе на ТВ и т.д. Кто-то боится, что если ошибешься в меньшую сторону, то наругают при не попадании. Кто-то - что накинут ещё задач..
Поэтому решать вопросы планирования не имеет смысла без предварительного формулирования "зачем"
А какого рода алгоритмы сейчас можно делать над FHE? Только комбинации And и Xor? Можно ли скрывать сами алгоритмы от вычислителя? Что насчёт условий или циклов (и соответствующих проблем типа подверженности к timing attack)? Массивы или адресная арифметика?
Эм, в прошлом веке прямо на средней продающейся на 1/8 части суши упаковке было написано русским по белому "в рулоне". Хотя, возможно, в данном случае, скорее всего, речь всё таки о кассетах.
Имеет смысл упомянуть, что iframe нужно реализовывать не абы как, а с соблюдением остальных требований PCI DSS, иначе получится решето. Ну и против атак вроде Evil Proxy Phishing можно применить только аттестацию девайса пользователя (аналог варианта с HSM). Без неё придётся применять только контрмеры различной степени шаманистости.
А как становятся [Chief] solution architect? Из разработки, аналитики, ПМ/ПрМ?
Я очень надеюсь, что автор подключился к ним правильно, исключив все логические уязвимости такой схемы. И, например, исключена ситуация, когда его система выключена, горелка не горит, а газ подаётся.
Ремонтник по котлам, который приходил для техобслуживания бытового сказал, что к сожалению, случаи, когда котёл травит окружающих из-за несработки датчика, случаются.
Как бы не случилось и в этом случаи ситуации "ой, а об этом мы не подумали".
Читая подобную статью, да ещё с такой манерой подачи ощущаешь, что уши начинают шевелиться от ужаса. Хочется, что бы в публичных пространствах была маркировка "вы находитесь в зоне, ответственность за которую - в голове современных инженеров". Один делает неотключаемую адекватным путём автоматику (причём, конкретно этим болеют сразу многие из разных стран) на основе показаний датчиков, которые, как оказывается, легко повернуть одновременно на определённый угол. Другие обучают и допускают к работам специалистов, которые могут, даже если разъём не встаёт на своё место, всё же, запихнуть его...
И примерно 10-20 минут затрат на следующую задачу из-за смены контекста, если это не просто "передвинуть" (а если так, то зачем вообще помнить, что надо что-то там передвигать?), а механика отчётности (именно её, судя по скринам, под видом декларированного "наведения порядка", внедрял автор).
На деле же им не нужен был трекер, а нужен был более-менее грамотный руководитель и какая-то концепция (стратегия), что они хотят в целом добиться. Тогда, если бы они решали реальные проблемы, то, может, и без трекера нужный порядок появился бы. К примеру, упоминаются личные чаты - один из способов наведения порядка - запрет личных чатов на уровне компании ("если это было только в личке, то этого не говорилось"). Пресловутые чаты под конкретные бизнес-процессы (техподдержка, запросы и т.п.) - это во многом эрзац-трекер.
А что делать, если в процессе следования по дорожной карте оказывается, что маршрут был проложен неверно (либо команда свернула по нему "не совсем туда"? Т.е. оценка резко увеличивается из-за какой-то ошибки.
По туристской аналогии: при передвижении по сильно пересечённой (горной) местности велика вероятность ошибки. И вы можете в итоге стоять от цели в 10 метрах геометрически, но что бы туда попасть, надо идти ещё пару суток. А всё из-за того, что случайно (в тумане и т.д.) свернули раньше/позже срока.
А если этой ситуации не избежать, то нужна ли вторая оценка (по разбиению работы на этапы) и нужно ли на неё тратить отдельное время? Мы же первоначальную оценку делаем для того что бы понять "съедим ли мы слона хотя бы теоретически". Может, оценку по более мелким этапам работ делать в момент, когда хотя бы по вводным для них всё понятно?
В Atlassian Jira раньше при редактировании описания задачи при нажатии Esc не запрашивалось подтверждения. Это была настоящая боль. Сколько нервов было потрачено из-за потерь введенного текста...
Выход по Esc это хорошо (в частности, то, что Esc в модальных диалогах идентичен нажатию "Отмена"). Но закрывать по этой клавише, например, окно браузера (для чего я чаще всего нажимаю Alt+F4) - это странно.
И при этом для такой частой операции, как закрытие окна, нужно нажимать Alt+F4
А это разве плохо? Хуже, если бы для этого требовалось бы [случайное] нажатие одной кнопки. Как в странных клавиатурах, которые продавались в начале нулевых неопытным пользователям, в которых кнопка выключения была расположена рядом с PgDn.
Переключение языка — вечная боль
К счастью, в X-Window из коробки можно настроить переключение с параметрами: XKBOPTIONS="grp:lctrl_lwin_rctrl_menu,grp:alt_shift_toggle,grp_led:scroll" Т.е. левый Ctrl + Win - английский, правый Ctrl + Menu - русский (ну и переключалка Alt+Shift на всякий случай и для посторонних). И статус отображается индикатором Scroll Lock (если включён, значит активна русская раскладка).
Выше уже указали, что сторипойнты не имеют смысла в отдельности от конкретной команды. Почему бы тогда не сделать оценку прямо в рабочих днях (часах) или в деньгах (если этот аспект прозрачен для команды)? В этом случае в итоге получится прямо коэффициент эффективности. Если при этом ещё ввести соревновательность в стиле "угадай мелодию" и KPI, привязанную к личной эффективности сотрудника, то заодно будет стимул к оптимизации эффективности.
И ещё, получается, что раз в вашем примере в январе была самая эффективная работа, а после ухода сотрудника стала самой неэффективной, то получается, эта эффективность ушла с сотрудником? И руководитель виноват, что не удержал его?
В вашей табличке, насколько я понял, владельцы процессов - это сеньоры, при этом за назначение дублёров они не отвечают. Как им поступать, если им в дублёры назначают сотрудников с недостаточными скиллами или мотивацией (см. также комментарии предыдущих ораторов на эту тему)?
Если важна заменяемость, почему бы не перенести владение процессом к руководителю этих сеньоров (и пусть они выполняют процессы по очереди/по расписанию дежурств (см. также замечание выше про улучшение процессов исполнителями)?
...
Вообще, приведённые примеры странные - кажется, что они не про "выстреливший" bus factor, а про управление компетенциями/ресурсами:
Т.е. кто-то "не зная броду" (не изучив предварительно систему и не придумав плана действий) и не "подстелив соломки" (не расписав планов отката) полез и был допущен шатать кластер? Кажется, что проблема в выборе соответствующего сотрудника (либо в манипулятивном принуждении его к действию несмотря на его активные возражения).
Если мониторинг на bare metal, то неспособность получить креды - это признак низкой квалификации SRE, а если в облаке или в среде со специализированной защитой - признак плохой работы техдира/ИБ.
А старую куда дели? Судя по слову "команда", этот пример - точно не про bus factor...
Контекст данного кейса маленький. Но инженер в данном случае, получается, был не только инженером (а неким аналогом биг босса, умеющим в инженерию), либо, опять же, вопрос к руководству/ИБ.
А как он сделает это без таск трекера (выкинуть которые предлагает обсуждаемая статья)? Или вы предлагаете, что бы исполнители не парились тем, что есть вообще какие-то задачки, а делали бы то, что им скажет начальник?
Я правильно понимаю, что вы можете достичь тех же целей, которых достигает производственная система, которая навела вас на мысль написать данную статью, но с меньшими ресурсами?
Тогда было бы здорово написать статью "как".
Как конкретно нужно поставить работу? Как вы убеждаете руководство, что "добудете медведя"
быстрее и с меньшим количеством охотников, чем ваш конкурент (при том что до этого был опыт охоты на других животных - на условных уток или зайцев)?
Я правильно понимаю, что вы предлагаете делать только то, что заметит пользователь или стейкхолдер, а остальное (всякую рутину типа фиксов уязвимостей с малым матожиданием ущерьа) не делать?
В смысле, задачу можно было решить только сверхурочно? Почему бы время на неё не учитывать в рамках задачи?
Существенная доля путаницы в этом вопросе - из-за того, что многие воспринимают назначение сроков и планирования - каждый по своему.
Кому-то надо понять, влезет ли задача в доступные ресурсы. Кому-то надо заранее договариваться об условной рекламе на ТВ и т.д. Кто-то боится, что если ошибешься в меньшую сторону, то наругают при не попадании. Кто-то - что накинут ещё задач..
Поэтому решать вопросы планирования не имеет смысла без предварительного формулирования "зачем"
А какого рода алгоритмы сейчас можно делать над FHE? Только комбинации And и Xor? Можно ли скрывать сами алгоритмы от вычислителя? Что насчёт условий или циклов (и соответствующих проблем типа подверженности к timing attack)? Массивы или адресная арифметика?
Эм, в прошлом веке прямо на средней продающейся на 1/8 части суши упаковке было написано русским по белому "в рулоне". Хотя, возможно, в данном случае, скорее всего, речь всё таки о кассетах.
Да, но не только.
Спасибо за ответ - интересный путь!
Имеет смысл упомянуть, что iframe нужно реализовывать не абы как, а с соблюдением остальных требований PCI DSS, иначе получится решето. Ну и против атак вроде Evil Proxy Phishing можно применить только аттестацию девайса пользователя (аналог варианта с HSM). Без неё придётся применять только контрмеры различной степени шаманистости.
А как становятся [Chief] solution architect? Из разработки, аналитики, ПМ/ПрМ?
Если автор по должности инженер, то техдир будет валить на него - типа, не предусмотрел.
Я очень надеюсь, что автор подключился к ним правильно, исключив все логические уязвимости такой схемы. И, например, исключена ситуация, когда его система выключена, горелка не горит, а газ подаётся.
Ремонтник по котлам, который приходил для техобслуживания бытового сказал, что к сожалению, случаи, когда котёл травит окружающих из-за несработки датчика, случаются.
Как бы не случилось и в этом случаи ситуации "ой, а об этом мы не подумали".
Читая подобную статью, да ещё с такой манерой подачи ощущаешь, что уши начинают шевелиться от ужаса. Хочется, что бы в публичных пространствах была маркировка "вы находитесь в зоне, ответственность за которую - в голове современных инженеров". Один делает неотключаемую адекватным путём автоматику (причём, конкретно этим болеют сразу многие из разных стран) на основе показаний датчиков, которые, как оказывается, легко повернуть одновременно на определённый угол. Другие обучают и допускают к работам специалистов, которые могут, даже если разъём не встаёт на своё место, всё же, запихнуть его...
И примерно 10-20 минут затрат на следующую задачу из-за смены контекста, если это не просто "передвинуть" (а если так, то зачем вообще помнить, что надо что-то там передвигать?), а механика отчётности (именно её, судя по скринам, под видом декларированного "наведения порядка", внедрял автор).
На деле же им не нужен был трекер, а нужен был более-менее грамотный руководитель и какая-то концепция (стратегия), что они хотят в целом добиться. Тогда, если бы они решали реальные проблемы, то, может, и без трекера нужный порядок появился бы. К примеру, упоминаются личные чаты - один из способов наведения порядка - запрет личных чатов на уровне компании ("если это было только в личке, то этого не говорилось"). Пресловутые чаты под конкретные бизнес-процессы (техподдержка, запросы и т.п.) - это во многом эрзац-трекер.
А что делать, если в процессе следования по дорожной карте оказывается, что маршрут был проложен неверно (либо команда свернула по нему "не совсем туда"? Т.е. оценка резко увеличивается из-за какой-то ошибки.
По туристской аналогии: при передвижении по сильно пересечённой (горной) местности велика вероятность ошибки. И вы можете в итоге стоять от цели в 10 метрах геометрически, но что бы туда попасть, надо идти ещё пару суток. А всё из-за того, что случайно (в тумане и т.д.) свернули раньше/позже срока.
А если этой ситуации не избежать, то нужна ли вторая оценка (по разбиению работы на этапы) и нужно ли на неё тратить отдельное время? Мы же первоначальную оценку делаем для того что бы понять "съедим ли мы слона хотя бы теоретически". Может, оценку по более мелким этапам работ делать в момент, когда хотя бы по вводным для них всё понятно?
В Atlassian Jira раньше при редактировании описания задачи при нажатии Esc не запрашивалось подтверждения. Это была настоящая боль. Сколько нервов было потрачено из-за потерь введенного текста...
Выход по Esc это хорошо (в частности, то, что Esc в модальных диалогах идентичен нажатию "Отмена"). Но закрывать по этой клавише, например, окно браузера (для чего я чаще всего нажимаю Alt+F4) - это странно.
А это разве плохо? Хуже, если бы для этого требовалось бы [случайное] нажатие одной кнопки. Как в странных клавиатурах, которые продавались в начале нулевых неопытным пользователям, в которых кнопка выключения была расположена рядом с PgDn.
К счастью, в X-Window из коробки можно настроить переключение с параметрами:
XKBOPTIONS="grp:lctrl_lwin_rctrl_menu,grp:alt_shift_toggle,grp_led:scroll"
Т.е. левый Ctrl + Win - английский, правый Ctrl + Menu - русский (ну и переключалка Alt+Shift на всякий случай и для посторонних). И статус отображается индикатором Scroll Lock (если включён, значит активна русская раскладка).
Различные варианты Space Cadet Keyboard периодически появляются. Но зачем? У математиков теперь есть TeX...
Не понимаю всё же, что за поток?
В BPMN должна быть описана обработка всех возможных ошибок?
Поток чего? Это же event-driven процесс. Не "цикл обработки событий" же в стиле дракон-схем рисовать...
Выше уже указали, что сторипойнты не имеют смысла в отдельности от конкретной команды. Почему бы тогда не сделать оценку прямо в рабочих днях (часах) или в деньгах (если этот аспект прозрачен для команды)? В этом случае в итоге получится прямо коэффициент эффективности. Если при этом ещё ввести соревновательность в стиле "угадай мелодию" и KPI, привязанную к личной эффективности сотрудника, то заодно будет стимул к оптимизации эффективности.
И ещё, получается, что раз в вашем примере в январе была самая эффективная работа, а после ухода сотрудника стала самой неэффективной, то получается, эта эффективность ушла с сотрудником? И руководитель виноват, что не удержал его?