Методология описана кратко, это факт. Мы сознательно не публиковали полную разбивку задач по типам и сложности — статья и так вышла длиннее запланированного. Это пробел, признаём.
Эффект новизны — честное замечание. Три месяца недостаточно, чтобы его исключить. Именно поэтому в статье прямым текстом написано: «продолжим замеры, через квартал будет честнее». Мы не утверждаем, что эффект устойчив — мы говорим, что он есть прямо сейчас.
Стоимость внедрения не посчитана — тоже верно. Лицензии, время на настройку скиллов и SDD, первые недели проб и ошибок — всё это реальные затраты, которые в velocity не видны.
Где не согласна.
Инфляция оценок как единственное объяснение не работает, потому что абсолютное число закрытых задач тоже выросло — и это штуки, не поинты. Если бы команда просто переоценивала задачи, фичи бы не появлялись быстрее.
«Маркетинг» — субъективно. Мы специально зафиксировали метрики до старта, а не после. Baseline взяли из реальных спринтов, не из потолка. Можно спорить о качестве методологии, но умысла подгонять не было.
По существу. Вы правы, что одна статья за один квартал — это не доказательство. Мы и не претендуем. Это срез первого цикла с реальными цифрами, а не научная публикация с контрольной группой. Статья через год — хорошая идея, мы её как раз планируем.
Считаем это ложной метрикой продуктивности, и вот почему.
Токены измеряют активность модели, а не полезный результат. Это примерно как судить о качестве разработчика по количеству нажатых клавиш.
Агент может сжечь огромный контекст на внезапный глюк, который потом часами чинит человек — и это будет «высокая продуктивность» по токенам.
Имхо, правильная пирамида метрик для агентов выглядит так:
Результат — закрытые задачи, баги на фичу, время цикла Качество взаимодействия — процент принятых предложений, доля правок после AI-генерации Операционка — токены, латентность, стоимость вызовов
Токены живут на дальнем уровне. Если смотреть только на них — можно оптимизировать не то и прийти к дешёвому агенту с бесполезным выхлопом.
И да, мы учимся бюджетировать запросы — лимиты и лицензии никто не отменял. Заранее прикидываем бюджет задачи и не раскидываемся токенами направо-налево. Лёгкие вопросы уходят в Kimi, сложные — в модели подороже. Не кидаем всю репу в контекст, чистим историю диалогов, пишем короткие конкретные промпты без вежливости и эмоций, переиспользуем скиллы и шаблоны.
Черри пикинг? Отчасти да, и намеренно. Типовые задачи выбрали осознанно, тк лезть сразу в архитектуру с ИИ - это не эксперимент, это хаос. То что они «быстро закончатся» — возможно. Но пока нет) Что будет на сложных задачах — честно говорим: не знаем, данных мало.
Гудхарт — уважаем, держим в голове. Именно поэтому velocity не единственная метрика, рядом штуки задач и конкретное время разработчика.
Про осторожный переход — полностью согласны. Мы и рекомендуем осторожно. Статья про один квартал, один продукт, с оговорками. Никакого экстаза, стулья на месте.
Согласна, velocity в изоляции — плохая метрика. Именно поэтому рядом третий график — абсолютное число закрытых фич и багов за спринт: с 10–18 до 17–23. Это штуки, не поинты. Фича либо есть, либо её нет.
Плюс конкретика: трансформация данных — с 2 дней до 2 часов, новый плагин — с 5 дней до 1 дня. Это реальное время разработчика, не переоценённый тикет.
Метафора со смузи хороша, если мерить только кружки. Мы смотрим ещё и на то, что реально уехало в прод в конце спринта.
В следующем цикле добавляем баги на фичу и время ревью — velocity без качества действительно половина картины.
Спасибо за внимательный разбор: часть замечаний по делу, часть хочется оспорить.
По инфляции story points. Да, это классический риск при любом ускорении команды, и мы его держим в голове. Именно поэтому в статье рядом с velocity идёт второй график — абсолютное количество закрытых фич и багов за спринт. Оно тоже выросло: с 10–18 до 17–23. Это не story points, это штуки. Если бы рост был только в оценках — фичи бы не появлялись. Так что инфляция оценок если и есть, то объясняет часть роста, не весь.
По техническому долгу. Честно — пока не можем ни подтвердить, ни опровергнуть. В статье это прямо написано: следующий шаг — добавить метрики качества: баги на фичу, время ревью, процент принятых AI-предложений. Именно потому что velocity без качества — неполная картина. Так что претензия справедливая, но она совпадает с тем, что мы сами планируем мерить.
По "вздрючиванию". Вот здесь принципиально не согласна. Никто никого не заставлял работать больше часов. Инструмент убрал часть механической работы — это другая история, чем увеличение нагрузки. Разработчики стали меньше писать шаблонный код и больше заниматься проектированием и ревью. Это скорее в сторону интереса, чем выгорания.
Продолжим замеры — через квартал будет честнее видно, устойчив эффект или нет.
В данном случае мы рассматриваем отдельный класс систем, которые представляют из себя конструктор, а не коробочные решения конкретно под Бюджетирование.
1) Быстрый пересчет сложных моделей при изменении условий (минуты против часов, для сложных моделей) – одна из основных задач ЕРМ-систем 2) Для этого в ЕРМ есть функция Трассировки вычислений, которая позволяет сразу провалиться в форму-источник данных, отобразить формулу и посмотреть, кто последний вводил значения 3) Все современные Российские ЕРМ-системы – self service инструменты. Внести подобные изменения не проблема для пользователя, если он, конечно, не ограничен в правах на внесение подобных изменений)
Солидный опыт, мы с командой тоже много лет внедряем системы автоматизации планирования на разных уровнях)
И, как вы правильно отметили, внедрение сложной автоматизированной системы с большим количеством пользователей и заинтересантов, будь то MES/ERP/EPM/BI – это чаще всего проект, который инициирует менеджмент компании. Пользователи обычно прекрасно существуют в привычных им инструментах.
И сразу отвечу на ваш комментарий в соседней ветке: внедрение любой ЕРМ сопровождается адаптацией, а часто трансформацией методологии компании, потому, что любой процесс компании должен быть управляемым с измеримыми результатами.
Связка Excel+querry+pivot – это предпоследний этап принятия и осознания изменений которые необходимы для контроля процесса)
В своем примере вы описываете как раз систему ручного управления и решение точечной задачи, а не управляемый процесс в компании.
Для решения подобных задач в ЕРМ у вас всегда есть «песочница» на отдельном срезе данных, где вы, как специалист, понимающий всю методику формирования мастер бюджетов, можете скорректировать необходимые драйверы и исходные данные для получения требуемого результата.
И когда вам необходимо внести изменения в сквозную калькуляционую модель, оценить влияние изменение атрибута одного из ресурсов с «покупной» на «собственного производства» и пересчитать весь производственно-финансовый план с выходом на отчетные формы корпорации в модели, которая состоит из связки Excel+SQL, кучи макросов в 80+ книгах и отдельной книгой для управления этими книгами, полный пересчет которой занимает 6 часов – это причина внедрения ЕРМ системы. Пересчет указанных выше изменений в ней займет 3-5 минут и останется время даже красоту навести и подготовить объяснение получившимся цифрам)
Но если задача стоит просто собрать таблицу – нужно собирать таблицу)
Продолжение обязательно будет, как и сравнение популярных Российских ЕРМ систем между собой и с 1С.
1) Да, теперь у линейных сотрудников и руководства есть "единое окно", где происходит ввод данных, согласование, корректировка и визуализация.
2) Конкретно в нашем случае да, прод крутится на одном сервере, но можно реализовать и "классическую" для 1С историю с локальными базами и последующей консолидацией или подтягивать данные в оперативном режиме. Сталкивались с разными пожеланиями заказчиков)
3) В проектах внедрения ЕРМ-систем методология всегда неразрывно связана с технической частью. Конкретно версии являются просто дополнительным измерением в каждом кубе, так называемые сквозные измерения. И можно в рамках одной формы сравнивать различные версии между собой в абсолютных и относительных величинах (План vs План с учетом корректировок vs Факт и тд.)
Про измерения и сводные таблицы вы говорите абсолютно верно (их же можно представить аналогом многомерных кубов, механика перетаскивания измерений схожа)
Сводные таблицы можно использовать, но как вы правильно отметили, необходимо собирать данные из множества листов в сводной таблице, где нет возможности редактировать информацию. Вам в таком случае необходимо идти в форму ввода, вносить данные, запускать пересчет книги и обновлять данные сводной таблицы.
В то же время в ЕРМ-системе у вас есть просто один гигантский лист, который сразу имеет представление сводной таблицы, пересчитывается на лету и дает возможность редактировать данные.
Эксель прекрасный инструмент, очень гибкий и понятный, с большими техническими возможностями. Но именно эта гибкость при масштабировании рождает проблемы в больших компаниях. В двух словах коснулись этой темы в разделах перед выводами.
Так это же классика внедрения любой системы, даже небольшой типа самописки на Аксесе. Пользователи всегда держатся за привычное до последнего) От этого сложно избавиться, но можно. Если вовлекать ключевых пользователей в новый инструмент, обучать, готовить инструкции или записывать ролики с полезными советами, они могут перетащить в новую систему и всех остальных. Но если ни у кого нет желания переходить на что-то новое, будет что-то в стиле "интернет этот ваш нам не нужОн".
Все так, съемные носители самый простой и удобный способ защиты в т.ч. под задачи отказоустойчивости, а объектные хранилища рассматриваем как альтернативу лентам из реестра МПТ
Нет, не только. Аналогичное поведение (автоназначение LUN ID) наблюдается на популярных СХД Huawei Dorado и многих других. Нет смысла брать вендора и модель СХД за основу при поиске потенциальных проблем. Вероятность попасть в такую ситуацию имеется при использовании любых СХД, если маппинг производился без учета требований VMware.
Здравствуйте! Спасибо за ваш комментарий. Мастер определяет, но не умеет автоматически перестраивать топологию кластера. Поэтому использовали орекстратор как средство управления топологией в случае сбоя.
По умолчанию установщик zVirt Node выделяет под него 1Гб. Engine при развёртывании также получает 1Гб. В версиях 4.1-4.4 на каждое ядро суммарно приходилось ~300мб файлов в /boot, плюс какие-то возможные остатки от прошлых обновлений. Так что 2Гб вполне достаточно для того, чтобы обновиться без проблем. Сейчас (в 4.5) ситуация стала получше - в /boot каждое ядро занимает суммарно менее 200мб. Так что если изначально разворачивать 4.5 и позднее обновляться на следующую версию - проблем быть не должно. Но в любом случае стоит перед обновлением проверить место, хотя бы на одном из хостов.
Где вы правы.
Методология описана кратко, это факт. Мы сознательно не публиковали полную разбивку задач по типам и сложности — статья и так вышла длиннее запланированного. Это пробел, признаём.
Эффект новизны — честное замечание. Три месяца недостаточно, чтобы его исключить. Именно поэтому в статье прямым текстом написано: «продолжим замеры, через квартал будет честнее». Мы не утверждаем, что эффект устойчив — мы говорим, что он есть прямо сейчас.
Стоимость внедрения не посчитана — тоже верно. Лицензии, время на настройку скиллов и SDD, первые недели проб и ошибок — всё это реальные затраты, которые в velocity не видны.
Где не согласна.
Инфляция оценок как единственное объяснение не работает, потому что абсолютное число закрытых задач тоже выросло — и это штуки, не поинты. Если бы команда просто переоценивала задачи, фичи бы не появлялись быстрее.
«Маркетинг» — субъективно. Мы специально зафиксировали метрики до старта, а не после. Baseline взяли из реальных спринтов, не из потолка. Можно спорить о качестве методологии, но умысла подгонять не было.
По существу. Вы правы, что одна статья за один квартал — это не доказательство. Мы и не претендуем. Это срез первого цикла с реальными цифрами, а не научная публикация с контрольной группой. Статья через год — хорошая идея, мы её как раз планируем.
Считаем это ложной метрикой продуктивности, и вот почему.
Токены измеряют активность модели, а не полезный результат. Это примерно как судить о качестве разработчика по количеству нажатых клавиш.
Агент может сжечь огромный контекст на внезапный глюк, который потом часами чинит человек — и это будет «высокая продуктивность» по токенам.
Имхо, правильная пирамида метрик для агентов выглядит так:
Результат — закрытые задачи, баги на фичу, время цикла
Качество взаимодействия — процент принятых предложений, доля правок после AI-генерации
Операционка — токены, латентность, стоимость вызовов
Токены живут на дальнем уровне. Если смотреть только на них — можно оптимизировать не то и прийти к дешёвому агенту с бесполезным выхлопом.
И да, мы учимся бюджетировать запросы — лимиты и лицензии никто не отменял. Заранее прикидываем бюджет задачи и не раскидываемся токенами направо-налево. Лёгкие вопросы уходят в Kimi, сложные — в модели подороже. Не кидаем всю репу в контекст, чистим историю диалогов, пишем короткие конкретные промпты без вежливости и эмоций, переиспользуем скиллы и шаблоны.
Черри пикинг? Отчасти да, и намеренно. Типовые задачи выбрали осознанно, тк лезть сразу в архитектуру с ИИ - это не эксперимент, это хаос. То что они «быстро закончатся» — возможно. Но пока нет) Что будет на сложных задачах — честно говорим: не знаем, данных мало.
Гудхарт — уважаем, держим в голове. Именно поэтому velocity не единственная метрика, рядом штуки задач и конкретное время разработчика.
Про осторожный переход — полностью согласны. Мы и рекомендуем осторожно. Статья про один квартал, один продукт, с оговорками. Никакого экстаза, стулья на месте.
Согласна, velocity в изоляции — плохая метрика. Именно поэтому рядом третий график — абсолютное число закрытых фич и багов за спринт: с 10–18 до 17–23. Это штуки, не поинты. Фича либо есть, либо её нет.
Плюс конкретика: трансформация данных — с 2 дней до 2 часов, новый плагин — с 5 дней до 1 дня. Это реальное время разработчика, не переоценённый тикет.
Метафора со смузи хороша, если мерить только кружки. Мы смотрим ещё и на то, что реально уехало в прод в конце спринта.
В следующем цикле добавляем баги на фичу и время ревью — velocity без качества действительно половина картины.
Спасибо за внимательный разбор: часть замечаний по делу, часть хочется оспорить.
По инфляции story points. Да, это классический риск при любом ускорении команды, и мы его держим в голове. Именно поэтому в статье рядом с velocity идёт второй график — абсолютное количество закрытых фич и багов за спринт. Оно тоже выросло: с 10–18 до 17–23. Это не story points, это штуки. Если бы рост был только в оценках — фичи бы не появлялись. Так что инфляция оценок если и есть, то объясняет часть роста, не весь.
По техническому долгу. Честно — пока не можем ни подтвердить, ни опровергнуть. В статье это прямо написано: следующий шаг — добавить метрики качества: баги на фичу, время ревью, процент принятых AI-предложений. Именно потому что velocity без качества — неполная картина. Так что претензия справедливая, но она совпадает с тем, что мы сами планируем мерить.
По "вздрючиванию". Вот здесь принципиально не согласна. Никто никого не заставлял работать больше часов. Инструмент убрал часть механической работы — это другая история, чем увеличение нагрузки. Разработчики стали меньше писать шаблонный код и больше заниматься проектированием и ревью. Это скорее в сторону интереса, чем выгорания.
Продолжим замеры — через квартал будет честнее видно, устойчив эффект или нет.
Добрый день! Пока что онлайн-варианта сетевых игр нет, к сожалению.
Если же вы говорите о конференции в целом, то мы планируем сделать и опубликовать записи докладов и дискуссий.
В данном случае мы рассматриваем отдельный класс систем, которые представляют из себя конструктор, а не коробочные решения конкретно под Бюджетирование.
1) Быстрый пересчет сложных моделей при изменении условий (минуты против часов, для сложных моделей) – одна из основных задач ЕРМ-систем
2) Для этого в ЕРМ есть функция Трассировки вычислений, которая позволяет сразу провалиться в форму-источник данных, отобразить формулу и посмотреть, кто последний вводил значения
3) Все современные Российские ЕРМ-системы – self service инструменты. Внести подобные изменения не проблема для пользователя, если он, конечно, не ограничен в правах на внесение подобных изменений)
Прекрасный пример автоматизации повторяемого процесса!
Солидный опыт, мы с командой тоже много лет внедряем системы автоматизации планирования на разных уровнях)
И, как вы правильно отметили, внедрение сложной автоматизированной системы с большим количеством пользователей и заинтересантов, будь то MES/ERP/EPM/BI – это чаще всего проект, который инициирует менеджмент компании. Пользователи обычно прекрасно существуют в привычных им инструментах.
И сразу отвечу на ваш комментарий в соседней ветке: внедрение любой ЕРМ сопровождается адаптацией, а часто трансформацией методологии компании, потому, что любой процесс компании должен быть управляемым с измеримыми результатами.
Связка Excel+querry+pivot – это предпоследний этап принятия и осознания изменений которые необходимы для контроля процесса)
В своем примере вы описываете как раз систему ручного управления и решение точечной задачи, а не управляемый процесс в компании.
Для решения подобных задач в ЕРМ у вас всегда есть «песочница» на отдельном срезе данных, где вы, как специалист, понимающий всю методику формирования мастер бюджетов, можете скорректировать необходимые драйверы и исходные данные для получения требуемого результата.
И когда вам необходимо внести изменения в сквозную калькуляционую модель, оценить влияние изменение атрибута одного из ресурсов с «покупной» на «собственного производства» и пересчитать весь производственно-финансовый план с выходом на отчетные формы корпорации в модели, которая состоит из связки Excel+SQL, кучи макросов в 80+ книгах и отдельной книгой для управления этими книгами, полный пересчет которой занимает 6 часов – это причина внедрения ЕРМ системы. Пересчет указанных выше изменений в ней займет 3-5 минут и останется время даже красоту навести и подготовить объяснение получившимся цифрам)
Но если задача стоит просто собрать таблицу – нужно собирать таблицу)
Продолжение обязательно будет, как и сравнение популярных Российских ЕРМ систем между собой и с 1С.
1) Да, теперь у линейных сотрудников и руководства есть "единое окно", где происходит ввод данных, согласование, корректировка и визуализация.
2) Конкретно в нашем случае да, прод крутится на одном сервере, но можно реализовать и "классическую" для 1С историю с локальными базами и последующей консолидацией или подтягивать данные в оперативном режиме. Сталкивались с разными пожеланиями заказчиков)
3) В проектах внедрения ЕРМ-систем методология всегда неразрывно связана с технической частью. Конкретно версии являются просто дополнительным измерением в каждом кубе, так называемые сквозные измерения. И можно в рамках одной формы сравнивать различные версии между собой в абсолютных и относительных величинах (План vs План с учетом корректировок vs Факт и тд.)
Про измерения и сводные таблицы вы говорите абсолютно верно (их же можно представить аналогом многомерных кубов, механика перетаскивания измерений схожа)
Сводные таблицы можно использовать, но как вы правильно отметили, необходимо собирать данные из множества листов в сводной таблице, где нет возможности редактировать информацию. Вам в таком случае необходимо идти в форму ввода, вносить данные, запускать пересчет книги и обновлять данные сводной таблицы.
В то же время в ЕРМ-системе у вас есть просто один гигантский лист, который сразу имеет представление сводной таблицы, пересчитывается на лету и дает возможность редактировать данные.
Эксель прекрасный инструмент, очень гибкий и понятный, с большими техническими возможностями.
Но именно эта гибкость при масштабировании рождает проблемы в больших компаниях. В двух словах коснулись этой темы в разделах перед выводами.
Так это же классика внедрения любой системы, даже небольшой типа самописки на Аксесе. Пользователи всегда держатся за привычное до последнего)
От этого сложно избавиться, но можно. Если вовлекать ключевых пользователей в новый инструмент, обучать, готовить инструкции или записывать ролики с полезными советами, они могут перетащить в новую систему и всех остальных.
Но если ни у кого нет желания переходить на что-то новое, будет что-то в стиле "интернет этот ваш нам не нужОн".
Все так, съемные носители самый простой и удобный способ защиты в т.ч. под задачи отказоустойчивости, а объектные хранилища рассматриваем как альтернативу лентам из реестра МПТ
Наша статья НЕ о "так надо". Цель изысканий - сказать "так надо, и вот почему".
Здравствуйте!
Спасибо!
Здравствуйте! Спасибо за ваш комментарий!
Нет, не только. Аналогичное поведение (автоназначение LUN ID) наблюдается на популярных СХД Huawei Dorado и многих других. Нет смысла брать вендора и модель СХД за основу при поиске потенциальных проблем. Вероятность попасть в такую ситуацию имеется при использовании любых СХД, если маппинг производился без учета требований VMware.
Добрый день!
Спасибо за ваш комментарий:) Мы старались не упустить деталей - для нас это важно.
Не только кластера, но и всего VC. LUN должен иметь одинаковый LUN ID для всех хостов в рамках vCenter Server'а.
Здравствуйте! Спасибо за ваш комментарий. Мастер определяет, но не умеет автоматически перестраивать топологию кластера. Поэтому использовали орекстратор как средство управления топологией в случае сбоя.
По умолчанию установщик zVirt Node выделяет под него 1Гб. Engine при развёртывании также получает 1Гб. В версиях 4.1-4.4 на каждое ядро суммарно приходилось ~300мб файлов в /boot, плюс какие-то возможные остатки от прошлых обновлений. Так что 2Гб вполне достаточно для того, чтобы обновиться без проблем.
Сейчас (в 4.5) ситуация стала получше - в /boot каждое ядро занимает суммарно менее 200мб. Так что если изначально разворачивать 4.5 и позднее обновляться на следующую версию - проблем быть не должно. Но в любом случае стоит перед обновлением проверить место, хотя бы на одном из хостов.