В посте выше упомянул закон Седова.
TL;DR: чтобы компания хорошо управлялась (в смысле имела высокое разнообразие управления) топами, нужно на более низких уровнях вводить ограничения в управлении

Любопытный тейк со странички про закон Седова:

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

Там же, выше:

Закон Седова определяет оптимальное соотношение как «80% детерминации — 20 % хаоса».

Получается, что "бизнесу" всё-таки важно, че у вас там за реакт на фронте? 🤡
Ну и еще получается, что доморощенный велосипед — верный путь к самоубийству организации. Подумайте об этом.

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

Задавайте свои вопросы.

Ещё я засетапил себе микрофон. В воскресенье вечером будет стрим, где попробуем звук. Поэтому пишите свои вопросы в комментариях к этому посту, а то будет не о чем говорить!

У меня, кстати, закончился NDA с нашим трейдинг деском. Про него тоже можно спрашивать.

Книжки для начинающих тимлидов. Обновление

В прошлый раз делал обзор на несколько книжек для начинающих руководителей. Тогда пришел к выводу, что посоветовать ничего не могу. Ну то есть FAST Management как бы да, но там не про IT, а нюансы всё-таки есть. Банально: айтишнику гораздо понятнее, когда примеры из среды IT.

Недавно закончил читать "Путь камикадзе" Эдварда Йордона. И вот эта книжка пока что становится моим фаворитом в рейтинге книг для молодых менеджеров в IT. Она по духу очень похожа на FAST Management, но в ней больше именно про IT. Хотя мне в некоторых местах не хватило конкретных советов, всё таки эта книга более релевантна для айтишников на мой вкус.

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

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

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

Следующая глава супер важная, про неё забывают почти всегда. Вероятно, это связано с тем, что в публичной дискуссии в основном люди из бигтехов, где эти все проблемы решены на уровне компании. Но в принципе, это супер важно знать, понимать и ценить. ЧТО ЭЕ ЭТО УЖЕ?
- Условия труда. Мониторы, компьютеры, кресла, ассистенты, ДМС и т.п.
- Лояльность, мотивация, вознаграждения
- Наём. Кого нанимать, как нанимать, когда нанимать и т.д.
- Средства коммуникации. Зума и телеграма тогда еще не было, но не могу сказать, что проблема сегодня решена.

Потом идут процессы. И здесь вообще чистый кайф. Если вы не хотите/не можете прочитать книгу целиком, то прочитайте только эту главу. Там написано буквально то же самое, о чем я постоянно говорю.
Тезисно:
- Прозрачно приоритезируем все задачи и делаем только самое важное, потому что сделать всё нельзя (бонусом вариант, как выбрать самое важное)
- Динамическое управление скоупом (про растущую сигма-алгебру вот это вот всё, но нормальным языком)
- Отменить карго-культ процессов, думать, что и зачем нужно, можно ли решить эту задачу эффективнее
- Концепция good enough
- Отбор лучших практик
- Управление рисками (!)

Следующий блок про технологии. Он маленький и по существу. Когда и зачем оправдано выбирать новые технологии. Чисто common sense.

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

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

То самое чувство типа: блин, так просто кажется, почему это придумал не я

Кривая дорожка обучения

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

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

Постепенно освоившись, я обнаружил, что в команде есть серьезные процессные проблемы: мы теряли задачи, периодически ловили инциденты, которых можно было легко избежать, обращения в поодержку отъедали всё больше времени. Нужно было что-то делать!

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

Как понять, что хорошо или плохо? Прежде, чем что-то менять / вводить, обозначь проблему. Если с проблемой стало хуже или ничего не изменилось — плохо. Иначе — хорошо. Но думай, можно ли лучше.

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

TL;DR
Хорошо делай, а плохо не делай. Если сделал плохо — прекрати. Если сделал хорошо — продолжай.

Кейс

Человек очень старается, вкладывает много сил и мотивации, но раз за разом достигает посредственного результата.
1. Как изменится результат, если он будет работать "обычно", не усердствуя?
2. Это просто нет таланта и вон из профессии или неповезло или условия неподходящие?
3. Как бы вы попробовали помочь такому человеку, если это ваш сотрудник?
4. Какой совет вы бы дали такому человеку, если бы были его женой/мужем?
5. Вы бы наняли к себе человека, о котором вам дали вот такую характеристику, как выше?)

Опять про типологии личностей

Намедни приобрел в компьютерной сети Интернет видеоролики на тему стратегического планирования. Имею вам сказать, что некоторые лекции откровенно высосаны из пальца (вы всё ещё переживаете, что ваш доклад недостаточно глубок, да?). Так, в одном из роликов сударыня изволит рассказывать, что люди делятся на X категорий. Но так как они _на_самом_деле_ не делятся, то в каждом человеке есть все эти категории одновременно. В некоторые дни иные являют себя одним образом, а на завтра уже радикально меняют категорию — очень удобно, это не модель говно не воспроизводится, это обстоятельства изменились. При этом якобы есть некий базовый психотип, характерный для конкретной персоны. Но помним об обстоятельствах!

Забавно в высшей степени и следующее обстоятельство. Аудитории предлагается привести примеры известных личностей и персонажей для каждого психотипа. При этом полностью игнорируется предыдущий тезис, что психотипы меняются во времени. Но смешно не это, аудитория _ни_разу_ не угадала интенцию выступающей. Более того, слушатели каждого персонажа приписывали к разным психотипам!

Сильнее всего я оторопел от того, что психотипами обладают, оказывается, ещё и бренды!

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

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

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

Очевидное невероятное
Если подготовить кофе в турке к варке и уйти лепить из пластилина на минут 30, получается уже немного cold brew. Его можно всё-таки сварить и получается вкуснее, чем сварить сразу.

Ещё недавно видел ОТКРЫТИЕ. Мол, если перед приготовлением эспрессо смочить таблетку, будет вкуснее. Я не пробовал, но в моей голове поросла связь между этими двумя фактами.

Нерешенная задача проектного управления и стори пойнты

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

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

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

У меня в закладках уже пару недель тогда лежала ровно та статья, про которую сказал коллега. И, вообще говоря, она оказалась не совсем про то же самое, но по смыслу — просто прекрасная! Сейчас расскажу.

Я люблю делить планирование на приоритезацию, прогнозирование сроков и ресурсное планирование. И приоритезировать всегда хочется по ROI (return on investment). Я для этого пропагандирую CD3 (Cost of Delay Divided by Duration). Но эта метрика не учитывает, _кем_ будет решаться задача (за это отвечает теория ограничений).
Но у нас есть альтернативный подход, однозначно заслуживающий внимания. И в нем неожиданно используются стори пойнты!

Чтобы решить, какой проект надо брать, ребята честно пытаются оценить ROI. Это ожидаемая "польза" проекта (в нашем случае, далеко не всегда это прибыль as is), деленная на условный ФОТ (фонд оплаты труда) (в человеко-попугаях). Как считать полезность мы обсудим в другой раз, а вот затраты рассмотрим сейчас.

Итак, есть ворох проектов, с разной полезностью, каждый из которых нужно делать разными пересекающимися наборами команд. Предлагается дать командам оценить задачи, как они обычно их оценивают. А потом посмотреть по статистике, сколько FTE (full-time employee) от каждой команды уйдет на реализацию её части проекта. Для этого для каждого сотрудника высчитывается его личная velocity. Тогда можно взять оценку задачи, поделить на velocity и получить FTE.

FTE это уже штука более понятная, чем стори пойнты или даже часы. Пусть и джун от сеньора будет сильно отличаться.

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

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

1. Оценки даже в стори пойнтах работают очень плохо. Здесь ребята пытаются уменьшить эффект от этого логированием реально затраченных ресурсов (неизбежно напарываясь на то, что реально потраченные стори пойнты это оксюморон). Статистика прошлого получается, оценить кому сколько выставить FTE — можно (ценой логирования затраченных ресурсов). Но вот планироваться так все равно нормально не получится. Кстати, в одной из моих команд тоже логируется затраченное время, именно для перевыставления FTE.
2. Предполагается, что задачи жестко прибиваются к исполнителям (иначе оценки не валидны). Это не помогает морали команды.
3. Здесь, чтобы осуществить ресурсное планирование, нужно сначала осуществить ресурсное планирование.

Та самая нерешенная проблема проектного управления. Как нам учесть в планировании все отпуска, дежурства, болезни и индивидуальные скорости сотрудников (которые еще и относительны к задачам). А никак.
Все проектные менеджеры вынуждены до сих пор брать гантта, раскладывать его на "колбаски" и впихивать эти колбаски между отпусками и национальными праздниками.

Может быть, вы умеете планировать это лучше? Научите меня в комментариях.

Про принятие решений

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

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

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

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

Здесь важно, что консенсуса достичь не получается практически никогда. Но мне нужно, чтобы решение, которое мы приняли, было продано каждому. То есть даже если мы решили disagree and commit, люди должны все таки commit. Саботаж точно не улучшит ситуацию, а породит только конфликты, которые зачастую станут деструктивными (здесь есть сложный момент — донести до всех, что решения не отлиты в граните, можно в любой момент поднять вопрос о том, чтобы его отменить).

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

Иногда это не получается. Я имею в виду, что иногда меня переубеждают и это прям хороший исход. Но иногда я могу передавить. У меня много аргументов, человек с ними соглашается, но что-то внутри него всё ещё радикально против. Такие ситуации прям мешают работе. Думаю, что здесь нужно действовать "по Кэмпу" — дать человеку право не согласиться и уйти с этим на какое-то время без принятого решения.

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

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

Пока работает. Думаю, что это будет работать до тех пор, пока к руководителю есть доверие и уважение (то есть нужен трек рекорд).

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

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

Я тоже нифига не понял, честно.
Если читая статью в энке, вы зададитесь вопросом "а где спиновые стекла?", то считайте, что они их там называют ферромагнетиком.

Дорогой брат пишет про парадокс образования: с одной стороны, ты, как преподаватель, оказываешь услугу, за её получение деньги уплочены; с другой стороны, если человек сам не учит, то никакие усилия преподавателя не помогут.

Я подумал, что это как спорт.
Можно купить абонемент в фитнес зал. Там ты заплатил, тренер показывает и говорит, что делать. Но делать должен ты сам.

А вот пойти на физтех это уже как спорт высоких достижений. Условно бесплатно, но фелонить нельзя. Здоровье, кстати, тоже страдает, только ментальное.

Пара анонсов и вопрос

Во-первых, сходите на Epic Growth, он уже сегодня! Мало того, что Таня делает круто, так в этом году ещё и с Яндексом!

Второе.
Я тут впервые провёл настоящую стратсессию. Получилось даже не так плохо, как могло бы. Щас вот сяду в самолёт из Алматы в Белград и напишу подробности.

А пока у меня вопрос: как вы считаете, что такое стратегия?