Об гиперпространственные тоннели между деятельностными мирами

Меня очень вдохновляет язык моделирования Archimate (https://www.cfin.ru/itm/EA_ArchiMate.shtml) при всех его недостатках. Я не особенно задумывался почему -- на нем удобно отображать связи и взаимодействие между людьми, процессами, приложениями, технологиями, но кажется этого недостаточно чтобы служить вдохновением.
Сегодня я понял в чем дело: за счет его метамодели у нас в рассуждениях появляется интерфейс, связывающий между собой понятия из самых разных областей.

Метамодель Archimate очень простая, это формула "cубъект -- выполняет действия -- с объектом", и в дополнение представление ее же во внешний мир в виде сервисов и интерфейсов.

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

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

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

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

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

В ISO 42010 / ГОСТ Р 57100 точки входа в такие тоннели называются Architecture Viewpoint.
Описываются они в стандартах и нотациях моделирования.
Если их освоить и гармонизировать между собой появляется возможность быстро путешествовать в любую точку мира.

Во вторник, 5 марта, на конференции DevOpsConf делаю доклад для инженеров и начинающих тимлидов о том как подключаться к новым проектам.
Если вы вдруг хотите купить билет, но почему-то этого еще не сделали, у меня для вас есть промокод на скидку 7%: DevOpsMoscow_2024
https://devopsconf.io/moscow/2024/abstracts/11628

Экспериментирую с пропусканием текстов через ChatGPT и последующей доработкой напильником

"Цель DevOps — это переход от документоориентированных (document-centric) процессов управления разработкой ПО и процессов управления IT-сервисами к кодоориентированным (software-defined).
При этом методы управления всеми этими процессами могут быть различными — как использование единого инструмента для оркестрации всех процессов и активностей, так и интеграция различных инструментов и сервисов в единую распределенную систему."

Выложили видео моего доклада на конференции DevOpsConf, которая происходила 4 и 5 марта 2024г.

Я делал доклад для инженеров и начинающих лидов — о том как ускорить свою производительность и снизить количество возникающих пожаров.

Ключевые слова: GTD, Meeting notes, Decision records

Поделитесь с теми ребятами у себя в команде, кто не очень хорошо справляется с организацией собственных дел
https://youtu.be/t_jZMmXRjGM

В противопоставлении document-centric и software-defined подходов я намеренно опустил один важный момент.

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

Мы можем каждую из активностей в этом процесе описать в виде подробного документа, дать с ним ознакомиться сотрудникам, проводить регулярное обучение и адаптировать в виде инструкций.
Либо можно для каждой из активностей написать портянку YAML, написать тесты и CI/CD для раскатки этого YAML, перевести на разработанные скрипты автоматизации все процессы разработки.
Для каждой активности назначить ответственного сотрудника, который будет регулярно обновлять и дорабатывать регламенты (в случае документоцентричного подхода) или дописывать новый YAML по запросу разработчиков (в случае кодоцентричного подхода).

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

Вместо методологии DevOps появились devops-инженеры ровно в тот момент когда мы из software-defined процессов убрали ориентацию на результат и заменили ее автоматизацией отдельных шагов.

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

Предположим, некий "devops-инженер" пишет разнообразную автоматизацию пайплайна SDLC для своей команды разработки.
- Его видимая работа состоит в написании различных автоматизаций на YAML. Эти задачи можно положить в таск-трекер и проконтролировать их выполнение.
- Следующий слой работы состоит в интеграции отдельных шагов пайплайна так, чтобы артефакты между ними передавались правильно и без ошибок. Эти задачи в таск трекер положить можно, но только либо в виде самого описания или definition of done задачи по реализации шага пайплайна, либо в виде багов — когда один шаг вроде бы интегрирован с другим, но дает неверные результаты. Причем, технически эту задачу отделить от первого шага вполне реально — я часто советую ребятам сделать два эти шага по отдельности, когда они буксуют над подобной составной задачей
- Слоем глубже находится построение поведения пайплайна, состоящего из нескольких шагов. Например, мы сперва публикуем контейнер в хранилище, дальше этот контейнер сканируем на уязвимости и подписываем ключом, и в конце разрешаем запуск контейнеров на средах только если они подписаны. Эту задачу можно положить в таск-трекер как набор отдельных задач, но для того чтобы реализовалась именно функциональность "разрешить запуск только контейнеров просканированных на уязвимости" нужно эти задачи или объединить в какой-нибудь эпик, или тщательно описать что должно происходить для каждой из задач, или описать весь процесс отдельным документом и прикрепить его к каждой из задач. Создание такого описания и декомпозиция его на тикеты может быть отдельной задачей перед собственно написанием автоматизации на YAML, и задачей окажется довольно немаленькой.
Ну или можно завести одну большую задачу "реализовать проверку подписи контейнеров", подразумевая всю эту цепочку, и отдать выяснять детали самому инженеру. Но тогда как состояние выполнения этой довольно немаленькой задачи, так и собственно способ ее реализации становятся плохо верифицируемыми для стороннего наблюдателя. Иными словами, если мы ставим такие достаточно большие составные задачи (или мини-проекты) мы должны быть уверены в том, что сотрудник умеет их решать, и решает их хорошо.
- Если идти еще глубже, мы приходим к построению принципов и стандартов работы пайплайна самого по себе, и как они будут интегрироваться с рабочим процессом команд разработки. Из этих принципов у нас появляются задачи на реализацию элементов функциональности пайплайна — т.е. задачи предыдущего слоя. Такой вид задач требует как знания предметной области ("как правильно строить пайплайны") с одной стороны, так и совершенно нетехнических компетенций с другой стороны — навыков анализа систем, планирования процессов и декомпозиции решений на элементарные задачи.

Все это хорошо, но какая здесь связь с DevOps?

Дело в том, что ориентация на результат, анализ сложных систем и планирование их реализации — это набор необходимых характеристик любого технического руководителя. Декомпозиция целевого решения на отдельные задачи тоже.
Вся суть "методологии DevOps" состоит в том, чтобы включать в активности по проектированию целевой системы не только функциональные и нефункциональные требования заказчика, но также и части системы связанные с Инфраструктурой и SDLC. Это не столько "методология" или "философия", сколько домен знания наподобие "проектирования интерфейсов" или "построения даталейков".
Скорее всего будучи руководителем, реализацию различных частей системы ты отдашь сотрудникам с соответствующей квалификацией.
В этот момент и возникает потребность в devops-инженерах, которые на деле являются такими же разработчиками как фронтендеры, тестировщики или разработчики на Java.

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

В телеграм такой длинный пост не влезает, прочитать его можно у меня на сайте:
https://timurb.ru/kb/kuda-idet-devops/
https://timurbatyrshin.medium.com/ed8c5fd01b02

Если хочется обсудить — пишите в канале, здесь обсуждение получится скорее всего лучше

20 апреля, в субботу через две недели, выступаю на онлайн-конференции «Systems Design» по проектированию ИТ-систем с докладом «Построение модели грейдов через моделирование цепочек добавленной ценности».

Расскажу о том, как построение Value Stream можно использовать не только для построения CI/CD-пайплайнов, но и для быстрого построения модели предметной области любого процесса, и для разворачивание этой модели в набор требований — в данном случае, например, в требования к грейдам в компании.

Кому конференция будет особенно полезна?
— Разработчикам
— Архитекторам
— Системным аналитикам
— ИТ-специалистам, которые интересуются вопросами проектирования

Более подробно про конференцию, воркшопы и доклады Вы можете узнать в отдельном TG-канале и на сайте конференции

Об менеджерское и инженерное рассмотрение процесса разработки [1/2]

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

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

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

Инженера же, напротив, интересует в первую очередь как именно происходит работа. Не соблюденный технологический процесс не приведет к тому результату, который мы ожидаем, в непротестированном коде почти наверняка будут ошибки. При этом, любая инженерная деятельность по своей сути весьма неравномерна — разработчик не может сказать "я написал код к фиче, как ее дальше будут тестировать и деплоить, и будет ли фича в принципе работать мне не важно". Почти всегда потребуется то или иное его участие и в других фазах. Ошибка найденная при тестировании или на продакшне возвращается к нему, и ее потребуется исправить. Для получения успешной системы в продакшне важно не только выполнение отдельных работ, но и весь технологический процесс, который поставляет результат в продакшн. В нем в отдельных фазах в принципе может не быть людей, а в других фазах могут участвовать одновременно несколько командных ролей, при этом у этих участников нет явно формализованной ответственности за участие в этой фазе. Если тестировщик нашел багу в написанном коде, разработчик садится с ним рядом и они вместе разбираются в чем там проблема, а не перекидывают тикеты друг другу ("-Я протестировал и нашел ошибку. -А я исправил. -А я снова потестировал и снова нашел"). При этом сбой на ранней стадии сквозного технологического процесса с большой вероятностью приведет к проблемам на его поздних стадиях, и поэтому этот процесс нужно проектировать также как и любой объект инженерной деятельности, и настолько же тщательно контролировать его реализацию: лучше всего описать его кодом чтобы получить гарантию что он всегда будет происходить именно так как проектировался.

Об менеджерское и инженерное рассмотрение процесса разработки [2/2]

Такое неоднородное вовлечение в процесс хорошо показано на "Горбатой диаграмме" из RUP (см выше).
Слева на право происходят фазы процесса разработки (можно провести параллель с состояниями тикета на доске или шагами пайплайна). Сверху вниз показаны роли, которые участвуют в каждой из фаз, и условный уровень их вовлечения в течение времени работы над проектом или фичей.

Итак, если рассмотреть особенности этих двух ролевые позиций - менеджера и инженера, то сразу становится ясна причина по которой звучат разные фантастические призывы вокруг DevOps, что мол "devops-инженер должен наладить взаимодействие между разными командами"  —  если смотреть на вещи как и прежде, с позиции менеджера, вполне закономерно будет казаться именно это. При этом, первый более-менее внятный ответ на вопрос в чем именно будет состоять «налаживание взаимодействия» кажется было дано лишь в подходе Team Topologies, и именно в нем снова начали говорить о «контрактах» между командами, до этого были достаточно пространные (с т.з. менеджера) слова про «коллаборацию» и «работу на общую цель», т.е. опять таки решение инженерное. UPD: скорее следующее будет не так, см обсуждение: Но раз у нас происходит разворот от менеджмента к инженерии, это налаживание взаимодействия (с т.з. корректировки обязанностей и контроля их выполнения) скорее становится новой задачей как раз таки менеджера (и это уже будет какой-то другой вид менеджера, например, scrum-мастер или менеджер потока). Инженерной же задачей здесь будет организация собственно технологического процесса, и этот технологический процесс будет затрагивать не только собственно конвеер CI/CD, но и фазы архитектурного проектирования и анализа. Как я писал чуть раньше, эту самую инженерную задачу скорее всего будет формулировать руководитель разработки. Devops-инженер же будет реализовывать по этому заданию конкретные компоненты сквозного процесса - подобно тому как разработчики реализуют бизнес-функциональность приложения по спеке/набору user stories от владельца продукта.

И еще один момент. Глядя на это же самое обстоятельство нельзя ставить знак "равно" между ITIL и DevOps. ITIL - дисциплина для менеджеров, даже несмотря на то, что в 4й версии его авторы изо всех сил постарались сделать его инженерным. Глядя же, например, на DevOps-топологии мы явно видим, что все топологии где идет речь о разграничении ответственности (т.е. о менеджерском взгляде на вещи) считаются антипаттерном для DevOps.

There is no “i” in IaC

Об платформенных инженеров [1/2]

Некоторое время назад я озвучивал свое мнение о том, что такое “devops-инженер” (спойлер: определенный вид разработчика), однако на днях было указание на термин “платформенный инженер” (спасибо, Антон!).

Несмотря на то, что термин “platform engineer” постепенно распространяется, я не считаю его верным. Но вместе с тем он может оказаться полезным.

Platform Engineering это домен проектирования, предметная область, такая же как, например “трансграничные переводы” или “автоматизация склада”, или шире “финтех” и “ретейл”.

Platform team разрабатывает Технологическую Платформу (вариант: Инфраструктурную Платформу, Internal Developer Platform, IDP)  —  систему, автоматизирующую деятельность сотрудников организации, только в данном случае не финансистов или кладовщиков, а программистов. Для автоматизация работы склада это может быть как коробочное решение (например, 1С Управление складом), так и полностью самописное решение. То же самое с Технологической Платформой  — есть вендоры, которые предлагают готовые решения, но чаще всего их собирают некие-инженеры из опенсорсных компонентов самостоятельно.

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

К примеру, платформенная команда занимающаяся компонентами платформы на базе Backstage будет состоять из typescript-разработчика, devops-инженера и DX-чемпиона (в России его скорее всего назвали бы не чемпионом, а аналитиком). Платформенная команда занимающаяся DBaaS будет состоять из Postgres DBA, Golang-программиста, фронтендера и архитектора. А платформенная команда занимающаяся мониторингом будет состоять из спеца по тюнингу прометеуса, девопс-инженера, голанг разработчика и DX-чемпиона.

Если проект маленький, все эти роли могут быть совмещены в одном человеке  —  в этом случае его можно будет назвать Platform Engineer. Но с большой вероятностью он тогда будет заниматься и задачами команд и ИТ за пределами собственно платформы. Иными словами, попробуйте в этом случае найти три отличия от “devops-инженера”, кроме названия.

Если проект большой – команда будет естественным образом больше. В кроссфункциональной команде возникнет либо разделение работ, либо разделение труда.

Разделение работ (“артель”) - это когда несколько взаимозаменяемых T-shape специалистов с примерно общими для всех компетенциями работают над общим проектом. В этом случае, наверное, термин platform engineer будет вполне корректным. T-shaped платформенные инженеры закрывают все задачи в создании Платформы от проектирования UI и API до производительности дисковой подсистемы и сопровождения в продакшне.

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

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

Во втором случае (“производство”) команда будет менее гибкая, скорее всего сложнее в эффективном управлении, но проще в подборе и масштабировании.

Об платформенных инженеров [2/2]

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

При этом “платформенная инженерия” вполне может и будет оставаться актуальным доменом проектирования систем, примерно таким же как “проектирование СЭД” или “проектирование WMS”, именно потому что автоматизация работы команд разработки так или иначе нужна всем, только работать в этих командах будут работать не Platform Engineer, а классические Software Engineer либо Devops Engineer.

Но тем не менее я поддержу термин “платформенный инженер” по одной простой причине. До сих пор не было хорошего способа способом самоидентификации для “devops-инженеров”, “automation engineer”, “build & release engineer”, и всех тех, кто попал в зазор между “developers” и “operations”. Были попытки в виде SRE и Cloud Engineer, но они захватили только часть всей профессии “devops-инженер”, поэтому проблема самоидентификации никуда не исчезла.

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

Об IT-компетенции [1/2]

Последний год или чуть больше достаточно большая часть моих задач на работе – организация пула devops-инженеров:
- построение найма (в т.ч. делегирование найма самим ребятам) и работы HR-специалистов
- уточнение критериев к грейдам
- описание типовых задач, которые команды devops закрывают на проектах
- классификация разношерстных проектных запросов на нашу грейдовую сетку (чтобы проекты перестали запрашивать лидов на “развертывание софта по инструкции”)

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

Я расскажу про онтологию получившуюся в результате всего этого движа своем докладе на конференции DevOpsConf 2025, которая пройдет 7 и 8 апреля. Цена билета будет расти в течение всего времени до начала конференции, есть вероятность что за пару недель до ее начала билеты закончатся.

Об IT-компетенции [2/2]

Помимо всего прочего за это время я изучил модели компетенций SFIA и iCD и хочу поделиться мнением об их сходствах и различиях (см. также сравнение от самих SFIA):
- И то и другое — модели компетенций с библиотекой, которая описывает собственно компетенции необходимые для профессий в IT
- SFIA – результат деятельности рабочей группы, которая его разрабатывают уже более 20 лет на базе того как работают компании в мире
- iCD начинался так же (в рамках Японии), но сейчас основан в большей степени на большом количестве стандартов и BoK (BABOK, SWEBOK, PMBOK, ITIL 2011, DMBOK, COBIT 5, CRISP-DM, японские внутренние стандарты), что на мой взгляд хорошо, т.к. не приходится переизобретать велосипед
- В iCD нет аналогов SFIA View (например, SFIA DevOps View или SFIA Cyber security View). Про SFIA DevOps View есть доклад Евгения Харченко.
- В SFIA описываются только “навыки”, в iCD описываются как “задачи” для той или иной роли (по факту, примерно то же что навыки SFIA), так и навыки, которые им соответствуют. Подробнее об этом можно почитать либо в сравнении от SFIA (ссылка выше по тексту), либо прямо в самих моделях.
- К примеру, в iCD задаче “Preparation for development environment” соответствуют навыки “Architecture design methods”, “Application architecture design methods”, “IT infrastructure building process”, “Systems Interoperability technology”, “Development process and methods”, “Development environment management”, “Standardization (software)”
- В iCD супер детально прописаны как классы задач (которые как я уже сказал, в целом примерно то же самое что компетенции SFIA), так и навыки необходимые для выполнения этих задач. Против ~100 навыков SFIA в iCD ~200 видов задач, которые детализируются в ~600 уточненных задач и в ~2500 элементарных операций. Плюс к этому ~500 навыков, которые разворачиваются в ~10 тысяч детальных объектов знания. Они группируются в дерево из 4 уровней, т.е. в них навигация довольно простая. В итоге можно брать и прям по рубрикатору выписывать все необходимые пункты. При необходимости можно расширить своими собственными пунктами, или чуть поменять формулировки в словаре
- Дополнительно в iCD благодаря Task Dictionary Chart можно посмотреть на ЖЦ некоей инициативы в организации, приложить к ней возможную ролевку и сразу есть ориентир какие из навыков нужны
- Вместо этого в SFIA детально вольным образом прописано для каждого навыка что именно требуется на каком уровне. К примеру, для “Release management” прописано (мой вольный перевод с сокращениями), что сначала специалист помогает с релизами, затем начинает принимать участие в их планировании, потом начинает разрабатывать подходы и автоматизацию, и самый высокий уровень – разрабатывает стратегии и стандарты. Для данного навыка описаны 5 уровней из 7, применение навыка на оставшихся двух не характерно.
- Уровни довольно сильно отличаются: в SFIA довольно детально прописана детализация для каждого из 7 уровней, причем каждый из них рассматривается в нескольких аспектах и детально прописывается под каждый навык. В iCD такой детализации нет, для всех задач и навыков есть 5 уровней (без опыта -> учебный опыт -> работа под руководством -> самостоятельная работа -> обучение других), плюс сверх этого для навыков есть еще 3 уровня “общественного признания”. Мне такой подход кажется более простым для понимания, применения и гармонизации с другими моделями.
- В целом SFIA мне показался больше подходящим для творческого осмысления и переработки под себя, а iCD как справочная таблица, которую ты при необходимости можешь чуть-чуть доработать, но которой можно и пользоваться как есть

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

Навскидку у меня получаются следующие сценарии использования:
- Стаффинг на проекты — определение состава проектной команды
- Оценка кандидатов при собеседованиях и промо
- Построение путей развития сотрудников
- Внепроектный поиск компетенций в компании для консультаций

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

Какие еще сценарии использования использования моделей компетенций я пропустил?

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

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

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

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

Сейчас это все звучит немного абстрактно и непонятно, поэтому давайте опишем более конкретно, например:
- Создание масштабируемой системы логирования
- Перестройка пачки ямлов в платформы разработки

Или если отойти в сторону от инфраструктуры и devops, это может быть например:
- Создание электронного кошелька
- Развитие системы управления складом

Такое описание уже конкретно, но мы еще не можем проверить, может ли команда выполнять эти задачи, есть ли у нее такая способность (capability).
Для этого нужно как-то задать уровень владения этой способностью.
Про это — в следующий раз.

Во вторник, 8 апреля, на конференции DevOpsConf буду рассказывать о том, как и куда можно расти инженерам.

https://devopsconf2025.timurb.ru/