Архив рубрики ‘управление рисками’

Игра по новым правилам. ГОСТ Р 72160-2025: что это — очередной навязанный стандарт или рабочая система

Готовы рискнуть вашими… проектами?

Bus-factor склада: как считать зависимость от ключевых руководителей

В инженерии программного обеспечения есть метрика bus-factor — минимальное количество людей, одновременная потеря которых останавливает систему. Чем выше число, тем устойчивее операция к кадровым изменениям. В IT эту метрику считают регулярно. На складах — почти никогда. При том что текучесть персонала в складской отрасли составляет около 49% в год. Склад, который не знает своего bus-factor, […]

Почему пилоты ИИ не масштабируются? У них нет системы управления

Собирательный кейс: демонстрация есть, системы нет Представим обычный проект в крупной организации. Команда делает пилот ИИ для обработки заявок. Модель классифицирует обращения, предлагает ответ оператору, иногда сама заполняет поля в CRM. На демонстрации всё выглядит убедительно: скорость выше, ручной работы меньше, руководитель направления доволен.

SLA как инструмент, а не отчёт

Часть 1. Как подружить бизнес и инженеров через общие цифры Наш прежний SLA формально выглядел корректно: была формула, «четыре девятки» и отчёты. Но в моменты сбоев это не помогало ответить бизнесу на вопросы: сколько времени мы были недоступны, какова потенциально недополученная прибыль и каким был вклад разных подразделений в «наши девятки». Команды по‑своему считали простои […]

Как CISO защищаются от прошлого, игнорируя будущее

Привет, Хабр! Меня зовут Андрей Бирюков. Я являюсь независимым экспертом в области ИТ и ИБ, преподаю в учебных центрах и пишу книги. Полагаю, многим известна фраза Черчилля о том, что «старые генералы всегда готовятся к прошедшей войне». Это высказывание можно в полной мере отнести и к стратегиям, применяемым многими CISO.

Bus factor = 1: 22 критичные для индустрии библиотеки, которые держатся на одном человеке

Где‑то прямо сейчас один программист не спит и патчит баг в библиотеке, от которой зависит половина интернета. Он делает это бесплатно. Его никто не знает. Если он уйдёт — никто не придёт. В апреле 2024 года исследователь безопасности Андрес Фройнд обнаружил бэкдор в xz utils — утилите сжатия, встроенной в большинство дистрибутивов Linux. Атака была почти идеальной: два года социальной инженерии, один выгоревший мейнтейнер и вредоносный код […]

«Мы же предупреждали!» Почему реестр рисков не спасет проект, если команда не умеет принимать решения

Почти в каждом проекте есть момент, когда кто-то говорит: «Ну мы же предупреждали». И это, пожалуй, самая неприятная фраза в проектном управлении. Так как она означает, что проблема была не в том, что команда не знала о рисках. Проблема была в том, что знание о рисках никак не повлияло на решения. Реестр рисков в таком […]

Риски в IT-продукте: как бизнес-аналитик спасает проект

Всем привет, меня зовут Сергей Прощаев, Tech Lead и руководитель направления Java / Kotlin разработки в FinTech & E-commerce, и уже несколько лет преподаю на курсах разработки и архитектуры в OTUS. За это время я провёл десятки собеседований и участвовал в найме системных и бизнес-аналитиков. И знаете, что бросается в глаза? Многие кандидаты блестяще знают […]

Потратил на безопасность 10 зарплат и попал в странную петлю

Вы когда-нибудь тратили деньги на то чтобы чувствовать себя спокойнее, а после этого начинали тревожиться еще сильнее? Поставили сигнализацию на машину и начали дергаться от каждого писка на парковке. Купили страховку и вдруг осознали сколько всего еще не застраховано. Сделали резервную копию рабочих файлов и тут же подумали, а что если и облако упадет.

Простые хлопоты: когда проекту действительно нужно управление

В управлении проектами есть странная особенность: многие действия считаются полезными почти по умолчанию, хотя момент их проведения чаще всего выбирается либо по ритуалу, либо по накопленному раздражению команды. Совещания, сверки, проверки, уточнения, ретроспективы давно стали привычной частью работы, но сама необходимость таких событий редко выводится из логики проекта как таковой.

123.5