Дневник тимлида C++
27 subscribers
46 photos
1 video
1 file
14 links
Откровенные заметки из жизни лида C++ разработчиков. Ситуации, проблемы, открытия и решения. Для обсуждения заходите в чатик https://t.me/teamLeadDiaryChat
Download Telegram
Лекция 6. Системный анализ аппарата руководства.

🧩 Как устроен аппарат руководства:

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

Но... всё гораздо сложнее.

📌 Мышление и реальность — разные миры

Щедровицкий говорит: то, как вы мыслите — это не реальность. Это — ортогональная плоскость, не совпадающая с действием. Чтобы мысль воплотилась, нужны сложные процедуры переноса — иначе говоря, проектирование. Мы всё время живём «в системе зеркал» — реальность отражается в мышлении, но никогда не совпадает с ним.

📌 Аппарат руководства — не просто иерархия, а система

Начальник, его замы, главный инженер — это не люди, а должности, связанные формальными связями. Эти связи живут независимо от личностей. Подчинённый подчиняется не Иванову, а «начальнику управления». Винтики в схеме.

Но есть и другая сторона.

📌 Формальное и неформальное: два слоя одной ткани

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

Причём клуб существует не только за пределами офиса. Он всегда проникает в производство: начальник может «договориться», «попросить по-человечески», а не сослаться на регламент.

📌 Человек — и винтик, и личность

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

📌 И тут возникает парадокс системности

Формально — вы часть одной системы управления. Но каждый ваш заместитель тоже управляет своей мини-системой. И вот вы уже не в едином механизме, а в переплетении автономных подсистем, «насаженных» друг на друга. Как стержни, на которые нанизаны сети — вы становитесь точкой пересечения.

📌 А что же тогда такое система?

Не вещи. Не «столы и стулья». Система — это связи и процессы. Но если убрать один элемент, система разрушается. И в то же время — каждый элемент участвует во множестве других систем. Формально отрезать границы нельзя — всё взаимопроникает. Получается слоёный пирог.

📌 Идея, изменившая подход к человеку

Маркс сказал: человек — это совокупность общественных связей. Без места в социальной структуре — нет человека. Даже тунеядец становится «человеком», когда получает определённую функцию. Иными словами: мы — это не только тело, но и место в системе. Сложной, многослойной, переплетённой.

📌 Управленец — это не кукловод, а режиссёр ансамбля

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

🤔 Главный вывод Щедровицкого:

Чтобы управлять системами, нужно сначала научиться правильно их мыслить.


И для этого одних схем и инструкций недостаточно. Нужно новое мышление. Новые понятия целостности. И новое понимание того, что такое — быть человеком в системе.
👍1
Рефлексия начальника управления строительством.

Зарисую возможные позиции начальника управления строительством. На схеме три позиции. Но у нас ведь не три начальника управления строительством, а один. А я зафиксировал его тройное существование: один раз он существует как место — как начальник управления строительством; второй раз он существует как наполнение этого места; третий раз он существует без места (скажем, кончились работы, он поехал отдыхать или приехал сюда, в ИПК).
И наконец, у него есть четвертая позиция, со звездочкой, когда он рефлектирует и сам себя во всех своих ипостасях и формах существования анализирует и представляет. И за счет этого в рефлексивной позиции у него на доске и на табло может получаться интересная вещь.
На доске он сам может быть представлен как объект: он сам себя видит со стороны. Если он изощренный, он себя рефлектирующим тоже представит, если не очень, то представит себя только в остальных позициях.
Про PERT из лекции 6.
#лек_6

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


Необходимость в сетевых графиках возникает тогда, когда вы можете не выполнить календарный план, и тогда вы начинаете играть в эти сетевые графики. Чтобы наверстать, вы составляете варианты такой организации работы... Когда американцы разрабатывали систему подводной лодки «Поларис», у них была технология, а сетевые графики родились из организации системы поставок. Им надо было получить два миллиона шестьсот четыре тысячи узлов. И нужно было определить, когда что. Технологический процесс определял сроки, а дальше надо было с помощью метода сетевого планирования определить начало работ, распределить ресурсы и т. д. Реально технология всегда есть ограничение на сетевой график. Она — как глубинная структура, а дальше мы должны маневрировать ресурсами с помощью метода сетевого планирования там, где нас не держит технология — в зазорах, на стыках, в степенях свободы от технологического процесса.
Как Проверка Тестовых Заданий Перезагрузила Мое Видение

Знаете, иногда рутина может незаметно подкрасться. Взялся недавно проверять тестовые задания кандидатов в стажёры. Казалось бы, что тут такого? Смотришь код, пишешь плюсы и минусы каждого кандидата и оцениваешь его вконце, нажимая зовем/не зовем на интервью. Но этот простой процесс начал меня... выматывать. Каждый день количество кандидатов увеличивалось. Эйчар мне посылает каждый день по 2-3 анкеты с заданием. Я начал хватать выгорание.

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

🔄 Паттерны применены у 5 процентов! Сколько же грамотного применения Consumer-Producer! Фабрики там, где они действительно нужны. Это не просто код, это уже применение опыта из книжек и советов stackoverflow.

🧪 Тесты? Обязательно! Многие (20 %) использовали gtest. Видеть юнит-тесты в тестовом задании – это уровень. Приятно видеть, как тестовый код запускает пользотельский. Это говорит о понимании качества.

GitHub-портфолио: Около 40% работ были оформлены на GitHub не просто как код, а как презентация себя и своих четких достижений. Чистые репозитории, внятные README, project-tree в середине, шаги к тому как запустить код и тесты. Это показатель ответственности и желания добить задачу до конца.

Те самые 3%: И – особый увжение людям! – те единицы, кто спросил. Уточнили у рекрутера, задали осмысленные вопросы. Знаете, для меня это ключевой индикатор. Я всегда готов с огромной прилежностью уделить внимание задающему вопрос.

Конечно, был разброс: кто-то показал навыки уверенного мидла, а кто-то... даже не дочитал задание до конца или проигнорировал требования (надо было сделать под Линукс 😉).

Но главное открытие пришло неожиданно:

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

Мы все – часть одного большого Дела. 🔥 Мы все проектируем, создаем, отлаживаем, тестируем. Каждый на своем месте, но ВМЕСТЕ.

И это – ТРИУМФ! Триумф не над кем-то, а над усталостью и сомнениями. Триумф понимания, что поток талантов и энтузиазма – реальность.

Поэтому о выборе:

Я не буду искать просто "самых лучших" по формальным критериям. Я не буду искать просто "самых прилежных".
Я буду искать самых ИНТЕРЕСУЮЩИХСЯ. Тех, кто спрашивает. Тех, у кого горят глаза. Тех, для кого этот код – не просто тест, а шаг в профессию, которой они искренне хотят учиться.

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

Напишите в комментариях: что для вас самое главное в программировании, конкретно, то, ради чего садитесь за код? Что самое главное в будущих стажерах?

Скоро: чек-лист 5 признаков сильного стажера в C++

#разработка #стажировка #программирование #карьера #мотивация #it #github #тестирование #gtest #паттерны #выгорание #триумф #команда #интерес #вопросы #учиться #будущееIT
3🔥1
5 признаков сильного стажера в C++.pdf
106.4 KB
Делюсь своим чек-листом чек-лист 5 признаков сильного стажера в C++
2👍1
❄️ Холодный пот: Когда за словами — пустота. ❄️

Сегодня было собеседование. Студент. Сделал задание хорошо. Говорит уверенно:
О, враппер? Класс-обертка для расширения поведения!

Фух, знает - мелькает надежда...
Уточняю: Зачем подставлять реализацию в него? Можно же скопировать код, или изменить изначальный класс?

Тишина. Глаза бегают. Уверенность тает на глазах.
Ну... для гибкости? — неуверенный шепот.

Холодок по коже. Иду глубже:
Допустим, враппер должен уведомить нас о завершении долгой операции. Как?

Эээ... Колбэк? — ловит спасательный круг-термин.

А ЗАЧЕМ? Что происходит, когда ВЫЗЫВАЕТСЯ этот колбэк? Как управление возвращается?

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

Чувствую ледяную тревогу.
Не за него — выучит.
За НАС. За индустрию, за университет.

Когда базовые паттерны (Wrapper/Adapter) и принципы (инверсия управления) — просто слова без понимания сути...
Что мы строим? На каком фундаменте? На каком образовании?

Как вам кажется? Это только у меня так? 🤯 Обсудим в комментариях?
#cpp #тимлид #собеседование #паттерны #тревога
3
Когда "Нет" стало стартом: история собеса, где мы дали шанс вместо отказа
Второе интервью 👋 Хочу поделиться необычным кейсом. Эмоции после — легкая ирония, но главное: уверенность, что потраченные 30 минут стоили того.

Сценарий:
🧑 Кандидат: вежливый, резюме — "3 года учебного С++", тестовое — идеально (спасибо его "другу" 👀).
💣 На техсобесе: тишина. Базовые вопросы — "простите, не знаю". Три тимлида — ноль ответов.

Вместо "до свидания":
Мы осознанно устроили мини-обзор работы! Каждый за 5 минут дал практический срез своей реальности:
✔️ "Какие задачи решает трейни у нас?"
✔️ "С какими вызовами столкнешься?"
Его вопрос: "Какую задачу дадут в первый день?" (респект за смелость!)

Почему закончили интервью?
👉 Честность: Он не врал — "Не знаю" звучало чаще любого паттерна.
👉 Готовность учиться: Впитывал как губка.
👉 Ностальгия: Узнал себя студентом.

Мой вклад:
Рассказал фундамент, который выручит всегда:
🌐 HTTP: как клиент/сервер "разговаривают"
🔧 Парсеры: зачем они и что парсят (html, xml, json)
🚀 Чеклист: сети (TCP/IP), алгоритмы, паттерны → учить системно.

Выводы для команды (без стыда!):
Эта ситуация — отправная точка для калибровки процессов:

1️⃣ HR + Tech: синхронизируем чеклисты
• Какие конкретные базовые вопросы задавать на скрининге под "3 года опыта"?
• Как проверять понимание, а не умение гуглить?
• Тестовое + разбор решения с кандидатом (чтобы "друг" не делал всю работу).

2️⃣ Техлидам: рефлексия вместо допросов
• Где в собесе точки остановки? Говорить "нет"?
• Что реально должен знать trainee в 2025?
• Избегать сценария "допрос vs бесплатная лекция"?

P.S. Ваша смелость + честное "не знаю" + готовность впитывать — вызывают уважение. Учитесь — и возвращайтесь!

#HR_процессы #Собеседования #Trainee #Менторинг #Рефлексия
#Человечность #JuniorDev #КарьерныйРост
🔥3🤔1
Почему мой блог о C++ не будет выходить каждый день

Меня последнее время преследует одно чувство. Хочешь вести свой блог, писать о том, что волнует. Но идеи, развернутые в пост не приходят. Возможно и сил писать ежедневно просто нет. Вести свой блог - это не должно стать тем самым состоянием, которого все боятся. Думаю, я не буду писать все о метапрограммировании, скорее напишу, как использовал сам constexpr. Постараюсь не писать книгу про многопоточность, как Райнер Гримм. Напишу про разницу между conditional variable и применение мьютексов. Мои первые 20-30 постов будут сырыми как raw pointers . Хочу создать свой уникальный путь, а не очередной учебник. Может быть в итоге собрать вокруг себя единомышленников, как хотел когда-то мой приятель в школе. Напишу пару новостных постов, например о том, что вышел ремастер MGS3, или про то, как устроено PS3. Или о том, что андроид хочет запретить установку через apk-файлы, и как подобраться к сборке AOSP, или Kiwi Browser. Посты будут выходить раз в две недели, по пятницам. Без суеты.

#тимлид #cplusplus #разработка #карьера #блогинг #менторство
👏2
Важность планирования на планшете.

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

Сейчас набирает популярность open-source сервис excalidraw.com Его применение все чаще можно встретить у блоггеров в видео на ютубе.
Простой инструмент удобный, collaborative, можно с командой в реальном времени рисовать, а потом ссылку кинуть — и всё работает без регистрации. 

В каком то смысле, это и есть тот планшет со схемами, о котором говорил Щедровицкий в #лек_5. В посте о важности схем приведены конкретные цитаты.

Например, нужно структурировать сложные, разрозненные идеи и донести их до команды/менеджера/себя самого. Стандартные инструменты (тот же Confluence) для этого слишком формальны и негибки.

А тут перед тобой открывается простой минималистичный холст, в котором можно писать текст, добавлять различные фигуры (ромб, квадрат, круг). Писать внутри них. Соединять стрелками. При последующем перемещении стрелки магнитятся к краям фигур и могут перемещаться вместе с ними. Можно вставить картинку, видео с ютуба, которое будет in place проигрываться.

Но мне могут возразить:
Рисовать схемы вручную? В 2024-том? Это же так... Долго. Я промптом в GPT-4o или Claude прошу: «нарисуй диаграмму последовательности для микросервиса аутентификации на C++ с использованием JWT и Redis для кеширования». И через 10 секунд получаю готовую, идеальную диаграмму в PlantUML или Mermaid. Я её потом только немного кастомизирую. Зачем тратить время на ручное рисование, если ИИ может сделать это за меня и, возможно, учесть нюансы, о которых я даже не подумал? Ваш Excalidraw — это крутой костыль, но будущее за prompt-based design.

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

Все знают, что резюме проверяют с помощью ИИ.

при этом все знают, что резюме пишут с помощью ИИ.

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

Ох...

Но при этом они знают, что можно руками подредактировать резюме, которое написала ИИ, и его все равно не заметит система... Вот это да!
😁5
Внезапно Linux не грузится и показывает странную консоль initramfs> после сбоя? Не паникуйте. Это не крах — это система просит вас о помощи.

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

ПЛАН (что делать):
1. В строке initramfs> пробуем команду fsck -y /dev/sda1 (чаще всего sda1, но может быть nvme0n1p2 и т.д., можно посмотреть ls /dev).
2. Если просит — жмём y (yes). Ждём завершения.
3. Пишем exit и пробуем загрузиться. В 90% случаев этого хватает.

Готово? Система запустилась? Вы только что вручную починили файловую систему! Теперь можно выдохнуть и разобраться в сути.

А ЧТО ЭТО БЫЛО?

Initramfs — Это мини-ОС в оперативке, чья задача — подготовить всё для загрузки основной системы. Если он не справляется и зовёт вас, причины обычно в этом:

▫️ ФС была повреждена (самое частое после сбоя питания)
▫️ Не может найти корневой диск (проблема с драйверами или конфигом)
▫️ Аппаратный сбой (отходит шлейф, умер диск)

Ваша реакция на initramfs> — это и есть то, что отличает специалиста от пользователя. Вы не переустанавливаете систему с нуля, а чините и подкручиваете её. Это ценный навык.

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

#linux #admin #восстановление #hardcore #timely_advice #собес
👍21
Смотрел сегодня мок-собесы и увидел совместную реализацию двух паттерное.

1. Первый - такназываемый «синглтон Мейерса»

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

Это идиома реализации синглтона в C++, предложенная Скоттом Мейерсом. Она использует статическую локальную переменную внутри функции-геттера:

class Singleton {
public:
static Singleton& instance() {
static Singleton s_instance;
return s_instance;
}

private:
Singleton() = default;
~Singleton() = default;
Singleton(const Singleton&) = delete;
Singleton& operator=(const Singleton&) = delete;
};

Какие особенности есть у этого похода:

- Ленивая инициализация: объект создаётся при первом вызове instance().

- Автоматическая корректная деинициализация: деструктор вызывается при завершении программы.

- Потокобезопасность (в C++11 и выше): стандарт гарантирует, что инициализация статической локальной переменной атомарна и потокобезопасна.

Доступность: к открытым методам такого класса можно получить доступ из любой точки мира, при условии, что вы включили заголовочный файл в другие файлы проекта с помощью #include.

2. CRTP (Curiously Recurring Template Pattern)

CRTP — это идиома, где базовый класс принимает в шаблоне тип производного класса:

template <typename Derived>
class SingletonBase {
public:
static Derived& instance() {
static Derived s_instance;
return s_instance;
}

protected:
SingletonBase() = default;
~SingletonBase() = default;
};

class MySingleton : public SingletonBase<MySingleton> {
friend class SingletonBase<MySingleton>; // чтобы конструктор был доступен
private:
MySingleton() = default;
};

Преимущества данного похода

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

#singleton #design_patterns #crtp
👍1
Точечные оценки — красивая ложь

Проект займёт 14 недель

— слышали такое?
Я слышу это постоянно. И каждый раз внутри меня что-то сжимается 😅
Эта цифра создаёт иллюзию точности. Как будто кто-то заглянул в будущее и увидел дату релиза. Реальность: это одна из тысяч возможностей.

Помню, как в одном проекте менеджер с уверенным видом объявил:
12 недель, не больше

Спойлер: проект занял 22 недели.

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

Точечная оценка без вероятности бессмысленна.

Она подразумевает 100% гарантию, хотя в разработке нет ничего гарантированного.

Три понятия, которые путают:

Оценка — вероятностный прогноз
Цель — желаемый результат
Обязательство — договорённость с учётом рисков

Когда менеджер говорит «14 недель», спросите: «Какова вероятность этого числа? 50%? 30%? 10%?»

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

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

А как у вас в команде с оценками? Говорите диапазонами или всё ещё верите в магию точных цифр?
5🔥1😁1
Асимметрия реальности

Многие представляют сроки проекта как колоколообразную кривую - симметричное распределение вокруг среднего (как нормальное распределение Гаусса).
Это неправда.

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

Помню, как менеджер спросил меня: «А если мы добавим ещё разработчиков?» Я ответил: «Девять женщин не родят ребёнка за месяц». Он не оценил мою метафору, но суть понял 🙃

А вот количество проблем ничем не ограничено:

Критические баги в продакшене
Уход ключевого разработчика
Изменение требований на 80% готового проекта
Проблемы с инфраструктурой
Интеграция, которая «должна была работать из коробки»

Эти пункты - не теория. Это список из моего последнего квартала. Причём все пять случились в ОДНОМ проекте. Одновременно. Я до сих пор не понимаю, как мы выжили 😁
Результат: график вероятностей имеет короткий левый хвост и длинный правый.
Медиана (точка 50/50) показывает: половина проектов завершится раньше, половина - позже. И эта «половина позже» может растянуться ОЧЕНЬ далеко.
Самый долгий проект в моей практике должен был занять 3 месяца. Закончили через 11. И нет, это не провал - это просто реальность, в которой работают разработчики.


А у вас был такой проект-долгострой? Сколько в итоге длился и что пошло не так?
🔥1
Иллюзия 90% уверенности

Эксперимент: людям дали тест из 10 вопросов. Нужно указать диапазон ответа с «90% уверенностью».
Результаты:

Средний балл: 2.8 из 10
Только 2% получили 8+ правильных ответов
Никто не ответил верно на все 10

Когда я впервые прочитал про этот эксперимент, подумал:
Ну это же они, обычные люди. Мы-то в IT поумнее


Провёл похожий тест в своей команде. Угадайте результат? Правильно, точно такой же провал 😅

Вывод:
интуитивное ощущение «90% уверенности» на деле соответствует примерно «30% уверенности».

То же самое в проектах. Команды регулярно представляют графики с «90% уверенностью» и регулярно их превышают — в 50-60% случаев, а не в 10%.

Был у меня один тимлид, золотой человек. На каждой планёрке: «Я на 90% уверен, что закончим к пятнице». Знаете, сколько раз из десяти он укладывался? Три. ТРИ, Карл! Это вообще 30%, а не 90%.
Я его спросил:
Слушай, а ты понимаешь, что значит 90%?

Он посмотрел на меня и честно ответил:
Ну... я просто так чувствую

Вот она, вся наша «уверенность» 🙃

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

Сейчас, когда кто-то в команде говорит «я на 90% уверен», я достаю блокнот и говорю:
Отлично! Давай запишем. Будем проверять калибровку твоей уверенности

.Обычно после этого люди начинают говорить более честно: «Ну... наверное, половина на половину» 😁

А вы когда-нибудь ловили себя на таком? Говорили «я уверен на 90%», а потом оказывалось совсем не так?
2