Как аккуратно войти в матрицу компетенций: что писать в скиллы?

Ключевая фигня с матрицей компетенций - что писать в скиллы.
Первый подход к снаряду - а давайте напишем то, чему реально нужно научить новичков? Получаем монстра типа такого: https://reqcenter.pro/wp-content/uploads/2017/05/competency_model.jpg
Тыкаемся-тыкаемся, и всё время обнаруживаем, что оценка весьма поверхностная. Сотрудники - разные, они прошли разную историю проектов. А если это ещё и хардкорные инженеры, а вы только-только пробуете запустить оценку - словите кучу троллинга в свой адрес.

Окей, давайте обощим!
Получаем что-то типа https://www.intervolga.ru/upload/medialibrary/cfe/cfe1b345b0493bfe34d7080dc7f766cd.png
Конечно, пример утрирован, чаще всего приходят к чему-то вроде такого: https://docs.google.com/document/d/1FVvoSY35YD4BfAkv-XYGRITFbE17pA7A-R6S76UVsBQ/pub
но проблемы останутся:
- часть реально имеющихся навыков пролетят мимо вашей картинки
- что-то будет слишком общим для вашей реальности
- субъективность оценки для "общих" вещей будет зашкаливать

и, самое плохое: выводы из полученной таблицы будут типа ну, Вася, надо тебе подтянуть MySQL.
Что - mysql? Что подтянуть? Нахрена, если в реальной практике у инженера не будет таких задач? Знания, курсы и навыки, которые не востребованы будут забыты уже через две недели.

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

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

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

Про длинные согласования документов
Не знаю, как вас, а меня вымораживают долгие согласования документа с кучей народа. Но иногда это не обойти, не объехать.
И вот идёт третья неделя, энная итерация правок. Оставим за бортом повествования вопрос "как не сойти с ума" - гораздо важнее "как дотащить это быстрее до конца?". Люди, с которыми нужно согласовывать-то уже тоже устали, у них появились другие *очень важные дела*, скорость коммуникаций падает, собирать всех на встречи по N раз в неделю - больно и бессмысленно.

Есть хорошее заклинание, которое можно применять в этот момент: Привет. В документе важные правки в главах <перечисление>. Ты поучаствуешь?. Разберём его:
- да, занятым людям надо давать summary изменений. Кратко.
- Не правильно говорить ответь, не правильно рассуждать о сроках, если вовлечения нет. Не правильно ждать согласования от невовлечённых людей. Правильный вопрос - вопрос о вовлечении.

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

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

Есть только проблема: в вашей голове нет картинки в динамике. Не может быть. Вы "помните" ощущение человека на текущий момент. Очень невнятное и без подробностей. И если он накосячил недавно - это будет перекрывать всё сделанное добро раньше.

Как расширить свои познания?

У вас уже есть все записи. Откройте, чёрт возьми, трекеры задач и времени за последние 3 месяца, почитайте. Пройдитесь по чатам, переписке. Если ваша команда не упоролась по тезису управление через коммуникации в ущерб здравому смыслу, то трекеров и чатов хватит на то, чтобы сформулировать 5..10 тезисов для обсуждения с сотрудником.
Скорее всего они разделятся на:
- то, за что хочется похвалить/поблагодарить
- то, что является проблемой
- то, что является непоняткой

Возможно ваши формулировки будут вида Вася, про тебя говорят, что ты мудак. Постарайся быть меньше мудаком. Иди работай, короч. Если это так - немедленно прекратите быть собой!
О том, как правильно давать фидбэк - смотри пост от 25 сентября.

О беспощадном найме
На хайлоде 2018 завернул к одному из стендов - так просто, поговорить, познакомиться чисто по-человечески. Сам два дня стоял на стенде, хочется пообщаться с собратьями по приключению.
И встречает меня Она - Беспощадный HR. Женщина не теряла много времени: сразу ткнула в список вакансий на мониторе и спросила - подхожу ли я под какое-то из определений.
Уклончив был мой ответ, как шелест камыша от утреннего ветерка: "Возможно", - говорю, намекая на неуместность такого формата общения.
"Тогда ты должен немедленно уволится и идти работать к нам" - безапеляционно поставили меня перед фактом.

Не надо так.

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

Меньшинство не должно подчиняться большинству. Начальник не должен принимать решение только из-за субординации. Как это ни удивительно - группа *может прийти к согласию* и это будет гораздо более ценно.
"Прийти к согласию" означает, что
- вы и ваше мнение не должны и не имеют права быть проигнорированы
- вы (как и любой участник) обязаны отстаивать свою позицию и доносить её до остальных
- вы (как и любой участник) обязаны слышать аргументы других людей
- группе (возможно с помощью какого-то модератора/фасилитатора) нужно уметь удерживаться в рамках конструктива, выходить из зацикливаний на узких темах и задавать правильные вопросы ("а почему это важно?", "а есть ли проблема?" и другие)

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

В фейсбуке наткнулся на интересную заметку про перенос — психологический феномен, заключающийся в бессознательном переносе ранее пережитых (особенно в детстве) чувств и отношений, проявлявшихся к одному лицу, совсем на другое лицо.
https://www.facebook.com/v.denisenkov/posts/1963309377095410
Особенными красками история про перенос начинает играть при принятии решений группой. Если у участника команды, принимающей решение, бомбанул перенос - его зачастую начинает зацикливать на рационализации (https://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F_(%D0%BF%D1%81%D0%B8%D1%85%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F) ) . Для обоснования своих страхов/переживаний/флэшбэков из Въетнама придумываются любые псевдо-рациональные аргументы.

А: Почему тебе не нравится этот чувак?
Б (смотрит на этого чувака  в синей шапке с золотым зубом, чувствует страх и отвращение и начинает рационализировать это ощущуние): его ответы не компетентны, и вообще он опоздал на встречу и с такими людьми плохо иметь дело

Проблема ли это? Да.
Как её преодолеть? Верить в себя и свою позицию, быть открытым и готовым услышать, рефлексировать. Учиться четко строить сложные логические цепочки, например, с помощью шахмат или сложных логических игр на мобильнике, чтобы отличать надуманные аргументы от реально вытекающих друг из друга.

Столкновения с реальностью пост
Подсунули мне тут книгу Голдратта "Цель". И вот там прямо написаны те вещи, которые на айтишных конференциях начали озвучивать года два как. По сути - про этот самый devops, разрушение оков и ускорение процессов во имя получения результатов asap.
Ключевое отличие книги от обсуждений в народе: в книге есть фундаментальное обоснование, из которого можно вывести все остальные принципы. Народ же в основном размахивает трусами и дерётся за терминологию, вместо сути.

Читаю, значит, и думаю попутно: "Интересно, книга написана по мотивам движухи за devops и agile, или наоборот, движуха поднялась по мотивам книги?". А потом вижу прекрасное: книга написана в 1984 году.

Патриотизма пост
Министерство связи теперь хочет Не включать программное обеспечение, базирующееся на программных продуктах иностранного происхождения в части СУБД, серверов приложений и платформ, в Реестр и в ближашие 6 месяцев избавиться от такого ПО (https://www.kmis.ru/blog/ekspertnyi-sovet-minkomsviazi-rekomendoval-razrabotchikam-v-techenie-6-mesiatsev-otkazatsia-ot-ispolzovaniia-obshchesistemnogo-inostrannogo-po/)
Я не работаю в минсвязи, но множество опенсорс-проектов выглядят как попадающие под это определение.

Вишенка на торте - сломанный https сертификат на сайте минсвязи.

Пару лет назад в народе ходила шуточная классификация менеджеров вида:

## Чайка-менеджмент
В случае опасности менеджер начинает громко хлопать крыльями, орать и срать во все стороны.
Рациональных действий при этом не делается.

## Сова-менеджмент
Менеджер приходит с вопросом, слушает ответ, и приговаривает "угу, угу".
Уже позже выясняется, что он не понял ни единого слова.

## Варан-менеджмент
Менеджер подходит и молча смотрит пока человек работает.

## Золотая рыбка-менеджмент
Менеджер договаривается, берёт на себя обязательства, но уже через 2-3 минуты начисто забывает всё, что было сказано.

Наконец-то умельцы собрали всё и обгадили всех, а не только менеджеров: https://people.neilon.software/

Давайте становиться лучше :)

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

Чего больше всего хочется от workflow задач именно вам?
anonymous poll

Прозрачности, т.е. отсутствия необходимости объяснять одно и то же два раза – 36
👍👍👍👍👍👍👍 40%

Поиск узких мест для ускорения релизов – 25
👍👍👍👍👍 27%

Унификации, чтобы не было разброда и шатания при росте – 11
👍👍 12%

Сделать действия команды более профессиональными – 11
👍👍 12%

Иметь гарантии и возможность их давать – 8
👍👍 9%

👥 91 people voted so far.

хорошие, прозрачные задачи
Что сделать, чтобы вас поняли? Написать текст. Но текст можно интерпретировать по-разному и придётся использовать чуть больше слов, чтобы тебя поняли точнее.
Если вы немного подумаете перед тем, как писать - то будете использовать максимально конкретные, сенсорные слова.

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

Вы знаете много способов жонглировать словами: попсовый SMART, модель TOTE, user stories и другие страшные слова.
Но есть одна сложная мысль, которую надо подумать:
Прозрачность достигается, когда отчуждена та информация, которая нужна, но не более того. "Где она, эта грань и зачем именно там?" - вот важнейший вопрос.

Вообще говоря, я несколько обескуражен результатами опроса и в то же время их, отчасти, понимаю.
А обескуражен из-за хайпа вокруг ускорения релизов.

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

Целью продуктовой работы могут являются хорошие, продуманные гипотезы. Фигачить быстро рандомные, недодуманные вещи не может быть стратегией развития. Ошибки согласованности изменения могут загубить прекрасную гипотезу.

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

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

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

И вы, конечно, знаете, что происходит потом: сначала нотификации включают, а когда в почту начинает валиться 100500 писем в час — отправляют их все в корзину.

Плохи ли нотификации? Нет, это прекрасный инструмент.
Но они должны быть только там, где они на самом деле нужны.

Если вы PM и получаете информацию о переходе из статуса X в статус Y на ежедневном митинге — именно эта нотификация вам не нужна.
Если вы инженер, задача назначена на вас и кто-то зафиксировал то, что вы только что обсуждали — этого письма не должно приходить в почту.

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

Что делать, если твой начальник - эффективный менеджер. Как сова из известного комикса.
ты такой начитался умных статей, пришёл к нему с идеями про эффективность, а он тебе от ворот поворот.

- Если мы сделаем автоматизиацию %idea% - нам будет лучше жить!
- А ты посчитай в деньгах, сколько конкретно нам нужно на разработку, составь ТЗ, план, посчитай экономическую эффективность, прикинь когда и кем мы это делать будем - и тогда приходи.

ну или более классическое

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

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

С наступающим!
Пусть у вас горит огонь в душе, но не пригорает задница.

А между тем, 26 апреля на площадке "Инфопространство" пройдёт конференция KnowledgeConf.

Если вам не безразличны:
- knowledge sharing
- культура непрерывного обмена знаниями
- технологии и методы обучения
- практические кейсы онбординга, организации базы знаний и внутреннего университета
- приёмы фиксации архитектурных решений, внутренней документации о продуктах и процессах
то следите за новостями, этого добра будет у нас ;)

А если вы хотите выступить - добро пожаловать: https://conf.ontico.ru/lectures/propose?conference=kc2019

Если вы серьезно лезете в управление знаниями - готовьтесь погружаться в устройство поиска и natural language processing. Сейчас обосную, как я пришел к этому тезису.

Очевидно, что знания - уже есть. Они гуляют туда-сюда по каналам коммуникаций: слакам, трекинговым системам, обрывочным вики и гугл-докам. Когда у вас возникает вопрос в стиле "кто сделал эту хуйню на главной странице и зачем?" - вы хотите увидеть весь материал со всех контентных систем.
Не обязательно держать кучу техписов или стегать разработчиков кнутом и пряником, чтобы они начали писать статьи в базу знаний. Перспектива загнать коммуникации в жёсткие правила - это, увы, утопия.

Пофантазируйте: вы заходите во внутренний сервис, вводите вопрос, который вас волнует, в формулировке, которая вас волнует - и получате выдачу в лучших традициях поисковиков. С расширенными сниппетами в стиле "Яндекс. Островов", быстрыми ссылками и прочими радостями.

Во Флант мы успешно делаем нечто подобное, сервис ищет по git-репозиториям с markdown, хабру, slack-у, а также issue и mr-ам gitlab-а. Это оказалось дико полезно и удобно.