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

Введение

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

Примечание. Мы понимаем что есть еще стандарты на ТЗ от IEEE, ISO и пр. Однако с чего-то же нужно начинать ;-) Мы в Аксиан) придерживаемся свободных взглядов на ТЗ — главное использовать в нем общий с Заказчиком язык.Читать полностью »

Есть хорошее определение услуги, данное в ITIL. Официальный перевод: услуга/сервис – это предоставление ценности заказчикам через содействие им в получении конечных результатов, которых Заказчики хотят достичь без владения специфическими затратами и рисками.
Это определение я буду называть «формулой» услуги.

На примере такси схематично формула выглядит так:

Услуги в области ИТ: Матчасть. Часть 2. Формула услуги - 1

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

image
Опыт поиска работы на бирже Elance разгорелось горячее обсуждение темы способов конкуренции с индийцами и пакистанцами на площадках сайтов для фрилансеров. В продолжение этой темы публикую свой вольный перевод статьи Евгения Розинского о проблемах краудсортинга в Индии. По словам Евгения он имеет 15 летний опыт в этой области и знает о чём говорит. Это взгляд из США, со стороны работодателей. Статья была опубликована ещё в 2013 году, но проблемы которые в ней рассматриваются сегодня стали ещё более актуальными.
Индийский ИТ-аутсорсинг стал бизнесом, который поставлен на поток. Бизнесом без каких-либо инноваций Единственным сомнительным плюсом которого является дешевизна. Но не миф ли это?
Это не попытка написать научную статью или предсказать будущее. Это просто личное мнение, сложившиеся у меня на основе более чем 15 лет работы с различными поставшиками услуг в Индии и по всему миру. Не стоит рассматривать статью как попытку сформировать стереотип для каждого сотрудника страны с населением 1,2 миллиарда человек. На протяжении многих лет мне посчастливилось работать с блестящими индийскими инженерами и менеджерами, как в Индии, так и в США. Этой рецензией я пытаюсь описать индустрию аутсорсинга Индии в целом и отметить характерные проблемы с которыми мы сталкиваемся в качестве клиентов, а не людей, работающих там.
Мои выводы и предположения базируются на том, что многие компании переходят к более гибким стратегиям разработки, в которых процесс принятия решений и способность адаптироваться является ключевой.
Читать полностью »

Существуют разные представления о том, как ведётся творческая работа. Для многих людей творец – это личность (поэт, художник, изобретатель), которая создаёт своё творение в момент озарения. Управлять озарением? О, нет! Это невозможно!!!

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

Творческая работа может вестись как индивидуально (одним творцом – учёным, художником, композитором или поэтом), так и коллективно (когда над созданием произведения работают коллективы людей разных специальностей). В данной статье мне бы хотелось сконцентрироваться на вопросах управления творческими коллективами на примере распределённого коллектива программистов, художников и дизайнеров из трёх стран, который выпускает приложение, продаваемое во всём мире. Каждый год продаётся более 10 миллионов экземпляров. Годовая выручка – 1 миллиард долларов.

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

В больших проектах выгоднее купить нужного специалиста на рынке, даже если его зарплата кажется чрезмерной. При съёмках кинофильма, продюсер не учит своего сценариста писать диалоги, если тот не умеет этого делать, а просто покупает сценариста для написания диалогов на рынке. Аналогичным образом поступают при разработке приложений. Если возникает недопонимание между командами из разных стран, то одну команду отправляют в длительную командировку. При миллиардной выручке затраты на командировку не имеют значения: главное – выпустить продукт в срок.
Читать полностью »

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

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

ИБ по американски. Часть 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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