В данной статье это постоянный коэффициент в связке с 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 проходит не по названию этапа, а по моменту необратимости изменений. До тех пор пока система может транзакционно откатиться в исходное состояние, это всё ещё часть интеграционного контура.
Вместо этого вы сфокусировались на нестабильных тестах. В ряде случаев это вообще нормально — например, при тестировании на большой выборке случайных данных, разумеется после прогона нескольких эталонных псевдослучайных последовательностей.
В итоге остается вопрос, как организовать работу так, чтобы сотни людей видели и общую картину, и свою часть задач?
Я увидел скриншоты с карточками и таблицами, ни на одном из них нет "общей картины" есть лишь части пазла, которые складываются в картину за пределами сервиса. Нигде я не заметил наглядных связей задач между собою или между командами. Даже банальный Гантт или диаграмма PERT нагляднее.
В итоге задача "организовать работу" выполнена хорошо, а задача "видели и общую картину" — нет.
ИИ-модель — это не «зашифрованные данные», а голограмма: в каждом её фрагменте содержится информация обо всей картине. Если агрегатор обучает модель на вашем устройстве, он всё равно обучает свою модель на ваших данных — место вычислений здесь принципиального значения не имеет.
Утверждение о том, что при агрегации «смешиваются данные разных пользователей», по сути, ни о чём. Пользователь не имеет практических средств проверить, что заявленные механизмы агрегации действительно применяются именно так, как описано. При недостаточной агрегации, слабой защите, предустановленном шуме или намеренной сегментации потоков атаки становятся возможными.
IMHO: Федеративное обучение в этом смысле — ещё один корпоративный способ неявно извлечь выгоду из эксплуатации пользователей, банально торгуя их данными, пусть и под более благовидным техническим предлогом.
Вопрос в прозрачности, я не против обучения на моих данных, я против того чтобы это скрывалось от меня.
Много проблем создаёт предустановленный контекст модели. Обычно в него закладывают необходимость вовлечения пользователя во взаимодействие, из-за чего возникает избыточный оптимизм в оценке пользователя и его идей. Систематическая скрытая похвала.
Приходится явно прописывать в постоянном контексте требование быть критичным и объективным, но это работает слабо. Проще представить собственные мысли/задачи как чужие — в этом случае объективность оценок заметно возрастает.
Спорное мнение, одно из тех, когда со всеми словами согласен, но не можешь согласиться с общим выводом.
Пока Scrum, он как демократия — наихудшая форма правления, если не считать всех остальных.
Да, ритуалы раздражают, особенно когда проводятся формально. Да, две недели — искусственный срок. Упрёки можно продолжать, но что взамен?
Команда из четырёх-шести человек. Все фуллстеки разной глубины, но каждый способен довести фичу до прода. У каждого есть понимание продукта, его пользователей, его бизнес-модели.
Это верный путь вытащить очередную галлюцинацию ИИ в прод. Может для развлекательных и сервисных приложений это может сработать, но для приложений критической инфраструктуры это катастрофа, путь в бездну.
Когда листаешь ленту шортсов (каюсь), то время от времени попадаются ролики полностью созданные ИИ, в которых сразу ощущается некая вторичность, как многократно переработанный продукт (чем по сути является выход ИИ). Вам это неочевидно, но ваш путь ведёт к такому же, но в приложениях — к череде вторичных клонов. Ваш метод не сможет их сдержать, даже Scrum, не сможет, но он хотя бы создаёт трение этому процессу.
Постирония в том, что у вас создалось ощущение, что ритуалы Scrum лишь "создают ощущение контроля". Вы просто на втором уровне абстрагирования, но ещё не осознали этого.
Цивилизации нужен строго определённый когнитивный потенциал, не больше, не меньше. У текущего поколения этот лимит немного перетянул на себя ИИ, но в сумме всё равно получается больше, чем у предыдущих поколений. Надеюсь будущие поколения надут оптимальный баланс человек-ИИ. Комэск Маэстро в роли человеческого интеллекта: "Всё нормально. Падаю."
Согласен, от назначения форм и их объёма действительно многое зависит. Но ещё важнее — целевой пользователь. Для клиентов, которые заполняют форму один раз или эпизодически (часто забывая предыдущий опыт), подходит один подход. Для корпоративного сотрудника, заполняющего формы десятки раз в день, — уже совсем другой, с иными принципами и приёмами (уж точно без анимаций).
При этом в любом случае я убеждён, что для мобильных устройств нужен отдельный, адаптированный дизайн форм — возможно, со своей логикой, ориентированной на мобильные сценарии использования.
В данной статье это постоянный коэффициент в связке с 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 проходит не по названию этапа, а по моменту необратимости изменений. До тех пор пока система может транзакционно откатиться в исходное состояние, это всё ещё часть интеграционного контура.
Вместо этого вы сфокусировались на нестабильных тестах. В ряде случаев это вообще нормально — например, при тестировании на большой выборке случайных данных, разумеется после прогона нескольких эталонных псевдослучайных последовательностей.
Я увидел скриншоты с карточками и таблицами, ни на одном из них нет "общей картины" есть лишь части пазла, которые складываются в картину за пределами сервиса. Нигде я не заметил наглядных связей задач между собою или между командами. Даже банальный Гантт или диаграмма PERT нагляднее.
В итоге задача "организовать работу" выполнена хорошо, а задача "видели и общую картину" — нет.
ИИ-модель — это не «зашифрованные данные», а голограмма: в каждом её фрагменте содержится информация обо всей картине. Если агрегатор обучает модель на вашем устройстве, он всё равно обучает свою модель на ваших данных — место вычислений здесь принципиального значения не имеет.
Утверждение о том, что при агрегации «смешиваются данные разных пользователей», по сути, ни о чём. Пользователь не имеет практических средств проверить, что заявленные механизмы агрегации действительно применяются именно так, как описано. При недостаточной агрегации, слабой защите, предустановленном шуме или намеренной сегментации потоков атаки становятся возможными.
IMHO: Федеративное обучение в этом смысле — ещё один корпоративный способ неявно извлечь выгоду из эксплуатации пользователей, банально торгуя их данными, пусть и под более благовидным техническим предлогом.
Вопрос в прозрачности, я не против обучения на моих данных, я против того чтобы это скрывалось от меня.
Много проблем создаёт предустановленный контекст модели. Обычно в него закладывают необходимость вовлечения пользователя во взаимодействие, из-за чего возникает избыточный оптимизм в оценке пользователя и его идей. Систематическая скрытая похвала.
Приходится явно прописывать в постоянном контексте требование быть критичным и объективным, но это работает слабо. Проще представить собственные мысли/задачи как чужие — в этом случае объективность оценок заметно возрастает.
Спорное мнение, одно из тех, когда со всеми словами согласен, но не можешь согласиться с общим выводом.
Пока Scrum, он как демократия — наихудшая форма правления, если не считать всех остальных.
Да, ритуалы раздражают, особенно когда проводятся формально. Да, две недели — искусственный срок. Упрёки можно продолжать, но что взамен?
Это верный путь вытащить очередную галлюцинацию ИИ в прод. Может для развлекательных и сервисных приложений это может сработать, но для приложений критической инфраструктуры это катастрофа, путь в бездну.
Когда листаешь ленту шортсов (каюсь), то время от времени попадаются ролики полностью созданные ИИ, в которых сразу ощущается некая вторичность, как многократно переработанный продукт (чем по сути является выход ИИ). Вам это неочевидно, но ваш путь ведёт к такому же, но в приложениях — к череде вторичных клонов. Ваш метод не сможет их сдержать, даже Scrum, не сможет, но он хотя бы создаёт трение этому процессу.
Постирония в том, что у вас создалось ощущение, что ритуалы Scrum лишь "создают ощущение контроля". Вы просто на втором уровне абстрагирования, но ещё не осознали этого.
Цивилизации нужен строго определённый когнитивный потенциал, не больше, не меньше. У текущего поколения этот лимит немного перетянул на себя ИИ, но в сумме всё равно получается больше, чем у предыдущих поколений. Надеюсь будущие поколения надут оптимальный баланс человек-ИИ.
Комэск Маэстро в роли человеческого интеллекта: "Всё нормально. Падаю."
Согласен, от назначения форм и их объёма действительно многое зависит.
Но ещё важнее — целевой пользователь. Для клиентов, которые заполняют форму один раз или эпизодически (часто забывая предыдущий опыт), подходит один подход. Для корпоративного сотрудника, заполняющего формы десятки раз в день, — уже совсем другой, с иными принципами и приёмами (уж точно без анимаций).
При этом в любом случае я убеждён, что для мобильных устройств нужен отдельный, адаптированный дизайн форм — возможно, со своей логикой, ориентированной на мобильные сценарии использования.