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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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