Привет, простите что в выходные.

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

Расскажите какие фишки есть в ваших командах?

Метод 5П для встреч 1х1

Книга «Карьера Software Engineering Manager», оказалась кладезью простых мудростей на каждый день, поэтому продолжу ими делиться.

Допустим вы недавно стали руководителем и вам надо начать встречаться с подчиненным 1х1. О чём с ними разговаривать? Я лично знаю две больших категории, первые говорят обо всём что угодно кроме работы и лишь изредка, когда совсем уже жесть, по делу. И те кто говорит на встречах только и исключительно о работе и вообще не интересуется личной жизнью. Абсолютно согласен с автором книги, который говорит что и то и другое плохо.

В книге предлагается простой фреймворк 4П, помогающий провести диалог 1х1 и не забыть что-то важное:
1. Прогресс
2. Проблемы
3. Планы
4. Персонал (в оригинале People, т.е люди)

Вот 4 столпа на которых автор предлагает строить встречи 1х1, сам же себе противореча, ведь тут снова только про работу.

Я предлагаю добавить к этому списку 5-ю П — персональное. Т.е после всего рабочего, можно пообсуждать не рабочее, там и про погоду, и общее самочувствие, и про жизнь в целом.

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

Чем закончился наш эксперимент с Focus Time?

Мы запустили его на две команды. У каждой команды в расписание встал 4-х часовой слот «focus time» на каждый день. Несмотря на то что мы давали выбор в первой или во второй половине дня — обе команды выбрали вторую половину дня, т.к в первой проходят стендапы и их сдвигать не хотелось. Через месяц и через два запустили пульс-опросы чтобы узнать как дела?

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

В общем, рекомендую.

Спасибо всем, кто участвовал

Недавно мы презентовали проект CodeRun на внутреннем мероприятии. Я подготовил небольшую презентацию на 5 минут, постарался вместить в неё все основные фишки проекта.

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

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

Как я начал читать?

Последние лет 5 я очень мало читаю. Менеджерская работа с кучей свитчей контекстов не оставляет времени на то, чтобы что-то почитать кроме статеек. Иногда, раз в год, бывает зацепит какая-то книга, но это скорее исключение. Ну и ещё я каждый год перечитываю «Понедельник начинается в субботу», но это уже совсем другая история.

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

Я стал ковыряться в причинах того, почему я не читаю и обнаружил два крайне забавных факта про себя:

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

2. Мне не хватает геймификации и ощущения прогресса. Т.е того что бы меня мотивировало хотя бы по чуть-чуть читать каждый день. Обнаружил я это совсем благодаря игрушкам time waster’ам. Почему я к ним возвращаюсь каждый день? Почему на них у меня время есть? Ведь глупее тапания ничего не придумаешь...

Т.е нужен трекер для книг, не привязанный к тому как именно ты читаешь книгу (бумажную, в читалке, в браузере), с минимальной геймификацией. Так я вышел на Turn. Это приложение максимально простое. Забил книгу. Когда начал читать — тапаешь «Начать сессию», когда закончил вбиваешь сколько страниц прочитал. Этого оказалось достаточно чтобы читать регулярно. За прошедший месяц я прочитал 9 книг, в том числе «Русскую модель управления», которую до этого трижды начинал читать.

Turn не идеален, но лично мне он нравится своей простотой. Теперь я читаю даже те 5-10 минут, пока сижу в машине и жду жену 🙂 В общем, рекомендую.

p.s. Если знаете аналоги, особенно для андроида/ПК, кидайте — добавлю в пост.

Пост для комментов. Не понимаю как это работает

go/ wiki/ staff/

В книге Software Engineering at Google рассказывается про документацию в Гугле, которая обёрнута в специальный сокращатель ссылок go/. Идея очень простая, что если тебе, например, нужно узнать что-то про MySQL, то ты идешь по урлу go/mysql. «Урл» в кавычках потому что я не знаю реально ли этот урл разыменовывается, или просто это удобное сокращение похода через сервис. Ниже ответ.

Забавно, что в Яндексе подобное сокращение урлов (а тут без кавычек) тоже используется, но на уровне сервисов,. Т.е мой профиль в интранете может быть доступен по урлу https://staff.yandex-team.ru/mokhov/, а может быть доступен по урлу staff/mokhov. А вот про инфохабы как-то не догадались.

Подобное сокращение урлов — это удобная альтернатива поисковым механизмам по интранету, особенно если следить за актуальностью. go/mysql — всегда будет ссылаться на хаб по тому, как внутри компании используется mysql. А staff/volozh — ну вы поняли :)

p.s. Комменты можно писать к прошлому посту для комментов. Я пока разбираюсь с поддержкой телеграма

Фил (канал Life of Phil) рассказал конкретнее как это устроено. Собственно как в Яндексе, есть шорткаты на уровне dns в интранете и это удобно

Ну давай я тогда сюда напишу просто?

«Урл» в кавычках потому что я не знаю реально ли этот урл разыменовывается, или просто это удобное сокращение похода через сервис.

В гугле ты можешь зарегистрировать свой домен первого уровня во внутренней сети: все эти go/..., me/..., они будут резолвиться на уровне dns, но их относительно сложно сделать. Надо что-то настраивать, ждать.

И есть го ссылки, ты можешь просто в UI нажать кнопку, заполнить 2 поля "go/oleg" --> "https://xn--r1a.website/teamleading", и тогда по ссылке https://golink.google-intranet/oleg" будет кидаться редирект на твой канал. Ну и дальше у тебя просто первым способом сделан DNS CNAME http://go на https://golink.google-intranet.

Технически всё чуть сложнее, но концептуально так работает.

Чем ты хочешь заниматься?

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

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

Даже в горизонте полгода можно визуализировать картинку. Купленный абонемент в спортзал или билеты в отпуск гарантированно дают её.

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

Ответом на этот вопрос должен быть не просто лозунг «Быстрее, выше, сильнее», а вполне конкретный ответ. И не то чтобы есть слишком много шансов поэкспериментировать. Трудоспособный возраст в РФ с 18 до ~60 лет. Итого, есть примерно 42 попытки выбрать чем хочется заниматься в горизонте года. И всего 8 попыток в горизонте 5 лет. Многие, кстати, одну попытку израсходуют на университет. 

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

Я начал искать как ответить на этот вопрос и набрел на икигаи. Вместо того чтобы пытаться ответить сразу же на вопрос экзестенциальный, сначала надо ответить на 4 других вопроса:
1. Чем вы любите заниматься?
2. Что у вас получается хорошо делать?
3. За что вам готовы платить?
4. Что нужно миру от вас?

И пересечения ответов есть разные жизненные сценарии. Например, пересечение «Что у вас получается хорошо делать?» и «За что вам готовы платить?» — это работа. А «За что вам готовы платить?» и «Что нужно миру от вас?» — призвание. А пересечение всех 4-х — это икигаи. И, пожалуй, если после ответа на 4 вопроса у вас нашлось занятие которое присутствует везде, то на перепутии я бы выбрал именно это направление движения.

Ко мне очень часто приходят мои подопечные с вопросом «А что мне делать дальше?». И раньше я всегда отвечал вопросом: «А что ты хочешь?». Кто-то отвечал, но звучало это чаще всего как те же «Быстрее, выше, сильнее». И вот недавно я понял, что можно не только задавать открытый вопрос, но и помогать искать ответ на этот вопрос. Принцип икигаи — это один из способов, который вы, как руководитель, можете предложить сотруднику, когда составляете PIP (Personal Improvement Plan) или когда беседуете по душам о его будущем. Принципом икигаи можете воспользоваться и вы сами, если есть желание что-либо поменять...

Пост для комментариев

Сколько менеджеров нужно на встрече?

В книге Джеффа Паттона есть короткий абзац-история про компанию ThoughWorks (в печатной книге страница 138). Суть такая, что команде нужно было обсудить бэклог, но при этом в продукте было 25 людей, принимающих решение и попытка собрать их в одной комнате обернулась сущим кошмаром для команды и она не смогла нормально запланироваться. Решение, которое предлагает Джефф очевидное и на поверхности — дробиться на небольшие группы и прорабатывать частички бэклога уже в них. Не так эффективно по времени, но эффективно по результату.

Казалось бы это элементарно, Ватсон. В доковидную эпоху это работало само собой, благодаря ограничениям размера переговорок, когда в маленькую переговорку не позовёшь 20 человек. Но в эпоху Zoom’митингов мы вернулись к формату похожих монстровстреч и соответствующих проблем. Сравните картинку из шедеврума и скриншот из зума (взято отсюда). Лично у меня нет ощущения во втором случае что когда я начну говорить то меня будут слушать 50 человек.

Итак, о чём я?
Вводная 1: надо собрать встречу, чтобы что-то обсудить
Вводная 2: все начинают звать всех кто мало-мальски заинтересован в любой теме, которая может быть поднята на встрече
Итог: на встречу приходит 30 человек и вместо обсуждения, автор встречи ведет плохой монолог-доклад-презентацию, все не довольны, потому что обсуждения не получается, а на выходе ощущение что всех поставили перед фактом.

Знакомо?

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

Остальные встречи на 10+ человек — это всегда презентации и монологи, к которым нужно готовиться заранее. Не стройте ложных иллюзий, что получится что-то типа беседы или что-то иное. В лучшем случае пара человек выскажется, и чаще всего это будет или рядовая похвала, или неприятная критика (публичная, к слову). Зачем вам оно?

Хочется обсудить — собираете до 10 человек и обсуждаете. Затесался 11? Увы, это уже презентация 😉 (табличка «sarcasm»)

Как всегда комментарии можно писать под этим сообщением. Поддержка не отвечает что происходит и почему в длинных постах нет ссылок на комменты.

О, чёрт, я кажется догадался в чём дело и почему под постами нет ссылок на обсуждение.

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

За сим вопрос к сообществу: подскажите хороших спам-ботов?

Сколько менеджеров нужно на встрече? Часть 2.

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

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

Позвольте небольшим группам работать вместе и принимать решения, а затем продолжите общение, в разговорной форме сообщив результаты всем остальным.

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

Let small groups work together to make decisions, and then use continued conversations to share the results with everyone else.

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

Я взглянул на многие встречи в прошлом и заметил эту же закономерность. Например, возьмём стендапы. Когда мы стендапились командами по 6 человек, то каждый был вовлечен в процесс, все обсуждали задачи, это было похоже на дискуссию и на командную работу. Когда на стендапы стало ходить 10+ человек, то это стало похоже на плохой открытый микрофон, где цель каждого участника выйти, рассказать свою часть и отключиться. Никакого обсуждения не получается, как ни модерируй.

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

Но допустим у вас не так, есть дискуссии, тимлид постоянно что-то спрашивает и уточняет у ребят. Я вас расстрою, это всё ещё плохой открытый микрофон. В хороший качественный процесс обсуждения должны быть вовлечены все члены команды, потому что в хорошей команде все должны быть заинтересованы в том, чтобы спринт сошелся, релиз состоялся, GMV росло и т.д. А если это волнует только тимлида, который бегает между разработчиками и пытается их расшевелить, то это всё ещё нифига не командная работа. «Я свои компоненты сделал, это тестирование не протестировало и поэтому релиза не будет» ничем не отличается от «Защитник отдал пас вперёд, но там никого не было». И это уже было обшучено 20 лет назад в КВНе моими любимыми Уральскими Пельменями.

Cколько менеджеров нужно на встрече? Часть 3

Предыдущие две заметки должны были подвести вас к одному вопросу, и если вы его ещё не задали себе, то давайте зададимся им прямо сейчас. Итак: зачем нужно помнить о каком-то количестве менеджеров на встрече?

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

Я считаю, что в норме у мидла в неделю должно быть не более 2 часов встреч, помимо процессных встреч, т.е планирований, стендапов, демо и ретроспектив.

Как действовать если календарь кишит регулярными встречами? map-reduce! Проходимся по списку встреч и задаём три вопроса про каждую из них:
1. Участвовал ли я активно в последних 3-х регулярках?
2. Что произойдет если я не приду на эту встречу?
3. Нужно ли мне знать что было на той встрече, и если да то каким образом мне комфортнее всего получать информацию о происходившем на ней?

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

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

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

Как быть, если слушатели горят желанием послушать? У Паттона описан метод «Аквариум». Во встрече активно участвуют до 5 человек, а остальные наблюдают. Если кто-то хочет подключиться к активной части, то нужно произвести замену, т.е чтобы кто-то из активных участников отключился от обсуждения. В оффлайне это сделать проще, чем в зуме. Но я думаю вы поняли, что смысл здесь в том, что эффективное обсуждение возможно только небольшой группой.

В конце хочу ответить на ещё один не заданный вопрос, почему мои посты называются «сколько менеджеров нужно на встрече?» Менеджер — это управленец, руководитель, а не только люди с M в названии должности (TPM, PM, Продакты). Руководителем можно быть не только группы, службы, отдела, но и функциональности, проекта, и даже эпика. И когда вы вступаете на эту дорогу руководства (если вы мидл, то уже наверняка бывали feature lead), то сразу же получаете кучу встреч впридачу, что сильно размывает ваш фокус, несмотря на то что подавляющее количество встреч вам посещать не обязательно.

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

Ходите только на полезные для вас встречи.

Право на работу

Вы, наверное, слышали что недавно в Австралии ввели закон, запрещающий работодателю звонить и писать работнику во вне рабочие часы. Хоть я этот тренд не разделяю, это отличное начало и я понимаю почему многим это нужно. Людям тяжело отказать руководителю в личной переписке, а многие руководители в вопросе «можно ли им не отвечать по выходным?» играют в молчанку.

Мой совет руководителям— проговорите это явно. Я говорю это на онбординге новым сотрудникам, что мои сообщения во вне рабочие часы можно игнорировать — если будет пожар, то я позвоню.

Я, особенно в преддверии выходных, хочу сегодня написать на другую тему — право на работу.

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

Недавно я прочитал книгу Nordic dads. Книга эта скорее вдохновляющая и развлекающая, но автор делает явный акцент на том что в северных странах есть право на отцовский декрет. Это право даёт отцам при рождении ребёнка уйти в декрет, который они не могут* пошарить с мамой ребёнка. Это не то же самое, что просто уйти в декрет — такое есть и в России. А это именно оплачиваемый государством декретный отпуск отца.

Так вот, что интересно, когда этот декрет вводили, то были люди, которые переживали за то что отцы будут брать отпуск не для того чтобы с ребёнком сидеть, а для того чтобы ездить на рыбалку, очень популярное занятие на северах. Но разум возобладал и с течением времени появилось много активных отцов, занятых в воспитании детей. Если в прошлом веке, когда отцовский декретный отпуск вводили, его брали от силы 10%, то сейчас в некоторых странах эта цифра доходит до 50%.

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

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

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

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

Таких примеров может быть больше (приглашаю в комментарии). Если вы хотите стабильности ваших проектов, то я предлагаю вам ввести «правила на работу» и заранее продумать как это будет работать и оплачиваться. И да, вы точно будете первое время терять деньги на этом, но если ваша цель стабильность проекта, то оно того стоит.

Ну что ж, а мой рабочий день закончился, всем отличных выходных! :)

—
* В некоторых странах бывает три вида оплачиваемых декретов: материнский, отцовский и смешанный. Как разделить смешанный решают мама с отцом и я думаю вы понимаете кому достаётся большая его часть чаще всего.

** Выходной день оплачивается либо х2, либо х1 и дополнительный отгул. Даже если ваш самолёт приземляется в субботу в 00:05 — это уже считается полностью оплачиваемым выходным. Именно это я подразумеваю под «захватывать выходные»

p2p feedback
и как его улучшить в рамках ревью?

Ревью, как процесс, есть во многих IT-компаниях. Обычно ревью проходит так: отзывы -> оценки -> калибровки -> изменения (пересмотр зарплат, премии и другие плюшки). Я в системе ревью уже 10 лет и за это время появились разные мысли, которыми хочется поделиться. Начнём с отзывов.

Отзывы — это старт, а для многих уже и финиш, ревью. Нужно запросить отзывы на себя у коллег, написать отзывы самому и сделать самоотзыв. У кого запросить? Где-то пользуются 360 degree feedback, где-то в полуавтоматическом режиме, где-то сам человек решает. Различается так же и то как фидбек даётся: в свободном стиле, или подробные опросники, или даже шкалы оценки. Все полученные фидбеки руководитель аггрегирует и ставит оценку перфоманса.

Так вот из года в год я наблюдаю одну и ту же картину. Какая бы схема фидбека не была бы выбрана, какие бы рекомендации не были бы даны по тому у кого запрашивать отзывы и как их писать. Всё равно большая часть отзывов сведется к мастерству авторов в написании простыней общий смысл которых будет «всё норм» 👌. Таких отзывов 90%, они представляют собой восхитительные рассказы, содержащие и эмоции, и перечисления всех тикетов и встреч, и так же истории о том какой человек классный и приятный. Но не факты. А даже если факты и будут, то они зачастую продублируют те что человек написал сам про себя в самоотзыве.

Это не сильно, но раздражает уже в момент выставления оценки, но ещё больше начинает бесить во время калибровок (выравнивания оценок). Потому что сквозь череду однотипно хвалебных отзывов очень трудно разглядеть смысл отличный от «всё норм».

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

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

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

Т.е важно не то какой отзыв написан на Васю. А какой это отзыв среди других отзывов того же автора. Иными словами из 30 отзывов, где 29 являются простынями про то что «всё норм» и один сухой отзыв «Вася крутой» от определённого автора — именно этот один отзыв должен сильнее всего влиять на оценку человека.

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

А пока давайте пообщаемся про то как у вас устроено ревью?