Всегда надо оставлять человеку возможность сохранить лицо в переговорах.
И всегда нужно предоставлять ему выбор. Даже если выбора на самом деле нет.

Среди руководителей разработки, внедряющих agile, считается, что гибкие методологии противоречат документации. Что документация - зло, она тормозит процессы и максимум того, что может производить команда - это пользовательская документация. Они возмущаются, что "Работающий продукт важнее исчерпывающей документации" и каким-то образом делают вывод, что внутренней документации в agile не должно быть. Это полная чушь!

Если вы упираете на формулировки в Agile-манифесте и слова авторитетных людей - обратите внимание на Constraints (http://agilemodeling.com/artifacts/constraint.htm)

Разработчики не хотят писать документацию - они любят писать код. Они не умеют и не хотят осваивать русский язык, с его сложными оборотами и неоднозначными формулировками. Однако именно разработчики и инженеры являются носителями знания о продукте. Если на крупном проекте не будет хорошей внутренней документации, то вы обрекаете себя на более трудную отладку багов, на чудовищный bus factor и полную непрогнозируемость работ.

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

Я считаю, что решение ребуса существует.

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

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

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

Есть решение.

Будильник.
Научите новичков ставить будильник на окончание очередного этапа решения задачи. Если не помогает - заведите будильник себе и бейте новичка по голове.

Будильник. Есть во всех компьютерах мира.

Про рефлексию и коммуникации

Управленческие фреймворки, пафосные фразочки из интернетика - это круто. Но, к сожалению, это так не работает.

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

Плохо:

Старший: Сходи, поговори с клиентом
через 2 дня
Старший: ну чё, поговорил? Чё он сказал? А ты чо? Ну тебе надо было сказать вот это и вот это.

Хорошо:

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

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

Уважаемые инженеры, собеседование - это не соревнование кто круче знает узкую тему.
Перед тем, как погружаться вглубь - нужно неглубоко пройтись с помощью "открытых" тем. Вместо вопроса как устроен кэш в mysql лучше спросить что самое интересное вы делали на базе mysql?. Один вопрос - 3..5 минут обсуждения вокруг.
Неглубокими вопросами вы должны покрыть, например, такие темы:
- опыт в вашем стеке
- архитектурный опыт
- понимание инфраструктуры
- понимание принципов работы распределённых систем
- отношение к факапам
- навыки код-ревью
- комуникационные навыки (объяснение сложного)
- опыт решения конфликтов и работы в команде
- навыки дебага (в широком смысле слова)
- продуктовый опыт

и многое другое. Закапывайтесь только в те темы, в которые надо будет конкретно с этим человеком.

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

Понятно откуда растут ноги - из классического производства: сколько деталей сделал - столько и продал. Проблема в том, что в 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 задач. Перенастройка трекеров, проработка нового функционала для них, настройка нотификаций и областей видимости, взаимодействие людей в разных ролях и много другого увлекательного ада и зависимостей.
Давайте поговорим об этом?