Требует ли процесс принятия решений проведения формального совещания?
Если процесс внесения изменений требует ведения документации в определенной форме, а система документооборота имеет ручные компоненты, которые не могут быть автоматизированы, это может негативно сказаться на гибкости и продуктивности.
Насколько далеко нужно продвинуться по иерархии менеджмента, чтобы выполнить необходимые изменения?
Если люди вынуждены получать одобрение на внесение изменений, влияющих на работу их команды, у менеджеров, находящихся на вышестоящих уровнях, они будут чувствовать, что у них связаны руки.
В этом примере будет рассмотрена деятельность государственного агентства по оказанию цифровых услуг (Government Digital Service; GDS). Эта организация является структурным подразделением британского правительственного секретариата кабинета министров. Она находится в лондонском районе Холборн и ответственна за преобразование правительственных цифровых услуг[63]. В 2010 году Марта Лейн Фокс (Martha Lane Fox) изложила соответствующие сведения в отчете Directgov 2010 and Beyond: Revolution Not Evolution (https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/60993/Martha_20Lane_20Fox_s_20letter_20to_20Francis_20Maude_2014th_20Oct_202010.pdf). Сформированное в апреле 2011 года, агентство GDS находится под надзором управляющего бюджетными расходами (Public Expenditure Executive, Efficiency & Reform).
Явно заданная культура
В государственном агентстве по оказанию цифровых услуг сформированы следующие семь цифровых принципов (https://www.flickr.com/photos/benterrett/7041509709):
• цифровая форма (по умолчанию);
• пользователи на первом плане;
• обучение в путешествиях;
• построение сети доверия;
• выход за барьеры;
• создание среды, способствующей процветанию технологических лидеров;
• не делать все самому (это просто невозможно).
Работайте с пользователями так, как будто собираетесь формировать кабинет министров, а не обычную технологическую фирму.
Как видите, в этих принципах явно присутствуют ценности и запреты. Например, фраза «пользователи на первом плане» представляет собой ценность, утверждающую высший приоритет для пользователей. Если, например, инженер хочет поэкспериментировать и изучить новый инструмент или архитектуру, тогда в игру вступает запрет «не делать все самому (это просто невозможно)». Важно отметить, что позитивные ценности преобладают над негативными запретами, хотя всегда проще сказать людям, что им не стоит делать. Имейте в виду, что описание желаемых поведений намного эффективнее при создании желаемой культуры или атмосферы.
Помимо описанных семи цифровых принципов агентство GDS также внедрило следующие десять принципов дизайна (https://www.gov.uk/design-principles):
• начните с выяснения потребностей;
• делайте меньше;
• проектируйте вместе с данными;
• облегчайте тяжелую работу;
• повторите, затем повторите еще раз;
• это предназначено для всех;
• поймите контекст;
• создавайте цифровые сервисы, а не сайты;
• будьте последовательны, но не однообразны;
• создавайте открытый код, он всегда лучше.
Эти принципы проектирования отражаются в одном из указанных ранее цифровых принципов: пользователи на первом плане. В данном случае выделяются все аспекты пользовательского опыта, а не только, например, умение создавать серверный код. Критически важной для культуры является идея, суть которой заключается в том, что преобразование заключается не только в аппаратной и программной технологии. На самом деле преобразование – это изменение опыта пользователей. В качестве примера можно рассмотреть внедрение цифровой услуги Claim Carer’s Allowance (https://gds.blog.gov.uk/2014/07/03/what-we-mean-when-we-say-service-transformation/).
Создание явной культуры вместо полагания на неявное понимание, которое часто приводит к недоразумениям, позволило агентству GDS четко сосредоточиться на определенных типах изменений, которые оно должно внести в своей сфере деятельности.
Планирование
Планирование – это важная часть любого процесса разработки программы либо предоставления цифровой услуги уполномоченной организацией. Путем явного оглашения целей и необходимого для их достижения времени, а также с помощью расстановки приоритетов для данного периода времени команды могут значительно увеличить вероятность достижения цели. Процесс планирования тесно связан с культурой явных определений. Если вы не сможете достаточно хорошо определить цели, чтобы запланировать их, вряд ли вы достигнете этих целей.
Процесс планирования изменений, осуществляемый командой GDS, включает выделение достаточного количества времени на исследование возможных решений. Чтобы выбрать решение, наилучшим образом удовлетворяющее текущие потребности, производится оценка предлагаемых решений. При этом соблюдаются вышеизложенные цифровые принципы и принципы проектирования. Также поддерживается общение с другими правительственными командами, позволяющее скоординировать усилия и удостовериться в том, что запланированная работа не выполняется в данный момент другой командой. Этот простой, но критически важный шаг позволит избежать пустых трат времени на дублирование работы.
Как только завершается сбор данных по проекту и требований к проекту, производится оценка потенциальных решений, реализованных в форме открытого и коммерческого кода. Затем создается прототип, который совместно используется командами, такими как разработчики, эксплуатационники и сервисные менеджеры. Благодаря этому возможно получение обратной связи от максимального числа заинтересованных сторон прежде, чем полностью утвердить выбранное решение. Также минимизируются впустую потраченные усилия, если выясняется изменение направления разработки, и обеспечивается максимальное удовлетворение потребностей каждого заказчика, которому предлагаются потенциальные решения.
При планировании проектов или других работ в организации, особенно работающей в условиях масштабирования, обращайте внимание на следующие моменты.
• Работают ли в этой области другие команды или группы?
• Каким образом могут координироваться или объединяться усилия с другими командами?
• Какие заинтересованные стороны и лица, принимающие решения, должны быть привлечены?
• Каким образом вы определяете успех для этого проекта?
Вызовы
Один из вызовов, который часто возникает в правительственных агентствах, – дублирование усилий разными группами (рис. 14.3). В каждой группе должны поддерживаться основные элементы инфраструктуры. Эти элементы применяются дополнительно к работе, которая находится в центре внимания или в области компетенции определенной группы. Поскольку эти основные услуги не централизованы, каждой команде или группе придется потратить время, чтобы нанять специалистов, обладающих необходимыми навыками.
Предоставление услуг на основе платформы многоарендной архитектуры в правительственном секторе позволило бы сэкономить время эксплуатационных команд. Экономия достигается за счет того, что вводится централизованная служба поддержки, которая удовлетворяет всем требованиям безопасности и конфиденциальности. Централизованное предоставление услуг позволило бы сервисным командам сосредоточиться на областях, навыках и требованиях, которые являются для них уникальными. Ключевые требования для мультиарендной платформы, используемой в правительственных учреждениях, приведены в следующем списке:
• она должна быть самообслуживаемой;
• должны использоваться несколько провайдеров услуг;
• должна быть изоляция кода, данных и логов.
Рис. 14.3. Дублирование услуг, предоставляемых правительственными организациями
Благодаря самообслуживанию пользователи получают полный контроль над нужными аспектами приложения. Это позволяет командам сосредоточиваться на разработке усовершенствований платформы, а не на создании услуг. В результате поощряется специализация, приводящая к формированию платформенных и сервисных команд.
Второе требование, заключающееся в использовании нескольких провайдеров услуг, предотвращает привязку к одному поставщику, стимулирует конкурентное ценообразование и способствует устранению единственных точек отказа. В процессе обдумывания требований проекта лучше использовать несколько облачных хранилищ, чем одно. Заблаговременное соблюдение этого требования позволит отказаться от использования специфичных для поставщика средств, привязка к которым затруднит переход к другому провайдеру либо включение дополнительных провайдеров в дальнейшем. Позднее в агентстве GPS решили отказаться от этого требования, поскольку решения с открытым исходным кодом также будут обеспечивать необходимую степень гибкости.
Третье, и наиболее существенное, требование для многоабонентской платформы заключается в полной изоляции кода, данных и логов между агентствами. Это необходимо, чтобы убедиться в том, что каждая группа или агентство в состоянии соблюдать собственные ограничения безопасности и конфиденциальности. Даже если одно из ограничений не удовлетворяется, платформа не может использоваться и, соответственно, не может рассматриваться как успешная. И хотя детали этого вызова являются уникальными для каждой правительственной организации, во многих организациях также должны удовлетворяться разные юридические требования (например, соблюдение совместимости с PCI, SOX либо HIPAA). Все эти моменты должны учитываться в процессе планирования, чтобы избежать потенциальных напрасных затрат усилий.