Наше всё

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

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

    И вот что получается. Успех бизнеса зависит от компетенций сотрудников. Мы, как и вы, пытаемся управлять бизнесом. Считаем деньги, выработку, управляем задачами, что-то пытаемся делать с проектами, налоги вычисляем… Управляем всем, чем можно, кроме чего? Компетенций.

    То есть самым главным-то мы не управляем.

    Проблемы с компетенциями


    Первое. Мы только примерно представляем себе, о каких именно компетенциях идет речь. Конечно, если бизнес построен на выполнении одного-двух видов работ, то управление не требуется. А если видов работ – десятки, и сотрудников – сотни?

    Какие компетенции у нас уже есть? Каких не хватает? На какие мы даже замахиваться не смеем? А нашим клиентам какие компетенции нужны? Продукт новый мы можем сделать, имея только наши компетенции? А может, нам не хватает одной-двух компетенций, чтобы выйти на другой рынок?

    Второе. Мы плохо себе представляем развитость компетенций. Примерно, крупными мазками, мы понимаем: Коля – спец по реакту, а Вася хорошо пишет продающие тексты. А Гена? А ангуляром кто владеет? А по «Управлению холдингом» кто что умеет? Есть ли у нас компетенции по ERP? А то все ее продают, а мы в стороне. Вроде, Серёга что-то знает по ERP… Но что именно, и насколько качественно?

    Третье. Мы привыкли измерять получение компетенций прохождением курсов и наличием сертификатов. Хотя понимаем, что реальные компетенции рождаются только практической работой. Но, т.к. развитие компетенций не измеряем, приходится довольствоваться суррогатом – дипломами, курсами и сертификатами. Бесспорно, определенное влияние на компетенции получение бумажек оказывает, но это лишь стартовый импульс, за которым должно следовать применение теоретических знаний на практике. А в реальности что происходит с этим импульсом?

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

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

    Пятое. Бизнес часто зависит от компетенций. Иногда – очень сильно.

    Например, если есть сотрудник с уникальными навыками. Если он уйдет, может целое направление бизнеса закрыться, хотя бы на время.

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

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

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

    Шестое. Существует постоянно тлеющий конфликт между сотрудниками и бизнесом, в части компетенций. Человек, как правило, хочет «сидеть на теме» — освоить небольшой спектр компетенций, если получится – стать в нем экспертом, и забирать себе значительную часть работ по выбранным темам.

    Человеку хорошо, и бизнесу бывает неплохо. Но если компании нужно освоение новых компетенций? Для бизнеса это – риск, для человека – тем более. Особенно, если за освоение новых компетенций не доплачивают. Человек, банально, может остаться на хлебе и воде, исполняя стратегический план компании.

    Седьмое. Когда мы берем нового сотрудника, то варианта три. Если он – большой специалист или носитель уникальных компетенций, то все хорошо – мы взяли его целенаправленно, схантили, и затыкаем им какую-нибудь дыру, либо завязываем на него новое направление работы.

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

    А если он новичок, то на некоторое время попадает под пристальное внимание. Бывает, конечно, что мы просто говорим – вот компьютер, вот таск-менеджер, сиди работай. Но, как правило, у всех давно есть какой-нибудь курс адаптации и обучения. Мы прикрепляем к новичку наставника, даем теорию и задачи по выбранным компетенциям, и зорко следим за его успехами.

    Проблема случается, когда новичок прошел курс молодого бойца. Человек **растворяется** — в массе тех самых середнячков, муравьев бизнеса. Пока он был под прицелом, мы понимали его компетенции и управляли ими. Когда он влился, то стал, как все. Вроде, неплохой парень. А что умеет? Да черт его знает… Что все, то и он.

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

    Компетенции


    Для начала определяемся, что такое компетенции. Пусть это будет иерархический справочник. В нашем случае он выглядит так:



    Вообще, четких правил по заполнению этого справочника нет. Принципиально он должен решать три задачи:

    1. быть небольшим;
    2. описывать текущую картину компетенций – что у нас уже есть;
    3. описывать целевую картину компетенций – чего у нас еще нет, но оно нам очень нужно.

    Я, заполняя этот справочник, решил только первые две задачи. Целевых компетенций еще не придумал.

    Группы у меня получилось четыре. Главная – «Разработка», наш основной хлеб, будь то услуги или создание продуктов. Как вы, возможно, знаете, мы разрабатываем на двух платформах – 1С и metadata.js, а в качестве СУБД используем CouchDB. Отсюда и три основных компетенции в разработке.

    Можно было, конечно, разбить ту же разработку 1С на отдельные компетенции, вроде СКД, управляемых форм, работы с оборудованием и т.д. Но конкретно нам это не нужно – слишком давно 1С занимаемся.

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

    Тут я тоже решил не мельчить, и просто перечислил продукты и сервисы. Сюда же затесалась «Административная работа» — не знал, куда ее приткнуть. Ну и «Маркетинг», как вид работ – он мне показался больше методическим.

    Дальше – «Тексты и видео». Это писанина всех мастей и создание презентаций, видео, и т.д.

    Ну и «Администрирование» — у нас его не очень много, хотя компетенция очень важная, т.к. мы продаем аренду серверов.

    Шаблоны компетенций


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

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

    Например, вот так выглядит шаблон, которым я оценивал задачи по разработке 1Сной части Flowcon:



    Первая строка – разработка, вторая – методическая, третья – тоже разработка, т.к. Flowcon довольно много взаимодействует с сервисами и CouchDB.

    Ну а дальше – полный кайф. Почти весь поток задач по Flowcon я оценивал одним шаблоном. Сколько времени на это ушло – напишу в конце статьи.

    Приобретение компетенций


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

    Можно начислять компетенции за решение задач. Можно – за продажи, или за прирост эффективности, за прохождение курса, за снижение дебиторки, за вовремя сданную отчетность, или просто так.

    Мы для себя решили, что будем начислять компетенции только за решенные задачи.

    Принципиально в решении есть три способа начислить компетенции:

    1. перечислить их в решенной задаче;
    2. перечислить их в произвольном объекте;
    3. начислить автоматически, ничего нигде не перечисляя.

    Кратко пробежимся по способам начисления.

    Компетенции в задачах


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



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

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

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

    Компетенции в произвольных объектах


    Быстро стало понятно, что недостаточно указывать компетенции только в задачах. Во-первых, не все пользуются именно флаконовскими задачами. Во-вторых, если начали пользоваться задачами вчера, как быть с компетенциями, полученными за предыдущие периоды?

    Причем, проблема прошлых периодов актуальна и для нас. Задачами во Flowcon мы пользуемся с ноября 2018 г., до этого был гитхаб с загрузкой в 1С. Не хочется терять такой объем данных о компетенциях.

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



    Внутри – уже знакомая табличка с компетенциями. Точно так же можно указать шаблон.



    И так – для любого объекта, который мы посчитаем носителем задач.

    Автокомпетенции


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

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

    Технически управление автоматическим начислением компетенций управляется справочником «Автокомпетенции». Он прост и скучен – надо лишь указать схему компоновки, и взвести флаг использования автокомпетенции.



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

    Преимущества такого подхода очевидны. Компетенции – такая вещь, с которой постоянно нужно «играться». Мы просто меняем схему компоновки, и получаем новые данные.

    Еще одно применение такого подхода – моделирование разных систем оценки. Можно изготовить два, или три разных варианта автокомпетенций, и посмотреть на одни и те же данные под разным углом.

    Оценки и периоды


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

    Другим людям никто не мешает оценивать компетенции в любой другой единице. Например, в часах и рублях. Достаточно указывать в поле «Оценка» то, что нужно. Какую бы единицу вы не выбрали, она все равно будет понятна только вам. Главное – динамика.

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

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

    Износ компетенций


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

    Вот это «убывание» компетенций мы решили назвать износом.

    Получается, нам нужны две величины – скорость износа и величина остатка. Эти параметры хранятся в настройках.



    Зная, что оценки компетенций у нас относительные, скорость износа и остаток можно выразить только в процентах – так мы и сделали. Главный вопрос – какие цифры поставить?

    Если честно, не знаю. И спросить не у кого. Да и незачем. Скорость износа можно определить по практике. Я выбрал 50 % в месяц – по моим наблюдениям, через два месяца вспомнить компетенцию уже достаточно сложно. В качестве остатка выбрал 10 %.

    И вот у нас есть две величины – приобретение компетенций (приход) и износ компетенций (расход). Не хватает третьей – остатка.

    Остаток – это самое крутое в компетенциях. Это «несгораемая сумма», реальный багаж знаний, доступный без предварительной подготовки. Если угодно, это ПЗУ специалиста. Именно такие компетенции человек использует максимально эффективно – просто садится и делает.

    Или по-другому: остаток компетенций – это как накопления в банке, или надежные инвестиции. Получил доход, отложил 10 %, а остальное – потратил зря. Ну, то есть, не зря конечно – надо же питаться, одеваться, развлекаться и т.д. Но в перспективе, затраты текущего периода особой роли не играют, не делают вклада в будущее.

    А инвестиции – наоборот, работают на будущее. Как и остаток компетенций.

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



    Скорость ввода данных


    Разработав систему учета компетенций, мы начали применять ее на себе. Я, зная, что скорость работы с компетенциями имеет решающее значение, сделал замеры – количества задач и времени.

    Итак:

    1. я заполнил компетенции в 3 000 задач (это примерно за полтора года, на двоих);
    2. одновременно я заполнял справочник компетенций, шаблонов;
    3. параллельно я исправлял обнаруженные ошибки;
    4. решил не использовать автокомпетенции, т.е. все объекты обработал вручную;
    5. все это я сделал за 6 часов.

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

    Но итоговая цифра меня порадовала – примерно 7.2 секунды на задачу. Время грязное – с учетом перекуров, чаепитий, открытия и записи объектов.

    3000 задач за полтора года – это примерно 8 задач в день на двоих. При наличии заполненного справочника компетенций и настроенных шаблонов на весь учет будет уходить 57 секунд в день. Шикарно.

    Профили компетенций


    Учет – это хорошо, но надо и управлять, в том числе компетенциями. Учет дает понимание текущей картины, насколько развиты те или иные навыки, каков остаток, в каком направлении и с какой интенсивностью идет динамика.

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

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

    Все это, по-русски, называется «планирование», которое есть основа управления. У нас для компетенций можно планировать два параметра – объем (=оценку) и баланс.

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

    Например, я решил изменить свой текущий баланс компетенций и написал для себя целевой профиль:



    Другой пример – решили мы нарисовать профиль разработчика. Оценки нас, допустим, не интересуют – только баланс. Его и заполним:



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

    Оценка соответствия профилю выполняется в отчетах.

    Отчеты


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

    Когда накопится практика работы с системой, сделаем новые отчеты.

    Отчет «Компетенции»


    Это – самый универсальный отчет. Он просто выводит данные о полученных компетенциях за период. Собирает отовсюду – из задач, произвольных объектов и автокомпетенций.

    Вот мои компетенции за полтора года:



    Что тут видно? Ну, меня видно – см. верхний левый угол. Видно иерархию компетенций. Видна оценка – приход навыков за полтора года. Износ рядом написан – сколько компетенций улетели в трубу естественным образом. Остаток с учетом износа – видно, что он намного ниже прихода.

    Кстати, на картинке данные отсортированы по убыванию остатка, и получается забавная картина – приход по писанине больше, чем по разработке, а остаток – наоборот. О чем это говорит? Я последние пару месяцев сильно увлекся разработкой, и эти компетенции еще не успели улетучиться.

    Ну и две группы колонок фактического баланса. Одна показывает процент в текущей группе («Разработка», «Методические» и т.д.), другая – в общей массе.

    Проверим мою гипотезу о том, что в последнее время я разработкой увлекся. Ограничим период прошлым месяцем:



    Ну да, 70% — разработка. Посмотрим без сотрудников, по всей компании за полтора года:



    Чудесно. Все-таки, мы больше разработчики, чем писатели.

    Отчет «Диаграмма компетенций»


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

    Для вывода информации в графическом виде мы сделали отчет «Диаграмма компетенций». Вот, например, профиль остатка моих компетенций за полтора года:



    Или гистограмма компетенций всей компании по верхнему уровню иерархии:



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



    Можно сравнить компетенции людей в графическом виде:



    А можно детализировать и сравнить компетенции, относящиеся только к разработке:



    Из этого сравнения очевидно, почему я в своем целевом профиле поставил почти 20 % разработки на metadata.js. Кстати, о профилях.

    Отчет «Соответствие профилю компетенций»


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

    Посмотрим, насколько я соответствую профилю компетенций, который сам для себя составил:



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

    Для примера я составил профиль абстрактного сотрудника – разработчика, который мог бы у нас работать. И проверил себя на этом профиле:



    Пф… Что ж я за человек-то такой… Все, завтра начинаю новую жизнь.

    Итого


    Реальность, к сожалению, ужасна. Компании нужно одно, сотрудники делают другое. И я – в том числе.

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

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

    Вы как хотите, а я буду меняться. Начну с себя.

    P.S.


    Чуть не забыл. Всё это на 1С сделано, за что мне, конечно, стыдно. В вашем таск-менеджере наверняка всё это можно сделать проще и быстрее.
    Поделиться публикацией

    Комментарии 24

      +1
      скорость износа и остаток можно выразить только в процентах – так мы и сделали. Главный вопрос – какие цифры поставить?

      Если честно, не знаю. И спросить не у кого. Да и незачем. Скорость износа можно определить по практике. Я выбрал 50 % в месяц – по моим наблюдениям, через два месяца вспомнить компетенцию уже достаточно сложно. В качестве остатка выбрал 10 %.

      Эмпирическое правило — если использовал компетенцию всего месяц, то и забудешь через месяц неиспользования. Если год — то через год. Ставить константу в 2 месяца — как-то сомнительно.
        +2
        мне кажется, тут любая цифра будет сомнительно. Я решил так — что-нибудь поставлю и успокоюсь.
          +1
          А целевой профиль — он же у вас из того же источника (от фонаря ;), не правда ли? Почему там администрирование 5%, а не например 50? Откуда это следует?
            +1
            целевой профиль — из стратегии развития бизнеса.
              +3
              И каким образом 5% администрирования позволяет реализовать стратегию? Поверьте, это вопрос с далеко не очевидным ответом.

              Вот у нас в компании к примеру решили, что нужно повышать компетенции сотрудников. И сказали всем: мы вас научим а) тестированию б) devops в) разработке. То есть, все должны стать более-менее универсалами. Если спроецировать на ваше решение, то это целевой профиль типа 30%, 30%, 40%, например.

              Проблема в том, что на самом деле люди разные.

              >Шестое. Человек, как правило, хочет «сидеть на теме» — освоить небольшой спектр компетенций, если получится – стать в нем экспертом, и забирать себе значительную часть работ по выбранным темам.

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

              А что на самом деле хорошо для бизнеса — далеко не очевидно.
                0
                Что хорошо для бизнеса — это не знание, а решение. Стратегия не ищется, а разрабатывается.

                Она вполне может оказаться неудачной, и станет полезным опытом.

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

                Текущих компетенций по администрированию вполне достаточно, чтобы обслужить в 2-3 раза больше клиентов. А вот для того, чтобы создать в 2-3 раза больше продуктов, компетенций не достаточно. Их и надо развивать.
          +1
          Я подозреваю, что начиная с некоторого уровня, даже остатка после многих лет забвения будет более чем хватать.
            0
            да, я согласен
          +1
          Если все вот это собственное изобретение — очень круто (несмотря на то что автор изобрёл велосипед), если это такое своеобразное переложение ITIL, то как-то все коряво кучеряво.

          Сам подход к управлению компетенциями — верен, но то что он привязан только к задачам, как-то странно.
          Предполагаем, что мы имеем CMDB, где есть дерево конфигураций. Одна ветвь конфигурационных элементов — активное и пассивное сетевое оборудование, LAN, WAN и прочие СКС. Другая ветвь — разнообразное пользовательское железо — АРМы как тонкие так и толстые, принтеры, плоттеры, телефоны, и прочее, если угодно то вплоть до табуреток (эммм… все зависит от подхода к построению дерева конфигураций). Третья ветвь — стойки, сервера, лезвия, возможно даже вся около-серверная инфраструктура — чиллеры, ИБП, железо от СКУД и т.п. Четвертая ветвь — инфраструктурная шина: единая служба каталога, почта, мониторинг, резервирование, бэкапирование и тому подобное. Пятая ветвь — уровень приложений — всякие бухгалтерии, ERP, CRM SCOM, SCCM и прочие IDM.
          Каждая из ветвей ясен фиг декомпозируется, железо до процессоров и гигов ОЗУ/ПЗУ, софт до конкретных программных модулей, библиотек, интеграций. Степень декомпозиции зависит от желаемой степени например мониторинга того или иного элемента конфигураций (но вообще, принцип декомпозиции может быть завязан не на мониторинг, а на что-то другое).
          Ах да, пусть шестая ветвь конфигурационных элементов пусть будет Компетенции. Которые в соответствии с DevOps декомпозирется на под-ветви — Разработка, Тестирование, Администрирование (ну или не по принципу девопса, этих принципов вагон). Каждая из подветвей заполняется соответсвующими конфиг.элементами: в Администрировании мы забиваем компетенции по администрированию ОС, СУБД, наших серверов приложений, ну и т.п. Аналогично — в Тестировании: регрееcс, UI, секьюрити и т.п.
          А дальше мы привязываем каждую из компетенций к юнитам ранее описанных ветвей — к сетям, железу, инфраструктурной шине, и т.п.
          А дальше мы каждой компетенции присваиваем признаки ЗУНС: компетенцией можно обладать на уровне Знания (чо то слышал о том как это делать), Умения (уже делал однажды, имею опыт), Навыка (делал много раз, опытный типа), Способность (вот ваще гуру по этой теме, пьяным меня разбуди всё равно сделаю).
          Дальше по каждому элементу сетевой, железячной, софтовой и иным ветвям CMDB определяем SLA, который описываем в терминах доступности, надежности, времени реакции, времени исправления и т.п.
          Наконец, берём сферического эксперта по каждой ветви CMDB и с помощью его экспертных оценок определяем исходя из SLA сколько и какого качества (ЗУНС) людей нам надо для планового девопса.
          Вуаля — полный цикл, каждый элемент CMDB связан с элементами из других ветвей.

          Тут вот я описал подход описанный во всяких там умных книжках.
          И я знаю несколько отечественных контор которые вот это всё сумели внедрить и сейчас счастливые пользуются скромно шаркая ножкой скажу что в некоторых из них это сделано с моим участием.

          Но мыслит автор правильно.
            0
            … ну и нахрена я эту простыню писал, если ни одного слова под ней, и непонятно — согласны читатели с моим опытом, или против.
              0
              Я прочёл, впечатлился, согласился, посмотрел на ваши другие комментарии, и подписался на вас. Буду ждать статей.
              0
              Как быть с вариантом: Делал много раз, но это было десять лет назад? Или в Вашем комментарии навыки статичны и не изменятся со временем в плюс или минус?
              Как я понял, статья именно про развитие компетенций человека, как часть стратегии развития бизнеса.
                0
                It depends on…
                Я много раз разбирал и собирал москвичевский и жигулевский ДВС, когда мне было 14-16-18 лет. С тех пор прошло больше четверти века, за которые я ни разу не разбирал ДВС. Но если завтра мне скажут разобрать-собрать именно жигулевский ДВС образца 85 года — я сделаю это без проблем.
                Но если меня попросят разобрать-собрать современный TFSI — большой вопрос смогу-ли. Разобрать-то смогу. Но вот дефектовать и собрать так чтобы заработало — не знаю.

                Другими словами, если за 10 лет среда (инструмент, окружение) не поменялось — да, Навык не утерян.
                Но такого не бывает, потому что среда меняется постоянно.
                  0
                  За сколько времени Вы разбирали-собирали жигулёвский ДВС в 18 лет? И сколько на это уйдёт сейчас? Вот в чём разница.
                  Исходя из способа описанного в статье — Ваша компетенция по разборке-сборки упала. В реальности то-же самое — Вы не забыли всё, у Вас просто уйдёт больше времени (тот самый минимум из статьи). Исходя из Вашего комментария — временной отметки у ЗУНС нет и это влияет на стратегию развития бизнеса — либо взять того, кто сейчас разберёт двигатель за час. Либо взять Вас и Вы его разберёте за три часа.
                  В статье не сказано напрямую, но по мере постоянного набирания опыта, скорость падения забывания уменьшается и увеличивается уровень незабывания (Ваш опыт работы с жигулёвскими ДВС).
                  В Вашем же ЗУНС нет отражения временной характеристики — либо З, либо У, либо Н, либо С. Соответственно, когда человек из З превратится в С в Вашей схеме неизвестно. Будет просто факт — был З стал С, если интервал проверки слишком большой. А если проверок нет, то информация явно устарела и причём давно, и не актуальна, и уже вредна для бизнеса, так как на её основе будет принято неверное решение по поставленной цели.
                    0
                    Те системы которые строились с моим участием действительно не имели коэффициента потери компетенции по времени. Я тогда не задумался почему архитекторами и аналитиками этого не было введено. Зато подумал сейчас.
                    Предполагаю следующее:
                    1. На момент старта CMDB и ее окружения, после заполнения БД выявлялся профицит или дефицит тех или иных компетенций.
                    2. Далее, отклонения выравнивались, чтобы наиболее соответствовать OLA/SLA.
                    3. Далее, при появлении в CMDB новых уникальных юнитов модель компетенция расширялась (например был внедрен SAP, значит нужен админ, нужен аналитик со знанием ABAP и т.п.); в случае количественного роста юнитов (например расширение сетевой инфраструктуры) принималось решение о соответствующем расширении нужной компетенции;
                    4. Предполагается, что любая актуально востребованная компетенция используется. Сети и сервера проходят регламентное и прочее обслуживание, как и все иные юниты CMDB. Другими словами — невостребованных «прозапас» компетенций нет, и нечему протухать. Если мы вывели из прода какой-то элемент инфраструктуры, то и удалили (перевели в архив) соответствующую компетенцию.
                      0
                      Всё, что Вы говорите — верно. Оно верно, когда используется ITIL/ITSM используется внутри компании. В таких случаях и не нужно смотреть постоянно за компетенциями сотрудников. Но когда это разработка ПО, то тут компетенции важны. Даже если это ИТ-аутсорсер работающий по ITSM, со всеми CMDB/SLA/OLA и прочим, то тут тоже компетенции важны, так как есть текучка, нужно уметь выбирать из претендентов, следить за ними. Компетенции и рост сотрудника важны и в магазине, где есть контакт с покупателем в виде консультации.
                      На заре моей молодости пришлось делать нечто подобное описанному в статье для продавца в компьютером магазине. Это было интуитивно, без анализа. Просто был экселевский файл, по которому я следил за зелёными стажёрами.
                        +1
                        Да, все верно пишите.
                        Управление компетенциями возможно тоько в процессно-ориентированных задачах. Все что связано с operations / services — вперед и с песней управляем (в том числе, например в управлении релизами, управлении тестированием, качеством, доступностью).
                        Управление компетенциями в чистой разработке это единорог. В приницпе недостижимая цель.
                        Потому что перед разработчиками ставят уникальные задачи, в реализации той или иной функции, интерфейса, структуры БД и т.п. — те задачи, путь реализации которой становится ясен по ходу реализации и определение трудозатрат на ее решение это особый вид искусства апроксимации и умножения названной цифры на число Пи, с гаданием на кофейной гуще «а как оно там на самом деле будет» по ходу реализации.
                        Я далек от мира 1С, поэтому могу только предполагать чем там занимаются разработчики. Предположу, что это разного рода кастомизации типовых форм отчетов, интеграция черз имеющиеся API с другими учетными системами и тому подобное. То есть все же не разработка в том виде, котором все привыкли. Именно поэтому Автор взялся и возмжно вполне успешно решил задачу управления компетенциями конкретно в этой экосистеме, если у тебя список задач, список автоматизируемых функций которые можно менять, окружение, workflow и тп — постоянно одно и тоже, то почему-бы действительно не записать все это в тетрадку раз и навсегда.
                          0
                          Управление компетенциями возможно только в процессно-ориентированных задачах
                          — да, мы, процессоры, на основе модели компетенций не только процессы рисуем, но и генерим от должностной инструкции до описания вакансии.
              +1
              Вспоминая материал автора про время написания статей — а вот эта статья тоже за пару часов на коленке написана?
              Автор, сознайся, ты себя клонировал?
                0
                эта статья относится к компетенции «Техническая писанина», а она у меня развита слабо. В итоге, я провозился с ней часа четыре.
                +1

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


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

                  –1
                  Конкретно этот инструмент относится к Flowcon, который, в свою очередь, реализован одновременно на двух платформах — 1С и metadata.js (которая — на javascript).

                  1С выбрана не потому, что я ее знаю. Методика управления, заложенная во Flowcon, говорит, что задачи, проекты, показатели должны жить там, где лежат исходные данные. А исходные данные у большинства лежат в 1С.
                  0
                  Любопытная статья, прочел с интересом. Спасибо.

                  Большинство задач, так или иначе, несложно стратифицируются на потоки

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

                    Главный айтишник
                    image


                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое