Прочитал у Канемана об эффекте привязки. Смысл примерно такой. Тебе в каком-то вопросе или утверждении называют число. Потом просят оценить никак не связанную с предыдущей информацией величину. Оказывается, что твоя оценка смещается в зависимости от того самого числа.
Например, тебя спрашивают Ганди был старше 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 человека по идее. Есть общий экран для всех, а есть ещё отдельные для капитанов команд.
Там ссылка есть на правила, почитайте. Для игры нужен какой-то канал связи между картинками и игроками.

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

Тем не менее, мне всегда нравился N+1. Там no bullshit. Но, зараза, сложновато из-за этого. И вот на самом деле, если задуматься, то так и должно быть. Нужен порог входа. Нужно, чтобы человек понимал, что на котятах квантмех не понять, что нужно всё-таки потрудиться.

Последние пару лет много слушал Андрея Конеява. И вот он называет проблемы научпопа те же, что бесили меня, и ещё тележку сверху досыпает. Но продолжает делать N+1. Сам не знает зачем, не понимает, это больше полезно или больше вредно, вообще очень грустно рассуждает на эту тему.
Я особенно почувствовал тлен в свежем видео подкаста о философии. Если вам тема близка, то тоже посмотрите https://youtu.be/dx4rvmMQNlQ?si=VNDtYpFPDCITKkEt

С днём победы!

Разбавлю серость нашего менеджерского бытия небольшим physics envy про планирование проектов, потому что могу

Канал у меня всё-таки немножко иногда когда-то очень давно и редко, но QUANT, а значит, в том числе и про quantitative finance. Это значит, что рисками здесь называются sensitivities, частные (давайте без усложнений пока) производные функции всех порядков по любым переменным. Это значит, что у слова риск нет негативной коннотации. Ещё это значит, что risk management это контроль размеров этих самых производных.

Теперь модель управления проектами. Пока самая простая, над сложными я ещё думаю.
Мы знаем что мы хотим сделать, мы знаем как это можно сделать, мы умеем оценивать текущее состояние дел.
Тогда пусть начальное состояние будет описываться вектором X, конечное — вектором Y. А сам план, который мы составляем это стохастическая функция f, такая что f(X)=Y. Стохастическая, потому что зависит в том числе от случайных величин (ну типа болезни увольнения и т.п.). Про функцию это я у Шароватова увидел (серия постов про планирование), мне кажется, что хорошая модель.

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

Это значит, что по теореме Вейерштрасса можно аппроксимировать нашу функцию полиномами по X.

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

Значит, наша функция f, наш план, полностью определяется рисками (чувствительностями) проекта к входящим аргументам.

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

Получается, чтобы составить план, нужно:
1. Определить набор рисков (вид функции f). Для этого нужно понять, как мы будем делать
2. Оптимизировать риски (коэффициенты при X в f). Это включает в себя управление вероятностями исходов И управление импактом от реализации риска

Просто прикол вам рассказал, короче 😁

Что упущено?
- Сколько стоит тратить ресурсов на планирование
- Что делать, когда Y это не константа, а неизвестная (в разной степени)
- Какие можно выводы делать из этой модели? Какие есть параллели с нашими любимыми рисками (опционными)? Какие типичные формы функции можно выделить?

Божечки ты мой, как я её понимаю, хоть и не врач. Ну, кто читал здесь посты про научпоп и докмед, тот знает.

Я тут устроил своего рода книжный клуб с LLM'кой. Хотя скорее даже проконсультировался со "специалистом"! Поспрашивал некоторые не вполне ясные мне вопросы из платоновских текстов у Gemini. Классно! Никакие хитрые промпты я не использовал, просто задавал вопросы в режиме диалога. Отвечает хорошо, понятно, соглашается, что места довольно запутанные, но успешно раскладывает по полочкам, что имелось в виду. Любопытно, что ответы у неё довольно лаконичные. Мне понравилось, буду и дальше с компьютером книжки обсуждать теперь.

Кстати, а вы знали, что лаконичность это свойство речи лакедемонян (спартанцев по-нашему)?

Еще про планирование

В предыдущем посте выяснили, что у нас проект это какой-то стохастический процесс. Что это значит? Это значит, что у нас есть вероятностное пространство! (Omega, F, P) — множество элементарных исходов, сигма алгебра и вероятностная мера. Что примечательно, сигма алгебра вообще говоря не обязана быть одинаковой для каждого момента времени t. Более того, если мы с вами посмотрим на то, как устроены большинство стох моделей, имеющих отношение к реальному миру, то увидим, что сигма алгебра в них расширяется со временем.

Я напомню, что сигма алгебра это, простыми словами, набор того, что может случиться. И вот эта мера P, она задана именно на сигма-алгебре F, т.е. она умеет мерить вероятность конкретного события.
Так вот, из-за того, что какие-то события происходят, информация о них имеется во все последующие моменты времени. Но вот в моменты времени t<t_n нет никакой информации о событиях, которые происходят начиная с момента t_n. Из-за этого сигма алгебра расширяется, информированность растёт. Уровень неопределенности уменьшается (*не убывает для душнил типа меня).

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

Зачем нужны джуны?

Многие задумывались: почему бы не взять в команду одних сеньоров и херачить всё быстро, качественно и умно? Хороших ответов я не слышал. Обычно говорят, мол, дорого. В том смысле, что всегда есть рутинная и простая работа, за которую платить сенбору дорого. Возможно. Но, честно говоря, не убедительно. С моим опытом не бьется. Сеньоры простые рутинные задачи делают гораздо быстрее, не тратят время на корректировки решений от младших, могут нормально подумать о сложных вещах, пока код пишут. Time to market одними сеньорами точно меньше.

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

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

Так, ок, а че джуну делать?
ОТВЕЧУ ПРИТЧЕЙ.
Когда я был маленький, я смотрел на сеньоров вокруг, делал всё то же, что они и не понимал, какого хрена я джун, а они сеньоры, если мы делаем одно и то же. Потом я вырос и понял, что разница между нами была в том, что сеньоры еще могли и мидловскую работу делать, а я — нет. Но матриц компетенции не было, а на мидлов я не особо смотрел (вероятно из-за высокомерия, а может потому что смотрел на "лучших" — не знаю). Поэтому я не знал, что есть что-то еще посередине. Сегодня я вижу таких же ребят в дельта окрестности от себя. Они уже умеют всякое сеньорское (пусть сильно медленнее), но не умеют мидловское. Вспоминаем про бигтехи, ревью и матрицы компетенций. Там прыгнуть через грейд нельзя. А чтобы вырасти в мидла, нужно обладать навыками мидла. Не сеньора. Вот такой парадокс.
Поэтому рекомендация джуну: найти матрицу компетенций, вытрясти из рук-ля образ следующего грейда и качаться в этом направлении. 1/2

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

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

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

Мы же уже провели первую встречу книжного клуба. А читать мы начали не абы что: классику айтишного управления, книгу, на которую ссылалось вообще всё, что я читал хотя бы косвенно связанное с управлением, великий и ужасный The Mythical Man-Month Брукса. Пока мы прочли только первые три главы, но я уже кайфанул. Книге 50 лет, а сутёво ничего не поменялось. Всё те же причины любить программирование, всё те же причины не любить. Мимоходом всё тот же МЕТОД критической цепи (всегда удивлялся, что это прям особый метод, а не что-то очевидное), всё та же история про коммуникации и ресурсы на них, всё те же ошибки в оценках сроков (никто никогда не думает, что будет тетсировать код в три раза дольше, чем будет его писать, но все всегда так и делают).

Отдельно отмечу главу про операционную. Метафора, как обычно, сомнительная, но есть несколько моментов. Во-первых, кросс-функциональная команда (эджайл тренеры до сих пор думают, что это они придумали). Во-вторых, есть явно выделенный лидер, за которым последнее слово, на котором ответственность (это такая борьба с долгим принятием решений и срачами, какой фреймворк болие лудший). В-третьих, в команде специалисты разного уровня! У них там разные функции. Есть самый главный программист, он ДУМАЕТ и принимает решения. Есть copilot (надеюсь, что современная тула это пасхалка), который в целом такой же крутой, но менее опытный. Он челленджит, об него думает главный, он ищет всякие проблемные места, а еще ходит на встречи, где нужна экспертиза в системе. Еще есть чувак, который просто набивает код (на перфокарты, но чем питон лучше?). Еще один чел пилит вспомогательный софт: всякие библиотечки, тулы, окружение (короче, программки масштабом поменьше основного продукта). И отдельно есть language lawyer, человек, который умеет на этих ваших алголах красивые конструкции делать, чтобы код был круче. Остальные там не программисты.

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

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

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

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

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

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

Всё фигня, по-моему. Лучше заставить машину двигать тикеты за людей.

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

2. Переносим действие в ту систему, где человек совершает действие
В нашем случае, система контроля версий, код-ревью, ci/cd -- всё в одном месте, в Аркануме. Настраиваем его так, что на создание пулл-реквеста тикет двигается в статус "пора смотреть", а при мёрже в статус "смёржено". Для гита есть гит-хуки, которые могут точно так же дергать таск-трекер за веб ручки (наверное). Собственно, события сборки и деплоя тоже в идеале должны двигать статусы тикетов.

3. Если не переносится
Тогда есть такой способ последней мили: пинать исполнителя, если тикет дольше нормы в каком-то статусе. У нас это просто джоба, которая раз в час ходит собирает подходящие тикеты и раз в n дней пинает в них исполнителя в комментариях с призывом

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

Отдельная форма боли нормального человека -- создавать задачи. Меня тоже ломает каждый раз. Тут есть две штучки в помощь: автосоздание тикетов и формы. Если можно создавать тикеты автоматически, то нужно это делать обязательно. У нас, например, при создании фича-тикета создается автоматом подзадача на декомпозицию -- мелочь, а приятно. А формочки помогают заполнить всё, что нужно, умеют валидировать типы (например, календарик для дедлайнов нарисуют), заставляют писать обязатльные поля, но так же и дают подсказки по формулировкам и контенту. Чтобы ты ничего не забыл, дорогой.

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

Рассказывайте про свою борьбу с рутиной!

Я ПРОШЁЛ ТИМЛИДА 🤡🤡🤡
по метрикам

У нас в компании замутили пилот оценки руководителей их сотрудниками по восьми показателям. Вот тут наша HR директор Даша рассказывала.

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

Мои ребята там наотвечали так, что я всесторонне развит на максималки.
Как в анекдоте с Физтеха. Почему ты лежишь и нихрена не делаешь? МЫ НА ПЕРЕДНЕМ КРАЕ НАУКИ, ДАЛЬШЕ НИЧЕГО НЕТ.

Короче, приходите ко мне в команду программировать процессинг на golang'е. Метрики говорят, что я идеальный руководитель.

https://yandex.ru/jobs/vacancies/разработчик-процессинга-платежей-golang-15169