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

А помните, я где-то год назад писал, что взялся стать индустриальным (научным?) руководителем у студентов магистратуры? Я тоже не помню. Но вроде было.
Дело там куда-то движется, а если точнее, то уже к предзащите.

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

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

Суть в том, что магазин, который не хочет никак трогать крипту, может тем не менее начать принимать оплату криптой! Выглядит это примерно так: заходишь ты на амазон, выбираешь себе умную лампочку за $5. Потом жмёшь кнопку криптопей (как эплпей, но не эплпей). Там выбираешь крипту, сеть, тебе показывают цену уже в этой крипте и сети. Если согласен, то отправляешь свою крипту на кошелёк экваера (ну типа куаркод считать или на ссылку нажать надо). Магазин тебе говорит, что всё круто, товар оплачен. Ты довольный криптобро. А в конце месяца (ну или как-то так) экваер магазину на счёт переводит фиатные твои $5, за вычетом комиссии.

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

ИНВЕСТИРУЙТЕ В НАШ СТАРТАП! 😁

Отдельно хочется ещё рассказать про нетехнические стороны этого предприятия. Мне ОЧЕНЬ нравится, что ребята сделали в районе исследования рынков и конкурентов, расчёты юнит-экономики, CJM, JTBD и ещё всякие непонятные аббревиатуры. Какие возникают вопросы про продвижение, custdev и планы развития. На моей работе всего этого нет, поэтому я так в новый мир попал. Мне нравится.

Как тимлиду получить хорошую оценку на перфоманс ревью

И почему это скорее всего не то, в чем заключается его роль.
Традиционный уже пост о ревью. На этот раз без математики, но всё ещё с бытовой философией. Очень много в интернете и книгах рассуждений о том, что должен делать тимлид. Вообще говоря, единого стандарта нет, где-то смотрел даже доклад, что тимлид не существует. Но есть несколько направлений, разные комбинации которых обычно звучат как требования к этой позиции.
1. Техническое лидерство (нарезать задачи, прорабатывать архитектуру, ПИСАТЬ КОД, ревьюить код и т.д.)
2. Управление процессами (фасилитация ритуалов, решение о введении или отмене практик, прогнозирование сроков и т.п.)
3. People management (найм, увольнения, удержание, развитие сотрудников и т.д.)
4. Операционное руководство (обратная связь, постановка задач, контроль, распределение задач и т.п.)
5. Team management (наладка взаимодействия в команде, закрытие ролей, управление конфликтами, knowledge sharing, управление bus factor'ом. Что характерно, риск менеджмента при этом никто не ждёт)
6. Результаты команды, деливери (ну ты же собрал людей, ты процессы туды-сюды, ты архитектуру делал, ты сроки давал, ты команду дружил, ты решал проблемы заблокированных сотрудников, ты КОД ПИСАЛ)
*перекройка процессов, построение культуры и всякое межкомандное традиционно считается областью ответственности MoMs (мидл менеджеры на нашем)

Возможно, я забыл что-то _очень_важное_, но мне пофиг.
Вот наш бедный тимлид какое-то подмножество из этого кому-то должен. Ок. А как же нам теперь оценить тимлида? Он вообще как, норм, или пора ему на мороз?
А тут надо посмотреть, кто его оценивает. Как же он видит ситуацию?
Да хер знает! Пойдите да спросите его.
С высокой вероятностью, он сам не знает. Тогда вам нужно провести ретроспективный анализ: за что ваши оценки были выше, а за что не были.
Хитрость заключается в том, что ты можешь по всем показателям рисовать себя дАртаньяном, но, например, деливерить будешь не то или архитектуру сделаешь не такую. И твоя оценка на ревью не совпадет с твоими ожиданиями, сформированными постами умных людей в интернете.

Сейчас кто-то очень умный в комментариях уже строчит, что это детский сад, и для этого придумали цели. Но на поверку оказывается, что вообще-то цели — это вот у них цели, а у нас цели это не цели, а направления мысли! И это, кстати, очень разумно! Предлагаю вам погуглить современное состояние индустрии в этой области и почему многие передовые компании отказываются от OKR (и тем более KPI). Короткий ответ: потому что сюрприз это не всем подходит! Есть огромное количество компаний, которые работают на уровне неопределённости такого порядка, что четких целей не может быть даже на квартал, не говоря уже о годе. Практика применения целей показала, что команды игнорируют ключевые возможности в угоду закрытию целей.
Ну и ещё может быть ситуация типа: ну вы че, блин, мы бы цели поменяли просто постфактум, че вы как эти, че творите-то.
Вы это, у руководства уточните, какие у вас цели там: настоящие или на юго-запад.

Так, я понял, что нужна пояснительная бригада к предыдущему посту

В первой версии, которую я удалил, был здоровенный кусок с логической выкладкой, как тебе понять, по каким показателям тебя оценят, исходя из топ-левел целей компании. Проблема в том, что твой начальник человек, а значит, он не рационален. Ещё сюда можно добавить фактор "светового пятна" (иерархия менеджеров это как осветительные фонари, висящие друг над другом: каждый вышестоящий освещает большую площадь, но менее интенсивно). А ещё вы никогда не угадаете, как цель увеличить GMV разложилась в цели "поднять доступность Х" и "сделать новый сервис Y". Дальше хуже, вы можете работать в компании, где идеи идут снизу вверх, а наверху только выбираются те, которые двигают компанию в нужном направлении.

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

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

Отдельно про метрики и KPI. Bad wording, но мне казалось, что из контекста должно быть ясно, что отказаться от KPI и OKR относится к командам, тимлидам, не к компании целиком. Это первое.
Второе. Мне не известно вообще ни об одном хоть каком-то исследовании о корреляции метрик/KPI/OKR и успешности (в любом виде) компаний, кроме статьи про DORA, в которой исследование откровенно слабое. Почитайте на досуге, если интересно.

Я много лет _собирался_ заняться bjj (борьба такая). У меня в Москве даже зал в соседнем дворе был. И вот сегодня, уже в Белграде, я наконец сходил на свою первую тренировку.
Это именно то, что мне нужно: не агрессивно, без ударов/амплитудных падений, на все группы мышц, интеллектуально. Буду стараться продолжать.

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

И это именно тот настрой, который нужно брать на вооружение молодому руководителю. Хвалить всегда приятно, награждать очень приятно, повышать невероятно приятно. А вот доносить корректирующую или даже развивающую обратную связь страшно.
Страшно по разным причинам. Как человек отреагирует? Будет ли он меня теперь считать козлом неблагодарным? А вдруг он обидится и уволится?
Очень много мыслей. Особенно страшно становится в периоды перфоманс ревью. Особенно если ты ставишь человеку пониженную оценку. Даже увольнять не так страшно.

Очень важно здесь осознать, что ты делаешь больно сейчас, чтобы было круто потом. Обратная связь должна быть конструктивной, чтобы было ясно, как конкретно нужно изменить поведение (а не самого человека, это табу). Если проблема систематическая, то должны быть последствия. Это, по Платону, как врачевание: если ты не полечишь, сделав надрез, то потом придётся уже ампутировать. Отсутствие последствий не просто расхлябывает сотрудника, оно роняет планку всей команде. И делает руководителя слабым в глазах команды. Потому что он не смог найти в себе смелость помочь им.

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

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

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

Фиганул тут для внутренних нужд ультимативно сжатый конспект книжки Койла "Культурный код", про которую писал выше. Поделюсь тут с вами, что ли. ПОЛУЧИЛОСЬ НЕ ИДЕАЛЬНО. Особенно по последней части. Но лучше я пока не смог.

Сплоченность покоится на доверии, взаимозависимости и кооперации. Добиться этого можно через безопасность (build safety), умение открывать друг другу слабые стороны (share vulnerability) и ставить общие цели (establish purpose). Дальше — пойнты, как это сделать.

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

Share vulnerability
— Говорите и постоянно напоминайте, что ждете кооперативной работы, хвалите за взаимопомощь.
— Модерируйте дискуссии, нацеливайте сотрудников на кооперацию и общую пользу: «Мы в одной команде!».
— Удержитесь от советов (это очень сложно): пусть сотрудник расскажет о проблеме и попробует сам найти решение.
— Делайте совместные постмортемы и ретроспективы, чтобы понять, как стать лучше.
— Давайте фидбек честно, открыто, прямолинейно, но не грубо: комментируйте действия, а не личность.
— Заводите команду в некомфортное состояние (контринтуитивно, но всё же): разбирайте самые большие факапы, чтобы мотивировать самих себя стать лучше.
— Разделяйте оценку работы и развитие сотрудника на две встречи (хотя интуитивно они рядом): это совсем разный эмоциональный контакт с сотрудником.
— Организуйте секции парной работы, когда сотрудники могут призвать на помощь любого коллегу для совета по любой задаче.
— «Отпускайте» сотрудников. Иногда. Дайте ребятам во время инцидента справиться самим, исчезните. Супербуст к кооперации и доверию, но всё же следите, чтобы он не вылился в большие потери.

Establish purpose
— Составьте список приоритетов: например, качество важнее сроков. Пусть этот список будет перед глазами всей команды.
— Внедряйте кринжовые фразочки типа: тикет без дизайна — деньги на ветер.
— Напоминайте и снова и снова объясняйте, что кроется за этими приоритетами.
— Выставляйте метрики, которые соответствуют приоритетам. Остальные можно убрать.
— Ставьте амбициозные цели.

Посмотрите первый сезон сериала "Тед Лассо", чтобы зацепить примеров.

Не engineering excellence единым

Много людей на собеседованиях говорят, что думают, раз у нас финансы, то всё офигенно тщательно тестируется, каждый коммит аудируется, код без багов и вообще qa больше, чем пользователей. Но проблема в том, что как бы хорошо ты ни делал, всегда можно лучше. Мир вокруг меняется с такой скоростью, что твоё решение из скрипта для запуска руками пару раз в месяц довольно быстро превращается в хайлоад сервис с десятками тысяч rps. А код там всё ещё от твоих скриптов, да.
И перед тобой каждый день стоит выбор: ещё чуть-чуть побежать на этом поделии и потерять на поддержке, багах, железе и штрафах, но сэкономить на разработке и ttm, или всё-таки взять мешок денег и все сделать заново под современные требования, как мы и сделали с платежным шлюзом, может кто видел доклад Антона Куранды на хайлоаде '23.

Сделали хорошо, красиво и современно, но у нас несколько сотен платежей в секунду летит 24/7. Понятное дело, что часть из них ловят какие-то баги. И вот эти поломанные платежи приходится разбирать руками.

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

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

Ошибёшься, и твой проект принесёт компании убытки. Зачастую в таком случае ещё и будет свёрнут на середине. А ты ведь так красиво всё придумал!
TFW ты понял, почему твои грандиозные космолеты зачастую не хотели брать в работу начальники с инженерными прошлыми (да как они могли! Ааа, вот как они могли).

Не могу, кайфую с этих постов, ребят
Может вам тоже понравится

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

Это я к чему. Мы на работе используем для приоритезации оценку cost of delay. Точных чисел у нас никогда нет. Поэтому это именно оценка.
Эту оценку мы выбрали, конечно, не за объективность, но всё-таки в противовес приоритезации по принципу "кто громче кричит".
Несомненно, оценки мы челленджим, но, как я говорил, наверняка не знаем никогда. Получается, что заказчику имеет смысл завышать CoD не только на случай "авось прокатит", но и для привязки к бОльшему числу нашей, уточнённой оценки.

Отсюда же, кажется, следует, что когда продаёшь машину, надо изначальный ценник заряжать повыше. 🤔

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

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

Нужно регулярно пересматривать процессы в вашей команде

Подсмотрел некоторое время назад у Виталия Шароватова такую штуку: Process Decision Record (PDR). Это как в трейдинге, когда ты перед сделкой должен себе записать: когда, что, сколько, ПОЧЕМУ - КАКАЯ БЫЛА ГИПОТЕЗА, дата пересмотра позиции (вдруг гипотеза больше не верна), критерий немедленного выхода из позиции. Но только не для трейдинга 🤡.
Пишем всё то же самое, но для процессного компонента: когда ввели, что ввели, с какой целью (гипотеза об эффекте), когда перепроверить (оно сработало или протухло?), критерий немедленного выхода из практики (может вы теперь вообще работать не можете).

Убираем стори пойнты

Так вот, завёл такую штуку. И вот по-тихоньку лью туда наши практики. Дошло дело до стори пойнтов. И такое дело... Стори пойнты не нужны.

- У нас не скрам, мы не планируем спринт.
- Мы не можем планировать квартал или полугодие в sp, потому что уровень неопределённости не позволяет.
- Мы никогда не используем sp, чтобы спрогнозировать заказчику сроки.

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

Но! Я всё же решил ради интереса посмотреть, насколько оценки story points реально прогнозируют сроки выполнения задачи. Оказалось, что стори пойнты не работают. По крайней мере вот в конкретной команде. Попробуйте проделать упражнение на своих данных.

Я построил график времени выполнения задачи от её оценки в sp. Если данные хорошо почистить, положить на логарифм и отрезать крайние sp, то можно добиться R2 около 0.07-0.1. Но вообще пикрелейтед. Смешно и грустно.

А если вспомнить, о минусах story points: время на оценку, мерянье пиписками, кто больше сделал, срачи про "я угадаю эту песню с пяти нот", дисморалящие команду, и чувство большого брата, считающего твои стори пойнты, то можно сделать вывод, что стори пойнты вредны!

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

Заметка про Государство Платона

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

Сразу: книга, как ни странно, пытается выяснить, что такое справедливость. А государство там всплывает только в качестве вспомогательного инструмента.
С другой стороны, устройства государства по Платону тесно связаны с понятием справедливости, как внутри государства, так и на уровне одного человека.

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

В целом же книга достаточно сильно отличается от Диалогов. Не знаю, почему. Главный герой здесь также Сократ. Но стиль доказательств и рассуждений другой, несмотря на всё те же "Клянусь Зевсом, Сократ" 😁.

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

Не, ну я тут на этом мои полномочия всё

Короче, у нас тут Тигран (тот самый) на майских праздниках умудрился попрограммировать на js (доработать понравившуюся ему игру) и захостить в Яндекс облаке.

Инжойтесь https://codenames.one/

У человека пятеро детей! И бесконечно более сложная работа, чем у большинства из нас с вами. И, насколько я знаю, нет бэкграунда в разработке.

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


UPD
Пояснительная бригада к игре. Там короче несколько человек играют (две команды). Минимум 4 человека по идее. Есть общий экран для всех, а есть ещё отдельные для капитанов команд.
Там ссылка есть на правила, почитайте. Для игры нужен какой-то канал связи между картинками и игроками.