Всем привет!
Поделюсь своими размышлениями о “дребезге” и попробую разобраться в его причинах.
Пример 1. “Размытая” эффективность.
На работе мне нужно создать школу менторов в ИТ компании. Чтобы понять, чему мы хотим научить менторов, мы решили составить список навыков, которыми они должны обладать. Один из пунктов был сформулирован так: ”Ментор должен уметь разрабатывать эффективные учебные планы (ИПР)”. Здесь у меня возникает ощущение “дребезга” из-за неясной референции. Не понимаю, что имеется в виду под “эффективным учебным планом”.
Учебный план входит в сферу интересов как минимум трех ролей: ментора, менти и заказчика обучения (например, руководителя отдела). В общем случае предпочтения у каждой роли будут отличаться. Например, ментору нужно, чтобы учебный план имел такое содержание, которое позволяет менти выйти на нужный уровень навыков в практической деятельности. Менти нужно, чтобы время проведения занятий и интервалы между ними позволяли ему двигаться в нужном темпе и закончить курс вовремя. А заказчику может быть важно, чтобы бюджет на обучение и средняя длительность обучения позволяли ему решать задачи бизнеса и обеспечивать квалифицированными ресурсами проекты клиентов.
В текущей формулировке неясно, что именно понимается под эффективностью? Предпочтения конкретной роли, например, заказчика обучения, или всех трех ролей? Чьим предпочтениям будет отдаваться приоритет, если по каким-либо причинам удовлетворить всем предпочтениям невозможно?
Назначил встречу для уточнения референции. В итоге договорились с автором, что термин “эффективный” относится не к учебному плану, а к процессу менторства. Учебный план сам по себе не может гарантировать результативность и эффективность обучения, какую бы интерпретацию эффективности мы не при этом не использовали. Решили, что учебный план должен быть сбалансированным с точки зрения предпочтений всех ролей, договорились о правилах управления приоритетами в случае конфликта предпочтений. Критерий эффективности к учебным планам не применяем, а формулируем конкретные критерии успеха для процесса менторства на основе учебных планов.
Пример 2. Два типа CTO.
Я работаю в относительно небольшой ИТ компании и у нас пока нет выделенной должности CTO (технического директора) и сотрудника, который эту должность бы занимал. В прошлом была попытка подобного назначения, но она не увенчалась успехом, потому что мы неправильно подобрали человека. В последние месяцы мы все острее ощущаем нехватку такого специалиста, потому что задачи накапливаются быстрее, чем мы с ними справляемся. И вот снова стали обсуждать найм CTO.
В этих обсуждениях у меня возникло ощущение “дребезга” и я попробую разобраться в его причинах. Есть два типа CTO, которых я встречал в опыте.
Первый тип - с глубокой и широкой технической экспертизой, такой Senior Architect & Developer в одном лице. У такого типа очень хорошо получается демонстрировать экспертизу в сложных технических вызовах, они прекрасно справляются с работой такого рода, но есть важная особенность - им нравится общаться с машинами больше, чем с живыми людьми. Люди скорее раздражают и утомляют их своей иррациональностью и плохо предсказуемым поведением.
Второй тип - тоже обладает хорошей технической экспертизой, как правило, несколько слабее, чем у первого типа, но все еще много выше среднего уровня. И у второго типа есть важная особенность - они склонны к общению с сотрудниками, им важно, как работают технические стандарты и решения в реальности, и они чаще сталкиваются с необходимостью выстраивания практик на группе сотрудников.
Так вот “дребезг” возникал потому, что на нескольких встречах CEO регулярно переключался с одного типа на другой, используя при этом один и тот же термин CTO. Из-за этого, например, рекрутеры никак не могли понять, кого мы все-таки ищем, каким опытом должен обладать этот сотрудник?
Когда это стало ясно, я попросил уточнить, что он имеет в виду, когда говорит про CTO? Итогом этого обсуждения стала явная договоренность, что мы рассматриваем CTO второго типа, который сможет выстраивать практики и внедрять стандарты в производство, который умеет влиять на поведение сотрудников. Отдельно разобрали класс ситуаций, в котором он переключался на первый тип CTO и поняли, что для решения этих задач нам нужен не CTO, а архитектор решений.