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

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

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

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

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

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

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

И здесь снова нужно ловить баланс между выйгрышем времени от скорости принятия решения и проигрышем в скорости из-за падающей производительности исполнителей.

Я бы сказал, что нужно стараться продать каждое решение, искать кворум (а лучше консенсус), но так вы рискуете погрязнуть в обсуждениях типа в какое время команда ходит на обед по четвергам. В таком случае вы не сделаете не то, что поздно, вы никогда ничего не сделаете. Ищите баланс.

Ооооо! 500! Нас пятьсот! Это целых пять сотен или пятьдесят десятков! Невероятно!
Я вообще зашёл токсичный пост написать, но теперь обрадовался и не буду ❤️

Очень интересная статья про грозы с картинками и фотографиями. Люблю такое

MIT и МФТИ братья навек 😁
Это я перешёл по ссылке и почитал мнение студента

Вчера разбирали с тимлидами главы с седьмой по девятую Брукса. В главе Calling the Shot есть прям данные. Я люблю данные, вы любите данные (основано на данных о похожих на мой каналах), все любят данные (не основано на данных). Данные говорят о нескольких вещах.
1. Чем больше система (просто в количестве инструкций), тем меньше кода в ней производят разработчики. Потому что система сложнее. Причем там нелинейный рост сложности. На данных из книги у Брукса получилось effort = C * (LOC)^1.5.
2. Чем больше коммуникаций между разработчиками (для синхронизации работы), тем меньше кода они пишут.
3. Чем больше коммуникаций (неявно выводим — точек сочленения) между командами, тем меньше кода пишут программисты. Здесь вообще всё драматично: 10к инструкций per man-year при маленьком количестве взаимодействий и 1,5к инструкций per man-year при частых взаимодействиях. На порядок!
4. Есть существенная разница в скорости разработки между командами, работающими над разными классами задач (управляющие программы разрабатывались в пять раз медленнее на программиста, чем, пусть и сложный, продукт: компиляторы и ассемблеры).
5. На языках высокого уровня инструкций в единицу времени пишется в пять раз больше, чем на ассемблере.
6. Половина времени разработчиков уходит НЕ на написание и отладку кода. Митинги, больничные, оформление бумаг, личные дела, срочные важные задачи, УМЕР ВАЙФАЙ, ДАЛЕКО ИДТИ ЗА КОФЕ, РАЗМЯТЬ СПИНУ — подобные вещи отъедают половину рабочего времени.

Мы у себя наблюдаем эти закономерности прямо сейчас. Программисты в инфраструктурных командах пишут меньше кода, чем программисты в продуктовых. Даже если это один и тот же программист (у нас есть люди, перешедшие по ротации из продукта, тот же язык, тот же опыт, те же технологии — кода меньше). Есть и обратные примеры.
Кроме того, новые системы, как наш PSP, разрабатываются быстрее, чем большие старые. А разработка сильно замедляется после ввода системы в эксплуатацию — прорастают коммуникации с другими командами, появляется фон багов и т.д.

Какие выводы можно сделать?
Не знаю. Но как минимум мы видим, что сравнивать разработчиков по объемам кода очень сложно. Ещё мы видим, что не приходится расчитывать на 40 часов в неделю от среднего разработчика.

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

Советов не будет.

Несколько месяцев назад прочитал статью про проектный менеджмент. Там утверждалось, что если в проекте из 20 задач, каждая сходится в срок с вероятностью 90%, то проект целиком сходится в срок с вероятностью *попробуйте угадать*. Ответ, который загадал автор посчитать довольно просто, вы умеете, спрячу под спойлер (12%).
Но вот только он неверный.
КАРТИНКИ КАРТИНОЧКИ ЩАС БУДУТ!


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

Но давайте, все-таки проект возьмем.
Здесь нужно явно проговорить предпосылки.
1. Задачи не параллелятся и идут строго друг за другом
2. Вероятности закрыть задачи в срок не зависят друг от друга
3. Все задачи одинаковой длины

Давайте ещё всё-таки считать, что если с 90% вероятностью задача попадает в дедлайн, то она с некоторой вероятностью может быть сделана и раньше дедлайна. Вопреки "закону Дорофеева", я верю, что так бывает.
Ещё давайте считать не точное попадание проекта в дедлайн (оно очевидно стремится к нулю с ростом размера и количества задач), а вероятность закончить проект _до_ дедлайна включительно.

Я взял задачи размером 100 (давайте считать часов).
Я взял 20 задач в проекте.
Тогда проектный дедлайн это 2000 часов.

И расчехляем Монте-Карло симулятор!

Для простоты можем считать, что распределение вероятностей сделать задачку в первый, второй и т.д. час равномерное. Тогда надо взять распределение на (0, 111], на нем с 90% вероятностью задача займет 100 часов. В среднем проект из 20 задач займёт тогда 1113+-144(1 std) часов. С вероятностью 99% проект займет не более 1457 часов.

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

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

Короч, вот я взял логнормальное распределение.
Например, со стандартным отклонением 30% (графики есть для 10, 30 и 90). В среднем проект тогда будет закрываться за 1420+-100 часов, а 99%% это 1665 часов.

Что меня несколько удивило, так это что при увеличении неопределенности (она симметричная), вероятность закончить в срок только растёт (см. для 0.1 и для 0.9). Контринтуитивно, если честно.

Во всех случаях вероятность закончить проект в срок, если каждая задача придет в срок с вероятностью 90%, сильно больше 99% и уж никак не 12%.

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

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

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

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

Пока Василий рефачил, делал какие-то крутые, но никому не нужные фичи (в смысле никому не нужна конфигурация размера кеша http-заголовков??), чинил тесты и учил молодежь, как делать пулл-реквесты на 4к LOC, прошло довольно много времени. Возможно, Василий даже умудрился опоздать к дедлайну, потому что опять забыл заложить время на UA-тестирование.

Как же можно этого избежать? Нужно контролировать скоуп! Должна быть написана спека. Спека это просто, человеческим языком объяснение, что должна делать система. Вход, выход, сайд-эффекты. Круто, если будет еще и формальная спека (openapi, матан, jls ch. 17.4, you name it). Но хотя бы словами.
Спека должна быть минималистична в смысле MOVE (Minial Outcome-Value Effor). То есть фича в спеке должна иметь ценность сама по себе (без необходимости делать еще какие-то фичи, можно продавать, как есть), но при этом в ней абсолютный минимум функционала.

Но спеки недостаточно. Нужно жестко следить за тем, чтобы в рамках задачи/фичи не делалось ничего такого, что в задаче не описано. То есть разработчик должен делать _только_ то, что _необходимо_ для работы фичи.

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

Что там про школы мысли-то?

Вот коллега пишет про дедлайны. Канал, кстати, совершенно замечательный, коллега тоже, подписывайтесь!
Если коротко, то его идея заключается в том, что нужно по каждой задаче ставить жесткий дедлайн и спрашивать за него.

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

1. Когда дедлайн _реально_ жесткий, есть последствия. Вам не заплатят денег, уволят с работы, четвертуют лида. Когда дедлайн "жесткий", вы максимум получите айяйяй и час в углу на горохе.
2. Когда делайн _обоснован_, люди _верят_, что это дедлайн и делают работу. Иначе это просто best effort.
3. Мы тут с вами выясняли, что никто не умеет оценивать. Некоторые, кстати, верят, что умеют или что могут научиться. Но пока что никто не умеет. А значит обязательно будут ошибки с дедлайнами. В обе стороны. Кого будут наказывать за хреновые оценки, впрочем, не уточняется.
4. В качестве способа достижения дедлайна указывается срезание углов и уменьшение скоупа. У меня вопрос: если что-то можно вырезать из скоупа, то почему бы не вырезать это с критического пути сразу? А всё nice-to-have'овое доложить в ганта где-нибудь с краешку, на случай внезапно освободившихся ресурсов.
5. Если _реально_ эскалировать всё подряд, то можно доэскалироваться. Как мы тут с вами знаем, подавляющее большинство работы в компании можно вообще не делать, будет только лучше. А если на каждую фигню отнимать время руководителей, то на действительно важные ресурса не останется.
Здесь хочется отметить, что требовать эскалации могут задачи на критическом пути. И то не все.

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

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

Сегодня защитились мои ребята магистранты. Двое получили отлично, ещё двое капельку не дотянули до отла и получили хорошо (7) отл начинается с 8, один решил не защищаться в этом году по итогам предзащиты.
Поздравляю ребят! Два года занятий после работы, домашек по выходным и работе над полноценным проектом для диплома наконец-то окончены.
Получилось хорошо, сделали рабочий прототип, расписали реалистичный роадмап, можно даже пробовать это развивать в реальный бизнес.
Что мне особенно нравится в этом проекте: бизнес-план, маркетинговая компания, развитие ИТ-систем — всё связано между собой. То есть из работ ребят совершенно ясно, почему и в какой момент будет сделана та или иная фича, и как и когда изменится архитектура приложения, как будет меняться позиционирование на рынке. Я доволен.
Пока мне это достоверно не известно, но думаю, что получилась одна из самых сильных работ на потоке. Спасибо за работу, господа магистры 😊