С утилизацией проблем не возникло: очередь гипотез, которые раньше вообще не доезжали до проверки, длиннее высвобожденных часов — статья, собственно, из этой боли и выросла. Окно возможностей обычно закрывалось раньше, чем задача доходила до прода; теперь до проверки доезжает больше.
И часть освободившегося времени съедает новая работа, которой раньше не было: постановка задач агентам и приемка результата. Так что свободных часов по факту меньше, чем кажется по арифметике.
Порядок тот же: maxnoosphere → arch1lochus → AOneAgency сегодня, Jur1k — после фактуры (время на отладку промпта, механика анти-зацикливания, один пример завернутого решения). Скажешь «ок» — могу вставить через твой Chrome, либо забирай текстом.
Так и есть, полный автопилот мы и не предлагаем. В контуре обязательные точки, где решает человек: постановка, приемка спеки, приемка результата. До человека к тому же доходит не все — скептик заворачивает 58% черновиков еще внутри контура.
Про смещение роли подпишусь по опыту двух кейсов: главная работа сместилась в постановку задачи и приемку. И важный нюанс — порог входа при этом не падает, а растет: неопытному специалисту оркестр агентов не поможет, чем сложнее домен, тем важнее живая экспертиза.
Смотря что считать выхлопом. Если сгенерированный код — подписка дешевле, спорить не буду. Мы считаем задачу, доведенную до прода: со спекой, ревью, тестами и выкаткой. В таком расчете на кейс уходят десятки долларов токенов при экономии в человеко-месяцы — сравнение с подпиской тут уже не главный вопрос.
А «десяток агентов на токенах» без общей доски, контекста и точек проверки — это правда дорогая игрушка, тут согласен. Ровно поэтому полстатьи не про агентов, а про фундамент, без которого они деньги жгут, а не экономят.
Про «вайбкодинг и чинить руками» — это не камень в профессионала с LLM. Это про сценарий, когда сгенерированный в чате кусок живет без контура: вставили, что-то поехало на стыке, чиним. Для отдельных фрагментов чат — нормальный рабочий режим, сами так работаем, и ваша схема «чат для фрагментов, критичное руками» вполне здравая.
А про деньги — разница не «чат против агентов», а что меряем. Чат за $20 ускоряет написание кода, и в этой дисциплине он честно выигрывает — в статье это и названо «ускорили один участок очереди». Агентный контур закрывает цикл целиком: спека, план, код, ревью, тесты, выкатка. Сессии по $100 бывают, да — но единица ценности не сессия, а довезенная до прода задача. У нас на кейс уходят десятки долларов токенов при экономии в человеко-месяцы; на этом фоне стоимость токенов — погрешность. Дорого становится тогда, когда агентов гоняют без доски, контекста и точек проверки — тогда жгутся и токены, и время.
Меряем три вещи: время от постановки до рабочего результата, трудоемкость против классики и стоимость токенов на прогон. База сравнения — оценка тимлида по обычному процессу для тех же задач, поэтому «4–7 недель» — это не замер параллельной разработки, а честная экспертная оценка, других у нас нет. Плюс считаем итерации агентов и точки, где вмешивался человек: в первом кейсе ~15–25 итераций, во втором ~12–14.
Про две недели настройки — справедливо, контур бесплатно не достается, и на одной задаче он не окупится. Но собирается он один раз: второй кейс заметно сложнее первого, а занял те же 2–4 дня — ровно потому, что контур уже был готов. Дальше setup размазывается по каждой следующей задаче, и чем больше их через контур проходит, тем меньше его доля в стоимости. Собственно, поэтому статья и топит за то, чтобы собирать контур там, где половина уже есть, а не с нуля.
ITAM в этой цепочке не замена визе ИТ-директора, а способ сделать так, чтобы эта виза была основана на данных, а не на обзвоне складов. Когда парк 200 машин - можно и руками проверить. Когда 5 000 по трём городам - без системы виза превращается в подпись вслепую.
Спасибо за комментарий - это, пожалуй, лучшее дополнение к статье, которое можно было написать.
Если у вас TNI + PowerShell + 1С работает шесть лет и закрывает задачи, это уже не «кривовато», это боевая система. Менять её имеет смысл только когда боль от текущего процесса станет больше, чем боль от перехода.
Справедливый вопрос. ITSM 365 действительно построен на базе Naumen, но позиционируется как облачный Service Desk - с фокусом на обработку обращений, а не на управление активами. ITAM-функциональность там ограничена: нет полноценного жизненного цикла актива, нет связки с финансами и закупками, нет инвентаризации в том смысле, который мы разбираем в статье. Это как сравнивать Jira и Jira Service Management - похожие корни, разные задачи.
Именно. И самое неудобное - что правильный вопрос звучит не “агенты хорошо или плохо”, а “что именно мы просим оптимизировать и готовы ли жить с последствиями”.
Большинство команд пока предпочитают не формулировать его вслух
Связка 1С + GLPI + вменяемые люди - рабочая комбинация, спору нет. На 800 компов и 20 серверах это действительно закрывает задачу. Вопрос в том, что происходит при масштабировании: когда подразделений становится не 18, а 50, когда появляются склады в разных городах, когда нужно считать TCO и связывать контракты с конкретными активами. GLPI в этой точке начинает упираться - и «вменяемые сотрудники» начинают тратить всё больше времени на то, что система должна делать сама. Но если у вас 1–2% расхождений — это отличный результат
На практике прирост штата зависит от трёх критических факторов: текущего уровня автоматизации, CSAT-метрик и наличия инструментов. Если ваш Service Desk уже хорошо автоматизирован (чат-боты, самообслуживание и др.), то прирост составит примерно 10-15% - это в основном специалисты по анализу качества, улучшению процессов и сбору обратной связи.
Если же Service Desk работает преимущественно вручную, первым шагом должна быть именно автоматизация, а не найм: она высвобождает 20-30% ресурсов, которые затем переучивают на качество и аналитику.
Не все хотят и должны быть творцами, но нужно дать возможность тем, кто хочет влиять на продукт. Если человеку нравится получать четкое ТЗ и писать качественный код это тоже очень ценно. Проблема начинается, когда всех насильно загоняют в режим "просто делай задачу и не задавай вопросов", даже тех кто мог бы предложить что-то дельное
когда от человека ждут, когда он придет и принесет свой проект в бизнес (в чей-то), причем бесплатно, или просто нагенерит коммерческих идей
мы говорим не о том, что разработчик должен генерить бизнес-идеи за продакта. Просто когда человек видит, что мы городим велосипед или архитектура не тянет, он должен иметь возможность это сказать, а не просто писать код по ТЗ
IMHO, ну неправильно это сравнивать взрослых людей с детьми, там, где требуется мало-мальски серьезное отношение.
Возможно, аналогия не очень удачная :) Суть была в том, что если мерить не то, получишь не тот результат. Мерим количество тасков – люди их дробят. Мерим часы – рисуют в конце месяца
Зависит от типа генерального директора, кмк
Да, тут про технического основателя, который понимает продукт. Если он просто согласовывает скрепки, то без комментариев, сами понимаете :)
Под ценностью мы имеем в виду не только деньги, но и знание. Если команда за месяц проверила идею и выяснила, что она не работает или не нужна – это огромная ценность, и вы не потратили год на развитие провальной фичи
И вот антипример: команда полгода делала что-то, что можно было проверить за две недели, или вообще делала не то, что нужно бизнесу, потому что никто не удосужился спросить
для многих компаний Jira действительно работает хорошо Мы рассказали о тех случаях, когда она не справляется. Если у вас в Jira всё прекрасно, значит, она подходит под ваши задачи, и это здорово
В некоторых ситуация ускорение происходит не только от смены таск-трекера. Часто это результат изменения подхода: переход от проектного мышления к продуктовому, улучшение синхронизации команд, интеграция с ITSM для приоритизации на основе инцидентов. Таск-трекер либо помогает этому, либо мешает
Понимаю ваш скепсис, статью я основывал на собственном опыте. Если у вас другой опыт, буду рад услышать, как вы решаете проблемы с синхронизацией команд
С утилизацией проблем не возникло: очередь гипотез, которые раньше вообще не доезжали до проверки, длиннее высвобожденных часов — статья, собственно, из этой боли и выросла. Окно возможностей обычно закрывалось раньше, чем задача доходила до прода; теперь до проверки доезжает больше.
И часть освободившегося времени съедает новая работа, которой раньше не было: постановка задач агентам и приемка результата. Так что свободных часов по факту меньше, чем кажется по арифметике.
Порядок тот же: maxnoosphere → arch1lochus → AOneAgency сегодня, Jur1k — после фактуры (время на отладку промпта, механика анти-зацикливания, один пример завернутого решения). Скажешь «ок» — могу вставить через твой Chrome, либо забирай текстом.
Так и есть, полный автопилот мы и не предлагаем. В контуре обязательные точки, где решает человек: постановка, приемка спеки, приемка результата. До человека к тому же доходит не все — скептик заворачивает 58% черновиков еще внутри контура.
Про смещение роли подпишусь по опыту двух кейсов: главная работа сместилась в постановку задачи и приемку. И важный нюанс — порог входа при этом не падает, а растет: неопытному специалисту оркестр агентов не поможет, чем сложнее домен, тем важнее живая экспертиза.
Смотря что считать выхлопом. Если сгенерированный код — подписка дешевле, спорить не буду. Мы считаем задачу, доведенную до прода: со спекой, ревью, тестами и выкаткой. В таком расчете на кейс уходят десятки долларов токенов при экономии в человеко-месяцы — сравнение с подпиской тут уже не главный вопрос.
А «десяток агентов на токенах» без общей доски, контекста и точек проверки — это правда дорогая игрушка, тут согласен. Ровно поэтому полстатьи не про агентов, а про фундамент, без которого они деньги жгут, а не экономят.
Про «вайбкодинг и чинить руками» — это не камень в профессионала с LLM. Это про сценарий, когда сгенерированный в чате кусок живет без контура: вставили, что-то поехало на стыке, чиним. Для отдельных фрагментов чат — нормальный рабочий режим, сами так работаем, и ваша схема «чат для фрагментов, критичное руками» вполне здравая.
А про деньги — разница не «чат против агентов», а что меряем. Чат за $20 ускоряет написание кода, и в этой дисциплине он честно выигрывает — в статье это и названо «ускорили один участок очереди». Агентный контур закрывает цикл целиком: спека, план, код, ревью, тесты, выкатка. Сессии по $100 бывают, да — но единица ценности не сессия, а довезенная до прода задача. У нас на кейс уходят десятки долларов токенов при экономии в человеко-месяцы; на этом фоне стоимость токенов — погрешность. Дорого становится тогда, когда агентов гоняют без доски, контекста и точек проверки — тогда жгутся и токены, и время.
Меряем три вещи: время от постановки до рабочего результата, трудоемкость против классики и стоимость токенов на прогон. База сравнения — оценка тимлида по обычному процессу для тех же задач, поэтому «4–7 недель» — это не замер параллельной разработки, а честная экспертная оценка, других у нас нет. Плюс считаем итерации агентов и точки, где вмешивался человек: в первом кейсе ~15–25 итераций, во втором ~12–14.
Про две недели настройки — справедливо, контур бесплатно не достается, и на одной задаче он не окупится. Но собирается он один раз: второй кейс заметно сложнее первого, а занял те же 2–4 дня — ровно потому, что контур уже был готов. Дальше setup размазывается по каждой следующей задаче, и чем больше их через контур проходит, тем меньше его доля в стоимости. Собственно, поэтому статья и топит за то, чтобы собирать контур там, где половина уже есть, а не с нуля.
Будем рады, если получится изучить наш материал и оставить справедливый отзыв, мы старались)
ITAM в этой цепочке не замена визе ИТ-директора, а способ сделать так, чтобы эта виза была основана на данных, а не на обзвоне складов. Когда парк 200 машин - можно и руками проверить. Когда 5 000 по трём городам - без системы виза превращается в подпись вслепую.
Спасибо за комментарий - это, пожалуй, лучшее дополнение к статье, которое можно было написать.
Если у вас TNI + PowerShell + 1С работает шесть лет и закрывает задачи, это уже не «кривовато», это боевая система. Менять её имеет смысл только когда боль от текущего процесса станет больше, чем боль от перехода.
Удачи с бюджетом и с ТСД. И с тётей Людой…
Справедливый вопрос. ITSM 365 действительно построен на базе Naumen, но позиционируется как облачный Service Desk - с фокусом на обработку обращений, а не на управление активами. ITAM-функциональность там ограничена: нет полноценного жизненного цикла актива, нет связки с финансами и закупками, нет инвентаризации в том смысле, который мы разбираем в статье. Это как сравнивать Jira и Jira Service Management - похожие корни, разные задачи.
Именно. И самое неудобное - что правильный вопрос звучит не “агенты хорошо или плохо”, а “что именно мы просим оптимизировать и готовы ли жить с последствиями”.
Большинство команд пока предпочитают не формулировать его вслух
Связка 1С + GLPI + вменяемые люди - рабочая комбинация, спору нет. На 800 компов и 20 серверах это действительно закрывает задачу. Вопрос в том, что происходит при масштабировании: когда подразделений становится не 18, а 50, когда появляются склады в разных городах, когда нужно считать TCO и связывать контракты с конкретными активами. GLPI в этой точке начинает упираться - и «вменяемые сотрудники» начинают тратить всё больше времени на то, что система должна делать сама. Но если у вас 1–2% расхождений — это отличный результат
Он ещё и стикер «не трогать!» повесил - так что формально процесс есть 😄
На практике прирост штата зависит от трёх критических факторов: текущего уровня автоматизации, CSAT-метрик и наличия инструментов. Если ваш Service Desk уже хорошо автоматизирован (чат-боты, самообслуживание и др.), то прирост составит примерно 10-15% - это в основном специалисты по анализу качества, улучшению процессов и сбору обратной связи.
Если же Service Desk работает преимущественно вручную, первым шагом должна быть именно автоматизация, а не найм: она высвобождает 20-30% ресурсов, которые затем переучивают на качество и аналитику.
Посмотреть функциональные возможности обновления можно здесь: https://rutube.ru/video/daebcfb53a9c579401cbcb58cc489f45/
Не все хотят и должны быть творцами, но нужно дать возможность тем, кто хочет влиять на продукт. Если человеку нравится получать четкое ТЗ и писать качественный код это тоже очень ценно. Проблема начинается, когда всех насильно загоняют в режим "просто делай задачу и не задавай вопросов", даже тех кто мог бы предложить что-то дельное
мы говорим не о том, что разработчик должен генерить бизнес-идеи за продакта. Просто когда человек видит, что мы городим велосипед или архитектура не тянет, он должен иметь возможность это сказать, а не просто писать код по ТЗ
Возможно, аналогия не очень удачная :) Суть была в том, что если мерить не то, получишь не тот результат. Мерим количество тасков – люди их дробят. Мерим часы – рисуют в конце месяца
Да, тут про технического основателя, который понимает продукт. Если он просто согласовывает скрепки, то без комментариев, сами понимаете :)
Под ценностью мы имеем в виду не только деньги, но и знание. Если команда за месяц проверила идею и выяснила, что она не работает или не нужна – это огромная ценность, и вы не потратили год на развитие провальной фичи
И вот антипример: команда полгода делала что-то, что можно было проверить за две недели, или вообще делала не то, что нужно бизнесу, потому что никто не удосужился спросить
для многих компаний Jira действительно работает хорошо
Мы рассказали о тех случаях, когда она не справляется. Если у вас в Jira всё прекрасно, значит, она подходит под ваши задачи, и это здорово
В некоторых ситуация ускорение происходит не только от смены таск-трекера. Часто это результат изменения подхода: переход от проектного мышления к продуктовому, улучшение синхронизации команд, интеграция с ITSM для приоритизации на основе инцидентов. Таск-трекер либо помогает этому, либо мешает
Понимаю ваш скепсис, статью я основывал на собственном опыте. Если у вас другой опыт, буду рад услышать, как вы решаете проблемы с синхронизацией команд