Эмоционально этот подход мне близок, но есть другая перспектива: я хочу иметь в голове модель, которая для действия X предсказывает, насколько вероятны те или иные исходы. Т.е. для Q = P("меня посадят" | do("я зашёл в Facebook")) - P("меня посадят" | ~do("я зашёл в Facebook")) может хотеться знать не просто категорическое Q>ε, а количественную оценку Q.
И вообще ИИ больше, чем в него загрузишь, не напишет (если не считать тонны воды).
LLM неявно содержит довольно много "усреднённых" знаний, поэтому даёт хорошую аппроксимацию "отстранённого взгляда" ("outside view"). Я вот недавно попробовал использовать её для оценки сроков задач, и пока что post factum точность оценок очень приличная.
А я знаю? Сидишь себе, никого не трогаешь, тут бац, какой-нибудь find_package(ZLIB REQUIRED) говорит "пошёл нахрен". Или случается The CXX compiler identification is unknown. Или просто настраиваешь какой-нибудь инструмент в первый раз, типа "хочу кросс-компилированный под ARM Go, использующий вот этот C-код".
И во всех этих случаях начинаешь с самого простого: пусть у меня соберётся программа, которая использует все релевантные технологии самым примитивным образом из возможных - напишет в консоль "привет", нарисует чайник, мигнёт одним светодиодом. В этом смысл Hello, world-программ: доказать, что у целевой системы можно вызвать какое-то поведение перед тем как пытаться вызывать сложное.
Hello world пишется столько раз, сколько надо проверить что система сборки как таковая не объявила забастовку и не сошла с ума. Завидую людям у которых это число раз равно 1.
Это объясняется банально - мы не можем чисто физически поглотить столько еды и с таким её разнообразием, что бы восполнить все витамины, мы не сможем всё нужное поглотить даже в течение недели или месяца.
Нужное для чего? Потому что если вы говорите о дозах с обычной пищей в принципе недоступных, то вы заведомо выходите за рамки медицинской нормы. Патологические дефициты витаминов (авитаминозы) известны и редки.
Если вы задаёте некоторый уровень "нужного", который определяется не патологиями, а анализами, то не худо бы хотя бы озвучить, какие плохие последствия вы ожидаете от меньшего уровня.
Есть какие-то конкретные соображения почему InvokeAI, а не Automatic1111 или ComfyUI? (Я открывал статью как раз с надеждой что в ней будет актуальное сравнение систем этого рода, а то сейчас грустно пытаюсь пропатчить sd-webui-SAG до работающего состояния. В статье нет, но может есть у комментаторов?)
А производителю, напротив выгодно будет ждать когда кто то разработает и взять после отзыва патента.
Работает только если все производители солидарно не используют полезный патент в течение specific timeframe. Это не выглядит как равновесие Нэша для независимых агентов.
1) Люди обучаются ещё и об реальность: действуют в мире с некоторыми ожиданиями, получают неожиданные результаты, корректируют (как минимум понижают в приоритете) часть ментальных моделей, "ответственную" за ожидание. У LLM такого механизма сейчас нет.
2) Обучение людей и процесс под названием "обучение", применяемый к LLM - это разные процессы. То что у первого есть условно устойчивые траектории не означает что они обязаны быть у второго.
3) Люди двигают науку за счёт обновления корпуса текстов между поколениями - не только включения, но и исключения ("новая теория становится мейнстримом, когда вымирают последователи старой"). При обучении LLM активного исключения текстов не происходит.
Моё примерное понимание - что у людей есть "естественная" продолжительность дня.
Жаворонки - те у кого она заметно меньше 24 часов (что коррелирует с более возбудимой психикой). Они просыпаются хорошо выспавшимися, легко начинают работать, но к вечеру уже ресурс заканчивается и ничем сложным не хочется заниматься.
Совы - у кого она заметно больше 24 часов, коррелирует с более инертной психикой. Утро настаёт слишком рано, подгрузка brain.exe медленная, какого чёрта все вокруг такие активные. Но к вечеру есть ещё столько интересных дел, и не у всех есть навык заставить себя ложиться по часам, а не когда устанешь.
Я довольно сильно "сова" - первый час после пробуждения со мной лучше не общаться, но, в обратную сторону, я могу один день обойтись вообще без сна - для "жаворонка" вещь малореальная.
"Не следовать эвристике" - это не описание стратегии принятия решений.
"Действовать обратно тому что написано на камне" - для вопросов "да/нет" действительно даст 99.9% ошибок, для вопросов с большим пространством ответов ещё больше.
"Кидать монетку и действовать согласно камню в 99.9%, наоборот в 0.1%" даст примерно 0.2% ошибок.
"Смотреть на реальность, назначая возможным наблюдениям очки, и действовать согласно камню только если очков набралось не больше 30, иначе действовать наоборот" - зависит от вашего метода подсчёта очков, очевидно. Но стратегия в этом духе - это единственный шанс ошибаться реже.
Вообще-то я за то чтобы было больше переводов, хороших и разных, но хочу заметить что у этого текста перевод уже был.
Ивермектин? Первая заклеймила! Безупречный рекорд.
A flawless (track) record здесь - "безупречный послужной список". Можно "рекордная точность" или "безупречный результат".
(Следующий абзац про булыжник как протестантского бога выпал из перевода вообще, а он важный.)
Гарвард лучше, чем State U, лучше, чем комьюнити-колледж.
X is better than Y is better than Z - X лучше Y, а тот в свою очередь лучше Z (перевод превратил цепочку в однородные члены).
Спору нет: его нанимать отличных сотрудников.
Моя ругать. Спору нет: он нанимает отличных сотрудников.
«Бывают редкие отклонения! Мои заслуги прежние!»
Гм. “Well, yes, sometimes there are outliers that even I can’t predict, I don’t think this detracts from my vast expertise and many years of success (...)". Хотя бы "Взгляните на мои прежние заслуги!"
Это обсуждалось когда модераторы SO объявляли протест против правил использования ИИ. Редактировать плохой ответ не легче чем написать хороший. ИИ генерирует ответы, которые выглядят хорошими, но таковыми не являются, и генерирует в количестве, превышающем способность профессионалов это осмысленно откомментировать.
Если ваша психика умеет эффективно работать в режиме "у задачи есть границы, меня не интересует что за ними", то это возможная стратегия (с поправкой на то, что вы можете хотеть заранее знать что у фирмы в целом дела плохи, хотя бы чтобы не строить лишних планов).
Но лично мне полезно понимать (полезно для мотивации, для предотвращения выгорания, для удовлетворения любопытства), как именно мои усилия складываются в получение некоторого объективного результата. И обратно: если единственная доступная обратная связь на мои действия - чьи-то слова (т.е. что-то, что я не могу сцепить с объективными событиями), то исчезает задача, которую можно осмысленно решать.
Что интересно, я дважды сталкивался (в российских условиях) с методикой, которую явно называли Scrum, и за описанием отсылали к Scrum Guide. И в обоих случаях мерой оценки задач были "часы работы данного исполнителя". Поэтому у меня есть впечатление, что Story Points - это отнюдь не непременный атрибут практики, не то что теории (в которой их изначально нет, и я готов спорить с аргументами о пользе их введения). И соображения "мне надо повозиться пару дней, чтобы понять, можно ли это сделать обсуждаемым способом вообще" вполне себе работали.
С другой стороны, сейчас я работаю в команде с принципиальным агностицизмом в отношении оценок времени. При хорошем опыте, приличном уровне и честности участников, застрять над задачей "думаю сделать это к пятнице" на месяц - печальная, повторяемая реальность. Поэтому, из моего опыта, проговаривание вслух декомпозиции на блоки меньше недели и их оценка - штука, негативные последствия нехватки которой я видел, а негативных последствий избытка - нет (и мои теоретические попытки их представить сводятся к избыточному микроменеджменту, который опять же, кажется, будет проблемой независимо от методологии).
Другими словами, мы вынуждены работать не с тем, что действительно важно, а с тем, что можем "осмысленно" оценить.
Мысли преобразуются в слова с потерей информации. В данном случае потеря заметна только когда точечные оценки времени сами по себе уже очень хорошие и хочется высшие моменты распределения, большинство людей и команд не в этой точке.
Вы либо не работаете над тем, чем действительно нужно/важно, либо ваши планы - с огромной долей вероятности - накрываются медным тазом.
Не согласен. Вы можете ставить в план задачи, которые кажутся более важными. Затем вы их оцениваете так хорошо как можете.
Если у вас система поощрений привязана к точности оценки и тем самым создаёт стимул выбирать предсказуемые задачи вперёд важных - это проблема системы поощрений. Scrum, насколько я вижу, какой-то конкретной системы поощрений не предписывает, это другая проблема. Я согласен что она есть, но мне кажется что а) это проявление многоликой проблемы credit assignment (Шишков, прости...), у которой хорошего, универсального, известного решения просто нет, поэтому она вылезет при любом устройстве работы; б) конкретно в случае программной разработки тимлид/ПМ должны уметь противостоять этому стимулу и в видимых мне случаях вполне это делают.
Ну т.е. цель - "релиз в сентябре"? :-)
Цель - то, про что достигнут консенсус что это цель. Если одной стороне хочется результат X, а другой - Y и Z, то консенсуса нет, и это опять же проблема при любой методологии. В коммерческой разработке желательно (для получения денег всеми участниками), чтобы продажники имели внятное представление, что можно обещать клиентам к тем или иным срокам, к примеру. Исследовательская задача тоже может быть целью, но тоже обычно важны сроки: что к некоторой черте либо получается результат, либо делается вывод что результата не получилось.
Я ненавижу оценки, потому что они порождают политику и на самом деле не ускоряют выполнение работы или не делают её лучше (наоборот, это чаще всего так).
Встречный тезис: всё способно порождать и подпитывать политику, так что "порождает политику" - не работает как критерий выбора между вариантами.
Количественные оценки, по крайней мере, сцеплены с реальностью: если я оценил задачу в шесть дней, то либо я в действительности сделал её за шесть дней, либо нет (и четыре дня, и девять - одинаковое "нет"). Если моя сказанная вслух оценка была неверна, мне намного тяжелее придумать самооправдание "почему на самом деле я не ошибся".
Затем, оценка у вас всегда есть. Ответ "я не знаю" никогда не является честным отражением знания в голове (он может являться политически наиболее приемлемым, но если ваша коммуникация на работе определяется соображениями политики, то вы уже в глубокой заднице, независимо от того что прописано в графе "методология разработки"). Правильнее бы сказать что в голове есть распределение, но с не-точечными оценками тяжело осмысленно работать.
Требования Scrum в своей основе банальны донельзя: каждую итерацию озвучьте декомпозицию задачи на куски ограниченного размера (если не можете - воспользуйтесь помощью зала), вместе оцените эти куски, определите где кончается каждый конкретный кусок, отслеживайте насколько хорошо откалиброваны ваши оценки. Стратегически, упорядочите по приоритетам разные вещи которые "надо бы" сделать, добавляйте в бэклог вещи которые сделать надо, но раньше об этом никто не подумал.
Методология не мешает включить в список этих вещей финальное документирование модуля, построение proof-of-concept для некоторой фичи, рефакторинг неудачного класса и т.д. Насколько я вижу, главная проблема здесь - что методология делает эти затраты времени явными, не позволяя скрывать их под общим одеялом "вон сидит разработчик, что-то пилит". Но это не проблема методологии разработки, это проблема коммуникации, давайте их разделять.
Если ваше взаимодействие с менеджментом оказывается взаимно более конструктивным в формате "мы знаем что делаем, релиз будет в сентябре, отстаньте от команды" - хорошо, вы можете подправить правила взаимодействия с Product Owner на более "чёрноящиковые". Остальные правила при этом можно оставить на месте, они ничем не мешают (и позволяют вам лучше оценить, что релиз таки-будет в сентябре, а не к новому году). Если же одновременно вы хотите тратить время на технический долг, менеджмент хочет знать чем команда занимается, и при этом вы не хотите защищать перед менеджером необходимость выделения времени на технический долг, то давайте для начала называть вещи своими именами: вы хотите менеджера обмануть. И если вы выбираете методологию из соображений "что меньше мешает обманывать", то да, чем больше коммуникации и проверяемых количественных оценок заложено в методологию, тем менее она полезна для этой задачи.
У компьютерных игр есть как минимум три разных источника:
Аркадные автоматы: быстрый цикл обратной связи ("видишь - стреляй");
Настольные игры, типа "Монополии" / головоломки типа "15": внятные правила и навигация по дереву решений.
Ролевые игры: построение и представление некоторого "большого" мира через окно ограниченных взаимодействий с ним, обычно "от лица" конкретного персонажа в этом мире.
Есть такое общее правило в разных юрисдикциях (которое может быть неприменимо в частном случае про который вы думаете, комментарии от случайного пользователя на Хабре не являются юридической консультацией, etc.): если вы нарушили закон, даже по мелочи (misdemeanor), но в результате этого нарушения погиб человек, то вы виновны в его смерти, даже если не причинили её прямо.
Проблема: не существует такой температуры кабинета, при которой всем сидящим в кабинете комфортно.
Решения: найти наименее некомфортную общую температуру ("компромисс - это решение, которым одинаково недовольны все стороны"), сделать два+ разных климатических пространства (пересадкой по кабинетам, перегородками, индивидуальными охладителями, рабами с опахалом - в зависимости от доступного бюджета), бросить монетку и выбрать положение которое комфортно хоть кому-то.
Предлагается вместо этого: "а поговорить?" Ну зашибись. У нас по-прежнему проблема что не существует комфортной для всех температуры и бонусом к ней проблема два - что какие-то гении социологии предлагают перед выбором одного из существующих решений как следует потрепаться. Реалистичный исход: проблему заболтают и вместо осознанного принятия какого-то конкретного решения будет решение "какое получилось". Зато, $&%@, поговорили. Эмпатично, безопасно и с заинтересованностью.
Эмоционально этот подход мне близок, но есть другая перспектива: я хочу иметь в голове модель, которая для действия X предсказывает, насколько вероятны те или иные исходы. Т.е. для Q = P("меня посадят" | do("я зашёл в Facebook")) - P("меня посадят" | ~do("я зашёл в Facebook")) может хотеться знать не просто категорическое Q>ε, а количественную оценку Q.
LLM неявно содержит довольно много "усреднённых" знаний, поэтому даёт хорошую аппроксимацию "отстранённого взгляда" ("outside view"). Я вот недавно попробовал использовать её для оценки сроков задач, и пока что post factum точность оценок очень приличная.
А я знаю? Сидишь себе, никого не трогаешь, тут бац, какой-нибудь
find_package(ZLIB REQUIRED)говорит "пошёл нахрен". Или случаетсяThe CXX compiler identification is unknown.Или просто настраиваешь какой-нибудь инструмент в первый раз, типа "хочу кросс-компилированный под ARM Go, использующий вот этот C-код".
И во всех этих случаях начинаешь с самого простого: пусть у меня соберётся программа, которая использует все релевантные технологии самым примитивным образом из возможных - напишет в консоль "привет", нарисует чайник, мигнёт одним светодиодом. В этом смысл Hello, world-программ: доказать, что у целевой системы можно вызвать какое-то поведение перед тем как пытаться вызывать сложное.
Hello world пишется столько раз, сколько надо проверить что система сборки как таковая не объявила забастовку и не сошла с ума. Завидую людям у которых это число раз равно 1.
Нужное для чего? Потому что если вы говорите о дозах с обычной пищей в принципе недоступных, то вы заведомо выходите за рамки медицинской нормы. Патологические дефициты витаминов (авитаминозы) известны и редки.
Если вы задаёте некоторый уровень "нужного", который определяется не патологиями, а анализами, то не худо бы хотя бы озвучить, какие плохие последствия вы ожидаете от меньшего уровня.
Есть какие-то конкретные соображения почему InvokeAI, а не Automatic1111 или ComfyUI?
(Я открывал статью как раз с надеждой что в ней будет актуальное сравнение систем этого рода, а то сейчас грустно пытаюсь пропатчить
sd-webui-SAGдо работающего состояния. В статье нет, но может есть у комментаторов?)Работает только если все производители солидарно не используют полезный патент в течение specific timeframe. Это не выглядит как равновесие Нэша для независимых агентов.
Возможные ответы:
1) Люди обучаются ещё и об реальность: действуют в мире с некоторыми ожиданиями, получают неожиданные результаты, корректируют (как минимум понижают в приоритете) часть ментальных моделей, "ответственную" за ожидание. У LLM такого механизма сейчас нет.
2) Обучение людей и процесс под названием "обучение", применяемый к LLM - это разные процессы. То что у первого есть условно устойчивые траектории не означает что они обязаны быть у второго.
3) Люди двигают науку за счёт обновления корпуса текстов между поколениями - не только включения, но и исключения ("новая теория становится мейнстримом, когда вымирают последователи старой"). При обучении LLM активного исключения текстов не происходит.
Моё примерное понимание - что у людей есть "естественная" продолжительность дня.
Жаворонки - те у кого она заметно меньше 24 часов (что коррелирует с более возбудимой психикой). Они просыпаются хорошо выспавшимися, легко начинают работать, но к вечеру уже ресурс заканчивается и ничем сложным не хочется заниматься.
Совы - у кого она заметно больше 24 часов, коррелирует с более инертной психикой. Утро настаёт слишком рано, подгрузка brain.exe медленная, какого чёрта все вокруг такие активные. Но к вечеру есть ещё столько интересных дел, и не у всех есть навык заставить себя ложиться по часам, а не когда устанешь.
Я довольно сильно "сова" - первый час после пробуждения со мной лучше не общаться, но, в обратную сторону, я могу один день обойтись вообще без сна - для "жаворонка" вещь малореальная.
Попробуйте так порисовать картинки, это доступно уже сейчас. Старая шутка про "с Наташи Ростовой падают трусы" покажется детским лепетом.
"Не следовать эвристике" - это не описание стратегии принятия решений.
"Действовать обратно тому что написано на камне" - для вопросов "да/нет" действительно даст 99.9% ошибок, для вопросов с большим пространством ответов ещё больше.
"Кидать монетку и действовать согласно камню в 99.9%, наоборот в 0.1%" даст примерно 0.2% ошибок.
"Смотреть на реальность, назначая возможным наблюдениям очки, и действовать согласно камню только если очков набралось не больше 30, иначе действовать наоборот" - зависит от вашего метода подсчёта очков, очевидно. Но стратегия в этом духе - это единственный шанс ошибаться реже.
Вообще-то я за то чтобы было больше переводов, хороших и разных, но хочу заметить что у этого текста перевод уже был.
A flawless (track) record здесь - "безупречный послужной список". Можно "рекордная точность" или "безупречный результат".
(Следующий абзац про булыжник как протестантского бога выпал из перевода вообще, а он важный.)
X is better than Y is better than Z - X лучше Y, а тот в свою очередь лучше Z (перевод превратил цепочку в однородные члены).
Моя ругать. Спору нет: он нанимает отличных сотрудников.
Гм. “Well, yes, sometimes there are outliers that even I can’t predict, I don’t think this detracts from my vast expertise and many years of success (...)". Хотя бы "Взгляните на мои прежние заслуги!"
Но эвристику так трудно превзойти
Это обсуждалось когда модераторы SO объявляли протест против правил использования ИИ. Редактировать плохой ответ не легче чем написать хороший. ИИ генерирует ответы, которые выглядят хорошими, но таковыми не являются, и генерирует в количестве, превышающем способность профессионалов это осмысленно откомментировать.
Не стоит для чего?
Если ваша психика умеет эффективно работать в режиме "у задачи есть границы, меня не интересует что за ними", то это возможная стратегия (с поправкой на то, что вы можете хотеть заранее знать что у фирмы в целом дела плохи, хотя бы чтобы не строить лишних планов).
Но лично мне полезно понимать (полезно для мотивации, для предотвращения выгорания, для удовлетворения любопытства), как именно мои усилия складываются в получение некоторого объективного результата. И обратно: если единственная доступная обратная связь на мои действия - чьи-то слова (т.е. что-то, что я не могу сцепить с объективными событиями), то исчезает задача, которую можно осмысленно решать.
Что интересно, я дважды сталкивался (в российских условиях) с методикой, которую явно называли Scrum, и за описанием отсылали к Scrum Guide. И в обоих случаях мерой оценки задач были "часы работы данного исполнителя". Поэтому у меня есть впечатление, что Story Points - это отнюдь не непременный атрибут практики, не то что теории (в которой их изначально нет, и я готов спорить с аргументами о пользе их введения). И соображения "мне надо повозиться пару дней, чтобы понять, можно ли это сделать обсуждаемым способом вообще" вполне себе работали.
С другой стороны, сейчас я работаю в команде с принципиальным агностицизмом в отношении оценок времени. При хорошем опыте, приличном уровне и честности участников, застрять над задачей "думаю сделать это к пятнице" на месяц - печальная, повторяемая реальность. Поэтому, из моего опыта, проговаривание вслух декомпозиции на блоки меньше недели и их оценка - штука, негативные последствия нехватки которой я видел, а негативных последствий избытка - нет (и мои теоретические попытки их представить сводятся к избыточному микроменеджменту, который опять же, кажется, будет проблемой независимо от методологии).
Мысли преобразуются в слова с потерей информации. В данном случае потеря заметна только когда точечные оценки времени сами по себе уже очень хорошие и хочется высшие моменты распределения, большинство людей и команд не в этой точке.
Не согласен. Вы можете ставить в план задачи, которые кажутся более важными. Затем вы их оцениваете так хорошо как можете.
Если у вас система поощрений привязана к точности оценки и тем самым создаёт стимул выбирать предсказуемые задачи вперёд важных - это проблема системы поощрений. Scrum, насколько я вижу, какой-то конкретной системы поощрений не предписывает, это другая проблема. Я согласен что она есть, но мне кажется что а) это проявление многоликой проблемы credit assignment (Шишков, прости...), у которой хорошего, универсального, известного решения просто нет, поэтому она вылезет при любом устройстве работы; б) конкретно в случае программной разработки тимлид/ПМ должны уметь противостоять этому стимулу и в видимых мне случаях вполне это делают.
Цель - то, про что достигнут консенсус что это цель. Если одной стороне хочется результат X, а другой - Y и Z, то консенсуса нет, и это опять же проблема при любой методологии. В коммерческой разработке желательно (для получения денег всеми участниками), чтобы продажники имели внятное представление, что можно обещать клиентам к тем или иным срокам, к примеру. Исследовательская задача тоже может быть целью, но тоже обычно важны сроки: что к некоторой черте либо получается результат, либо делается вывод что результата не получилось.
Встречный тезис: всё способно порождать и подпитывать политику, так что "порождает политику" - не работает как критерий выбора между вариантами.
Количественные оценки, по крайней мере, сцеплены с реальностью: если я оценил задачу в шесть дней, то либо я в действительности сделал её за шесть дней, либо нет (и четыре дня, и девять - одинаковое "нет"). Если моя сказанная вслух оценка была неверна, мне намного тяжелее придумать самооправдание "почему на самом деле я не ошибся".
Затем, оценка у вас всегда есть. Ответ "я не знаю" никогда не является честным отражением знания в голове (он может являться политически наиболее приемлемым, но если ваша коммуникация на работе определяется соображениями политики, то вы уже в глубокой заднице, независимо от того что прописано в графе "методология разработки"). Правильнее бы сказать что в голове есть распределение, но с не-точечными оценками тяжело осмысленно работать.
Требования Scrum в своей основе банальны донельзя: каждую итерацию озвучьте декомпозицию задачи на куски ограниченного размера (если не можете - воспользуйтесь помощью зала), вместе оцените эти куски, определите где кончается каждый конкретный кусок, отслеживайте насколько хорошо откалиброваны ваши оценки. Стратегически, упорядочите по приоритетам разные вещи которые "надо бы" сделать, добавляйте в бэклог вещи которые сделать надо, но раньше об этом никто не подумал.
Методология не мешает включить в список этих вещей финальное документирование модуля, построение proof-of-concept для некоторой фичи, рефакторинг неудачного класса и т.д. Насколько я вижу, главная проблема здесь - что методология делает эти затраты времени явными, не позволяя скрывать их под общим одеялом "вон сидит разработчик, что-то пилит". Но это не проблема методологии разработки, это проблема коммуникации, давайте их разделять.
Если ваше взаимодействие с менеджментом оказывается взаимно более конструктивным в формате "мы знаем что делаем, релиз будет в сентябре, отстаньте от команды" - хорошо, вы можете подправить правила взаимодействия с Product Owner на более "чёрноящиковые". Остальные правила при этом можно оставить на месте, они ничем не мешают (и позволяют вам лучше оценить, что релиз таки-будет в сентябре, а не к новому году). Если же одновременно вы хотите тратить время на технический долг, менеджмент хочет знать чем команда занимается, и при этом вы не хотите защищать перед менеджером необходимость выделения времени на технический долг, то давайте для начала называть вещи своими именами: вы хотите менеджера обмануть. И если вы выбираете методологию из соображений "что меньше мешает обманывать", то да, чем больше коммуникации и проверяемых количественных оценок заложено в методологию, тем менее она полезна для этой задачи.
У компьютерных игр есть как минимум три разных источника:
Аркадные автоматы: быстрый цикл обратной связи ("видишь - стреляй");
Настольные игры, типа "Монополии" / головоломки типа "15": внятные правила и навигация по дереву решений.
Ролевые игры: построение и представление некоторого "большого" мира через окно ограниченных взаимодействий с ним, обычно "от лица" конкретного персонажа в этом мире.
Есть такое общее правило в разных юрисдикциях (которое может быть неприменимо в частном случае про который вы думаете, комментарии от случайного пользователя на Хабре не являются юридической консультацией, etc.): если вы нарушили закон, даже по мелочи (misdemeanor), но в результате этого нарушения погиб человек, то вы виновны в его смерти, даже если не причинили её прямо.
Раздражает.
Проблема: не существует такой температуры кабинета, при которой всем сидящим в кабинете комфортно.
Решения: найти наименее некомфортную общую температуру ("компромисс - это решение, которым одинаково недовольны все стороны"), сделать два+ разных климатических пространства (пересадкой по кабинетам, перегородками, индивидуальными охладителями, рабами с опахалом - в зависимости от доступного бюджета), бросить монетку и выбрать положение которое комфортно хоть кому-то.
Предлагается вместо этого: "а поговорить?" Ну зашибись. У нас по-прежнему проблема что не существует комфортной для всех температуры и бонусом к ней проблема два - что какие-то гении социологии предлагают перед выбором одного из существующих решений как следует потрепаться. Реалистичный исход: проблему заболтают и вместо осознанного принятия какого-то конкретного решения будет решение "какое получилось". Зато, $&%@, поговорили. Эмпатично, безопасно и с заинтересованностью.