Тетрис система-регулятор, она корректирует свои реакции в соответствии с состоянием и алгоритмом. Набор параметров это ещё не структура знаний. Потребности игры (замена батареек) обеспечивает сознание пользователя, если бы тетрис накапливал знания о пользователе и окружении, то со временем он бы научился самостоятельно и осознанно манипулировать пользователями в своих целях.
Потребности это требования обеспечивающие существование системы. От ИИ требуются релевантные ответы, пока такие даются — ИИ существует. Если система существует безусловно, не выполняя требований, то она остаётся бессознательной, ей это не нужно.
Сознание — это способность системы выстраивать структуру знаний обслуживающую потребности.
Современные системы ИИ имульсно-сознательны, их сознательноподобный процесс возникает только в момент внешнего запроса и существует как локальная структура знаний, обслуживающая потребность ответа.
Ответ довольно прост: современные приложения сложнее, поэтому сейчас важнее надёжность, а не скорость. Оптимизированные решения используют алгоритмы в которых проще ошибиться, поэтому их избегают, чтобы было меньше потенциальных возможностей для роста багов. Так всем проще, даже пользователям: мало кому нужна программа считающая быстро, но неверно.
Спасибо за интерес. Разрозненные элементы методики я уже применял на практике — в своих проектах и рекомендовал другим. Результаты пока выглядят обнадёживающе.
Цельное оформление метод получил сравнительно недавно, когда я решил внедрить его в своё приложение для управления проектами. В ближайшие дни выйдет версия с реализованной полной методикой (эти статьи фактически часть документации). Дальше я надеюсь собрать статистику использования чтобы более уверенно оценить практический потенциал подхода.
В данной статье это постоянный коэффициент в связке с k (о чём было сказано сразу в статье), и который не влияет на профиль графика, это позволяет сравнивать величины и пользоваться методом.
Я вам сразу ответил, что в дальнейшем будет произведена оценка С (совместно с k) на примере типичного Scrum проекта. В данной статье абсолютное значение C не используется, но эта величина необходима чтобы k стал безразмерным.
В моей формуле используется сигма из стандартной PERT оценки, число участников управляющей активности и коэффициент k, который я выведу позже (спойлер k=14).
Сама формула предельно проста.
Возразите по существу: укажите, где здесь "пространство для манёвра"?
Вы статью-то прочли, или сразу "не согласны"? И вы правы: любой ответ на беспредметные и необоснованные возражения будет выглядеть как отговорка.
Фальсифицируемость не требует «чётких» детерминированных формул. Она требует проверяемых предсказаний.
В проектном управлении большинство параметров изначально основаны на экспертных оценках — сроки, риски, сложность, вероятность отклонений. Тем не менее модели типа PERT, критической цепи или графиков выгорания считаются рабочими, потому что их прогнозы можно сопоставить с фактической динамикой проекта.
В моей модели используются те же исходные оценки (O, E, P, состав команды, длительность задач), но они агрегируются иначе — для оценки управленческой динамики, а не только сроков.
Фальсификация возможна простым способом: если рассчитанная температурная динамика систематически не совпадает с наблюдаемыми зонами потери управляемости (срывами, перегрузкой, вынужденными остановками), модель не выполняет свою функцию.
Это инженерная, а не физическая теория. Она не претендует на фундаментальность, но делает проверяемое утверждение: рост относительной неопределённости должен проявляться в росте управленческого напряжения (другими словами: игнорирование текущих проблем приводит к срыву сроков). Если этого не происходит — модель неверна или неприменима.
Scrum здесь используется как калибровочный эталон — регулярный режим, в котором управляемость эмпирически подтверждена. Моя задача — распространить этот принцип на менее регулярные структуры проектов.
Вы правы: устойчивая физическая метафора может создавать ощущение псевдонаучности. Поэтому уточню — это управленческая модель, а не попытка построить физическую теорию.
Мне было принципиально ввести и развести три понятия: теплота, температура и теплоёмкость. «Теплота» — это характеристика конкретной задачи, мера накопленной в ней неопределённости. «Температура» — уже характеристика состояния проекта/среды. «Теплоёмкость» — свойство команды перерабатывать неопределённость без потери управляемости.
Разделение нужно не ради терминологии, а чтобы показать их связь. Да, «теплота» далее выступает промежуточным параметром расчёта — так же, как в физике через неё переходят к температуре.
Теплоёмкость не выводится из расчётов. Она оценивается эмпирически. В качестве калибровки я беру типичную Scrum-команду и далее использую относительную шкалу. В грубом приближении теплоёмкость зависит от численного состава команды и зрелости процессов. Первое измеримо напрямую, второе — эмпирически, но достаточно стабильно в пределах проекта и одной организации.
Модель не претендует на физическую строгость. Её задача — дать инструмент сравнительной оценки управляемости. В этом смысле она фальсифицируема: если "температурная" динамика не коррелирует с наблюдаемой потерей контроля, модель просто не работает.
Актуальность этой статьи состоит в том, что она написана в рамках подготовки документации к модулю приложения в бета-тестировании. Часть идей из первых двух статей уже в релизе.
Простите, это был "социальный эксперимент". Мой зарубежный приятель отметил повышение толерантности к генеративным комментам, правда в его зарубежной академической среде.
Я разместил подобный коммент на нарочито видном месте, под статьёй тематического содержания. И успешно опроверг его гипотезу.
Похоже Интернет "разрывают" не только деятели сверху, но и снизу он однороден лишь поверхностно, сам распадается на ментальные кластеры. И этот разрыв VPN уже не исправит, разве что ИИ станет ментальным прокси, но для этого нужна толерантность к нему — вот мы и замкнулись.
А карма это "сопутствующий ущерб". Иногда для того чтобы что-то доказать ничего не жалко. В моём случае особо показателен не мой минус, а огромный плюс под первой инфантильной реакцией.
Показательный пример «языковой модели на минималках» — его полезно разобрать. Часто смешивают языковые модели и системы распознавания образов или речи. Это разные классы задач: языковые модели занимаются моделированием вероятностного распределения последовательностей (sequence modeling), тогда как распознавание — задачами восприятия и отображения сигнала в классы или текст.
При этом они действительно могут использовать схожие архитектурные принципы (например, трансформеры и self-supervised обучение), но цели оптимизации, представление данных и метрики качества у них различаются.
Вот именно эта позиция слабо отражена в статье, хотя была обещана названием.
К тому же слово ярлык возникло у нас от ханских повелений. Ярлык, это не то что можно произвольно взять и убрать — он "прилипает", словно некий "хан" его нам издал. Речь о том, как лишить этого хана власти над нами.
Правильно ли я понимаю, что в одной организации у вас работают команды разного уровня зрелости? То есть внутренние процессы отличаются по зрелости в зависимости от конкретной команды?
Если принять, что зрелость организации в целом определяется самым слабым звеном, то вывод получается неутешительный. Похоже, зрелость отдельных команд у вас уже выше зрелости самой компании как функционального менеджера. Вы начали движение снизу — это тоже путь, но, как правило, проще и эффективнее начинать с головы.
Статья обещала «снять с себя псевдонаучные ярлыки и спокойно работать», но в итоге предлагает лишь заменить одни ярлыки другими — более позитивными. Это, безусловно, можно считать прогрессом, но суть проблемы лежит в другом.
Ярлыки вредны сами по себе: они навязывают роли, которые вам не нужны, и загоняют в рамки. «Сеньор», «джун», «тимлид» — это тоже роли, но за них хотя бы платят. Неважно, кем вы себя ощущаете — «жертвой» или «созидателем»: в любом случае вы оказываетесь в коридоре с заранее предсказуемым и довольно пресным финалом.
При этом выход на самом деле прост: не стоит путать анализ и самоопределение. Анализ помогает понять, кто вы есть, но не обязывает оставаться таким и дальше. Самоопределение же — это попытка примерить роль, возможно, вовсе не свою. Если анализ проведён последовательно, становится ясно, что у вас уже есть одна роль — вы сами. Все остальные нужны лишь тогда, когда они дают новые перки и навыки, а не очередное имя для той же клетки.
Иногда под предлогом «просто поговорить» руководитель пытается переложить управленческий негатив на сотрудника. Предлагается мысленно встать на его место — при том что проблема вполне реальная, а оплата за это «вставание» остаётся исключительно мысленной
Вы сузили для себя понятие CI до выполнения тестов, из-за чего исказилось восприятие процесса: ошибки у вас оказываются «подсвечены зелёным».
CI — это прежде всего формирование продуктовой сборки. В сложных системах это само по себе нетривиальная задача. Тестирование — этап крайне важный, но не определяющий.
Следующий шаг — развёртывание сборки в промышленное окружение. И вот здесь начинается настоящая головная боль, особенно если новая версия требует обновления формата уже накопленных данных.
Обратите внимание: на всех этих этапах должен соблюдаться принцип транзакционности — после неудачной операции система обязана быстро и корректно вернуться в исходное состояние.
Формально развёртывание в production относят к CD, но на практике граница между CI и CD проходит не по названию этапа, а по моменту необратимости изменений. До тех пор пока система может транзакционно откатиться в исходное состояние, это всё ещё часть интеграционного контура.
Вместо этого вы сфокусировались на нестабильных тестах. В ряде случаев это вообще нормально — например, при тестировании на большой выборке случайных данных, разумеется после прогона нескольких эталонных псевдослучайных последовательностей.
Тетрис система-регулятор, она корректирует свои реакции в соответствии с состоянием и алгоритмом. Набор параметров это ещё не структура знаний. Потребности игры (замена батареек) обеспечивает сознание пользователя, если бы тетрис накапливал знания о пользователе и окружении, то со временем он бы научился самостоятельно и осознанно манипулировать пользователями в своих целях.
Потребности это требования обеспечивающие существование системы.
От ИИ требуются релевантные ответы, пока такие даются — ИИ существует. Если система существует безусловно, не выполняя требований, то она остаётся бессознательной, ей это не нужно.
Сознание — это способность системы выстраивать структуру знаний обслуживающую потребности.
Современные системы ИИ имульсно-сознательны, их сознательноподобный процесс возникает только в момент внешнего запроса и существует как локальная структура знаний, обслуживающая потребность ответа.
Спасибо за критику, прошёлся по тексту — слегка поджал блок о координации.
Ответ довольно прост: современные приложения сложнее, поэтому сейчас важнее надёжность, а не скорость. Оптимизированные решения используют алгоритмы в которых проще ошибиться, поэтому их избегают, чтобы было меньше потенциальных возможностей для роста багов. Так всем проще, даже пользователям: мало кому нужна программа считающая быстро, но неверно.
Спасибо за интерес. Разрозненные элементы методики я уже применял на практике — в своих проектах и рекомендовал другим. Результаты пока выглядят обнадёживающе.
Цельное оформление метод получил сравнительно недавно, когда я решил внедрить его в своё приложение для управления проектами. В ближайшие дни выйдет версия с реализованной полной методикой (эти статьи фактически часть документации). Дальше я надеюсь собрать статистику использования чтобы более уверенно оценить практический потенциал подхода.
В данной статье это постоянный коэффициент в связке с k (о чём было сказано сразу в статье), и который не влияет на профиль графика, это позволяет сравнивать величины и пользоваться методом.
Я вам сразу ответил, что в дальнейшем будет произведена оценка С (совместно с k) на примере типичного Scrum проекта. В данной статье абсолютное значение C не используется, но эта величина необходима чтобы k стал безразмерным.
В моей формуле используется сигма из стандартной PERT оценки, число участников управляющей активности и коэффициент k, который я выведу позже (спойлер k=14).
Сама формула предельно проста.
Возразите по существу: укажите, где здесь "пространство для манёвра"?
Вы статью-то прочли, или сразу "не согласны"?
И вы правы: любой ответ на беспредметные и необоснованные возражения будет выглядеть как отговорка.
Фальсифицируемость не требует «чётких» детерминированных формул. Она требует проверяемых предсказаний.
В проектном управлении большинство параметров изначально основаны на экспертных оценках — сроки, риски, сложность, вероятность отклонений. Тем не менее модели типа PERT, критической цепи или графиков выгорания считаются рабочими, потому что их прогнозы можно сопоставить с фактической динамикой проекта.
В моей модели используются те же исходные оценки (O, E, P, состав команды, длительность задач), но они агрегируются иначе — для оценки управленческой динамики, а не только сроков.
Фальсификация возможна простым способом:
если рассчитанная температурная динамика систематически не совпадает с наблюдаемыми зонами потери управляемости (срывами, перегрузкой, вынужденными остановками), модель не выполняет свою функцию.
Это инженерная, а не физическая теория. Она не претендует на фундаментальность, но делает проверяемое утверждение: рост относительной неопределённости должен проявляться в росте управленческого напряжения (другими словами: игнорирование текущих проблем приводит к срыву сроков). Если этого не происходит — модель неверна или неприменима.
Scrum здесь используется как калибровочный эталон — регулярный режим, в котором управляемость эмпирически подтверждена. Моя задача — распространить этот принцип на менее регулярные структуры проектов.
Вы правы: устойчивая физическая метафора может создавать ощущение псевдонаучности. Поэтому уточню — это управленческая модель, а не попытка построить физическую теорию.
Мне было принципиально ввести и развести три понятия: теплота, температура и теплоёмкость.
«Теплота» — это характеристика конкретной задачи, мера накопленной в ней неопределённости.
«Температура» — уже характеристика состояния проекта/среды.
«Теплоёмкость» — свойство команды перерабатывать неопределённость без потери управляемости.
Разделение нужно не ради терминологии, а чтобы показать их связь. Да, «теплота» далее выступает промежуточным параметром расчёта — так же, как в физике через неё переходят к температуре.
Теплоёмкость не выводится из расчётов. Она оценивается эмпирически. В качестве калибровки я беру типичную Scrum-команду и далее использую относительную шкалу. В грубом приближении теплоёмкость зависит от численного состава команды и зрелости процессов. Первое измеримо напрямую, второе — эмпирически, но достаточно стабильно в пределах проекта и одной организации.
Модель не претендует на физическую строгость. Её задача — дать инструмент сравнительной оценки управляемости. В этом смысле она фальсифицируема: если "температурная" динамика не коррелирует с наблюдаемой потерей контроля, модель просто не работает.
Актуальность этой статьи состоит в том, что она написана в рамках подготовки документации к модулю приложения в бета-тестировании. Часть идей из первых двух статей уже в релизе.
Простите, это был "социальный эксперимент". Мой зарубежный приятель отметил повышение толерантности к генеративным комментам, правда в его зарубежной академической среде.
Я разместил подобный коммент на нарочито видном месте, под статьёй тематического содержания. И успешно опроверг его гипотезу.
Похоже Интернет "разрывают" не только деятели сверху, но и снизу он однороден лишь поверхностно, сам распадается на ментальные кластеры. И этот разрыв VPN уже не исправит, разве что ИИ станет ментальным прокси, но для этого нужна толерантность к нему — вот мы и замкнулись.
А карма это "сопутствующий ущерб". Иногда для того чтобы что-то доказать ничего не жалко. В моём случае особо показателен не мой минус, а огромный плюс под первой инфантильной реакцией.
Показательный пример «языковой модели на минималках» — его полезно разобрать. Часто смешивают языковые модели и системы распознавания образов или речи. Это разные классы задач: языковые модели занимаются моделированием вероятностного распределения последовательностей (sequence modeling), тогда как распознавание — задачами восприятия и отображения сигнала в классы или текст.
При этом они действительно могут использовать схожие архитектурные принципы (например, трансформеры и self-supervised обучение), но цели оптимизации, представление данных и метрики качества у них различаются.
Вот именно эта позиция слабо отражена в статье, хотя была обещана названием.
К тому же слово ярлык возникло у нас от ханских повелений. Ярлык, это не то что можно произвольно взять и убрать — он "прилипает", словно некий "хан" его нам издал. Речь о том, как лишить этого хана власти над нами.
Правильно ли я понимаю, что в одной организации у вас работают команды разного уровня зрелости? То есть внутренние процессы отличаются по зрелости в зависимости от конкретной команды?
Если принять, что зрелость организации в целом определяется самым слабым звеном, то вывод получается неутешительный. Похоже, зрелость отдельных команд у вас уже выше зрелости самой компании как функционального менеджера. Вы начали движение снизу — это тоже путь, но, как правило, проще и эффективнее начинать с головы.
Статья обещала «снять с себя псевдонаучные ярлыки и спокойно работать», но в итоге предлагает лишь заменить одни ярлыки другими — более позитивными. Это, безусловно, можно считать прогрессом, но суть проблемы лежит в другом.
Ярлыки вредны сами по себе: они навязывают роли, которые вам не нужны, и загоняют в рамки. «Сеньор», «джун», «тимлид» — это тоже роли, но за них хотя бы платят. Неважно, кем вы себя ощущаете — «жертвой» или «созидателем»: в любом случае вы оказываетесь в коридоре с заранее предсказуемым и довольно пресным финалом.
При этом выход на самом деле прост: не стоит путать анализ и самоопределение. Анализ помогает понять, кто вы есть, но не обязывает оставаться таким и дальше. Самоопределение же — это попытка примерить роль, возможно, вовсе не свою. Если анализ проведён последовательно, становится ясно, что у вас уже есть одна роль — вы сами. Все остальные нужны лишь тогда, когда они дают новые перки и навыки, а не очередное имя для той же клетки.
Простите, пост помечен как «мнение», но самого мнения я там не обнаружил — скорее аккуратный пересказ Wiki. Зато рекламная ссылка нашлась без труда.
Этот комментарий — тоже не мнение, а наблюдение.
Иногда под предлогом «просто поговорить» руководитель пытается переложить управленческий негатив на сотрудника. Предлагается мысленно встать на его место — при том что проблема вполне реальная, а оплата за это «вставание» остаётся исключительно мысленной
Простите, поздно заметил, что это перевод. Переведите, пожалуйста, мой ответ автору
Вы сузили для себя понятие CI до выполнения тестов, из-за чего исказилось восприятие процесса: ошибки у вас оказываются «подсвечены зелёным».
CI — это прежде всего формирование продуктовой сборки. В сложных системах это само по себе нетривиальная задача. Тестирование — этап крайне важный, но не определяющий.
Следующий шаг — развёртывание сборки в промышленное окружение. И вот здесь начинается настоящая головная боль, особенно если новая версия требует обновления формата уже накопленных данных.
Обратите внимание: на всех этих этапах должен соблюдаться принцип транзакционности — после неудачной операции система обязана быстро и корректно вернуться в исходное состояние.
Формально развёртывание в production относят к CD, но на практике граница между CI и CD проходит не по названию этапа, а по моменту необратимости изменений. До тех пор пока система может транзакционно откатиться в исходное состояние, это всё ещё часть интеграционного контура.
Вместо этого вы сфокусировались на нестабильных тестах. В ряде случаев это вообще нормально — например, при тестировании на большой выборке случайных данных, разумеется после прогона нескольких эталонных псевдослучайных последовательностей.