но все усилия перечеркиваются какой-нибудь мелочью: то в компании забыли оплатить контактный телефон; то переполнился электронный почтовый ящик; то забыли указать новый адрес на «Яндекс.Картах»
Допускаю, что тотальные прогулы учебы к успеху не приведут, однако учиться можно разному. Кому-то важна проработка курсовых работ (особенно если человек работает по профилю), а кому-то гуманитарная составляющая (выступить, организовать, мотивировать и т.п.). Мы в свое время смеялись над сокурсниками по направлению "менеджмент", а вот сейчас стало очевидным, как плохо выстроенный процесс руинит инженерные шедевры.
С одной стороны цифра странная, т.к. в статье нет развернутого описания (как они вообще проверяли? там же просто новость в 1 предложение), а с другой - в масштабах такой компании вполне предсказуемо. Наверное дело не в терминах, а в номенклатуре запчастей от различных производителей. Видимо, в попытках экономии их стало слишком много и теперь нужна помощь роботов, чтобы разобрать этот бардак
Специалисты Toyota подсчитали, что только за счёт унификации терминологии в документации и информационных системах можно на 30% сократить количество промежуточных операций и ускорить процесс выпуска автомобилей.
Хорошо, я вернусь к этому вопросу, если мне попадется нужный материал. Я просто собираю информацию различных форматах, а статьи на Хабре - один из таких.
Уметь описать предметную область, по которой у вас диплом (ок, я опускаю шаг №0 как этот диплом выбирается - вы сами или вам уже дают готовую тему). И пока ты все это пишешь (разумеется самостоятельно, либо контролируешь того, кто делает за тебя), ты погружаешься в разные области, что не может не закрепить знания по курсу хотя бы в общем виде. Вышка - это больше не про знание самого предмета, а про знание где и что написано, ну и чтобы уметь этим знанием воспользоваться;
Найти проблему и придумать решение по ее устранению, посчитать экономический эффект и возможные риски;
Выступить с докладом. Выделить главное, сделать те самые 10-15 слайдов, написать речь. Я вот на предзащите облажался. Я все делал сам и мог объяснить любую запятую, но когда надо было “толкать речь” с таймером в 10 минут, я поплыл. То есть я бы мужественно провалил тот самый питчинг в лифте и не сделал бы “продажу” своей идеи
Я периодически конспектирую сложные вопросы, которыми занимался, и довольно часто получается больше 500 листов вместе с фотографиями и слайдами - это итоги 2 - 3 месяцев работы. Без этого уже через полгода я не вспомню и трети материала.
Мое почтение! Я все никак не решусь дописать статью “как я стал knowledge manager”, так вот в ее основе тоже постоянное конспектирование, которое дает мне ощутимую базу на много-много лет
Философия 6 сигм — это не просто набор правил, а мировоззрение, которое перестраивает мышление сотрудников и руководителей. Качество продукта или услуги определяется не внутренними стандартами компании, а ожиданиями заказчика.
Я не просил мне делать автомобили с сенсорными экранами, iOS 26 и обувь, которая носится пару сезонов. “Ожидания заказчика” как будто перевернуты с ног на голову. Или можно ли сказать, что “эти компании же не по сигмам работают”? Но знать эту методологию, безусловно, полезно.
Количественно надежность процесса — это интегральная оценка его рисков, выраженных количественно. Надежный процесс не «сломается», если на него будут воздействовать.
Похоже на мета-оценку, т.к. предполагается, что есть процесс, регламент и люди, все это выполняющие бесконечное кол-во времени. Это хороший показатель качества, спасибо за статьи. Надежность - это целый предмет для изучения, но опять же “свойство устройства, обеспечивающее выполнение им требуемой задачи” - т.е. кто-то это должен сделать и кто-то потребовать выполнения, вроде бы противоречия нет.
Есть смысл. Перечислите? Желательно с их таксономией (иерархией) и единицами измерения, примером расчета.
Такой цели у меня не было, я лишь хотел найти вменяемую картинку и не нашел. Знаю, что есть книга “Управление услугами на основе измерений”, наверняка в маркетинге, проектном и продуктовом управлении есть что-то свое, включая неочевидную “метрику” - “а захочет ли команда пойти с тобой в другие проекты?” #humor
Цель документации – быть понятной и приносить пользу.
Но с ограничением: документация хороша тогда, когда затраты на ее производство и поддержку меньше принесенной пользы (видео: «Документация — это про деньги»).
стандартные критерии качества при работе с техническим текстом
Если термина и определения в ТЗ нет, можно воспользоваться открытыми проверенными источниками
Я бы рекомендовал подходить к таким ресурсам с осторожностью. Например, определение услуги в ITIL написано не очень понятно, поэтому для рядового пользователя лучше “упростить тяжёлые для восприятия словесные обороты”
минимизировать терминологическую вложенность, которая усложняет работу с глоссарием
И да и нет. Нет - потому что я сторонник давать и определение термина, и его возможную классификацию (например, есть Эскалация - Иерархическая и Функциональная, чтобы не листать глоссарий, это все должно быть в одном месте)
Самый доступный способ профилактики фактических ошибок и несоответствий — ревью технических текстов.
Да, а еще для самоконтроля можно схему нарисовать - насколько описание согласуется с графическим представлением, понятна ли логика или чего-то не хватает
Тема полезная, но я бы немного исправил форматирование - добавил заголовки (много жирного текста - сливается при скроллинге), убрал номера пунктов (1. 1.1 1.2...). Подача информации - это тоже часть адаптации, чтобы быстро найти нужные моменты
Если аналитик видит риск или возможность, не нужно ждать, пока бизнес сам это увидит и оформит в задачу.
Посыл конечно хороший, и с точки зрения карьеры правильный, но во-первых, это нужно будет сильно отвлекать ЗС от их работы “пока еще никто не за что не кусает”, а во-вторых, как быть со своими текущими задачами?
Для актуализации и порядка в базе знаний, нужно системное мышление того кто эту базу создает, курирует, а его нет.
Потому что чаще всего такая позиция закрывается теми, кто есть, без претензий к текущим процессам. А эти процессы, как правило, пора пересматривать. Но это же нужна сила воли, желание принимать решения… БЗ же сама по себе может быть отдельным продуктом, который помогает бизнесу в лучшем случае не разваливаться.
Качество не бывает принудительным. Его невозможно получить от человека, которому безразлично, что он делает. А человеку безразлично то, что никак не связано с его личным результатом — ни материально, ни профессионально, ни морально. Технологии передаются в документации. Культура качества — нет.
в документации всегда остаются «белые пятна», которые могут трактоваться неоднозначно
Тот самый случай, когда “не баг, а фича”, то есть технической поддержке же тоже нужно работать :) А если описывать “абсолютно все”, то трудозатраты рискуют улететь в бесконечность.
Оптимальным, на мой взгляд, подходом было бы совмещать описание с вебинарами (или очными курсами) и здравой логикой (чтобы софт не менялся до полной неузнаваемости за 1 итерацию)
Про качество клиентского обслуживания - 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 написано не очень понятно, поэтому для рядового пользователя лучше “упростить тяжёлые для восприятия словесные обороты”
И да и нет. Нет - потому что я сторонник давать и определение термина, и его возможную классификацию (например, есть Эскалация - Иерархическая и Функциональная, чтобы не листать глоссарий, это все должно быть в одном месте)
Да, а еще для самоконтроля можно схему нарисовать - насколько описание согласуется с графическим представлением, понятна ли логика или чего-то не хватает
Потому что системное мышление дано не всем. Как удачно ты продолжил мою мысль :)
Тема полезная, но я бы немного исправил форматирование - добавил заголовки (много жирного текста - сливается при скроллинге), убрал номера пунктов (1. 1.1 1.2...). Подача информации - это тоже часть адаптации, чтобы быстро найти нужные моменты
Посыл конечно хороший, и с точки зрения карьеры правильный, но во-первых, это нужно будет сильно отвлекать ЗС от их работы “пока еще никто не за что не кусает”, а во-вторых, как быть со своими текущими задачами?
Потому что чаще всего такая позиция закрывается теми, кто есть, без претензий к текущим процессам. А эти процессы, как правило, пора пересматривать. Но это же нужна сила воли, желание принимать решения… БЗ же сама по себе может быть отдельным продуктом, который помогает бизнесу в лучшем случае не разваливаться.
Интересное наблюдение (из статьи “Японец увидел это на заводах СССР и отказался от сделки на миллионы”):
Про размытые формулировки - https://habr.com/ru/articles/1015130/
Тот самый случай, когда “не баг, а фича”, то есть технической поддержке же тоже нужно работать :) А если описывать “абсолютно все”, то трудозатраты рискуют улететь в бесконечность.
Оптимальным, на мой взгляд, подходом было бы совмещать описание с вебинарами (или очными курсами) и здравой логикой (чтобы софт не менялся до полной неузнаваемости за 1 итерацию)
Как раз этим и славится хорошее базовое образование - оно помогает проще и быстрее адаптироваться, если контекст постоянно меняется.