Рубрика «управление рисками» - 4

За свой опыт в разработке ПО я работал на многих проектах, и часто приходилось включаться в уже существующий проект или видеть как новая команда на моих проектах подхватывает проект с историей. Часто новый разработчик приходящий на проект и приступающий к выполнению задачи первым делом начинает плеваться на существующий дизайн. Ему кажется, что всё сделано не правильно, не очевидно и слишком переусложнено. И как результат, при выполнении задачи, начинают появляться дыры в уже разработанном дизайне и существующая архитектура начинает обрастать костылями. В конце концов, проект или его подсистему требуется переписать почти полностью. Чем старше проект, тем таких случаев может быть больше.

Также бывает и другая крайность, для реализации нового функционала или переделки существующего, один и разработчиков говорит: «Я знаю как сделать лучше!» после чего, вместо того чтобы дать идее «отлежаться» и оценить все плюсы и минусы, сразу начинает её делать. Где-то через месяц разработки может возникнуть ситуация, что чего-то он не предусмотрел, и приходится отказываться от разработки и выкидывать код или срочно искать варианты решения проблемы. Почти каждому разработчику в этом случае хочется сохранить лицо: «Как же так? Я же профессионал!» — думает он, «Если я признаю свою ошибку то все подумают, что я не настолько крут как всем говорю». И в этом случае Идея которая недостаточно проработана входит в проект и становится проблемой уже всей команды. Что также удорожает проект. А так как это становится заметно не сразу и внимания на причинно-следственные связи почти никто не обращает, то ситуация может повторяться снова и снова.
Читать полностью »

ИБ по американски. Часть 4. Разбираемся с «подгонкой» и «перекрытиями» и завершаем этот обзор
*Оставьте свою работу на рабочем месте!*

Итак, нелёгкий путь по обзиранию созданию краткого обзора NIST SP 800-53 подходит к логическому концу. Я рад, что мне удалось совершить задуманное и написать пусть небольшой, но законченный по содержанию цикл статей, не остановившись на первой или второй части. В дальнейшем, надеюсь, получится от случая к случаю делиться с общественностью своими соображениями на тему ИБ, ИТ и аудита.

Итак, в этой статье будет наконец-то поведано о выборе набора контролей безопасности, подгонке его под нужды конкретной организации и создании так называемых перекрытий «overlays», применимых вне масштабов отдельной организации.

Ссылки на предыдущие статьи:

ИБ по-американски. Часть 1. Что такое NIST 800-53 и как выглядят контроли безопасности?
ИБ по-американски. Часть 2. А можно поподробнее о NIST 800-53 и причём тут управление рисками?
ИБ по-американски. Часть 3. Что из себя представляет базовый набор контролей безопасности и как определять критичность информационных систем?

Читать полностью »

ИБ по американски. Часть 3. Что из себя представляет базовый набор контролей и как определять критичность систем?
*Безопасность — это отнюдь не борьба с ветряными мельницами*

В предыдущих статьях я уже достаточно подробно рассказал о публикации NIST SP 800-53. Были успешно освещены разбиение контролей на семейства, подробное описание структуры контролей безопасности, процесс управления рисками в масштабах организации и даже вкратце отдельная публикация FIPS 200.
Из-за выхода в свет Geektimes пришлось немного задержаться, но мы продолжаем двигаться дальше, и сегодня речь пойдёт о базовых наборах контролей безопасности и об определении критичности информационных систем.
Ну и конечно в комплекте аутентичные американские плакаты, посвященные безопасности.

Ссылки на предыдущие статьи:
ИБ по-американски. Часть 1. Что такое NIST 800-53 и как выглядят контроли безопасности?
ИБ по-американски. Часть 2. А можно поподробнее о NIST 800-53 и причём тут управление рисками?

Читать полностью »

Салют коллеги!
20-21 февраля 2015г. в Москве в ивент-холле «Инфопространство» пройдет 4-я международная конференция, посвященная управлению ИТ проектами и продуктами — Software Project Management Conference (SPM Conf).
image

Мы уже начали публикацию первых докладов и вас ждет масса интересного и профессионального контента. Приглашаем поделиться знаниями, выступив с интересным докладом. Докладчики участвуют в конференции бесплатно!

Ну а пока о конференции словами участников.

Почему надо участвовать в конференции

О пользе и ценности участия

Читать полностью »

О том, о чём все и так знают

Почему-то очень многие люди говорят, что защищают три свойства информации (да, те самые: конфиденциальность, целостность, доступность).
Почему-то при оценке рисков выписывают «активы», причём только активы.

Услышав это ещё раз я не выдержал, и решил написать этот скучный и неинтересный пост о том, о чём все и так знают.

Ведь эти люди прекрасно знают, например, что такое ЭЦП. Мы что, не защищаем подлинность?
Защищаем.
Не защищаем неотказуемость?
Защищаем.
Все это знают.
Очевидно, что защищаемых свойств информации больше, чем три.

Давайте ещё раз определимся, что свойств информации не три и что когда мы выписываем «активы» — это не выписывание строк из книги учёта имущества организации.
Читать полностью »

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

Сразу оговорюсь, что эта публикация – своего рода эссе по ментальной карте в которую я упаковал собственный опыт и приобретенные знания по теме управления конфликтами. Мой взгляд не полон и ограничен, а значит если есть какая-либо дыра в смысловой ткани темы — дайте знать, доработаю (для кого удобнее использовать для понимания ментальную карту — она в конце текста):

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

Конфликт, как как частный случай

Обычная (регулярная) ситуация переходит в конфликтную, а затем кристаллизуется в конфликт, при наступлении одного или нескольких факторов:

  • введении конфликтогена (раскрывается ниже);
  • изменение целей у участников ситуации;
  • изменении обстоятельств, которые затрагивают ценности, интересы или цели участников ситуации;
  • создание участниками (или одним из) позиции, по отношению к ситуации;

И если с целями и обстоятельствами более-менее понятно, то два других пункта нуждаются в уточнении.
Читать полностью »

Было бы очень занимательно поуправлять ЦРУ, но это доступно только товарищу Сноудену. В данной заметке (хотя размер для заметки великоват) речь пойдет про три столпа ИБ, как уже все, конечно, догадались: конфиденциальность (Confidentiality), целостность (Integrity), доступность (Availability). Материал не сильно похож на тот, что есть в учебниках российского производства, поэтому, надеюсь, будет интересным. Некоторые понятия оставляю в оригинале, те, кто в курсе в переводе не нуждаются, да и в контексте, думаю, будет все предельно ясно. Каждый из этих трех аспектов тесно связан физической безопасностью (Safety) и нарушение какого-либо из них может привести к негативным последствиям.
Читать полностью »

Семь смертных грехов руководителя проекта

Теологи утверждают, что грех помрачает ум, ослабляет и пленяет волю, сдавливает сердце человека печалью и унынием. Блажен тот, кто осознаёт причину своего горя — греховность, а не жизненные обстоятельства или действия других людей. Правильный диагноз ведёт и к исцелению.
Читать полностью »

«Риски и выгода всегда ходят рука об руку» (с) Том Демарко, Тимоти Листер.

6 декабря 2013 года в Казани состоялась 3-я Международная конференция в области управления проектами «Software Project Management Conference». В своем выступлении я попытался рассказать о главном, что надо знать об управлении рисками в программном проекте.

Разработка продукта длилась 5 лет вместо одного года. Бюджет проекта был превышен более, чем в 5 раз.

Это - провал?

Нет. Это был MS Word!

Руководителю проекта разработки ПО надо уметь делать немногое. Надо лишь уметь управлять рисками. Рисками не уложиться в срок. Рисками сделать не то, что требуется. Рисками перерасходовать проектный бюджет. Всё остальное – производные активности.

Можно, разумеется, рисками не управлять. Чувствовать себя Ником Валлендом от разработки ПО и ходить по канату без страховки нацеливать себя и свою команду исключительно на благоприятное развитие событий.

Таким большим оптимистам можно дальше и не читать. Для остальных продолжу.

Читать полностью »

Вася говорит Когда Вася говорил, что заказчик не глуп и ему следует рассказать о рисках проекта, все говорили, что заказчик испугается и откажется от проекта.

Когда Вася говорил, что любая оценка проекта есть величина статистическая и имеет свой доверительный интервал, все говорили, что уровень неопределенности так высок, что его ни в коем случае нельзя показывать заказчику.

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

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

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

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

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js