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

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

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

Не нужно делать много, нужно делать то, что нужно делать. А так как последнего мы не знаем наверняка - надо пробовать.

Не ходи в историю с матрицами компетенций.
Не ходи в историю с матрицами компетенций.
Не ходи в историю с матрицами компетенций.

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

Матрица компетенций нужна крупной корпорации, чтобы на 1000+ сотрудников понять "а чо там вообще происходит". Пытаться сделать некий высер на 10..100 сотрудниках-айтишниках, в разрезе по технологиям/фреймворкам/уровням компетенций - обречённая история.

Хочешь опровергнуть? Стучись: @i_tsupko

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

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

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

2. Цель руководителя (который обязан быть на перфоманс ревью!) - узнать у самого сотрудника, А ЕСТЬ ЛИ ПРОБЛЕМА?
Если у руководителя представленные факты вызывают боль - так и надо об этом сказать, но выводы о том, есть ли проблема или нет - должны родиться именно в процессе перфоманс ревью.
До момента этого совместного обсуждения проблемы нет. Поступившие вам факты могут быть ложными и картинка может быть не полной.
Если же факты серьёзные, а сотрудник уходит в тупую отказку - руководитель всегда может сказать я всё-таки считаю, что это проблема. Но если сотрудник с этим не согласится - грош цена вашему ревью, положительных изменений вы не добьётесь.

3. После того, как вы согласились о существовании проблемы вы вместе должны прийти к возможным путям решения. Причём сначала эти пути решения должен предложить сотрудник, а только потом, сугубо в сослагательном наклонении и с расшаркиваниями - руководитель. Не правильно: это решается вот так. Правильно: если позволишь, добавлю ещё свой взгляд. Я бы решал проблему вот так и так.
Конечно же, это должны быть максимально конкретные шаги.
Плохо: не ругайся на клиентов матом. Хорошо - прийти к причине, почему человек плохо себя контролирует/считает, что мат в переписке с клиентами это ок. Докопаться до психологических поведенческих паттернов. По необходимости - провести в ближайшие 2..3 недели серию обучалок. По необходимости - уделять внимание поведению сотрудника в ближайший месяц и хватать его за руку. По необходимости - просить сотрудника когда он чувствует, что что-то идёт не так приходить за помощью.

Это кажется трудоёмким, но это единственно честный способ действительно прийти к изменениям, а не уповать на удачу и "ненуачо, мы ж людей наняли за большие бабки, пусть работают, твари!".
Любите людей, пожалуйста.

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

Ключевая фигня с матрицей компетенций - что писать в скиллы.
Первый подход к снаряду - а давайте напишем то, чему реально нужно научить новичков? Получаем монстра типа такого: http://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 месяцев избавиться от такого ПО (http://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% - нам будет лучше жить!
- А ты посчитай в деньгах, сколько конкретно нам нужно на разработку, составь ТЗ, план, посчитай экономическую эффективность, прикинь когда и кем мы это делать будем - и тогда приходи.

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

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

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

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