На пути в светлое будущее. Управление информационной безопасностью
Авторы Наши партнёры Наши проекты: IT WorldIT-WeeklyIT Contact
IT-Manager Allcio Manager
Вход
X

Логин

Пароль

Запомнить

Забыли свой пароль?

На пути в светлое будущее

Лента новостейБезопасностьУправление ИБ

На пути в светлое будущее

Андрей Коротков | 02.12.2016

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

Попробуем все же разобраться: можно ли применять, где, как и насколько успешно ту самую пресловутую и загадочную гибкую методологию разработки? Как состыковать бизнес, ИТ (разработку) и, наверное, один из наиболее тяжело вписывающихся в эту схему компонентов — информационную безопасность? Куда деть ее пресловутые политики, требования, стандарты и аудиты? Как заставить всех говорить на одном языке и должен ли это быть язык бизнеса?

Не принимайте близко к сердцу

Сразу хотелось бы предупредить, что описанные ниже рецепты, не следует воспринимать как истину в последней инстанции и инструкцию к действию, хотя все они, а также многие другие были использованы друзьями, коллегами и мной. Причем использованы со стороны и бизнеса, и ИТ, и ИБ. Часть из них заработала, часть привела в тупик, часть напоминала надевание штанов через голову. Не действующие и попросту бредовые я предлагаю оставить за кадром и рассмотреть самые, на мой взгляд, универсальные и простые для понимания принципа. И да простят меня Agile-коучи за возможные неточности, перефразирования и подмену понятий — ведь, как они знают, работающая статья важнее точной документации.

А стоит ли игра свеч?

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

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

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

«Чтобы продать что-нибудь ненужное, надо купить что-нибудь ненужное», а у нас методологии нет

Не спорю, еще достаточно часто встречается, но уже заметно стагнирует и почти исчез старый подход «работы ради работы», в котором ИТ пытается что-то сделать исходя из своих технических способностей и своего понимания бизнес-процессов, а ИБ выявляет и анализирует риски, «аудируя» процесс со стороны и запрещая все, что ему кажется опасным или просто не очень понятным. И оба этих звена воздействуют на третье — бизнес. Воздействуют с двух противоположных сторон, жестоко наседая ему на шею и бюджет, пытаясь доказать, что мир совсем не такой, каким он кажется, и все нужно делать по-другому. Как ни странно, иногда бизнес продолжает в это верить.

К чему бы этот рассказ о беспорядочной работе, где во главу угла ставится хаос и способности отдельных ИТ-специалистов? К тому, что для перехода к гибкой методологии разработки нужно иметь хоть какую-то. Например «водопад», который существует и до сих пор действует в среде довольно крупных и консервативных компаний. Метод, если смотреть на него принципиально, предельно прост: бизнес заказывает, ИБ согласует, «срезая» часть опасных требований, ИТ оценивает, «срезая» еще часть недоступных для него требований, и, если к финишу что-то уцелело — реализует продукт, попутно еще раз урезая его в запале тестирования и сдачи-приемки. Все это приправляется изрядным количеством комитетов, совещаний, утверждений и т. д. Итогом становится продукт, соответствие которого заказу бизнеса, скорость вывода на рынок, корректировки под рынок, а также ценность для потребителя после описанных процессов являются весьма туманными и сомнительными.

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

Диалог во главе угла

«Вот и рецепт», — скажете вы. Но я бы рекомендовал остановиться и тщательно все обдумать. Важно, обращу внимание, очень важно понять, что гибкая разработка не является, ни лучшей практикой, ни инструкцией, ни алгоритмом. Это методология (читай: иной образ мышления) взаимодействия и работы. Невозможно заставить отдельную часть бизнес-процесса или всю компанию следовать методологии в принудительном порядке (вспомните тот же переход от хаоса к «водопаду»). Это нельзя ввести приказом или внедрить. К слову сказать, сочетание «внедрить Agile» обычно можно увидеть только в описании требований вакансии нового директора ИТ у некоторых компаний, и если вы видите или слышите предложение «внедрить гибкую разработку» — бегите от этих людей, и как можно быстрее.

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

Но вернемся к нашей реальности. Итак, все приняли решение, что идти вперед нужно и мы обязательно пойдем, но как это делать? Как уменьшить количество неудачных попыток и идти, а не спотыкаться? Как попросту не угробить бизнес? Для того чтобы найти ответ, следует вспомнить, сколько копий было сломано на различных форумах и сколько страниц написано об этом сакральном умении ИТ/ИБ говорить на языке бизнеса, об умении бизнеса понимать и осознавать ИБ и прочих взаимных лингвистических упражнениях. Возможно, я вызову шквал возмущений, но, как показывает практика, умение понимать и говорить на других языках на первых порах (часто и на вторых, и на третьих) невозможно — это величайшее и часто недостижимое при самостоятельных упражнениях искусство. Уж слишком разные стороны сталкиваются и слишком по-разному они смотрят на происходящее, как те слепые мудрецы из древней притчи, видевшие в слоне каждый свое. Подразделение ИТ, обладающее нулевым аппетитом к бизнес-риску, никогда не поймет и не заговорит на понятном бизнесу языке баланса между риском инвестиции и ее доходностью, обсуждая новый продукт. Равно как и бизнес не сможет внятно пояснить ИБ в конкретных единицах, какие риски для него допустимы, а какие нет.

И здесь очень большую помощь могут оказать так называемые бизнес-партнеры, по сути своей — отчасти переводчики с одного языка на другой, отчасти медиаторы в неизбежных конфликтах. Они способны принципиально и на верхнем уровне понять проблемы, пожелания и опасения каждого из участников процесса, транслировать их на всех и заставить людей говорить и договариваться, организуя диалог. Вспомним манифест гибкой разработки: «Люди и взаимодействие над процессами и инструментами». Важно начать сотрудничать и понимать друг друга, выстраивая взаимодействие, а не только фанатично отстаивать свою точку зрения.

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

Не забывайте о безопасности

«А куда делась безопасность? — спросите вы. — Почему ее не взяли в команду?» Безопасность зачастую начинает дистанцироваться на этом этапе, продолжая классическим способом исполнять свои классические задачи. Вызывая, этим еще большую волну недовольства своей работой, чем обычно. Хотя, по сути, она права и поступает вполне обоснованно со своей точки зрения и в сложившейся стрессовой ситуации следует достигнутым и закрепленным в политиках договоренностям участников и предостерегает бизнес, гуляющий по краю пропасти, от падения в нее. Но, как бы то ни было, изменения необходимы — остальные части компании идут вперед и прежние методы будут как минимум тормозить движение, а как максимум приведут к снижению уровня безопасности, не соответствуя новым реалиям. Команда уже готова и ждет командной работы.

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

Кто виноват и что делать?

К сожалению (далее я поясню это сожаление), единственным выходом является перенос оперативного управления рисками из тайных недр ИБ в команду, на уровень бизнеса, и ИТ, на уровень диалога. Выявление и экспресс-анализ рисков на стороне команды с осознанным принятием первых или передачей их на обработку — объективная реальность, и от нее уже не уйти. Нельзя оценивать риски на стадии только проектирования или только сдачи готового продукта — это должно стать живым процессом при каждом изменении процесса, ведь «готовность к изменениям важнее следования первоначальному плану».

А теперь о сожалении: зачастую данная трансформация проходит очень болезненно и с большими потерями, ведь в отличие от других процессов происходит не просто изменение структурной единицы организации, а ее разделение и изменение формата работы получившихся двух частей, где одна (переместившаяся в команду) становится заказчиком, а вторая (оставшаяся в ИБ) — только и всецело исполнителем. Теперь заказчик диктует правила обращения с рисками, а исполнитель лишь прорабатывает и сопровождает конкретные способы их минимизации, ведет мониторинг, а также уведомляет заказчика о больших отклонениях и совместно корректирует их. И политики с регламентами теперь уже диктуют не правила работы, а правила взаимодействия, ведь «сотрудничество с заказчиком важнее согласования условий контракта».

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

Единственное, чего не хватает для полноты картины, — выбрать наиболее подходящий фреймворк, будь то Scrum, Lean, FDD или что-то выдуманное вами лично, но это уже тема совсем другого разговора.

Теги: безопасность, бизнес

Журнал IT-Manager № 11/2016    [ PDF ]    [ Подписка на журнал ]

Об авторе

Андрей Коротков

Андрей Коротков

ИТ-эксперт

мероприятия

| 07.12.2017
XIII Пиринговый форум

Краснопресненская наб.,12.

Также смотрите

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

Журнал IT-Manager: № 09/2017

Последние новости

Фоторепортажи

Мероприятия

<<<< Ноябрь >>>>
Пн Вт Ср Чт Пт Сб Вс
303112345
6789101112
13141516171819
20212223242526
27282930123