Об платформенных инженеров [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 до производительности дисковой подсистемы и сопровождения в продакшне.
Разделение труда (“производство”) - это команда в которой каждый выполняет свою часть функциональных задач: фронтендер пишет фронтенд, голангер пишет голанг, а девопс настраивает интеграции.
В первом случае (“артель”) команда будет эффективнее с т.з. результативности и проще в управлении, но сложнее в подборе и дороже по стоимости, т.к. будет требовать сеньорных разносторонних экспертов, либо будет требовать развитого и хорошо поставленного процесса онбординга, либо будет необходимо наличие большого количества таких “разносторонних экспертов на рынке” (чего не случится никогда).
Во втором случае (“производство”) команда будет менее гибкая, скорее всего сложнее в эффективном управлении, но проще в подборе и масштабировании.
Некоторое время назад я озвучивал свое мнение о том, что такое “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/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” дает людям хороший ориентир куда развиваться и к чему стремиться.
И одновременно закладывает в понятийное пространство нанимателей организационный паттерн “технологическая платформа”
В свете вышесказанного видится, что “платформенный инженер” как отдельная специальность/должность скорее всего будет актуальной исключительно для компаний, для которых сверхбыстрое и сверхпредсказуемое ИТ является важным конкурентным преимуществом, а не просто способом снизить стоимость реализации проектов. При этом компания будет достаточно большой (от нескольких десятков команд), чтобы IDP выделять как отдельную сущность. Т.е. в первую очередь “платформенные инженеры” будут существовать только в бигтехе и scale-ups в высококонкурентных областях. Либо в высокорегламентированных областях типа медицины, но там их задача будет не ускорение разработки, а обеспечение повторяемого качества релизов любых команд и соответствию регуляторке, и такие платформы вероятно будут достаточно сильно отличаться от платформ в компаниях, работающих в “экономики скорости”. Во всех остальных случаях термин «платформенный инженер» кажется не будет иметь смысла.
При этом “платформенная инженерия” вполне может и будет оставаться актуальным доменом проектирования систем, примерно таким же как “проектирование СЭД” или “проектирование WMS”, именно потому что автоматизация работы команд разработки так или иначе нужна всем, только работать в этих командах будут работать не Platform Engineer, а классические Software Engineer либо Devops Engineer.
Но тем не менее я поддержу термин “платформенный инженер” по одной простой причине. До сих пор не было хорошего способа способом самоидентификации для “devops-инженеров”, “automation engineer”, “build & release engineer”, и всех тех, кто попал в зазор между “developers” и “operations”. Были попытки в виде SRE и Cloud Engineer, но они захватили только часть всей профессии “devops-инженер”, поэтому проблема самоидентификации никуда не исчезла.
Теперь этот способ самоидентификации появился, и при всех его приведенных выше недостатках он выглядит достаточно неплохо: термин “Platform Engineer” дает людям хороший ориентир куда развиваться и к чему стремиться.
И одновременно закладывает в понятийное пространство нанимателей организационный паттерн “технологическая платформа”
👍1
Об IT-компетенции [1/2]
Последний год или чуть больше достаточно большая часть моих задач на работе – организация пула devops-инженеров:
- построение найма (в т.ч. делегирование найма самим ребятам) и работы HR-специалистов
- уточнение критериев к грейдам
- описание типовых задач, которые команды devops закрывают на проектах
- классификация разношерстных проектных запросов на нашу грейдовую сетку (чтобы проекты перестали запрашивать лидов на “развертывание софта по инструкции”)
В ближайшее время доработаем с ребятами типовые пути развития и набор курсов/учебников, которые помогут по ним двигаться, и можно будет заниматься развитием вовне (например, построением технологического радара согласованного со всем вышеперечисленным).
Я расскажу про онтологию получившуюся в результате всего этого движа своем докладе на конференции DevOpsConf 2025, которая пройдет 7 и 8 апреля. Цена билета будет расти в течение всего времени до начала конференции, есть вероятность что за пару недель до ее начала билеты закончатся.
Последний год или чуть больше достаточно большая часть моих задач на работе – организация пула 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 как справочная таблица, которую ты при необходимости можешь чуть-чуть доработать, но которой можно и пользоваться как есть
Помимо всего прочего за это время я изучил модели компетенций 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 как справочная таблица, которую ты при необходимости можешь чуть-чуть доработать, но которой можно и пользоваться как есть
👍4
Если продолжить тему моделей компетенций (а как минимум до своего доклада на DevOpsConf это останется моим основным направлением рассуждений здесь), то кажется логичным описать назначение и способы использования такой модели, чтобы дальше под эти сценарии подобрать наилучший инструмент.
Навскидку у меня получаются следующие сценарии использования:
- Стаффинг на проекты — определение состава проектной команды
- Оценка кандидатов при собеседованиях и промо
- Построение путей развития сотрудников
- Внепроектный поиск компетенций в компании для консультаций
После функциональной декомпозиции можно определять конкретные структурные элементы в организации, на которые можно назначать эти сценарии.
Какие еще сценарии использования использования моделей компетенций я пропустил?
Навскидку у меня получаются следующие сценарии использования:
- Стаффинг на проекты — определение состава проектной команды
- Оценка кандидатов при собеседованиях и промо
- Построение путей развития сотрудников
- Внепроектный поиск компетенций в компании для консультаций
После функциональной декомпозиции можно определять конкретные структурные элементы в организации, на которые можно назначать эти сценарии.
Какие еще сценарии использования использования моделей компетенций я пропустил?
Прежде чем подбирать процессы, которые будут реализовывать эти сценарии стоит прояснить связи между ними.
На мой взгляд стаффинг и подбор проектной команды это главный сценарий — весь разговор о моделях компетенций появляется когда нам нужно предсказуемым образом собирать (или усиливать) проектную команду.
Эта необходимость повлечет за собой и потребность оценивать кандидатов из найма.
И если мы рассматриваем не только найм кандидатов со стороны, но и выращивание компетенций внутри компании, рядом тут же появляется построение путей их развития.
И то и другое это процессы подчиненные стаффингу.
Внепроектный поиск компетенций же будет стоять немного особняком — про него поговорим несколько позже.
Итак, компания собирает команду под некую бизнес-задачу, и я считаю, что к команде можно применить обычные методы проектирования систем.
Сперва рассмотрим команду как черный ящик — пока не будем заглядывать внутрь и опишем какие задачи нужно выполнять команде.
Это может быть в зависимости от степени непрозрачности этого ящика, например:
- Автоматизация неких существующих бизнес-процессов
- Не просто автоматизация, но и реинженеринг таких процессов
- Создание и реализация пользовательского пути
- Создание новой функциональности
- Создание новой системы (или приложения) с нуля
- Доработка функциональности существующей системы
- Поддержка существующей системы.с минимальными доработками
- и т.д.
Сейчас это все звучит немного абстрактно и непонятно, поэтому давайте опишем более конкретно, например:
- Создание масштабируемой системы логирования
- Перестройка пачки ямлов в платформы разработки
Или если отойти в сторону от инфраструктуры и devops, это может быть например:
- Создание электронного кошелька
- Развитие системы управления складом
Такое описание уже конкретно, но мы еще не можем проверить, может ли команда выполнять эти задачи, есть ли у нее такая способность (capability).
Для этого нужно как-то задать уровень владения этой способностью.
Про это — в следующий раз.
На мой взгляд стаффинг и подбор проектной команды это главный сценарий — весь разговор о моделях компетенций появляется когда нам нужно предсказуемым образом собирать (или усиливать) проектную команду.
Эта необходимость повлечет за собой и потребность оценивать кандидатов из найма.
И если мы рассматриваем не только найм кандидатов со стороны, но и выращивание компетенций внутри компании, рядом тут же появляется построение путей их развития.
И то и другое это процессы подчиненные стаффингу.
Внепроектный поиск компетенций же будет стоять немного особняком — про него поговорим несколько позже.
Итак, компания собирает команду под некую бизнес-задачу, и я считаю, что к команде можно применить обычные методы проектирования систем.
Сперва рассмотрим команду как черный ящик — пока не будем заглядывать внутрь и опишем какие задачи нужно выполнять команде.
Это может быть в зависимости от степени непрозрачности этого ящика, например:
- Автоматизация неких существующих бизнес-процессов
- Не просто автоматизация, но и реинженеринг таких процессов
- Создание и реализация пользовательского пути
- Создание новой функциональности
- Создание новой системы (или приложения) с нуля
- Доработка функциональности существующей системы
- Поддержка существующей системы.с минимальными доработками
- и т.д.
Сейчас это все звучит немного абстрактно и непонятно, поэтому давайте опишем более конкретно, например:
- Создание масштабируемой системы логирования
- Перестройка пачки ямлов в платформы разработки
Или если отойти в сторону от инфраструктуры и devops, это может быть например:
- Создание электронного кошелька
- Развитие системы управления складом
Такое описание уже конкретно, но мы еще не можем проверить, может ли команда выполнять эти задачи, есть ли у нее такая способность (capability).
Для этого нужно как-то задать уровень владения этой способностью.
Про это — в следующий раз.
Во вторник, 8 апреля, на конференции DevOpsConf буду рассказывать о том, как и куда можно расти инженерам.
https://devopsconf2025.timurb.ru/
https://devopsconf2025.timurb.ru/
devopsconf.io
Тимур Батыршин на DevOpsConf 2025
Если вы задавались вопросом, куда вам расти как инженеру и каким образом — этот доклад для вас.Если задумывались, как строить модель грейдов в компании — для вас тоже.Если ломали голову над проблемой, как при росте избежать превращения хорошего инженера в…
🔥6
Об ведение базы знаний
(копия моего поста в одном из чатов)
При ведении базы знаний у тебя есть несколько сценариев работы с информацией (по сути, жизненный цикл объекта информации-знания):
- Поиск внешний
- Сбор и учет материала, фиксация ссылок, выгрузка контента
- Осмысление материала, фиксация мыслей
- Анализ взаимосвязей между темами
- Корректировка и переработка материала
- Поиск материала в своей БЗ
- Обмен материалами с другими людьми / встраивание материалов в повседневную работу
Ключевое в ведении базы знаний — это то, чтобы эти сценарии происходили хоть как-то.
Ты лично должен их осуществлять — за тебя никакой инструмент не запишет твои мысли после прочтения статьи.
Но может помочь с этим (предоставив удобную локацию для записи и удобный интерфейс), или помешать (заставив тебя задумываться куда именно записывать).
Ну и инструменты обычно помогают только с какими-то небольшим набором сценариев.
К примеру, OneNote хорошо помогает фиксировать ссылки ко встречам в аутлуке, выгружать с них контент (мой основной юзкейс для него), но не помогает со всем остальным.
А Obsidian/Logseq из коробки с этим никак не помогают и здесь у нас разрыв в деятельности (если кто-то может рассказать как быстро и просто из календаря в аутлуке попадать в страницу в obsidian, и из нее обратно в календарь — я буду очень благодарен).
Хорошие инструменты помогают с большим количеством сценариев — по сути удобны для всех этих сценариев кроме разве что поиска внешнего (и поиск это отдельная большая важная тема) и обмена материалами с другими.
Часто возникает и куча смежных задач для инструмента, типа работы с задачами, рисования и т.д. — это часто реализуется через плагины, здесь Obsidian на высоте.
А с поиском внешним (в интернете, в корпоративном поиске или других системах) никак не помогают.
И вернусь к основной мысли — ключевое не в инструменте, а в подходах к работе, в обмене ими я вижу максимальную ценность
Я могу описать несколько принципов, которым стараюсь следовать:
- Не держу миллион вкладок в броузере, ссылки сохраняю в БЗ и в двух словах пишу что это и зачем (например, «Сравнение инсталляторов Kubernetes https:///ссылка»)
- Если прочитал статью и нашел ее интересной — выгружаю ее снимок в Zotero, т.к. через год-другой ее в интернете уже не найдешь. Кстати, можно попробовать вести таким образом библиотеку контента из интернета расшаренную на компанию. Плюс линкую в БЗ в виде отдельной страницы (происходит автоматом в виде плагина)
- Если нужно письменно о чем-то порассуждать — делаю это в БЗ, и сразу проставляю [[ссылки]] на другие страницы, чтобы через полгода при поиске информации можно было найти свои старые мысли через обратные ссылки/backlinks. Конкретно в этом пункте в Obsidian будет некоторое ограничение, т.к. в нем (в отличие от Logseq) по-моему нет ленты/журнала в который я пишу мысли не задумываясь «в какое место их положить», и обратных ссылок в Obsidian тоже по-моему нормальных не было
- Предыдущий пункт мне позволяет «автоматически» создавать страницы про концепты и делать связи между не связанными на первый взгляд темами. Пример в скрине ниже — я не писал ничего про Engineering, но в 5 страницах ссылался на термин, плюс Logseq мне нашел еще 117 страниц, где слово встречается в тексте
- Если где-то написал что-то что захочу сохранить (например, этот пост) — копирую к себе в БЗ.
- Ну и все вообще записи (кроме проектных) веду в Logseq — поэтому он останется приватным
- Вся проектная активность — вокруг корпоративного стека MS Office (Outlook, OneNote) и проектных Gitlab/Wiki/и т.п.
Вот по сути вся моя методология ведения базы знаний. Поделитесь своей?
(копия моего поста в одном из чатов)
При ведении базы знаний у тебя есть несколько сценариев работы с информацией (по сути, жизненный цикл объекта информации-знания):
- Поиск внешний
- Сбор и учет материала, фиксация ссылок, выгрузка контента
- Осмысление материала, фиксация мыслей
- Анализ взаимосвязей между темами
- Корректировка и переработка материала
- Поиск материала в своей БЗ
- Обмен материалами с другими людьми / встраивание материалов в повседневную работу
Ключевое в ведении базы знаний — это то, чтобы эти сценарии происходили хоть как-то.
Ты лично должен их осуществлять — за тебя никакой инструмент не запишет твои мысли после прочтения статьи.
Но может помочь с этим (предоставив удобную локацию для записи и удобный интерфейс), или помешать (заставив тебя задумываться куда именно записывать).
Ну и инструменты обычно помогают только с какими-то небольшим набором сценариев.
К примеру, OneNote хорошо помогает фиксировать ссылки ко встречам в аутлуке, выгружать с них контент (мой основной юзкейс для него), но не помогает со всем остальным.
А Obsidian/Logseq из коробки с этим никак не помогают и здесь у нас разрыв в деятельности (если кто-то может рассказать как быстро и просто из календаря в аутлуке попадать в страницу в obsidian, и из нее обратно в календарь — я буду очень благодарен).
Хорошие инструменты помогают с большим количеством сценариев — по сути удобны для всех этих сценариев кроме разве что поиска внешнего (и поиск это отдельная большая важная тема) и обмена материалами с другими.
Часто возникает и куча смежных задач для инструмента, типа работы с задачами, рисования и т.д. — это часто реализуется через плагины, здесь Obsidian на высоте.
А с поиском внешним (в интернете, в корпоративном поиске или других системах) никак не помогают.
И вернусь к основной мысли — ключевое не в инструменте, а в подходах к работе, в обмене ими я вижу максимальную ценность
Я могу описать несколько принципов, которым стараюсь следовать:
- Не держу миллион вкладок в броузере, ссылки сохраняю в БЗ и в двух словах пишу что это и зачем (например, «Сравнение инсталляторов Kubernetes https:///ссылка»)
- Если прочитал статью и нашел ее интересной — выгружаю ее снимок в Zotero, т.к. через год-другой ее в интернете уже не найдешь. Кстати, можно попробовать вести таким образом библиотеку контента из интернета расшаренную на компанию. Плюс линкую в БЗ в виде отдельной страницы (происходит автоматом в виде плагина)
- Если нужно письменно о чем-то порассуждать — делаю это в БЗ, и сразу проставляю [[ссылки]] на другие страницы, чтобы через полгода при поиске информации можно было найти свои старые мысли через обратные ссылки/backlinks. Конкретно в этом пункте в Obsidian будет некоторое ограничение, т.к. в нем (в отличие от Logseq) по-моему нет ленты/журнала в который я пишу мысли не задумываясь «в какое место их положить», и обратных ссылок в Obsidian тоже по-моему нормальных не было
- Предыдущий пункт мне позволяет «автоматически» создавать страницы про концепты и делать связи между не связанными на первый взгляд темами. Пример в скрине ниже — я не писал ничего про Engineering, но в 5 страницах ссылался на термин, плюс Logseq мне нашел еще 117 страниц, где слово встречается в тексте
- Если где-то написал что-то что захочу сохранить (например, этот пост) — копирую к себе в БЗ.
- Ну и все вообще записи (кроме проектных) веду в Logseq — поэтому он останется приватным
- Вся проектная активность — вокруг корпоративного стека MS Office (Outlook, OneNote) и проектных Gitlab/Wiki/и т.п.
Вот по сути вся моя методология ведения базы знаний. Поделитесь своей?
👍1
Об весенние конференции 2025
В апреле 2025 я делал два доклада на конференциях примерно на одну и ту же тему.
1. «Компетенции и уровни развития инженера инфраструктуры. Системный взгляд» на конференции DevOpsConf 2025.
Я рассказывал про то, как расти инженеру – во многом на базе материалов, которые я публиковал здесь на канале.
Я сам недоволен тем какой доклад получился, поэтому видео не выкладываю. При должном желании вы его найдете, или увидите его когда доклад опубликуют организаторы конференции.
2. «Бизнес-ориентированные модели компетенций: инженерный подход к построению» на конференции MergeConf 2025.
Доклад на базе той же модели, но без адаптации под конкретный профиль сотрудника, и чуть расширенная для того чтобы захватить не только направление devops.
В докладе я разбираю как деятельность любой организации разворачивается в проекты, в наборы компетенций проектных команд (более точное название – capability), знание предметных областей, и наконец, в набор элементарных навыков.
Модель может задать систему координат в построении моделей компетенций конкретно под вашу компанию.
Слайды доклада: https://mergeconf2025.timurb.ru/
Видео: https://youtu.be/iJl4kQq1YcY
Краткое содержание:
- Попытаемся рассмотреть модель компетенций как продукт, опишем сценарии ее использования, и через нее построим ее содержательно
- 5 основных сценариев, в которых пытаются использовать модель компетенций
- Уровень в организации определяется ответственностью за результат
- Декомпозиция результатов на составляющие и во времени
- Предметные области и шкала владения ей
- Жизненный цикл системы задает набор навыков необходимых команде
- Middle-минус работают не по результатам, а по задачам
- Типовая задача devops-инженера, которая встретится на любом проекте
- Построение карьерных путей — навигация по пространству ответственности
- Построение обучения внутри уровня — описание предметной области
В апреле 2025 я делал два доклада на конференциях примерно на одну и ту же тему.
1. «Компетенции и уровни развития инженера инфраструктуры. Системный взгляд» на конференции DevOpsConf 2025.
Я рассказывал про то, как расти инженеру – во многом на базе материалов, которые я публиковал здесь на канале.
Я сам недоволен тем какой доклад получился, поэтому видео не выкладываю. При должном желании вы его найдете, или увидите его когда доклад опубликуют организаторы конференции.
2. «Бизнес-ориентированные модели компетенций: инженерный подход к построению» на конференции MergeConf 2025.
Доклад на базе той же модели, но без адаптации под конкретный профиль сотрудника, и чуть расширенная для того чтобы захватить не только направление devops.
В докладе я разбираю как деятельность любой организации разворачивается в проекты, в наборы компетенций проектных команд (более точное название – capability), знание предметных областей, и наконец, в набор элементарных навыков.
Модель может задать систему координат в построении моделей компетенций конкретно под вашу компанию.
Слайды доклада: https://mergeconf2025.timurb.ru/
Видео: https://youtu.be/iJl4kQq1YcY
Краткое содержание:
- Попытаемся рассмотреть модель компетенций как продукт, опишем сценарии ее использования, и через нее построим ее содержательно
- 5 основных сценариев, в которых пытаются использовать модель компетенций
- Уровень в организации определяется ответственностью за результат
- Декомпозиция результатов на составляющие и во времени
- Предметные области и шкала владения ей
- Жизненный цикл системы задает набор навыков необходимых команде
- Middle-минус работают не по результатам, а по задачам
- Типовая задача devops-инженера, которая встретится на любом проекте
- Построение карьерных путей — навигация по пространству ответственности
- Построение обучения внутри уровня — описание предметной области
🔥1
Я последний месяц слишком часто в обсуждениях кидаю скрин этого слайда, выложу и сюда. Он на самом деле ключевой во всей теме.
Уровень ответственности в абсолютно любой организации, и уровень сложности задач растет как показано слева (но далеко не во всех организациях есть предсказуемые переходы на следующий уровень).
Навыки которые нужны для этого уровня ответственности — справа. Обратите внимание на то, что это за навыки содержательно, что именно мы получаем при их применении.
Пример: Если ты знаешь не одну вендорскую коробку, а а две или три — это кажется и не рост вовсе. (Например, если ты помимо ELK изучил еще fluentbit, loki, vector и otel).
Если при этом научился делать аргументированный выбор между ними — вырос.
Если не просто выбрал и реализовал решение, но и научился и начал этим решать чьи-то чужие проблемы (проблема — это то, что не решается в лоб стандартными способами) или разобрался как это приносит постоянную пользу кому-то другому и начал это применять — вырос еще
Уровень ответственности в абсолютно любой организации, и уровень сложности задач растет как показано слева (но далеко не во всех организациях есть предсказуемые переходы на следующий уровень).
Навыки которые нужны для этого уровня ответственности — справа. Обратите внимание на то, что это за навыки содержательно, что именно мы получаем при их применении.
Пример: Если ты знаешь не одну вендорскую коробку, а а две или три — это кажется и не рост вовсе. (Например, если ты помимо ELK изучил еще fluentbit, loki, vector и otel).
Если при этом научился делать аргументированный выбор между ними — вырос.
Если не просто выбрал и реализовал решение, но и научился и начал этим решать чьи-то чужие проблемы (проблема — это то, что не решается в лоб стандартными способами) или разобрался как это приносит постоянную пользу кому-то другому и начал это применять — вырос еще
Святослав Котусев небезызвестный в кругах Enterprise Architecture своими исследованиями EA, выпустил новую версию своего легковесного фреймворка по Enterprise Architecture:
https://eaonapage.com/
4 больших одностраничных карты вместо 1.5 тыс страниц TOGAF (в прошлой версии было 2 одностраничника):
Из изменений:
- Добавилась модель зрелости EA
- Добавились полтора десятка вариантов функциональной оргструктуры архитектуры (в зависимости от размера и типа организации), в т.ч. небольшой бенчмарк по количеству архитекторов в организации
- Расширилась карта практик EA (добавились связи с артефактами ЕА, появились примеры, карта стала более практической)
- Уточнены формулировке на карте артефактов
Рекомендую как минимум полистать всем, кто так или иначе сталкивается со следующими темами или интересуется ими:
- Lifecycle объектов уровня солюшена и масштабнее
- Опермодель архитектурной функции и взаимодействие между отделами и проектами
- Виды архитектурной документации (обоснования, governance, портфолио и архрепозитории)
https://eaonapage.com/
4 больших одностраничных карты вместо 1.5 тыс страниц TOGAF (в прошлой версии было 2 одностраничника):
Из изменений:
- Добавилась модель зрелости EA
- Добавились полтора десятка вариантов функциональной оргструктуры архитектуры (в зависимости от размера и типа организации), в т.ч. небольшой бенчмарк по количеству архитекторов в организации
- Расширилась карта практик EA (добавились связи с артефактами ЕА, появились примеры, карта стала более практической)
- Уточнены формулировке на карте артефактов
Рекомендую как минимум полистать всем, кто так или иначе сталкивается со следующими темами или интересуется ими:
- Lifecycle объектов уровня солюшена и масштабнее
- Опермодель архитектурной функции и взаимодействие между отделами и проектами
- Виды архитектурной документации (обоснования, governance, портфолио и архрепозитории)
👍1