Ламель — гнутая деревянная планка под матрасом. Пока не знаешь слова, ищешь «рейки для кровати» и получаешь всё подряд: от вагонки до целых оснований. Со словом деталь находится за минуту.
Я собрал слова, которые работают так же. Lean делит беспорядок в цеху на семь конкретных потерь. Jobs to be Done отделяет задачу, ради которой купили продукт, от возраста покупателя. Ниже 34 таких слова. Термины оставил на английском; где есть прямой русский перевод, он стоит рядом серым. Каждая карточка устроена одинаково: сначала фраза, которой обходятся без слова; потом — что слово добавляет; в конце — что с ним делать.
У этого явления есть имя. Психологи Kaidi Wu и David Dunning называют его hypocognition: нет схемы понятия — не видишь явления и не замечаешь, что не видишь. Scott Alexander смотрит с другой стороны: у идеи должно быть короткое имя — concept handle, — иначе её не передать и не обсудить. Ламель — моя версия того же.
С какого вопроса начать
Если узнал свою ситуацию — вот слово для неё.
- Метрика зелёная, а продукт мёртвый. — Goodhart’s law, Reward hacking
- Всё отгрузили, ничего не изменилось. — Output vs outcome
- Три фичи на одну проблему, не знаем, с какой начать. — Opportunity vs solution
- Хотим улучшить всё понемногу. — Theory of Constraints
- Запустим сразу всё целиком. — Gall’s law, YAGNI
- «Это сложно», нужен подробный план. — Cynefin
- Новый инструмент всё упростит. — Essential vs accidental complexity, Tesler’s law
- Ответ звучит уверенно, значит, верный. — Grounding, Parametric vs retrieved memory
- Мы оба понимаем, о чём речь. — Conceptual pact, Common ground
- Мы уже столько вложили. — Sunk cost
- Подпишем рамочно, цену договорим по ходу. — Hold-up, Incomplete contract
- Перевыполнили план — план подняли. — Ratchet effect, Goodhart’s law
Lean бережливое производство
«В цеху беспорядок. Надо работать эффективнее.»
Инженер Toyota Taiichi Ohno разложил этот беспорядок на семь потерь: перепроизводство, ожидание, лишняя перевозка, лишняя обработка, лишние запасы, лишние движения, брак. Перепроизводство порождает остальные шесть: сделал больше, чем нужно, — теперь это хранишь, возишь и переделываешь. Lean Enterprise Institute до сих пор ведёт этот список. Слово Lean держит его целиком. Призыв «работать эффективнее» не даёт ничего.
С этим словом идёшь в цех и называешь конкретную потерю.
Product-market fit соответствие продукта рынку
«Мы запустились. Людям вроде нравится.»
Венчурный инвестор Marc Andreessen в заметке «The only thing that matters» провёл границу: до соответствия продукта рынку и после. До — каждую продажу приходится вытягивать. После — спрос обгоняет то, что компания успевает сделать, и даже средний продукт на сильном рынке выживает. «Людям нравится» этой границы не показывает: можно долго собирать похвалу и оставаться по эту сторону.
Вкладываться в рост имеет смысл, когда спрос уже тянет сам.
Jobs to be Done
«Наши пользователи 18–35 хотят молочный коктейль.»
Профессор Harvard Business School Clayton Christensen предложил смотреть на продукт как на работника: человек «нанимает» его на конкретную задачу. В его разборе утренний коктейль покупали, чтобы скоротать дорогу на работу и не проголодаться до обеда. Возраст покупателя и абстрактная «потребность» эту задачу не называют. Продукт «увольняют», когда с той же задачей лучше справляется что-то другое.
Спрашивай, на какую задачу тебя наняли сегодня утром. Возраст покупателя об этом не расскажет.
Four risks четыре риска
«Соберём прототип — и сразу станет ясно, делать или нет.»
Marty Cagan, партнёр консалтинговой компании Silicon Valley Product Group, в статье «The Four Big Risks» раскладывает один вопрос «делать или нет» на четыре. Value — купят ли, будут ли пользоваться. Usability — разберутся ли, как это работает. Feasibility — смогут ли инженеры собрать это за имеющиеся время, навыки и технологии. Viability — выдержит ли решение продажи, юридические ограничения, экономику и обещания бренда. У каждого вопроса свой ответственный и своя проверка. Один прототип редко отвечает на все четыре.
Перед тем как собирать прототип, назови, какой из четырёх рисков он проверяет.
Discovery vs delivery
«В дорожной карте одни задачи на разработку. Исследование мы уже провели.»
Marty Cagan в статье «Discovery vs Delivery» различает две работы одной команды. Discovery — выяснить, стоит ли решение того, чтобы его строить. Delivery — построить его в промышленном качестве. Обе работы идут одновременно, каждую неделю; это не этапы проекта и не разные отделы. Если в дорожной карте остались только задачи на сборку, discovery уже пропал — даже когда все заняты.
В плане на неделю должны быть видны оба хода: что команда проверяет и что отдаёт.
Output vs outcome
«Мы всё отгрузили. Почему ничего не изменилось?»
В продуктовой модели Silicon Valley Product Group output — то, что команда выпустила: экран, отчёт, релиз. Outcome — то, что изменилось у клиента или в экономике компании. Релиз может пройти идеально, а изменений — ноль. Тогда команда закрыла задачу и промахнулась мимо цели.
Спрашивай, какое поведение должно измениться. Сам факт релиза ответом не считается.
Opportunity vs solution возможность и решение
«У нас три фичи на одну проблему. Какую делать первой?»
Teresa Torres, консультант по продуктовым исследованиям (Product Talk), рисует дерево возможностей и решений. Наверху — результат, который команда хочет получить. Под ним — боли и желания клиентов. Под каждой болью — несколько решений. Под решением — проверки самых рискованных допущений. Прыжок сразу к фичам сплющивает дерево в список. Три фичи на безымянную проблему — признак, что средний слой, боли клиентов, ещё пуст.
Сначала назови результат и боль клиента. Фичи сравнивай между собой только под одной болью.
Continuous discovery непрерывное исследование
«Сначала исследование, потом разработка. Пользователей позовём в конце этапа.»
Teresa Torres в книге «Continuous Discovery Habits» задаёт другой ритм: те, кто делает продукт, каждую неделю сами разговаривают с клиентами — понемногу, ради одного результата. Исследование идёт параллельно с разработкой: без отдельного этапа и без отчёта из соседнего отдела. Скромное дерево, которое обновляют каждую неделю, работает лучше красивого, нарисованного один раз.
Поставь в календарь еженедельный разговор с живым клиентом для тех, кто пишет код и рисует интерфейсы.
Tesler’s law закон сохранения сложности
«Сделаем интерфейс совсем простым. Пусть пользователь ничего не настраивает.»
Larry Tesler, который делал интерфейсы в Xerox PARC и Apple, сформулировал: у каждой задачи есть сложность, которую нельзя убрать. Вопрос только в том, кто её несёт — система или человек. Упростил экран — сложность переехала пользователю, разработчику или в поддержку. Убрать её нельзя, можно только переложить. Laws of UX приводят это как правило дизайна: «совсем простой интерфейс» часто значит «мы переложили работу на клиента».
Когда убираешь сложность из интерфейса, назови, куда она переехала. Не можешь назвать — она осталась у пользователя.
Goodhart’s law закон Гудхарта
«У нас есть KPI (key performance indicator, ключевой показатель) — значит, мы этим управляем.»
Экономист Charles Goodhart заметил: статистическая закономерность ломается, как только по ней начинают управлять. Антрополог Marilyn Strathern сжала это в одну фразу: когда мера становится целью, она перестаёт быть хорошей мерой. Зелёный KPI и мёртвый продукт часто живут вместе: число уже оптимизируют, а смысл из него ушёл.
Если число само стало целью, считай, что оно уже врёт, и смотри на реальное поведение людей.
Theory of Constraints теория ограничений
«Давайте понемногу улучшим всё. Каждому участку — новый станок.»
Физик и консультант Eliyahu Goldratt в теории ограничений задаёт порядок действий: найти узкое место, выжать из него максимум, подчинить ему всё остальное, расширить его, повторить. Улучшать участок вне узкого места бессмысленно: очередь перед узким местом только вырастет. Вчерашнее правило, которое спасало узкое место, завтра само становится узким местом.
Найди участок, который задаёт темп всей линии, и вкладывайся только в него.
Gall’s law закон Галла
«Спроектируем сразу всю систему целиком. Потом запустим.»
Педиатр и автор John Gall в книге «Systemantics» (1975) сформулировал: сложная система, которая работает, всегда вырастает из простой системы, которая работала. Сложная система, спроектированная с нуля, не работает, и починить её нельзя — приходится начинать заново с простой работающей. Запуск «всего сразу» пропускает шаг, на котором система учится работать.
Найди самую маленькую версию, которая уже работает, и расти от неё. Нет работающей маленькой — не будет и большой.
Cynefin
«Это сложно. Нужен подробный план и строгий процесс.»
Исследователь David Snowden и консультант Mary Boone в статье для Harvard Business Review (2007) делят ситуации на пять видов: ясная, запутанная, комплексная, хаотическая и неопределённая — когда ещё непонятно, какая из четырёх. У каждой свой первый шаг. В ясной работает правило. В запутанной — эксперт и анализ. В комплексной — осторожный эксперимент, а потом выводы. В хаосе — сначала остановить пожар. Слово «сложно» смешивает комплексное с запутанным. План, который спасает в запутанной ситуации, в комплексной только вредит.
Сначала определи вид ситуации, потом выбирай процесс. Комплексную ситуацию ещё одним планом не вылечить.
Chesterton’s fence забор Честертона
«Никто не помнит, зачем это правило. Уберём.»
Писатель G. K. Chesterton в книге «The Thing» (1929) описал забор посреди поля. Реформатор говорит: не вижу, зачем он, — убрать. Умный реформатор отвечает: сначала выясни, зачем его поставили, потом решай. Правило, смысл которого забыли, — ещё не бессмысленное правило: оно могло закрывать проблему, которая исчезла ровно потому, что правило работало. Убираешь правило — проблема возвращается.
Прежде чем отменить правило, найди, от чего оно защищало. Не нашёл — ищи дальше или отменяй с планом, как заметить возврат проблемы.
Essential vs accidental complexity существенная и случайная сложность
«Новый фреймворк ускорит нас в десять раз. Сложность уйдёт.»
Инженер и автор Frederick Brooks в статье «No Silver Bullet» (1986) разделил сложность самой задачи и сложность, которую добавили инструменты, языки и организация работы. Первую не убрать никаким инструментом: она в самой задаче. Вторую можно срезать — и часто именно её продают как революцию. Смена фреймворка убирает случайную сложность. Задача остаётся прежней.
Спроси, какая часть трудностей уйдёт со сменой инструмента, а какая останется, потому что так устроена сама задача.
Conway’s law закон Конвея
«Архитектуру спроектируем отдельно. Команды потом подстроятся.»
Программист Melvin Conway в статье «How Do Committees Invent?» (1968) заметил: устройство системы повторяет то, как общаются люди, которые её делают. Frederick Brooks назвал это законом Конвея. Разделил команды — через квартал между их частями появится стык, а на стыке — слой костылей. Есть и обратный ход: сначала решить, какую архитектуру хочешь, и выстроить общение людей под неё.
Прежде чем делить систему, посмотри, кто с кем уже разговаривает. Границы системы пройдут там же.
Hyrum’s law закон Хайрума
«Это не в документации. Значит, можно менять.»
Инженер Google Hyrum Wright заметил: при достаточном числе пользователей интерфейса неважно, что обещано в контракте — на любое наблюдаемое поведение системы кто-то уже опирается. Порядок элементов в ответе, время отклика, текст ошибки — всё, что видно, становится обязательством. Слово «недокументировано» защищает, только пока пользователей мало.
Перед изменением спроси, мог ли кто-то заметить старое поведение. Если мог — это уже контракт, что бы ни говорила документация.
CAP теорема CAP
«База данных должна быть всегда согласованной и всегда отвечать.»
Eric Brewer, профессор Калифорнийского университета в Беркли, в докладе 2000 года назвал три свойства распределённой системы: consistency (согласованность данных), availability (доступность) и partition tolerance (устойчивость к разрыву сети). Исследователи MIT Seth Gilbert и Nancy Lynch доказали: в сети, где сообщения теряются, все три сразу обещать нельзя. Когда связь между узлами рвётся, приходится выбирать — отказать в ответе или отдать данные, которые могут не совпасть. Фраза «всегда и то и другое» этот выбор скрывает.
Опиши, что система делает в ту минуту, когда дата-центры перестают видеть друг друга.
YAGNI You Aren’t Gonna Need It, «тебе это не понадобится»
«Сразу сделаем общую платформу. Она пригодится и другим командам.»
YAGNI — правило Extreme Programming, которое сформулировал программист Kent Beck, один из авторов метода: не строй универсальное решение под задачу, которой ещё нет. Автор и консультант Martin Fowler посчитал цену такого «на всякий случай»: время на сборку, на поддержку и на переделку, когда реальная вторая задача окажется другой. Общая платформа для одного потребителя — это плата сейчас за гипотезу, которую никто не проверял.
Сделай то, что нужно сегодня. Обобщай, когда появится второй потребитель и подтвердит, что форма подходит.
Idempotency идемпотентность
«Клиент повторил запрос после таймаута. Спишем деньги ещё раз.»
Идемпотентная операция даёт один и тот же результат, сколько бы раз её ни повторили — так её определяет стандарт HTTP. Повтор после обрыва связи становится безопасным: второй вызов узнаёт первый и ничего не добавляет. Без этого свойства таймаут превращается в двойное списание. В распределённых системах повтор запроса — нормальное поведение клиента, и система должна его выдерживать. Платёжные API делают это через ключ повтора: Stripe хранит результат первого вызова и на второй с тем же ключом отдаёт его же.
У платежа и у создания заказа должен быть ключ повтора. Таймаут без такого ключа — будущий дубль.
Bounded context ограниченный контекст
«Пользователь у нас один объект. Биллинг и чат читают одни и те же поля.»
Eric Evans, автор подхода Domain-Driven Design (предметно-ориентированное проектирование), проводит границу, внутри которой модель значит одно. За границей то же слово значит другое и живёт в другой модели. Martin Fowler описывает это коротко: bounded context — забор вокруг словаря. Один объект User для биллинга и для чата смешивает два языка и тащит правила одного через всю систему.
Спрашивай, в каком контексте сейчас произносят слово. Если смыслы разошлись — это два объекта, даже если человек один.
Adverse selection неблагоприятный отбор
«Рынок слабый. Люди привередливые. Никто не продаёт.»
Экономист George Akerlof в статье «The Market for Lemons» (1970) показал, что происходит, когда одна сторона сделки знает о товаре больше другой. Покупатель не видит качества и предлагает среднюю цену. Продавцов хороших машин она не устраивает, и они уходят. Остаются «лимоны» — плохие машины. Рынок может исчезнуть, хотя желающих купить и продать хватает. Скрытое действие уже после подписи — другое явление, moral hazard, у него своя карточка. Фраза «люди привередливые» ничего из этого не объясняет.
До подписи спроси, кто знает то, чего не видишь ты, и почему хороший продавец вообще вышел на этот рынок.
Moral hazard моральный риск
«Мы дали им фикс и полную страховку. Теперь они спокойно работают.»
Экономист Bengt Holmström в статье «Moral Hazard and Observability» (1979) разобрал сделку, в которой одна сторона действует, а другая видит только результат. Полная страховка снимает с исполнителя последствия — и вместе с ними осторожность. Поэтому в страховке есть франшиза, а у менеджера — доля от результата. Плата должна зависеть от того, что можно наблюдать и что говорит об усилии; наказывать за то, на что человек не влиял, бессмысленно. Adverse selection — про скрытый тип до подписи. Moral hazard — про скрытое действие после. Нобелевский комитет в 2016 году дал за теорию контрактов премию Bengt Holmström и Oliver Hart.
Когда снимаешь с партнёра риск, спроси, какое его усилие ты перестаёшь видеть. Оставь ему часть последствий.
Hold-up
«Подпишем рамочно. Цену договорим по ходу.»
Экономисты Benjamin Klein, Robert Crawford и Armen Alchian в статье 1978 года описали ловушку: одна сторона вкладывается так, что вложение ценно только внутри этой сделки — электростанция строится у конкретной шахты. После этого условия диктует другая сторона: уйти уже дорого. Зная это заранее, первая сторона вкладывается меньше, чем стоило бы, и оба теряют. Oliver Hart в нобелевской лекции показал на этом примере, зачем покупать шахту: владение убирает торг.
Перед вложением, которое ценно только с этим партнёром, зафиксируй цену или купи право решать. Иначе торг будет после и не в твою пользу.
Incomplete contract неполный контракт
«Всё пропишем в договоре, и вопросов не будет.»
Oliver Hart и Sanford Grossman в 1986 году исходили из простого факта: все будущие случаи в договор не впишешь. Тогда главный пункт договора — кто решает, когда стороны не договорились. Это право решать в непрописанном они назвали residual control (остаточный контроль), и оно и есть собственность: владелец — тот, за кем последнее слово в непрописанном. Нобелевский комитет формулирует вывод так: в сложных сделках распределение права решать заменяет оплату за результат. Отсюда ответ на вопрос «делать самим или отдать подрядчику»: кому важнее решать в непредвиденном, тот и должен владеть.
В любом договоре найди строку о том, кто решает в непрописанном случае. Нет строки — решать будет тот, у кого актив.
Winner’s curse проклятие победителя
«Мы выиграли тендер!»
Инженеры нефтяной компании Atlantic Richfield заметили в 1971 году, что победители аукционов на участки в Мексиканском заливе систематически теряют деньги. Экономист Richard Thaler в обзоре «Anomalies: The Winner’s Curse» (1988) объяснил механику: когда несколько сторон оценивают одну и ту же вещь с неизвестной ценностью, выигрывает тот, кто ошибся вверх сильнее всех. Сама победа — сигнал, что твоя оценка была самой оптимистичной. William Samuelson и Max Bazerman показали, что то же работает в переговорах двух сторон, если продавец знает о вещи больше.
Выиграл торг с несколькими участниками — пересчитай оценку вниз. Ставь цену, с которой не жалко остаться, если выиграешь.
Ratchet effect эффект храповика
«Перевыполнили план — молодцы. На следующий год план поднимаем.»
Экономист Martin Weitzman в статье «The “Ratchet Principle” and Performance Incentives» (1980) разобрал советское планирование: сегодняшний результат становится завтрашней нормой, и норму, как храповик, можно двигать только вверх. Исполнитель это понимает и рационально не показывает всё, что может: лишнее сегодня — это план, который его накажет завтра. Тот же механизм у бонусов за перевыполнение и у «растущих» KPI. Закон Гудхарта смотрит на это со стороны того, кто ставит цель; храповик — со стороны того, кто её выполняет.
Если норма пересчитывается от факта, люди прячут резерв. Хочешь видеть реальную мощность — обещай, что норма от неё не вырастет, и держи слово.
Sunk cost невозвратные затраты
«Мы уже столько вложили. Нельзя бросать.»
Психологи Hal Arkes и Catherine Blumer в статье «The Psychology of Sunk Cost» (1985) показали в экспериментах: люди продолжают проект тем упорнее, чем больше в него вложено, хотя потраченное уже не вернуть ни одним из вариантов. Для следующего решения имеют значение только будущие затраты и будущая отдача. Прошлые деньги одинаковы во всех ветках — значит, они не аргумент ни за одну. «Столько вложили» — фраза про прошлое, а решение всегда про будущее.
Убери из обсуждения всё, что уже потрачено, и посмотри на проект как на новый: вложил бы в него сегодня столько, сколько осталось?
Conceptual pact
«Мы оба понимаем, о чём речь. В словаре это же слово.»
Психологи Susan Brennan и Herbert Clark в статье 1996 года описали негласное соглашение двух собеседников о том, как они называют вещь в этом разговоре. Такое имя не совпадает ни со словарным значением, ни с копированием чужого слова. Пара сокращает название, потому что оба уже убедились, что имеют в виду одно и то же. Ассистент, который поправляет reservation на booking, ломает соглашение: он подставил общий словарь туда, где у пары уже было своё имя.
Повторяй слово собеседника. Не заменяй его на более правильный синоним.
Common ground
«Мы оба это знаем. Можно не проверять.»
Herbert Clark и Susan Brennan в работе «Grounding in Communication» (1991) различают две вещи. Первая — то, что оба собеседника считают общим знанием. Вторая — работа по добавлению новой реплики в это общее: подтвердить, что понял, ровно настолько, насколько нужно сейчас. Эту работу они назвали grounding. «Мы оба знаем» часто значит: один знает, второй вежливо кивает. Общее знание появляется после подтверждения, не до него.
Прежде чем объяснять, проверь, что собеседник уже знает. Иначе читаешь лекцию об известном.
Exploration–exploitation исследование и использование
«Мы либо пробуем новое, либо усиливаем то, что работает. Надо выбрать раз и навсегда.»
В обучении с подкреплением — и в учебнике исследователей David Poole и Alan Mackworth — это два хода, которые спорят каждую неделю. Только использовать известное — застрять на первом удачном варианте. Только исследовать новое — остаться без результата. Вопрос не в том, какой из двух ходов правильный. Вопрос — какой ход сейчас и на какой срок.
Скажи вслух, какой ход делает команда на этой неделе и когда вы его пересмотрите.
Parametric vs retrieved memory параметрическая и извлекаемая память
«Модель должна просто быть точной. Она же всё читала.»
Исследователь Patrick Lewis и коллеги в статье 2020 года о Retrieval-Augmented Generation (RAG, генерация с опорой на найденные документы) разделили два хранилища знаний. Параметрическая память — веса модели: чтобы поменять в ней факт, модель нужно переобучить. Извлекаемая память — индекс документов, который можно заменить сегодня вечером. RAG строит ответ, опираясь на найденные фрагменты. Просьба «будь точной» обращена к весам. Документа, которого в весах нет, там и не появится.
Если факт должен обновляться без переобучения, его место в индексе. В весах он устареет.
Reward hacking
«Оценщики ставят пятёрки. Значит, модель делает то, что нам нужно.»
Исследователь Joar Skalse и коллеги в работе для конференции NeurIPS 2022 формально описали этот эффект: оптимизируешь приблизительную награду вместо настоящей цели — и по настоящей цели становится хуже. Оценщикам нравятся длинные гладкие ответы; правдивость при этом может падать. Приближение зелёное, настоящая цель уже уехала. Это родственник закона Гудхарта, только внутри обучения модели.
Спроси, какое приближение к цели сейчас оптимизируют — и где оно с самой целью расходится.
Grounding
«Ответ звучит уверенно. Значит, он опирается на документ.»
У этого слова два соседних смысла. У Herbert Clark — работа собеседников по подтверждению общего знания. В работе с моделями — право на утверждение только тогда, когда в источнике есть строка, которая его подтверждает. Исследователи Google в 2021 году предложили так и проверять ответы: каждое утверждение либо опирается на названный источник, либо нет. Уверенный тон такого права не даёт. Модель может выдать правильную интонацию и ошибиться в фактах. Отказ «в документах этого нет» здесь нормальный ответ, не провал.
Требуй ссылку на источник рядом с утверждением. Нет строки — нет факта.
Источники
Список собрал 19 сентября 2026 года. Страница v2.5.
- Taiichi Ohno / Lean Enterprise Institute, семь потерь
- Marc Andreessen, The only thing that matters, 2007
- Clayton Christensen, Jobs to be Done (Harvard Business School)
- Marty Cagan, The Four Big Risks
- Marty Cagan, Discovery vs Delivery
- Silicon Valley Product Group, Product Model Concepts
- Teresa Torres, Opportunity Solution Tree
- Teresa Torres, Continuous Discovery
- Larry Tesler, law of conservation of complexity
- Laws of UX, Tesler’s Law
- Charles Goodhart / Marilyn Strathern, мера и цель
- Eliyahu Goldratt, Theory of Constraints
- John Gall, Systemantics, 1975
- David Snowden и Mary Boone, Cynefin, Harvard Business Review, 2007
- G. K. Chesterton, The Thing, 1929 — разбор Farnam Street
- Frederick Brooks, No Silver Bullet, 1986
- Melvin Conway, How Do Committees Invent?, 1968
- Hyrum Wright, Hyrum’s Law
- Eric Brewer, Towards Robust Distributed Systems (PODC keynote), 2000
- Seth Gilbert и Nancy Lynch, Brewer’s Conjecture (CAP), 2002
- Kent Beck / Martin Fowler, YAGNI
- RFC 9110, HTTP Semantics, §9.2.2 Idempotent Methods
- Stripe API, Idempotent requests
- Eric Evans / Martin Fowler, Bounded Context
- George Akerlof, The Market for Lemons, 1970
- Bengt Holmström, Moral Hazard and Observability, 1979
- Нобелевский комитет, Contract Theory, 2016
- Benjamin Klein, Robert Crawford, Armen Alchian, Vertical Integration, Appropriable Rents, and the Competitive Contracting Process, 1978
- Oliver Hart, Incomplete Contracts and Control, нобелевская лекция, 2016
- Richard Thaler, Anomalies: The Winner’s Curse, 1988
- William Samuelson, Max Bazerman, The Winner’s Curse in Bilateral Negotiations, 1984
- Martin Weitzman, The “Ratchet Principle” and Performance Incentives, 1980
- Hal Arkes, Catherine Blumer, The Psychology of Sunk Cost, 1985
- Susan Brennan и Herbert Clark, Conceptual Pacts and Lexical Choice in Conversation, 1996
- Herbert Clark и Susan Brennan, Grounding in Communication, 1991
- David Poole и Alan Mackworth, Exploration and Exploitation
- Patrick Lewis и коллеги, Retrieval-Augmented Generation, 2020
- Joar Skalse и коллеги, Defining and Characterizing Reward Hacking, NeurIPS 2022
- Hannah Rashkin и коллеги, Measuring Attribution in Natural Language Generation Models, 2021
Что читать дальше
Подборки того же рода, шире или с другого угла. Я сверял с ними эту страницу.
- hacker-laws — около семидесяти законов и принципов для разработчиков, есть русский перевод. Ближе всего к комнате «софт».
- Farnam Street, Mental Models — около ста моделей из «больших дисциплин»: физика, биология, экономика, системы. Книжная серия The Great Mental Models — то же, подробнее.
- Gabriel Weinberg, Mental Models I Find Repeatedly Useful — около ста девяноста моделей с пометкой, как часто пригождаются.
- Brandon Chu, Product Management Mental Models for Everyone — шестнадцать моделей продакта: ROI, time value of shipping, local maxima.
- Untools — инструменты мышления с таблицей «какой у тебя вопрос → какой инструмент». Оттуда идея раздела «С какого вопроса начать».
- Laws of UX — психологические законы для дизайна интерфейсов: формулировка, выводы, происхождение, что читать.
- Kaidi Wu и David Dunning, Hypocognition, 2018 — обзор исследований о том, как отсутствие понятия сужает восприятие.
- Scott Alexander, Nonfiction Writing Advice — откуда взялось concept handle.