Именно. И самое неудобное - что правильный вопрос звучит не “агенты хорошо или плохо”, а “что именно мы просим оптимизировать и готовы ли жить с последствиями”.
Большинство команд пока предпочитают не формулировать его вслух
Связка 1С + GLPI + вменяемые люди - рабочая комбинация, спору нет. На 800 компов и 20 серверах это действительно закрывает задачу. Вопрос в том, что происходит при масштабировании: когда подразделений становится не 18, а 50, когда появляются склады в разных городах, когда нужно считать TCO и связывать контракты с конкретными активами. GLPI в этой точке начинает упираться - и «вменяемые сотрудники» начинают тратить всё больше времени на то, что система должна делать сама. Но если у вас 1–2% расхождений — это отличный результат
На практике прирост штата зависит от трёх критических факторов: текущего уровня автоматизации, CSAT-метрик и наличия инструментов. Если ваш Service Desk уже хорошо автоматизирован (чат-боты, самообслуживание и др.), то прирост составит примерно 10-15% - это в основном специалисты по анализу качества, улучшению процессов и сбору обратной связи.
Если же Service Desk работает преимущественно вручную, первым шагом должна быть именно автоматизация, а не найм: она высвобождает 20-30% ресурсов, которые затем переучивают на качество и аналитику.
Не все хотят и должны быть творцами, но нужно дать возможность тем, кто хочет влиять на продукт. Если человеку нравится получать четкое ТЗ и писать качественный код это тоже очень ценно. Проблема начинается, когда всех насильно загоняют в режим "просто делай задачу и не задавай вопросов", даже тех кто мог бы предложить что-то дельное
когда от человека ждут, когда он придет и принесет свой проект в бизнес (в чей-то), причем бесплатно, или просто нагенерит коммерческих идей
мы говорим не о том, что разработчик должен генерить бизнес-идеи за продакта. Просто когда человек видит, что мы городим велосипед или архитектура не тянет, он должен иметь возможность это сказать, а не просто писать код по ТЗ
IMHO, ну неправильно это сравнивать взрослых людей с детьми, там, где требуется мало-мальски серьезное отношение.
Возможно, аналогия не очень удачная :) Суть была в том, что если мерить не то, получишь не тот результат. Мерим количество тасков – люди их дробят. Мерим часы – рисуют в конце месяца
Зависит от типа генерального директора, кмк
Да, тут про технического основателя, который понимает продукт. Если он просто согласовывает скрепки, то без комментариев, сами понимаете :)
Под ценностью мы имеем в виду не только деньги, но и знание. Если команда за месяц проверила идею и выяснила, что она не работает или не нужна – это огромная ценность, и вы не потратили год на развитие провальной фичи
И вот антипример: команда полгода делала что-то, что можно было проверить за две недели, или вообще делала не то, что нужно бизнесу, потому что никто не удосужился спросить
для многих компаний Jira действительно работает хорошо Мы рассказали о тех случаях, когда она не справляется. Если у вас в Jira всё прекрасно, значит, она подходит под ваши задачи, и это здорово
В некоторых ситуация ускорение происходит не только от смены таск-трекера. Часто это результат изменения подхода: переход от проектного мышления к продуктовому, улучшение синхронизации команд, интеграция с ITSM для приоритизации на основе инцидентов. Таск-трекер либо помогает этому, либо мешает
Понимаю ваш скепсис, статью я основывал на собственном опыте. Если у вас другой опыт, буду рад услышать, как вы решаете проблемы с синхронизацией команд
по моему мнению, структура инструмента заставляет создавать лишние слои. Бизнес-отдел работает в своём проекте, команды в своих. Связать их можно, но приходится настраивать иерархию или горизонтальные связи, которые Jira не очень любит.
Мы убрали этот промежуточный слой, бизнес и команды работают с одним бэклогом продукта
Справедливо. Речь скорее не про то, что новичок сам выбирает приоритеты, а что ему нужно понять контекст: какой продукт делаем, зачем, как его задача вписывается в общую картину. В Jira это размазано по проектам и Confluence. В SimpleOne продукт с описанием ценности это отдельная сущность, которую сразу видно
А чем менеджер занимается, который управляет этими командами? Почему нельзя просто завести один эпик и в него кинуть 3 разных задачи?
Можно, но когда эпик живёт в одном проекте, а задачи команд в трёх других, получается 4 проекта, между которыми нужно прыгать. Бизнес не опускается в задачи команд, команды поднимаются в эпик бизнеса. Мы решаем это через единый бэклог продукта, из которого команды берут задачи, это плоская структура вместо иерархии проектов
Это вообще не связано с таск трекером. Не беда, если какая-то инфа лежит на конфлюенсе. Человек умрет что-ли, если в конфлюенс перейдет?
Согласен, что информация может лежать где угодно. Но проблема в том, что когда у вас 20+ проектов и 30 команд, новый человек тратит кучу времени, чтобы понять, где его доска, что за продукт делают, зачем это нужно. Confluence отдельно, Jira отдельно, Miro где-то ещё. Единая точка входа упрощает онбординг
Аналогия понятна, но есть нюанс: Mercedes вы покупаете под свои задачи. А Jira многие используют просто потому что все так делают, хотя она под их задачи не заточена. Если у вас одна команда из 5 человек, Jira отлично работает. Если 30 команд и используется например SAFe, начинаются проблемы, которые мы описали
Добрый день! Также хотелось бы дополнить наш первый ответ
Мы постоянно работаем над тем, чтобы специалистам было проще освоить платформу. У нас есть бесплатные и платные обучающие курсы, а требования к навыкам для работы с платформой соответствуют уровню Junior-Middle.
Код, лежащий в ядре системы, является полностью нашей разработкой.
Объектная модель в нашей системе реализована по принципам, схожим с ведущими мировыми платформами, что обеспечивает ее эффективность и гибкость.
Импорт BPMN-моделей включен в нашу дорожную карту развития продукта, можно ознакомиться с ней на сайте.
Наша платформа не ограничивается функциональностью BPMS, а предоставляет более широкие возможности в рамках концепции ESM.
Ценообразование нашего продукта основано на рыночных принципах. Мы ведем честный бизнес и открыты к диалогу по любым вопросам.
Приглашаем присоединиться к Сообществу SimpleOne, где вы сможете более подробно обсудить все аспекты работы с нашей платформой. Мы ценим каждое мнение и стремимся к постоянному совершенствованию.
Именно. И самое неудобное - что правильный вопрос звучит не “агенты хорошо или плохо”, а “что именно мы просим оптимизировать и готовы ли жить с последствиями”.
Большинство команд пока предпочитают не формулировать его вслух
Связка 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 для приоритизации на основе инцидентов. Таск-трекер либо помогает этому, либо мешает
Понимаю ваш скепсис, статью я основывал на собственном опыте. Если у вас другой опыт, буду рад услышать, как вы решаете проблемы с синхронизацией команд
по моему мнению, структура инструмента заставляет создавать лишние слои. Бизнес-отдел работает в своём проекте, команды в своих. Связать их можно, но приходится настраивать иерархию или горизонтальные связи, которые Jira не очень любит.
Мы убрали этот промежуточный слой, бизнес и команды работают с одним бэклогом продукта
Справедливо. Речь скорее не про то, что новичок сам выбирает приоритеты, а что ему нужно понять контекст: какой продукт делаем, зачем, как его задача вписывается в общую картину. В Jira это размазано по проектам и Confluence. В SimpleOne продукт с описанием ценности это отдельная сущность, которую сразу видно
Можно, но когда эпик живёт в одном проекте, а задачи команд в трёх других, получается 4 проекта, между которыми нужно прыгать. Бизнес не опускается в задачи команд, команды поднимаются в эпик бизнеса. Мы решаем это через единый бэклог продукта, из которого команды берут задачи, это плоская структура вместо иерархии проектов
Согласен, что информация может лежать где угодно. Но проблема в том, что когда у вас 20+ проектов и 30 команд, новый человек тратит кучу времени, чтобы понять, где его доска, что за продукт делают, зачем это нужно. Confluence отдельно, Jira отдельно, Miro где-то ещё. Единая точка входа упрощает онбординг
Аналогия понятна, но есть нюанс: Mercedes вы покупаете под свои задачи. А Jira многие используют просто потому что все так делают, хотя она под их задачи не заточена. Если у вас одна команда из 5 человек, Jira отлично работает. Если 30 команд и используется например SAFe, начинаются проблемы, которые мы описали
Спасибо, что маякнули! Всё поправили :)
Добрый день! Также хотелось бы дополнить наш первый ответ
Мы постоянно работаем над тем, чтобы специалистам было проще освоить платформу. У нас есть бесплатные и платные обучающие курсы, а требования к навыкам для работы с платформой соответствуют уровню Junior-Middle.
Код, лежащий в ядре системы, является полностью нашей разработкой.
Объектная модель в нашей системе реализована по принципам, схожим с ведущими мировыми платформами, что обеспечивает ее эффективность и гибкость.
Импорт BPMN-моделей включен в нашу дорожную карту развития продукта, можно ознакомиться с ней на сайте.
Наша платформа не ограничивается функциональностью BPMS, а предоставляет более широкие возможности в рамках концепции ESM.
Ценообразование нашего продукта основано на рыночных принципах. Мы ведем честный бизнес и открыты к диалогу по любым вопросам.
Приглашаем присоединиться к Сообществу SimpleOne, где вы сможете более подробно обсудить все аспекты работы с нашей платформой. Мы ценим каждое мнение и стремимся к постоянному совершенствованию.
https://docs.simpleone.ru/ru/platform/developer-help/developer-api/server-side-api/simplesystem#ssdebugmessage
https://docs.simpleone.ru/ru/platform/developer-help/developer-api/server-side-api/simplesystem#ssinfomessage
https://docs.simpleone.ru/ru/platform/developer-help/developer-api/server-side-api/simplesystem#sswarningmessage
https://docs.simpleone.ru/ru/platform/developer-help/developer-api/server-side-api/simplesystem#sserrormessage
Недавно раскрывали аспекты нашей платформы в подкасте, можете посмотреть здесь в конце материала