“Качество в бизнесе не то, что вкладывает производитель, это то, что ценит потребитель” (Питер Друкер). Эта цитата подчеркивает важность понимания и удовлетворения потребностей клиента, к чему и стремится CES.
Статья про метрику, которая измеряет уровень усилий, затраченных клиентом при взаимодействии с компанией или использовании её продуктов и услуг.
Hba — время адаптации до внедрения базы знаний, час
Тут бы сначала зафиксировать факт успеха адаптации, то есть задачи дб унифицированы по времени выполнения и\или сложности. А то получится, что одному “новичку” повезло с потоком, а второму не очень. Полагаю, что в банке с этим проще, чем в ИТ.
Ta — среднее время эксперта на разборки с неправомерной эскалацией, час
Тогда этот параметр тоже должен как-то фиксироваться в системе учета, не выискивать же по злобным комментариям.
у более 1000 статей выросло удобства восприятия контента на 18,6% и улучшилось качества обработки обратной связи на 28,4%
опытные специалисты тратят на поиск информации на 35% меньше времени
Идеальная фраза! Однако тонкость в том, чтобы уметь это сформулировать. Обычно народ доходит до чего-то очевидного и на этом все заканчивается. Ну а там, где очевидно, зачем что-то описывать? Потом проходит поколение и причинно-следственная связь теряется (рука-лицо).
Забавно, что когда я начинал читать PMBoK, я не понял - чего там учить-то? Там были описаны весьма банальные вещи, но потом я прошел курс по управлению проектами, и методология закрепилась сама собой. Потом я решил для сравнения пройти курс про Prince и моя логика сломалась - очень сложная методология, по которой я бы работать не смог. Ну то есть для запуска космических аппаратов - самое оно, но для рядовых ИТ-проектов перебор. Потому и спросил.
Когда я только начинал выстраивать процессы внутри команды, я экспериментировал с различными подходами
Если это не перевод статьи, то хочу спросить автора - а каковы были предпосылки? Ну, в чем сложность - дана голая команда без какой-либо системы работы или нужно как-то повысить ее эффективность? Почему Prince а не PMBoK?
но все усилия перечеркиваются какой-нибудь мелочью: то в компании забыли оплатить контактный телефон; то переполнился электронный почтовый ящик; то забыли указать новый адрес на «Яндекс.Картах»
Допускаю, что тотальные прогулы учебы к успеху не приведут, однако учиться можно разному. Кому-то важна проработка курсовых работ (особенно если человек работает по профилю), а кому-то гуманитарная составляющая (выступить, организовать, мотивировать и т.п.). Мы в свое время смеялись над сокурсниками по направлению "менеджмент", а вот сейчас стало очевидным, как плохо выстроенный процесс руинит инженерные шедевры.
С одной стороны цифра странная, т.к. в статье нет развернутого описания (как они вообще проверяли? там же просто новость в 1 предложение), а с другой - в масштабах такой компании вполне предсказуемо. Наверное дело не в терминах, а в номенклатуре запчастей от различных производителей. Видимо, в попытках экономии их стало слишком много и теперь нужна помощь роботов, чтобы разобрать этот бардак
Специалисты Toyota подсчитали, что только за счёт унификации терминологии в документации и информационных системах можно на 30% сократить количество промежуточных операций и ускорить процесс выпуска автомобилей.
Хорошо, я вернусь к этому вопросу, если мне попадется нужный материал. Я просто собираю информацию различных форматах, а статьи на Хабре - один из таких.
Уметь описать предметную область, по которой у вас диплом (ок, я опускаю шаг №0 как этот диплом выбирается - вы сами или вам уже дают готовую тему). И пока ты все это пишешь (разумеется самостоятельно, либо контролируешь того, кто делает за тебя), ты погружаешься в разные области, что не может не закрепить знания по курсу хотя бы в общем виде. Вышка - это больше не про знание самого предмета, а про знание где и что написано, ну и чтобы уметь этим знанием воспользоваться;
Найти проблему и придумать решение по ее устранению, посчитать экономический эффект и возможные риски;
Выступить с докладом. Выделить главное, сделать те самые 10-15 слайдов, написать речь. Я вот на предзащите облажался. Я все делал сам и мог объяснить любую запятую, но когда надо было “толкать речь” с таймером в 10 минут, я поплыл. То есть я бы мужественно провалил тот самый питчинг в лифте и не сделал бы “продажу” своей идеи
Я периодически конспектирую сложные вопросы, которыми занимался, и довольно часто получается больше 500 листов вместе с фотографиями и слайдами - это итоги 2 - 3 месяцев работы. Без этого уже через полгода я не вспомню и трети материала.
Мое почтение! Я все никак не решусь дописать статью “как я стал knowledge manager”, так вот в ее основе тоже постоянное конспектирование, которое дает мне ощутимую базу на много-много лет
Философия 6 сигм — это не просто набор правил, а мировоззрение, которое перестраивает мышление сотрудников и руководителей. Качество продукта или услуги определяется не внутренними стандартами компании, а ожиданиями заказчика.
Я не просил мне делать автомобили с сенсорными экранами, iOS 26 и обувь, которая носится пару сезонов. “Ожидания заказчика” как будто перевернуты с ног на голову. Или можно ли сказать, что “эти компании же не по сигмам работают”? Но знать эту методологию, безусловно, полезно.
Количественно надежность процесса — это интегральная оценка его рисков, выраженных количественно. Надежный процесс не «сломается», если на него будут воздействовать.
Похоже на мета-оценку, т.к. предполагается, что есть процесс, регламент и люди, все это выполняющие бесконечное кол-во времени. Это хороший показатель качества, спасибо за статьи. Надежность - это целый предмет для изучения, но опять же “свойство устройства, обеспечивающее выполнение им требуемой задачи” - т.е. кто-то это должен сделать и кто-то потребовать выполнения, вроде бы противоречия нет.
Есть смысл. Перечислите? Желательно с их таксономией (иерархией) и единицами измерения, примером расчета.
Такой цели у меня не было, я лишь хотел найти вменяемую картинку и не нашел. Знаю, что есть книга “Управление услугами на основе измерений”, наверняка в маркетинге, проектном и продуктовом управлении есть что-то свое, включая неочевидную “метрику” - “а захочет ли команда пойти с тобой в другие проекты?” #humor
Цель документации – быть понятной и приносить пользу.
Но с ограничением: документация хороша тогда, когда затраты на ее производство и поддержку меньше принесенной пользы (видео: «Документация — это про деньги»).
стандартные критерии качества при работе с техническим текстом
Если термина и определения в ТЗ нет, можно воспользоваться открытыми проверенными источниками
Я бы рекомендовал подходить к таким ресурсам с осторожностью. Например, определение услуги в ITIL написано не очень понятно, поэтому для рядового пользователя лучше “упростить тяжёлые для восприятия словесные обороты”
минимизировать терминологическую вложенность, которая усложняет работу с глоссарием
И да и нет. Нет - потому что я сторонник давать и определение термина, и его возможную классификацию (например, есть Эскалация - Иерархическая и Функциональная, чтобы не листать глоссарий, это все должно быть в одном месте)
Самый доступный способ профилактики фактических ошибок и несоответствий — ревью технических текстов.
Да, а еще для самоконтроля можно схему нарисовать - насколько описание согласуется с графическим представлением, понятна ли логика или чего-то не хватает
Статья про метрику, которая измеряет уровень усилий, затраченных клиентом при взаимодействии с компанией или использовании её продуктов и услуг.
Статья про ROI при внедрении базы знаний в банках - https://habr.com/ru/companies/teamly/articles/1063618/
Добрый день!
Тут бы сначала зафиксировать факт успеха адаптации, то есть задачи дб унифицированы по времени выполнения и\или сложности. А то получится, что одному “новичку” повезло с потоком, а второму не очень. Полагаю, что в банке с этим проще, чем в ИТ.
Тогда этот параметр тоже должен как-то фиксироваться в системе учета, не выискивать же по злобным комментариям.
А это как определялось?
Идеальная фраза! Однако тонкость в том, чтобы уметь это сформулировать. Обычно народ доходит до чего-то очевидного и на этом все заканчивается. Ну а там, где очевидно, зачем что-то описывать? Потом проходит поколение и причинно-следственная связь теряется (рука-лицо).
Забавно, что когда я начинал читать PMBoK, я не понял - чего там учить-то? Там были описаны весьма банальные вещи, но потом я прошел курс по управлению проектами, и методология закрепилась сама собой. Потом я решил для сравнения пройти курс про Prince и моя логика сломалась - очень сложная методология, по которой я бы работать не смог. Ну то есть для запуска космических аппаратов - самое оно, но для рядовых ИТ-проектов перебор. Потому и спросил.
Не уверен за контекст, но добавлю ссылку на статью: "Качественные исследования в бизнесе: книга, которой не хватало"
Если это не перевод статьи, то хочу спросить автора - а каковы были предпосылки? Ну, в чем сложность - дана голая команда без какой-либо системы работы или нужно как-то повысить ее эффективность? Почему Prince а не PMBoK?
Про качество клиентского обслуживания - https://www.osp.ru/os/2026/02/13060837
Допускаю, что тотальные прогулы учебы к успеху не приведут, однако учиться можно разному. Кому-то важна проработка курсовых работ (особенно если человек работает по профилю), а кому-то гуманитарная составляющая (выступить, организовать, мотивировать и т.п.). Мы в свое время смеялись над сокурсниками по направлению "менеджмент", а вот сейчас стало очевидным, как плохо выстроенный процесс руинит инженерные шедевры.
Добавил 2 критерия для регламентов: согласованность и детализация.
С одной стороны цифра странная, т.к. в статье нет развернутого описания (как они вообще проверяли? там же просто новость в 1 предложение), а с другой - в масштабах такой компании вполне предсказуемо. Наверное дело не в терминах, а в номенклатуре запчастей от различных производителей. Видимо, в попытках экономии их стало слишком много и теперь нужна помощь роботов, чтобы разобрать этот бардак
https://habr.com/ru/news/1055090/
Я подозревал, что терминология влияет, но не думал, что на 30%! Теперь хоть будет ресурс, на который можно ссылаться :)
Хорошо, я вернусь к этому вопросу, если мне попадется нужный материал. Я просто собираю информацию различных форматах, а статьи на Хабре - один из таких.
Товарисчи! Давайте будем честны - никому ваши знания неинтересны. Фактически, дипломом проверяется 3 навыка:
Уметь описать предметную область, по которой у вас диплом (ок, я опускаю шаг №0 как этот диплом выбирается - вы сами или вам уже дают готовую тему). И пока ты все это пишешь (разумеется самостоятельно, либо контролируешь того, кто делает за тебя), ты погружаешься в разные области, что не может не закрепить знания по курсу хотя бы в общем виде. Вышка - это больше не про знание самого предмета, а про знание где и что написано, ну и чтобы уметь этим знанием воспользоваться;
Найти проблему и придумать решение по ее устранению, посчитать экономический эффект и возможные риски;
Выступить с докладом. Выделить главное, сделать те самые 10-15 слайдов, написать речь. Я вот на предзащите облажался. Я все делал сам и мог объяснить любую запятую, но когда надо было “толкать речь” с таймером в 10 минут, я поплыл. То есть я бы мужественно провалил тот самый питчинг в лифте и не сделал бы “продажу” своей идеи
Мое почтение! Я все никак не решусь дописать статью “как я стал knowledge manager”, так вот в ее основе тоже постоянное конспектирование, которое дает мне ощутимую базу на много-много лет
Я не просил мне делать автомобили с сенсорными экранами, iOS 26 и обувь, которая носится пару сезонов. “Ожидания заказчика” как будто перевернуты с ног на голову. Или можно ли сказать, что “эти компании же не по сигмам работают”? Но знать эту методологию, безусловно, полезно.
Похоже на мета-оценку, т.к. предполагается, что есть процесс, регламент и люди, все это выполняющие бесконечное кол-во времени. Это хороший показатель качества, спасибо за статьи. Надежность - это целый предмет для изучения, но опять же “свойство устройства, обеспечивающее выполнение им требуемой задачи” - т.е. кто-то это должен сделать и кто-то потребовать выполнения, вроде бы противоречия нет.
Такой цели у меня не было, я лишь хотел найти вменяемую картинку и не нашел. Знаю, что есть книга “Управление услугами на основе измерений”, наверняка в маркетинге, проектном и продуктовом управлении есть что-то свое, включая неочевидную “метрику” - “а захочет ли команда пойти с тобой в другие проекты?” #humor
По идее как-то так: https://habr.com/ru/articles/1044662/
Добрый день! Хорошо, но дополню:
Но с ограничением: документация хороша тогда, когда затраты на ее производство и поддержку меньше принесенной пользы (видео: «Документация — это про деньги»).
Написал про критерии (и заодно добавлю себе ссылкой про “Стоимость чтения этих материалов”) - https://habr.com/ru/articles/830584/
Хорошее описание плохого примера: https://habr.com/ru/companies/ruvds/articles/985818/
Я бы рекомендовал подходить к таким ресурсам с осторожностью. Например, определение услуги в ITIL написано не очень понятно, поэтому для рядового пользователя лучше “упростить тяжёлые для восприятия словесные обороты”
И да и нет. Нет - потому что я сторонник давать и определение термина, и его возможную классификацию (например, есть Эскалация - Иерархическая и Функциональная, чтобы не листать глоссарий, это все должно быть в одном месте)
Да, а еще для самоконтроля можно схему нарисовать - насколько описание согласуется с графическим представлением, понятна ли логика или чего-то не хватает
Потому что системное мышление дано не всем. Как удачно ты продолжил мою мысль :)