Как образуются «разновидности» архитекторов

Зашел разговор о том, что казалось бы устоявшуюся в рынке «тройку» Software Acrhitect / Solution Acrhitect / Enterprise Architect никак нельзя считать основанной на «трех видах архитектуры». Это никакие не «виды архитектуры», а просто так оказывается удобно нарезать области ответственности в крупной организации за принятие технических решений разного характера и масштаба. Причем на поверку оказывается, что даже при однаковости названий этих ролей реальная ответственность в организацииях порезана сильно по-разному., так что общей карты даже и не составить. Например, «функциональные архитекторы» в одной организации напоминают «доменных архитекторов» в другой организации, но все же отличаются тем, входит ли в область ответственности решения уровня инфраструктуры.

Если пытаться искать что-то реально устойчивое, то мы найдем скорее не роли, и даже не какие-то хаарктерные предметы/области ответственности, а скорее линии потенциального разреза, по которым разные компании частенько проводят границы. При этом линий этих довольно много, и если порезать по всем этим линиям — получится абсурдно мелко, поэтому каждая компания определяет свой орг-дизайн (а роли — это про орг-дизайн), выбирая какие-то из этих линий, причем на разных уровнях и в разных орг-единицах — набор выбранных линиц разреза может быть совершенно разный и это нормально. Само же (статистическое) существование этих линий гоорит нам о потенциале, о том, что связи поперек этой линии достаточно слабы, так что по ней резать «ну в принципе можно». А вот, например, резать по признаку «фаза ЖЦ клиента» не стоит.

Навскидку описал коротко эти «базовые типовые линии разделения ответственностей, формирующие типовые паттерны ролей архитекторов»:

  • Деление «по масштабу«. Оно же стратегия/тактика. Кто-то думает за крупное, кто-то — за части.
  • Деление «по бизнесу» — если мы с т.з. системной организации бизнеса видим уже разделенные (по многочисленным возможным бизнес-причинам (из-за функциональной структуры деятельности, масштаба, территориальности, законодательства, истории слияний/поглощений, и т.п.) бизнес-функции или орг-единицы, то это может быть удобная линия разреза для ответственности в ИТ и ролей архитекторов
  • Деление «по изменениям» — если идет параллельно несколько проектов изменений, то, хотя это не статические образования, но они достаточно долгие, чтобы за их целостностью нужно было следить и одновременно удерживать scope от расширения (PM), и техническую полноту и реализуемость WBS (architect). Так рождается project/programme/solution architect как роль.
  • Деление «по доменам» и поддоменам. Даже в рамках общей орг-структуры можно выделить какие-то поддомены и группы бизнес-функциональности, между которыми слабые связи и свои жаргоны и ubiquity-языки (DDD). Можно делить. Доменный архитектор получается.
  • Деление «по техническим системам«. Вот если у нас уже есть несколько технических систем (например включая и софт и инфраструктуру), то дальнейшее ведение их ЖЦ может быть областью ответственности.
  • Классическое деление «бизнес»/»ИТ». «Бизнес» тут — это устройство организационной системы, использующей ИТ. Оно аж в язык вошло. По этой линии можно резать.
  • Можно взять и поделить софт по линии «функциональность/устройство» (черный/прозрачный ящик). Про это было много копий сломано, но вообще так можно, если и там и там много сложности набирается.
  • Можно поделить по линии «свой софт/готовая инфраструктура«. Потому что софт мы проектируем от паттернов и есть много свободы и нужно не переусложнить. А в инфраструктуре мы работаем от того, что есть на рынке и надо знать рынок и свойства готовых продуктов. Четко видная линия разреза.
  • Можно делить по viewpoint’ам (аспектам). Но тут традиционно некоторые хорошо выделяются (security, compliance), в которых много регуляции и вообще стандартных проблем-решений, а другие — хуже (performance??? reliability??? сомневаюсь), в которых больше уникальности и больше связей с уникальной функциональностью, и поэтому хуже отделяется. Рынок подсказывает наличием спец-инструментов и специалистов и аутсорсинга по тому же security и secure SDLC.
  • Можно делить по видам базовых технологий/платформ, но только если мы в технике тоже можем провести границу со слабыми связями. Например backend-frontend. Или database можно отделить, если там сложно (Oracle) и граница четкая. AWS/OnPremise. Java/.NET.

Не знаю, как еще бывают, но наверное есть.
Можно накидывать еще примеры, если кто видел другую базу для разделения.

Ну вот и получается, что названные типичные паттерны ограничены/сформированы/оформлены несколькими из этих «потенциальных линий разреза».

  • «Enterprise Architect» — в ответственности «все предприятие», при этом с тремя опциями по линиям «IT/орг-механизмы/бизнес-модель»
  • «Solution Architect» — в ответственности «одна инициатива изменения», иногда включая орг-механизмы, иногда — только IT.
  • «Software Architect» — в ответственности отдельная программная техническая система и без инфраструктуры, иногда (все чаще) с указанием экосистемы разработки.

Это не «виды архитектуры», а паттерны нарезки ответственностей (=> ролей и должностей).

Можно добавить, что глубина разделения труда (обычно по этим видам линий) в целом, конечно, растет.

Очередной «эффективный», «удобный», «естественный» для разделения центр или область ответственности формируется под воздействием нескольких трендов:

  • укрупнение организаций (Сбер Всё, так что нужно как-то биться по дивизионам, направлениям, филиалам, дочкам, и т.п.)
  • усложнение функциональное (нужно делать более крутые штуки) и по показателям качества (терабайты данных, миллионы юзеров, глобальность, гарантии надежности, etc)
  • усложнение технологическое (много новых технологий появляется и закрепляется, объем того, чем нужно владеть в сумме чтобы реализовать хоть что-то — растет)
  • снижение возраста и уровня общих компетенций в IT (меньше влезает в голову одному человеку, и он хуже понимает/держит много уровней и аспектов)
  • появление новых инфраструктур и относительно замкнутых экосистем, которые имеют свои «языки» и т.о. формируют границы. (архитектор AWS != архитектор GCP/Azure, Software Architect Java != Software Architect .NET)

Это очень динамичный процесс, все это плывет и меняется, за 5 лет сильно, особенно «по низам». Но сами разновидности «линий деления» кажутся устойчивыми.

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

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

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

Чек-лист микросервисной архитектуры

Чем-то коллегам в отрасли приглянулся этот списочек, несколько раз просили перепостить. Это некий «снепшот» моего понимания микросервисного подхода трехлетней давности, сегодня я бы что-то в этом списке наверняка поменял, дополнил, или, наоборот, ослабил. А тогда (при проектировании Modeus) мне нужен был этот список как максимально полный перечень, чтобы быть уверенным, что мы ничего не упускаем. При этом понятно было, что какие-то из пунктов мы в моменте обеспечить не можем, или даже рано — масштаб еще не тот. Но было важно сделать этот временный отказ осознанным. Возможно, именно в такой роли этот список может быть полезен кому-то и сейчас — если отказываться от каких-то пунктов, то обоснованно и осознанно.


  1. Приложение состоит из нескольких четко идентифицированных сервисов, разрабатываемых отдельно, и работающих в разных процессах ОС.
  2. Все сервисы имеют ограниченный размер и сложность, позволяющие без слишком неприятных затрат и рисков любой одиночный сервис выкинуть и переписать заново, и удерживать сложность любого сервиса в одной средней голове.
  3. Сервисы построены вокруг тесно связанных моделей в ограниченном контексте (DDD bounded contexts), а иногда делятся дополнительно под давлением НФТ.
  4. Сервисы разворачиваются в контейнерах под управлением контейнерной системы оркестрации.
  5. Образ сервиса содержит все зависимости и не требует специальной (зависящей от сервиса) подготовки хоста.
  6. Сервисы взаимодействуют друг с другом через протоколы, не зависящие от технологии реализации сервисов.
  7. Сервисы могут быть написаны на нескольких различных технологических стеках.
  8. Сервисы могут иметь свою БД, но не имеют прямого доступа к БД других сервисов.
  9. Для взаимодействия сервисов активно используется асинхронный обмен сообщениями (messaging).
  10. Кроме системы оркестрации для работы с сервисами создана, поддерживается и развивается отдельной командой развитая (как внутренний продукт) инфраструктурная платформа микросервисов, обеспечивающая их разработку, развертывание (CI/CD), исполнение и управление (мониторинг, диагностика, и т. п.).
  11. Инфраструктурная платформа разрабатывается с применением практик Infrastructure as a Code.
  12. Создание нового сервиса и его интеграция с другими по синхронным/асинхронным каналам — дешевая автоматизированная в платформе операция (< 1 ч*ч), не требующая участия кого-либо, кроме прикладного программиста.
  13. Для всех сервисов на уровне платформы обеспечено обнаружение зависимостей, т.к что сервису нужно знать только логическое имя другого сервиса.
  14. Разрешением зависимостей можно управлять в runtime, отделяя части трафика по признакам на отдельные экземпляры (QoS), или пропуская через промежуточные прокси-сервисы.
  15. Для всех сервисов на уровне платформы обеспечено централизованное унифицированное журналирование, не требующее работы специалистов при добавлении нового сервиса.
  16. Для всех сервисов на уровне платформы обеспечено централизованное унифицированное конфигурирование, не требующее работы специалистов при добавлении нового сервиса.
  17. Для всех сервисов на уровне платформы обеспечен централизованный унифицированный мониторинг доступности и здоровья, не требующее работы специалистов при добавлении нового сервиса.
  18. Для всех сервисов на уровне платформы обеспечен централизованный унифицированный мониторинг, сбор и анализ технических и бизнес-метрик, включая производительность, не требующее работы специалистов при добавлении нового сервиса.
  19. Прикладной программист может самостоятельно, дешево и просто добавить атрибут в журнал, по которому будет возможен поиск и метрику, по которой возможно создание графиков и алертов.
  20. Обеспечена отладочная/диагностическая трассировка вызовов от входа через все синхронно вызываемые сервисы до БД включительно.
  21. Сервисы обновляются по отдельности или малыми группами.
  22. Работает по несколько экземпляров каждого сервиса, нагрузка перераспределяется между ними.
  23. Одновременно может работать несколько разных (близких) версий сервиса.
  24. Сервисы сами обновляют необходимые им структуры данных.
  25. Не используется никаких распределенных транзакций, вместо них — саги, eventual consistency, идемпотентные операции, протоколы отката и т. п. паттерны.
  26. Сервисы тестируются по отдельности.
  27. Обновления системы проходят с нулевым простоем.
  28. Сбой отдельного узла не оказывает значимого влияния на функционирование и доступность системы (практика chaos monkey).
  29. В случае сбоя сервис быстро останавливается (а не виснет) и система оркестрации его перезапускает.
  30. Для тестирования сервиса может быть собрана группа сервисов из одной (или нескольких одноименных) ветки-на-фичу (feature branch).
  31. Отдельные стенды для тестирования/демонстрации системы или фрагмента системы из нескольких сервисов создаются платформой быстро, дешево, и без участия специалистов.
  32. Перенос нужных версий БД с одного стенда на другой производится быстро, дешево, и без участия специалистов, местами — автоматически с зачисткой чувствительных данных.
  33. Обновления сервисов и инфраструктуры описано кодом и корректность этих кодов обновления автоматически тестируется на тестовых стендах (в delivery pipeline).
  34. Для сервисов проводятся автоматические тесты на соблюдение контракта платформы.
  35. Для сервисов автоматически строится фактическая диаграмма взаимодействия.
  36. Для всех сервисов есть гарантированно точные описания интерфейсов (REST, Events) и контрактов (JSON schema, etc), обновляемые не вручную отдельно, а как неизбежная часть цикла разработки.
  37. Для каждого поддерживаемого технологического стека заготовлен проект-стартер, позволяющий создать болванку корректно работающего сервиса, не делающего ничего, за 5 минут.
  38. Новая команда может подключиться к разработке нового сервиса за один день, прогнать через тесты и выпустить его на PROD.
  39. Canary releases. Для новых версий сервисов разворачивается небольшое число экземпляров, автоматически контролируется успешность вызовов к ним и при наличии большого числа ошибок или выходов за SLA версия откатывается и автоматически ставится дефект.
  40. Для сервисов определены и контролируются автоматически контракты НФТ — производительность (задержка, пропускная способность), ресурсоемкость.
  41. Сервисы активно используют паттерны для обработки отказов смежных сервисов — fallback, повторы вызовов, таймауты, и т. п.
  42. Сервисы толерантны к незначительным изменениям форматов своих зависимостей (добавление атрибутов и т. п.).
  43. Все сервисы могут работать в тестовом режиме, когда отдельные зависимости не требуются и заменяются встроенными заглушками c тестовыми данными.
  44. На уровне платформы есть механизмы контроля содержимого всех входящих/исходящих запросов и сообщений для любого сервиса.
  45. Количество экземпляров сервиса может автоматически меняться в зависимости от нагрузки.
  46. Количество хостов кластера системы оркестрации может автоматически меняться в зависимости от нагрузки.
  47. Для отдельных экземпляров или для сервиса в целом можно во время выполнения менять конфигурационные параметры (например, менять детализацию журналирования) и выдавать команды обслуживания (например, сбрасывать кеши).
  48. Платформа предоставляет готовые библиотеки/средства для решения типичных задач взаимодействия сервисов (транзакции-саги, передача реплик данных, автоматическое создание очередей, и т. п.).
  49. В любой момент времени у каждого сервиса есть одна небольшая команда-владелец, отвечающая за него включая PROD (хотя могут быть изменения и от других команд и выделенная служба эксплуатации 1-2 линии).
  50. Клиентские приложения также модульны (micro frontends) и на них распространяется большинство вышеперечисленных принципов и требований.

 

Про системное мышление

Уже несколько раз встревал в разных разговорах на понятии «системного мышления». Очень-очень частая ситуация (и моя, когда-то, тоже), что человек думает и говорит: «Я умею системно мыслить», но на самом деле подразумевает за этим мышление «четкое, логичное, убедительное», и даже не подозревает, что может быть «дисциплинированное» системное мышление, т.е. основанное на вполне конкретных приемах и системной метамодели, т.е. на достаточно строгом понятии системы и ряде связанных с ним.

В очередной раз отвечая на вопрос о том, «ну что же такое это системное мышление» я вздохнул и написал это:

> (собеседник)… Хотя… пока термин (системное мышление) не раскрыт, судить о его смысле, не верно….

Давайте раскроем конкретнее, выпукло и поэтично. Хорошо освоенное системное мышление — это когда вы: быстро (в «реальном времени», в середине разговора, на грани осознавания, как обычно водите машину, но при необходимости осознавая на 95%) очень многие попадающиеся вам ситуации и вещи раскладываете по характерной мета-модели, в которой есть связанная группа понятий: система (подсистема, надсистема, целевая/обеспечивающая система), роль=функция, элемент/функциональный компонент, материал=морфология, стейкхолдер/интерес, модель/описание/вид/точка зрения, производственный/эксплуатационный контекст, потребность/требование/решение/архитектура/дизайн, функция/процесс/слой, структура/состав, связь/отношение, паттерн/стиль/архетип, понятие/знак/значение/термин, обязанность/ответственность; бегло (также на скорости речи) перемещаетесь между системными уровнями, между позициями стейкхолдеров, между точками зрения; за счет этого можете свои интуитивные «чуйки» (которые у вас были всегда) обосновать рационально, быстро протянув цепочку следствий и влияний от внутреннего технического решения до интересов стейкхолдера; проще можете «продать» идею, понимая позицию стейкхолдера; мыслите примерно одинаково системно и «железные» технические системы, и программные, и организационные, потому что в этой метамодели нет разницы; отказываетесь от любых правил, best practice, и догматов («Scrum велит делать так!») и переходите к механизмам и ситуациям, причинам и следствиям в данном конкретном окружении; начинаете требовать рациональных объяснений от других, не удовлетворяясь скрижалями и авторитетами; обнаруживаете, что многие «методологии» (от SOLID и DDD до Теории Ограничений и TOGAF) суть ограниченные и иногда ущербные частные примеры общих принципов системного подхода; легче определяете любую деятельность как целенаправленную или механистичную/догматичную; отказываетесь от многих ритуалов, не встраивающихся в цепочку системных причин и следствий до ваших интересов; легче принимаете те ритуалы, которые встраиваются в ваши интересы, даже будучи в остальном бессмысленными :), начинаете различать проблемы и задачи, реальные цели и модные лозунги, проблемы в компетенциях/личности и в организации; лучше предвидите проблемы, вызванные недостатками организации; легче отказываетесь от «стандартов», не несущих пользы, лучше видите ход мысли других людей и лучше можете его направлять, подбрасывая в реальном времени новые схемы и понятия; понимаете системное устройство коммуникации и за счет этого спокойнее и быстрее договариваетесь или рационально переубеждаете; можете объяснить по шагам, как и для чего вы делаете все вышеперечисленное и почему это наилучшее с вашей стороны действие в данный момент в данной ситуации.

Сегодня мне это видится как-то так 🙂

Про «хороший» аудит

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

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

Обычно заказчик сам плохо представляет себе, что именно он хочет найти посредством аудита. И поэтому всегда первое, что необходимо сделать — это фокусировку, определить максимально конкретно, насколько это возможно, границы аудируемых системе и деятельности, а также аспекты качетсв и области рисков, на которые аудиторы будут нацелены. Наличие фокусировки не означает, что аудиторы совсем не будут обращать внимания на явные проблемы в других областях — конечно, будут, и скажут о них, но при прочих равных углубляться они будут именно в обозначенные темы.

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

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

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

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

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

Обычно заказчик, даже планируя вложиться в аудит, всегда очень обеспокоен тем, как много рабочего времени это потребует от его сотрудников. Типичный случай — когда аудит затевается без изменения жестких проектных и программных сроков. Поэтому этап работы «только над документами» может быть полезен и как экономное средство быстро погрузить аудиторов в этот удивительный новый мир.

На следующем этапе появляется общение с отдельными сотрудниками заказчика, этот этап удобно проводить в формате телеконференций Skype/Zoom, и это практические первый контакт аудиторов с живыми людьми (встречи на presale можно не брать в расчет, там больше ритуалов, чем людей). Естественно, уровень глубины и искренности разговоров пока очень поверхностный, и эти встречи служат скорее верификации целей, знакомству, верификации понимания аудиторами рассмотренных документгов и общей проектной ситуации.

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

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

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

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

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

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

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

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

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

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

Надо сказать, что в период эпидемии COVID-19 эта важнейшая (очная) часть работы, видимо, претерпит принципиальные изменения, новые (дистанционные) формации будут иметь свои плюсы и минусы, но критически важно не потерять ту ценность, которую дает процессу плотное личное общение глаза-в-глаза.

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

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

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

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

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

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

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

Про орг-методологические сессии

Иногда меня спрашивают о том, какие можно проводить «стратегические сессии» (чаще всего это так называется), и что от них можно получить. В этой статье описал свое понимание на текущий момент, в ограничениях того, что я сам готов делать (экзотику типа 200 участников на 10 дней — не потяну).

1. Тема и вид сессии

Для начала нужно определиться с целями сессии, как их видит руководитель.

Что это может быть?

  1. Совместно с коллективом решить какую-то уже выделенную проблему в устройстве организации/подразделения. Тогда это будет сессия проектирования. Чтобы ее проводить нужно четкое вИдение руководителя, в чем проблема. Коллектив, если эта проблема в целом в поле его понимания и компетенции может помочь найти оптимальное решение, учитывающее все факторы, и не бьющее по кому-то из них. От руководителя на старте потребуется предъявить проблему. На выходе в идеале – тезисное описание принципиального решения.
  2. Найти заранее неизвестные проблемы в устройстве, которые компании/подразделению мешают развиваться. Это полезно, если руководитель недостаточно хорошо представляет, что происходит в производстве, готов согласиться с тем, что не видит всей картины. Коллектив, который погружен в контекст более глубоко, и живет в нем – может помочь выявить гипотезы проблем. Но от руководителя здесь требуется вводная – почему компании совершенно необходимо развитие подразделения, и какие атрибуты качества/производительности/эффективности должны быть улучшены. Такую сессию можно назвать сессией проблематизации. На выходе в идеале – перечень проблем, которые нужно разрешить для осуществления шага развития подразделения.
  3. «Посадить на людей» какое-то уже известное решение, известное запланированное организационное изменение, попутно проверив его на разумность, прочность, доработанность. От руководителя требуется понимание целей и причин орг-изменения, уверенность в принципиальной правильности решения. Тогда это будет сессия организационного планирования. На выходе в идеале – понимание людей, кто какую позицию займет «с понедельника», готовность к этому, снятое сопротивление, понимание причин и необходимости.
  4. Определить направление развития организации/подразделения в условиях сложной, динамично меняющейся окружающей обстановки. Тогда это будет сессией стратегического планирования или форсайт-сессией. Тут уже от участников требуется достаточно высокий уровень подготовки и способность говорить о стратегическом уровне, не скатываясь в операционку, а также – достаточно объемные представления об окружающем компанию рыночном пространстве. На выходе в идеале –образ будущего компании, ее места и стратегии, учитывающие действия конкурентов и тренды отрасли.

В начале ведущий-методолог и руководитель-заказчик составляют что-то типа «ТЗ» на мероприятие. В чем ситуация, какие цели видим, что хотим получить, в каком режиме работаем, какой примерно состав участников, какое деление на группы (микрокоманды по 2..9 человек), какие возможны способы мотивации.

2. Возможные дополнительные результаты

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

3. Сложности и риски

В любом случае нужно понимать, что все подобные мероприятия сопряжены с некоторыми рисками и могут а) не дать желаемого результата, б) иметь и негативные последствия. С «а» все понятно – может просто ничего не получиться, а какое может быть «б»?

  1. Если результат будет маленьким или неочевидным для людей – их мотивация и уверенность в руководстве и будущем компании может снизиться: «сами ничего решить не могут, позвали какого-то урода, который тоже помочь не может, от любимой работы оторвали, тратят наше общее время-деньги на фигню, видимо компании скоро крындец». И все такое, вплоть до заявления об увольнении у особо резких.
  2. Даже если результат есть, и кто-то из участников тоже это видит, всегда найдутся недовольные – или ходом процесса, или поведением руководства, или результатами, или предстоящими переменами.
  3. Если ход процесса будет жарким, то могут возникнуть новые или усилиться старые конфликтные отношения и разногласия.
  4. … и еще много-много того, о чем мы сейчас даже подумать не в состоянии.

4. Формат организации

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

  • Установочный доклад руководителя о ситуации и целях
    (предварительно проговаривается с ведущим-методологом и проверяется на соответствие тому, что фиксировали в ТЗ)
  • Установочный доклад методолога-ведущего
    (о требуемом способе групповой работы, регламенте и необходимом по форме и содержанию результате)
  • Групповая работа в микро-коллективах (может быть полезен руководитель группы и/или игротехник)
  • Совместное (пленарное) заседание – доклады групп и коллективная дискуссия по ним
  • Методологическая консультация (прояснение понятий, введение схем)
  • Финальная рефлексия всех участников
  • Письменная рефлексия участников после мероприятия
  • Очное обсуждение результатов руководителем и ведущим-методологом

5. Роль ведущего-методолога

Ведущий-методолог обеспечивает:

  • Разработку сценария и структуры групп
  • Организацию работы в соответствии со сценарием
  • Мотивацию и направление мышления участников на целевые результаты
  • Интерпретацию полученного результата и его качества, конструктивную критику
  • Подбрасывание понятий и приемов для мышления и схематизации
  • Управление дискуссией и ее стилем, фокусировкой, атмосферой
  • Разрешение простых конфликтов, переведение их с личностной на предметную плоскость
  • Рефлексию и обратную связь участникам о происходящем
  • Информирование об источниках для самообразования

Кроме того, ведущий-методолог в меру возможности сам выступает в качестве аналитика-эксперта, хотя эта роль – вторична (если он как эксперт или interim manager может сам понять и решить ситуацию, то незачем проводить такое дорогое и рискованное мероприятие).

6. Примерный сценарий в варианте «2 раза по полдня»

Масштаб мероприятия может быть от минимального однодневного до двух, трех, или даже пяти дней с выездом за город и полным погружением. Чем длиннее и полнее погружение, тем более глубокие вещи удается вскрыть, больше ментальных барьеров преодолеть, больше материала наработать. Но и люди устают сильнее, и стоит, очевидно дороже. А результат все равно никогда не гарантирован.
Минимальный масштаб точно неизвестен, но можно попробовать «2 раза по полдня», предполагая также промежуточную работу групп между этими двумя днями и финализирующую работу групп по завершению мероприятия.

День 0

Ведущий-методолог и руководитель составляют ТЗ, договариваются о целях, форматах, сценарии мероприятия, тезисах установочного доклада руководителя. Примерная длительность очной встречи: 2 часа.

День 1

15:00-16:00       – общее заседание, открывает руководитель, представление ведущего-методолога. Установочный доклад руководителя о ситуации и целях мероприятия. Установочный доклад ведущего-методолога. Выдача задания на работу в группах.

16:00-18:00       – работа в группах.

(15 минут кофе-брейк)

18:00-20:00       – общее заседание, доклады групп, дискуссия.

День 2

15:00                   – короткое установочное сообщение ведущего-методолога.

15:00-18:00        – работа в группах.

(15 минут кофе-брейк)

18:00-20:00       – общее заседание, доклады групп, дискуссия.

20:00-20:30        – рефлексия участников, заканчивая руководителем и ведущим-методологом, выдача задания на фиксацию результатов.

7. Подготовка помещений, оборудования, реквизита, персонала

Хорошо проветриваемая комната для общих заседаний, отдельные комнаты для работы групп.

Проектор или большой телевизор (для мероприятий побольше, когда участники готовят презентации), несколько комплектов флипчарт-бумага-маркеры (по 1 на группу). Малярный скотч (вешать листы на стену). Блокноты или бумага А4, ручки.

Видео или аудио-запись общих заседаний.

Озвучка помещения (микрофоны, колонки), если народу много.

Кофе-брейки (чай, кофе, перекус).

Хорошо, если есть помощник («девочка») для административных и простых организационных поручений (актуально для мероприятий побольше).

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

Краткая историческая реконструкция тренда Web-scale IT

Эту статью я написал для первой российской конференции по Web Scale IT. Взгляд — исключительно авторский, может не совпадать с мнением организаторов конференции. 


Попробуем вкратце восстановить причины разбега web и enterprise миров, разобраться в происходящем сегодня, а через это — понять те громкие прогнозы, которые делает Gartner и другие эксперты.

Web-индустрия начиналась почти исключительно как цифровая. Сама услуга, т.е. поставляемая ценность, была цифровой, и это, как ни странно, определило довольно многое.

Во-первых, клиент компании оказался по совместительству пользователем ее софта. И наоборот, пользователь софта перестал быть нанятым сотрудником, а вдруг стал клиентом компании. Это в корне перевернуло отношение к качеству пользовательских интерфейсов и породило новую специализацию — UX-инженерию. Потому что если клиенту чем-то не понятен или неудобен пользовательский интерфейс софта, он быстро перестает быть клиентом, в отличие от нанятого сотрудника, которому за использование самого ужасного интерфейса платят деньги и на место которого легко найдется другой.

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

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

Давайте соединим все вместе. В результате скоротечной рыночной эволюции, длившейся около двух десятков лет, в web-индустрии крайне успешными оказались некоторые компании, которые смогли вырасти до гигантских размеров, при этом их ИТ-системы и ИТ-производство обеспечивает удивительную для enterprise комбинацию свойств — высочайшую масштабируемость, привлекательность для клиентов, и способность к быстрому устойчивому развитию.

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

Для начала  можно сыграть роль информационного посредника с удобным клиентским интерфейсом, и порог входа для этого оказывается совсем небольшим. Не нужны масштабные капитальные вложения в офисы, оборудование и склады, если все это уже делает кто-то другой, пусть и по старинке. Но зато можно обеспечить совершенно новый заказ для всех этих мощностей, причем, возможно, от конкурирующих “немасштабируемых” поставщиков, создав новый сервис только за счет удобной “информационной добавки”, забрав на себя (чисто информационную! масштабируемую!) функцию заключения контракта.

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

Это — то, что мы сейчас наблюдаем. Крупные, очень динамично развивающиеся, горизонтально масштабируемые и привлекательные для клиента сервисы из “мира web” медленно, но верно начинают перехватывать и переделывать старые рынки, где давно сложившиеся паритеты, нормы и правила игры оказываются устаревшими и неконкурентоспособными.

Тренд Web-scale IT, объявленный Gartner, означает следующее — в долгой перспективе выживут только те крупные классические корпорации старого “мира enterprise”, которые смогут перестроить свои методы работы таким образом, чтобы стать конкурентоспособными в новой борьбе, по новым правилам, найдут в себе силы отбросить те традиции, которые безнадежно удерживают их в прошлом, смогут за счет невероятной трансформации обрести те же ключевые способности, которые свойственны лучшим из “мира web”. Придется догонять. Для тех, кто не сможет, или не захочет меняться — тренд Web-scale IT не интересен, но их место под солнцем завтрашнего дня, мягко говоря, не гарантировано.

Эта конференция — для тех, кто решил, что будет меняться.

Copyright © 2022 Igor Bespalchuk