Каковы ваши стратегии управления рисками?

Question

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

Вот что у меня есть (и я буду вести рабочий список):

Технические

• Контроль источника
• Модульное тестирование
• Согласованные стандарты кодирования
• Резервные копии на разных физических Места
• Отслеживание ошибок
• QA тестирование
• Аудит безопасности

Другое

• Подробно подробные контракты
• Страхование бизнеса
• Планирование на основе доказательств
• Еженедельные результаты и клиент подписок офф
• Аудиторские следы подотчетности

Answer 1

На более абстрактном уровне:

Ведите список рисков со всеми возможными рисками, о которых вы можете подумать, будь то большие или маленькие, вероятные или маловероятные. Обновляйте или, по крайней мере, перепроверяйте этот список каждые несколько недель. Это может быть так же ощутимо, как «сбой жесткого диска на главном сервере» или так же нематериально, как «конкурент запускает свой продукт первым».

Затем для каждого риска оцените влияние и вероятность в некотором масштабе (это может быть совершенно произвольно). Реальный риск будет в некоторой степени пропорционален продукту того и другого. То есть высокая потенциальная стоимость с очень низкой вероятностью не так плоха, как средняя стоимость с высокой вероятностью. Эти цифры просто помогут вам разобраться в риске, не воспринимайте их всерьез.

Далее, для каждого риска подумайте о мерах, которые вы можете предпринять, будь то контрмеры, страхование, что угодно. Опять же, изобразите стоимость тех (не только стоимость денег!).

Только теперь вы действительно можете решить, что (и если вообще нужно) делать с каждым риском. Принятие риска может быть приемлемым решением на данном этапе, но не раньше.

Возможно, вы захотите прочитать «Вальсинг с медведями: управление рисками в программных проектах». Том Демарко, Тимоти Листер. Хорошо в то время.

Answer 2

Шаг 0 - выявить и реализовать проект POC по всем техническим проблемам высокого риска.

Еженедельные результаты с принятием клиента (даже если это просто поддельный клиент).

Answer 3

Вы включили один пункт об инфраструктуре.

• Резервные копии в разных физических местах

Я рекомендую расширить это, чтобы включить данные защита .

• Оборудование, защищающее от потери питания (аккумулятор или механическое питание)
• Аппаратное и программное обеспечение, которое поддерживает быстрый доступ к вашему коду и сборкам

Сбой и потеря ваших данных нарушает процесс кодирования, а восстановление из резервной копии занимает гораздо больше времени, чем когда-либо.

Answer 4

• Хороший план управления проектом (т.е. SOW, сбор требований, "как есть" модель, будущая модель и т. д.)
• В то время как резервные копии представляют большой риск шаг управления, сколько люди / компании не принимают в рассмотрение их процесс для резервное копирование. Я видел слишком много случаи, когда процесс для резервное копирование (вставка лент, планирование, удаление лент, перемещение ленты за пределами площадки и т. д.) было слишком легко сломать.

Answer 5

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

Answer 6

Даже в небольшой компании я чувствую, что «собственность» и «ответственность» являются ключевыми. Если у вас будет много общественных проектов, то кто ответит, если все пойдет плохо? Очевидно, это то, что должно развиваться вместе с компанией, и слишком строгий подход к иерархии приводит к подавленным командам. Но стоит подумать о том, какую командную динамику вы хотите создать и развивать в своей компании.