Comments 18
Сказать что статья плохая, этого недостаточно, статья разрушительно вредная. Полное отсутсвие понимания принципов обеспечения качества, прямо полный 0. Вопиющее невежество в управлении мотивации персоналом. Почему описываемый процесс мониторинга плохой и довольно вредный поймет любой мало - мальски грамотный системный администратор. Так не то что. за людьми, за железками не присматривают.
Можно, пожалуйста, подробнее?
А то пока комментарий напоминет иллюстрацию к Бритве Хитченса из вот этой недавней статьи: https://habr.com/ru/post/710590/
По тематике качества породившей Японское экономическое чудо написано много томов. Если совсем не в теме, то погуглите, "теория всеобщего менеджмента качества (TQM)", Уолтер Шухарт, цикл Деминга. Возможно Вас заинтересует принцип "Ни один сотрудник не нанимается на работу что бы работать плохо". Вообще, существует целая серия стандартов iso 9000, но они очень большие, обширные, поэтому, если сталкиваетесь с этим впервые, то лучше сначала разобраться с принципами решения проблемы качества, теорией TQM, поясняющей почему ОТК, малая или большая толпа разных контролеров в принципе не способны обеспечить надлежащее качество продукции, услуг и работ. Предлагаемые в статье походы не используют ни в какой мере эти принципы, по этому результаты по качеству будут неудовлетворительные.
Что касается мотивации. Помилосердствуйте, но автор внедряет палочную систему учета. А что это значит. Есть галка в списке задач, молодец, нет галки, плохой, кормить не буду. А многообразие задач и что сложность у задач разная, это автор учитывать не собирается, у автора в голове звенит принцип сословного общества "я начальник, ты дурак, знай, холоп, свое место", автор барин, а не командный игрок, он отказывается формировать мотивацию (какие такие сякие научно обоснованные походы и методы) ему "не по чину", он "начальник". Ну какая, в этом случае, мотивация сформируется у персонала? Только "надо воровать и валить". Первыми сбегут наиболее ценные специалисты.
Что касается мониторинга. Тот кто делал элементарный мониторинг серверов, тот довольно скоро с удивлением узнает что от 20% до 35% сигналов это шум, ложные срабатывания и с этим надо что-то делать. Казалось бы, такая простая система, элементарное сравнение показателей, что там может не работать, а оказывается что жизнь штука столь разнообразная что всего предусмотреть нельзя. И при таком высоком уровне шума, автор собирается принимать решения ответственные решения в отношении подчиненных требующие высочайшей тщательности.
По итогу автор фактически предлагает путь, что бы угробить работу, разогнать персонал и обворовать инвесторов (автор же кушать хочет). С такими друзьями никаких врагов не надо. Поэтому, с моей точки зрения, статья вредная и разрушительная.
PS. Деятелей с позицией автора очень много. Лучшим рецептом для выстраивания отношений с подобными персонами может быть сдельный метод оплаты труда, оклады тут категорически противопоказаны.
Как вы предлагаете оценивать работу сервисных отделов ИТ. По отзывам сотрудников? По количеству выполненных задач? Просто потому что они приходят на работу?
Я согласен с вами в том, что оценка качества это очень сложная тема и требует индивидуального подхода к оценке задач и людей учитывая их специфику.
Автор предложил систему учёта и оценок. Называет её рабочей и успешной. Хотелось бы конечно услышать мнение сотрудников по этому вопросу.
Интересно как вы группируете задачи? Интересно название метрик которые вы оцениваете. Интересны оценки ежедневные и кто этим занимается?
Какие сложности внутри команды были? Провокации? Саботаж?
Поддержку сложно оценивать. Если разработку ещё можно оценить по Скраму или Канбану, то поддержка это вечный ватерфол со спецификой сотрудника. Один решая задачу напишет инструкцию и при следующих обращениях будет кидать в ответ ссылку, а другой замкнет на себе столько процессов пользователя и будет делать их за пользователя, считая себя полезным и незаменимым.
Еще интересно, как автор объяснял систему контроля топ руководству. Ген.диру или собственникам.
Спасибо за ответы.
Джон7 TQM возьму для себя на заметку к изучению. Спасибо за развернутый ответ автора.
Постараюсь ответить на вопросы:
Задачи и их метрики
Не все, но ключевые метрики для основных типов задач - в списке
Инциденты (время закрытия не долно превышать T1 дней, обновления статуса должны происходить не реже раз в T2 дней)
Проблемы (обновления статуса должны происходить не реже раз в T3 дней, источних проблемы должен быть найдет за не более чем T4 дней)
Чендж реквесты (запуск в рабоу, включая полный анализ, должно завершаться не более чем за T5 дней, завершение должно быть не позже утвержденной даты)
Деманды (полный анализ должен занимать не более T6 дней)
Хорошо, что подход в принципе может помочь контролировать любой процесс, отраженный в системе - была бы возможность сказать "чего не должно быть" и "кто за это отвечает". Мы используем ServiceNow и фактически там - вся IT жизнь.
Как проходит ежедневны контроль
Автоматически. Есть пакетный процесс. Он обегает контрольные отчеты, и для каждой строки отправляет напоминалку ответственному - какие "косяки" найдены. Письма персональные, с прямыми сылками на тикеты, требующие внимания.
Также процесс публикует сводную таблицу косяков в каналы MS Teams.
Другой пакетный процесс запускается еженедельно, в оговоренный момент - если этот процесс находит "косяки" - то это уже фиксируется как "штрафные очки".
Сложности внутри команды
Были проблемы с "принятием" факта что теперь операционка очень серьезно контроллируется. Сопровождалась стандартными этапами - отрицание, гнев, торг, принятие.
В некоторых случаях происходило и происходит до сих пор уклонение, выражающееся в двух формах:
минимизация контроллируемой операционной нагрузи. Это либо переброс на внешних подрядчиков, на которых контроль не распространяется, либо на других коллег. Это плохое проявление и это задача руководителя контроллировать нагрузку. С другой стороны - контроль начал распространятся и на продрядчиков.
вывод работа за пределы стандартных контролей: был инцидент - стала проблема, был стандартный чендж - стал рутинный, или вообще сервис. С ченджами пример позитивный, поскольку на самом деле приводит к улучшению процесса, его формализации и ускорению. С проблемами - не очень. Но поскльку это изместно - оно под контролем.
Объяснения руководству
Изначально метрики распространяются top-down. Как я написал в комментарии ниже - они сформированы в результате получения откликов от внутренних заказчиков и таким образом отражают (в упрощенном виде, конечно) их ожидания.
ИТ руководство само регулярно, но гораздо реже, проводит контроль этих показателей. Так что объяснять показатели - не нужно.
Перевод показателей в измеримые элементы персональных годовых планов еще не распространены в дрыгих отделах - только в наших группах. Но поскольку результаты есть и они очевидны (наша группа не фигурирует или находится глубоко в нижней части в "штрафных" отчетах руководства - у нас все хорошо) то, возможно, практика распространится на другие отделы.
Однако тут нужна воля на уровне отдела. Наши непосредственные бизнес заказчики очень требовательны, и процессы в периметре нашей команды бизнес-критические. Поэтому нам нужно было приводить дела в порядок самим. В других командах возможно ситуация спокойнее.
Спасибо за развернутый ответ.
Основные метрики мониторят время. Дедлайн на выполнения вопроса.
Есть ли хитрецы играющие со статусами? Например "отписка наообум т.к. ничего не делал и изменил статус с "В работе" на "Тестируется пользователем", а потом пользователь проверят и возвращает задачу в работу, т.к. отписка не работает"...
Как контролируете качество выполнения задач?
По аналитическим задачам - Ченджи и Деманды содержание и качество анализа контролируется тимлидом перед подписанием. Таких задач не много.
По обновлениям статуса инцидентов и проблем - да, иногда встречаются не содержательные ответы типа "подрядчики все еще работают и ничего не ответили". Но, к сожалению, очень часто так оно и есть. Хотя бы статистика накапливается.
Была идея, просматривать содержание комментариев в инцидентах, и проверять с помощью ML NLP модели - классифицировать на "полезный" / "отписка". Но до этого ход еще не дошел.
В этом обсуждении мы здорово сместились с темы организации и оценки операционной деятельности отдела ИТ в сторону обеспечения производственного качества.
Однако, производственное качество, а точнее его контроль (не обеспечение и не улучшение) и представление результатов контроля упоминалось здесь только в качестве драйвера идеи. Ровно с той же точки зрения упомянут был и поход "функций потерь" из области машинного обучение, который, кстати, не вызвал обсуждения.
Все это для того чтобы показать возможные подходы к переходу от "измеряемых но сложно/по-разному интепретируемых" понятий к абстракциям.
TQM прекрасен как набор мер именно повышения качества. Однако нельзя улучшить то, что не меряешь. А за "измрение" в качестве отвечает именно "контроль".
Получается ваша система приследует основную цель: напоминание сотрудником о задаче и сроках. Это здорово.
А какое количество задач в среднем поступает в день всего и в расчете на одного человека?
Конечная цель, вообще-то, чтобы все было сделано. Но да - напоминать помагает лучше всего, хотя и имеет неприятный побочный эффект "привыкания". Люди начинают слишком полагаться на напоминалку, и в худшем случае ничего не делают пока напоминалка не прийдет. А если она вдруг сломается, то, скорее всего, процесс остановится.
По поводу загрузки.
У нас в среднем порядка 900-1200 инцидентов в месяц, среднее время закрытия - около 4 дней (это инциденты не класса "компьютер не включается" - они связаны с сбоями функционирования нагруженной системы). Они в основном обрабатываются внешней подрядной организацией.
Среднее количество открытых "тяжелых" тикетов (ченджи, проекты, деманды) - 80-90.
Среднее количество открытых тикетов разных типов на одном штатном сотруднике - около 8.
Опять-же, пропуская обощенную оценку, расскажите, как вы формируете мотивацию к исполнению скучной рутины в веренном Вам отделе / подраделении?
Если есть хороший, позитивный личный опыт управления - ну дайте ссылку на свою статью, где вы все это описываете?
Идея интегрального представления качества через "штрафные баллы" и "финальную оценку" - это подход контроля качества (Quality Control), а не обеспечения качества (Quality Assurance). Такой подход применяется в многопрофильных независимых лабораториях.
Но нет — метрики тут же доводятся до работников со строгим напутствием «попробуйте, блин, нарушить!». И в этот момент вместо производства работы — работники начинают производить метрики. И метрики можно выкидывать — или усложнять до полной потери смысла. Ибо набор метрик целиком и полностью однозначно описывающий некую деятельность — как правило обладает не меньшей сложностью чем сама деятельность…
Нет, правда — почему ?!
Потому что власть дают тем, кто жаждет власти. Есть люди которые хотят созидать, а есть люди которые хотят власти ради власти. Первые используют свои силы на созидание, вторые только на достижение власти и могущества. Первые проигрывают конкуренцию, но не только по этому, носители власти это кланы и группировки. По тому как устроена и работает власть и почему так происходит, есть очень хорошая, полезная книга "Лестница в небо" авторы Сергей Щеглов и Михаил Хазин. В первом квартале 2023 года ожидается второе издание, двухтомник передан в набор.
Оставляя в стороне ваше частное оценочное мнение, расскажу, почему так происходит.
Есть определенные ожидания бизнеся от ИТ. В частности - "делайте быстро", "делайте к договоренному сроку", "информируйте, как идет работа", итд.
Такие ожидания трансформируются в формальные метрики поверх тикетинг-системы, и контроллируются на высоком уровне (С, С-1). Очевидно, исполнение этих метрик, вменяется в обязанности каждому линейному руководителю ИТ подразделения.
Теперь руководитель подразделения уже должен обеспечить чтобы каждый в его подразделении понимал и следовал ожиданиям, выраженным через метрики. Да, действительно люди начинают "чинить метрики" - это неизбежно. Но знаете, поскольку метрики отражают запрос клиента - бизнес доволен что мы "успеваем в срок", "своевременно и регулярно информируем" итд.
Можно ли обойтись без метрик вообще сохраняя качество клиентского сервиса? Теоретически - да. Просто надо набрать блестяще умных, мотивированных, лично эффективных, при этом все еще достаточно скромных людей которым не считают зазорным не только "творить великое", но еще и делать это в срок, и сопровождать это качественной коммуникацией в сторону клиента. Таких людей нужно "всего" порядка тысячи по всему миру.
После этого можно и всех "эффективных менеджеров" поувольнять.
Великолепная цитата:
"Просто надо набрать блестяще умных, мотивированных, лично эффективных, при этом все еще достаточно скромных людей которые не считают зазорным не только "творить великое", но еще и делать это в срок, и сопровождать это качественной коммуникацией в сторону клиента."
Распечатаю и буду применять как визитку утопических ответов.
Как поставить и контролировать цели на «текучку» по SMART и не забывая про мотивацию