Comments 24
скорость износа и остаток можно выразить только в процентах – так мы и сделали. Главный вопрос – какие цифры поставить?
Если честно, не знаю. И спросить не у кого. Да и незачем. Скорость износа можно определить по практике. Я выбрал 50 % в месяц – по моим наблюдениям, через два месяца вспомнить компетенцию уже достаточно сложно. В качестве остатка выбрал 10 %.
Эмпирическое правило — если использовал компетенцию всего месяц, то и забудешь через месяц неиспользования. Если год — то через год. Ставить константу в 2 месяца — как-то сомнительно.
мне кажется, тут любая цифра будет сомнительно. Я решил так — что-нибудь поставлю и успокоюсь.
А целевой профиль — он же у вас из того же источника (от фонаря ;), не правда ли? Почему там администрирование 5%, а не например 50? Откуда это следует?
целевой профиль — из стратегии развития бизнеса.
И каким образом 5% администрирования позволяет реализовать стратегию? Поверьте, это вопрос с далеко не очевидным ответом.
Вот у нас в компании к примеру решили, что нужно повышать компетенции сотрудников. И сказали всем: мы вас научим а) тестированию б) devops в) разработке. То есть, все должны стать более-менее универсалами. Если спроецировать на ваше решение, то это целевой профиль типа 30%, 30%, 40%, например.
Проблема в том, что на самом деле люди разные.
>Шестое. Человек, как правило, хочет «сидеть на теме» — освоить небольшой спектр компетенций, если получится – стать в нем экспертом, и забирать себе значительную часть работ по выбранным темам.
Из любого правила есть исключения. Я знаю массу людей, которым так жить тупо скучно. Включая и себя самого. Но: это не значит, что я хотел бы бросить разработку, и начать совершенствоваться скажем в тестировании. Или пойти в devops.
А что на самом деле хорошо для бизнеса — далеко не очевидно.
Вот у нас в компании к примеру решили, что нужно повышать компетенции сотрудников. И сказали всем: мы вас научим а) тестированию б) devops в) разработке. То есть, все должны стать более-менее универсалами. Если спроецировать на ваше решение, то это целевой профиль типа 30%, 30%, 40%, например.
Проблема в том, что на самом деле люди разные.
>Шестое. Человек, как правило, хочет «сидеть на теме» — освоить небольшой спектр компетенций, если получится – стать в нем экспертом, и забирать себе значительную часть работ по выбранным темам.
Из любого правила есть исключения. Я знаю массу людей, которым так жить тупо скучно. Включая и себя самого. Но: это не значит, что я хотел бы бросить разработку, и начать совершенствоваться скажем в тестировании. Или пойти в devops.
А что на самом деле хорошо для бизнеса — далеко не очевидно.
Что хорошо для бизнеса — это не знание, а решение. Стратегия не ищется, а разрабатывается.
Она вполне может оказаться неудачной, и станет полезным опытом.
Например, администрирование. Это — следствие продажи аренды. Продал аренду — продаешь администрирование. В аренду сдается не просто сервер, а размещенный на нем продукт (в нашем случае). Чтобы продать продукт, надо его создать. Чтобы его создать, нужны компетенции по разработке, а не по администрированию.
Текущих компетенций по администрированию вполне достаточно, чтобы обслужить в 2-3 раза больше клиентов. А вот для того, чтобы создать в 2-3 раза больше продуктов, компетенций не достаточно. Их и надо развивать.
Она вполне может оказаться неудачной, и станет полезным опытом.
Например, администрирование. Это — следствие продажи аренды. Продал аренду — продаешь администрирование. В аренду сдается не просто сервер, а размещенный на нем продукт (в нашем случае). Чтобы продать продукт, надо его создать. Чтобы его создать, нужны компетенции по разработке, а не по администрированию.
Текущих компетенций по администрированию вполне достаточно, чтобы обслужить в 2-3 раза больше клиентов. А вот для того, чтобы создать в 2-3 раза больше продуктов, компетенций не достаточно. Их и надо развивать.
Я подозреваю, что начиная с некоторого уровня, даже остатка после многих лет забвения будет более чем хватать.
Если все вот это собственное изобретение — очень круто (несмотря на то что автор изобрёл велосипед), если это такое своеобразное переложение ITIL, то как-то все коряво кучеряво.
Сам подход к управлению компетенциями — верен, но то что он привязан только к задачам, как-то странно.
Предполагаем, что мы имеем CMDB, где есть дерево конфигураций. Одна ветвь конфигурационных элементов — активное и пассивное сетевое оборудование, LAN, WAN и прочие СКС. Другая ветвь — разнообразное пользовательское железо — АРМы как тонкие так и толстые, принтеры, плоттеры, телефоны, и прочее, если угодно то вплоть до табуреток (эммм… все зависит от подхода к построению дерева конфигураций). Третья ветвь — стойки, сервера, лезвия, возможно даже вся около-серверная инфраструктура — чиллеры, ИБП, железо от СКУД и т.п. Четвертая ветвь — инфраструктурная шина: единая служба каталога, почта, мониторинг, резервирование, бэкапирование и тому подобное. Пятая ветвь — уровень приложений — всякие бухгалтерии, ERP, CRM SCOM, SCCM и прочие IDM.
Каждая из ветвей ясен фиг декомпозируется, железо до процессоров и гигов ОЗУ/ПЗУ, софт до конкретных программных модулей, библиотек, интеграций. Степень декомпозиции зависит от желаемой степени например мониторинга того или иного элемента конфигураций (но вообще, принцип декомпозиции может быть завязан не на мониторинг, а на что-то другое).
Ах да, пусть шестая ветвь конфигурационных элементов пусть будет Компетенции. Которые в соответствии с DevOps декомпозирется на под-ветви — Разработка, Тестирование, Администрирование (ну или не по принципу девопса, этих принципов вагон). Каждая из подветвей заполняется соответсвующими конфиг.элементами: в Администрировании мы забиваем компетенции по администрированию ОС, СУБД, наших серверов приложений, ну и т.п. Аналогично — в Тестировании: регрееcс, UI, секьюрити и т.п.
А дальше мы привязываем каждую из компетенций к юнитам ранее описанных ветвей — к сетям, железу, инфраструктурной шине, и т.п.
А дальше мы каждой компетенции присваиваем признаки ЗУНС: компетенцией можно обладать на уровне Знания (чо то слышал о том как это делать), Умения (уже делал однажды, имею опыт), Навыка (делал много раз, опытный типа), Способность (вот ваще гуру по этой теме, пьяным меня разбуди всё равно сделаю).
Дальше по каждому элементу сетевой, железячной, софтовой и иным ветвям CMDB определяем SLA, который описываем в терминах доступности, надежности, времени реакции, времени исправления и т.п.
Наконец, берёмсферического эксперта по каждой ветви CMDB и с помощью его экспертных оценок определяем исходя из SLA сколько и какого качества (ЗУНС) людей нам надо для планового девопса.
Вуаля — полный цикл, каждый элемент CMDB связан с элементами из других ветвей.
Тут вот я описал подход описанный во всяких там умных книжках.
И я знаю несколько отечественных контор которые вот это всё сумели внедрить и сейчас счастливые пользуютсяскромно шаркая ножкой скажу что в некоторых из них это сделано с моим участием.
Но мыслит автор правильно.
Сам подход к управлению компетенциями — верен, но то что он привязан только к задачам, как-то странно.
Предполагаем, что мы имеем CMDB, где есть дерево конфигураций. Одна ветвь конфигурационных элементов — активное и пассивное сетевое оборудование, LAN, WAN и прочие СКС. Другая ветвь — разнообразное пользовательское железо — АРМы как тонкие так и толстые, принтеры, плоттеры, телефоны, и прочее, если угодно то вплоть до табуреток (эммм… все зависит от подхода к построению дерева конфигураций). Третья ветвь — стойки, сервера, лезвия, возможно даже вся около-серверная инфраструктура — чиллеры, ИБП, железо от СКУД и т.п. Четвертая ветвь — инфраструктурная шина: единая служба каталога, почта, мониторинг, резервирование, бэкапирование и тому подобное. Пятая ветвь — уровень приложений — всякие бухгалтерии, ERP, CRM SCOM, SCCM и прочие IDM.
Каждая из ветвей ясен фиг декомпозируется, железо до процессоров и гигов ОЗУ/ПЗУ, софт до конкретных программных модулей, библиотек, интеграций. Степень декомпозиции зависит от желаемой степени например мониторинга того или иного элемента конфигураций (но вообще, принцип декомпозиции может быть завязан не на мониторинг, а на что-то другое).
Ах да, пусть шестая ветвь конфигурационных элементов пусть будет Компетенции. Которые в соответствии с DevOps декомпозирется на под-ветви — Разработка, Тестирование, Администрирование (ну или не по принципу девопса, этих принципов вагон). Каждая из подветвей заполняется соответсвующими конфиг.элементами: в Администрировании мы забиваем компетенции по администрированию ОС, СУБД, наших серверов приложений, ну и т.п. Аналогично — в Тестировании: регрееcс, UI, секьюрити и т.п.
А дальше мы привязываем каждую из компетенций к юнитам ранее описанных ветвей — к сетям, железу, инфраструктурной шине, и т.п.
А дальше мы каждой компетенции присваиваем признаки ЗУНС: компетенцией можно обладать на уровне Знания (чо то слышал о том как это делать), Умения (уже делал однажды, имею опыт), Навыка (делал много раз, опытный типа), Способность (вот ваще гуру по этой теме, пьяным меня разбуди всё равно сделаю).
Дальше по каждому элементу сетевой, железячной, софтовой и иным ветвям CMDB определяем SLA, который описываем в терминах доступности, надежности, времени реакции, времени исправления и т.п.
Наконец, берём
Вуаля — полный цикл, каждый элемент CMDB связан с элементами из других ветвей.
Тут вот я описал подход описанный во всяких там умных книжках.
И я знаю несколько отечественных контор которые вот это всё сумели внедрить и сейчас счастливые пользуются
Но мыслит автор правильно.
… ну и нахрена я эту простыню писал, если ни одного слова под ней, и непонятно — согласны читатели с моим опытом, или против.
Как быть с вариантом: Делал много раз, но это было десять лет назад? Или в Вашем комментарии навыки статичны и не изменятся со временем в плюс или минус?
Как я понял, статья именно про развитие компетенций человека, как часть стратегии развития бизнеса.
Как я понял, статья именно про развитие компетенций человека, как часть стратегии развития бизнеса.
It depends on…
Я много раз разбирал и собирал москвичевский и жигулевский ДВС, когда мне было 14-16-18 лет. С тех пор прошло больше четверти века, за которые я ни разу не разбирал ДВС. Но если завтра мне скажут разобрать-собрать именно жигулевский ДВС образца 85 года — я сделаю это без проблем.
Но если меня попросят разобрать-собрать современный TFSI — большой вопрос смогу-ли. Разобрать-то смогу. Но вот дефектовать и собрать так чтобы заработало — не знаю.
Другими словами, если за 10 лет среда (инструмент, окружение) не поменялось — да, Навык не утерян.
Но такого не бывает, потому что среда меняется постоянно.
Я много раз разбирал и собирал москвичевский и жигулевский ДВС, когда мне было 14-16-18 лет. С тех пор прошло больше четверти века, за которые я ни разу не разбирал ДВС. Но если завтра мне скажут разобрать-собрать именно жигулевский ДВС образца 85 года — я сделаю это без проблем.
Но если меня попросят разобрать-собрать современный TFSI — большой вопрос смогу-ли. Разобрать-то смогу. Но вот дефектовать и собрать так чтобы заработало — не знаю.
Другими словами, если за 10 лет среда (инструмент, окружение) не поменялось — да, Навык не утерян.
Но такого не бывает, потому что среда меняется постоянно.
За сколько времени Вы разбирали-собирали жигулёвский ДВС в 18 лет? И сколько на это уйдёт сейчас? Вот в чём разница.
Исходя из способа описанного в статье — Ваша компетенция по разборке-сборки упала. В реальности то-же самое — Вы не забыли всё, у Вас просто уйдёт больше времени (тот самый минимум из статьи). Исходя из Вашего комментария — временной отметки у ЗУНС нет и это влияет на стратегию развития бизнеса — либо взять того, кто сейчас разберёт двигатель за час. Либо взять Вас и Вы его разберёте за три часа.
В статье не сказано напрямую, но по мере постоянного набирания опыта, скорость падения забывания уменьшается и увеличивается уровень незабывания (Ваш опыт работы с жигулёвскими ДВС).
В Вашем же ЗУНС нет отражения временной характеристики — либо З, либо У, либо Н, либо С. Соответственно, когда человек из З превратится в С в Вашей схеме неизвестно. Будет просто факт — был З стал С, если интервал проверки слишком большой. А если проверок нет, то информация явно устарела и причём давно, и не актуальна, и уже вредна для бизнеса, так как на её основе будет принято неверное решение по поставленной цели.
Исходя из способа описанного в статье — Ваша компетенция по разборке-сборки упала. В реальности то-же самое — Вы не забыли всё, у Вас просто уйдёт больше времени (тот самый минимум из статьи). Исходя из Вашего комментария — временной отметки у ЗУНС нет и это влияет на стратегию развития бизнеса — либо взять того, кто сейчас разберёт двигатель за час. Либо взять Вас и Вы его разберёте за три часа.
В статье не сказано напрямую, но по мере постоянного набирания опыта, скорость падения забывания уменьшается и увеличивается уровень незабывания (Ваш опыт работы с жигулёвскими ДВС).
В Вашем же ЗУНС нет отражения временной характеристики — либо З, либо У, либо Н, либо С. Соответственно, когда человек из З превратится в С в Вашей схеме неизвестно. Будет просто факт — был З стал С, если интервал проверки слишком большой. А если проверок нет, то информация явно устарела и причём давно, и не актуальна, и уже вредна для бизнеса, так как на её основе будет принято неверное решение по поставленной цели.
Те системы которые строились с моим участием действительно не имели коэффициента потери компетенции по времени. Я тогда не задумался почему архитекторами и аналитиками этого не было введено. Зато подумал сейчас.
Предполагаю следующее:
1. На момент старта CMDB и ее окружения, после заполнения БД выявлялся профицит или дефицит тех или иных компетенций.
2. Далее, отклонения выравнивались, чтобы наиболее соответствовать OLA/SLA.
3. Далее, при появлении в CMDB новых уникальных юнитов модель компетенция расширялась (например был внедрен SAP, значит нужен админ, нужен аналитик со знанием ABAP и т.п.); в случае количественного роста юнитов (например расширение сетевой инфраструктуры) принималось решение о соответствующем расширении нужной компетенции;
4. Предполагается, что любая актуально востребованная компетенция используется. Сети и сервера проходят регламентное и прочее обслуживание, как и все иные юниты CMDB. Другими словами — невостребованных «прозапас» компетенций нет, и нечему протухать. Если мы вывели из прода какой-то элемент инфраструктуры, то и удалили (перевели в архив) соответствующую компетенцию.
Предполагаю следующее:
1. На момент старта CMDB и ее окружения, после заполнения БД выявлялся профицит или дефицит тех или иных компетенций.
2. Далее, отклонения выравнивались, чтобы наиболее соответствовать OLA/SLA.
3. Далее, при появлении в CMDB новых уникальных юнитов модель компетенция расширялась (например был внедрен SAP, значит нужен админ, нужен аналитик со знанием ABAP и т.п.); в случае количественного роста юнитов (например расширение сетевой инфраструктуры) принималось решение о соответствующем расширении нужной компетенции;
4. Предполагается, что любая актуально востребованная компетенция используется. Сети и сервера проходят регламентное и прочее обслуживание, как и все иные юниты CMDB. Другими словами — невостребованных «прозапас» компетенций нет, и нечему протухать. Если мы вывели из прода какой-то элемент инфраструктуры, то и удалили (перевели в архив) соответствующую компетенцию.
Всё, что Вы говорите — верно. Оно верно, когда используется ITIL/ITSM используется внутри компании. В таких случаях и не нужно смотреть постоянно за компетенциями сотрудников. Но когда это разработка ПО, то тут компетенции важны. Даже если это ИТ-аутсорсер работающий по ITSM, со всеми CMDB/SLA/OLA и прочим, то тут тоже компетенции важны, так как есть текучка, нужно уметь выбирать из претендентов, следить за ними. Компетенции и рост сотрудника важны и в магазине, где есть контакт с покупателем в виде консультации.
На заре моей молодости пришлось делать нечто подобное описанному в статье для продавца в компьютером магазине. Это было интуитивно, без анализа. Просто был экселевский файл, по которому я следил за зелёными стажёрами.
На заре моей молодости пришлось делать нечто подобное описанному в статье для продавца в компьютером магазине. Это было интуитивно, без анализа. Просто был экселевский файл, по которому я следил за зелёными стажёрами.
Да, все верно пишите.
Управление компетенциями возможно тоько в процессно-ориентированных задачах. Все что связано с operations / services — вперед и с песней управляем (в том числе, например в управлении релизами, управлении тестированием, качеством, доступностью).
Управление компетенциями в чистой разработке это единорог. В приницпе недостижимая цель.
Потому что перед разработчиками ставят уникальные задачи, в реализации той или иной функции, интерфейса, структуры БД и т.п. — те задачи, путь реализации которой становится ясен по ходу реализации и определение трудозатрат на ее решение это особый видискусства апроксимации и умножения названной цифры на число Пи, с гаданием на кофейной гуще «а как оно там на самом деле будет» по ходу реализации.
Я далек от мира 1С, поэтому могу только предполагать чем там занимаются разработчики. Предположу, что это разного рода кастомизации типовых форм отчетов, интеграция черз имеющиеся API с другими учетными системами и тому подобное. То есть все же не разработка в том виде, котором все привыкли. Именно поэтому Автор взялся и возмжно вполне успешно решил задачу управления компетенциями конкретно в этой экосистеме, если у тебя список задач, список автоматизируемых функций которые можно менять, окружение, workflow и тп — постоянно одно и тоже, то почему-бы действительно не записать все это в тетрадку раз и навсегда.
Управление компетенциями возможно тоько в процессно-ориентированных задачах. Все что связано с operations / services — вперед и с песней управляем (в том числе, например в управлении релизами, управлении тестированием, качеством, доступностью).
Управление компетенциями в чистой разработке это единорог. В приницпе недостижимая цель.
Потому что перед разработчиками ставят уникальные задачи, в реализации той или иной функции, интерфейса, структуры БД и т.п. — те задачи, путь реализации которой становится ясен по ходу реализации и определение трудозатрат на ее решение это особый вид
Я далек от мира 1С, поэтому могу только предполагать чем там занимаются разработчики. Предположу, что это разного рода кастомизации типовых форм отчетов, интеграция черз имеющиеся API с другими учетными системами и тому подобное. То есть все же не разработка в том виде, котором все привыкли. Именно поэтому Автор взялся и возмжно вполне успешно решил задачу управления компетенциями конкретно в этой экосистеме, если у тебя список задач, список автоматизируемых функций которые можно менять, окружение, workflow и тп — постоянно одно и тоже, то почему-бы действительно не записать все это в тетрадку раз и навсегда.
Вспоминая материал автора про время написания статей — а вот эта статья тоже за пару часов на коленке написана?
Автор, сознайся, ты себя клонировал?
Автор, сознайся, ты себя клонировал?
По заголовку и первой картинке первая мысль пришла — опять nmivan будет рассказывать как 1с спасет мир. Но к счастью содержание не об этом.
В целом от статьи к статье мысли интересные, вижу автора и иду читать внутрь, но прям видится тяжелое влияние долгой работы с 1с, своеобразная проф. деформация, когда любая задача рассматривается сквозь призму привычного инструмента. Про такое как раз есть поговорка — когда в руках молоток, всё вокруг кажется гвоздями.
Конкретно этот инструмент относится к Flowcon, который, в свою очередь, реализован одновременно на двух платформах — 1С и metadata.js (которая — на javascript).
1С выбрана не потому, что я ее знаю. Методика управления, заложенная во Flowcon, говорит, что задачи, проекты, показатели должны жить там, где лежат исходные данные. А исходные данные у большинства лежат в 1С.
1С выбрана не потому, что я ее знаю. Методика управления, заложенная во Flowcon, говорит, что задачи, проекты, показатели должны жить там, где лежат исходные данные. А исходные данные у большинства лежат в 1С.
Любопытная статья, прочел с интересом. Спасибо.
Теперь знаю это слово.
Большинство задач, так или иначе, несложно стратифицируются на потоки
Теперь знаю это слово.
Во многих видах бизнеса, особенно в ИТ, ключевое значение имеют компетенции сотрудников. Избитая, знакомая всем фраза. На сайтах большинства компаний, где присутствует раздел миссии или ценностей, написано что-нибудь вроде «наше главное богатство – это наши сотрудники».
Главный айтишник
Sign up to leave a comment.
Наше всё