Комментарии 17
Если слоты заняты, то ставить больше нельзя (попросту некуда). Сиди жди.
Потрясающе. Нет записи в трелло - нет проблемы. Делюсь аджайл-лайфхаком - сократите количество слотов до одного, люди рано или поздно прекратят размещать задачи - и прекрасный вид пустой доски будет радовать глаз ещё чаще. KPI будет - мама не горюй.
Если ты хочешь занять срочный слот своей фигнёй – пожалуйста, но доска публичная и все это увидят.
То есть сотрудник должен испытывать чувство стыда от того что у него возникла проблема и он хочет чтобы её решили. Это не хайринг обкекался наняв человека без нужных навыков и не менеджмент зафейлил не разъяснив сотруднику чем он должен заниматься, это сотрудник виноват что у него вообще возможно возникновение проблем.
Делимся мега-ответом на такое: Вроде, если ты вообще нормальный...
Делюсь мега-ответом на такое: "Понял, заявление занесу сегодня вечером, две недели по договору доработаю".
Какие всё-таки потрясающие аджайл практики внедряют "вожди"-оптимизаторы в "бирюзовых компаниях". Вы часом оптимизацией здравоохранения или образования не занимались раньше?
Если слоты заняты, то ставить больше нельзя (попросту некуда). Сиди жди.
Увы, каждый отдел может переварить только определенное количество запросов каждый день. При грамотном расчете это приводит к тому, что заказчик(другие отделы) начинают более осознанно заниматься планированием и пиритизацией своих запросов. В одной из компаний мы ипользовали аналогичную систем, только у каждого типа заявок была своя "стоимость" исходя из средних времязатрат на тот или иной тип задач, а в месяц для каждого управления\отдела выдавалось определенное количество "баллов" для траты. Можно заказать 50 быстрых задач или 5 лёгких, можно договориться с другим управлением, чтобы они часть своих баллов передали вам и т.д. Скажу честно, что бывало и такое, что задача изначально оценивается в 2 часа, а реально решается за 10 минут. такое бывало, но редко, тогда сотрудника сам менял "стоимость" заявки и на еженедельном митинге уведомлял заказчика что у него высвободилось сколько-то баллов.
Если ты хочешь занять срочный слот своей фигнёй – пожалуйста, но доска публичная и все это увидят.
Думаю, что тут имеется ввиду, что руководитель-технолог прежде чем закинуть задачу сисадминам старается сам решить\найти среди подчиненных кто в этом разбирается.
На моем опыте такой подход позволяет тем, кому это интересно, сильно развиваться и переходить работать в техподдержку в будущем. В одной из компаний где я работал был такой подход. В итоге каждый сотрудник кроме основной специализации имел глубокие знания о рабочем инструменте и в итоге, например, помимо об обработки заявок в jira\jsd мог настроить права, flow, автоматизацию, автонавешивание тегов, автосоздание связанных заявок, уведомление ответственных при профуканном SLA и т.д. Такой подход, как я думаю, снизил количество запросов в техподдержку по данным сервисам на процентов 99% и требовал привлечение техподдержки только там, где требовались права админа.
В каждом подходе есть свои плюсы и минусы.
Если проанализировать ситуацию до, то внезапно окажется вот какая интересная штука: сотрудники компании думают, что ресурс админов бесконечен и легкодоступен. Никого из сотрудников не интересует, чем админ занимается, ведь прямо сейчас человек не может распечатать. Тогда как если человек внимательно посмотрит на сообщение то окажется что в принтере нет бумаги, но ему проще поднять трубку и позвать админа разобраться с проблемой, скинув ее со своей головы. И вопросов, связанных с банальным ипользованием компьютера у сотрудника достаточно много, но он предпочитает не забивать себе голову, а каждый раз спросить у админа как отформатировать таблицу - мотивации к учебе-то нет.
А сотрудники компании не должны в этом разбираться. Ровно как и сисадмины - решать, оказывать услуги или нет.
Тогда пусть пишут в резюме и обсуждают с начальством при трудоустройстве, что они не "опытный пользователь ПК", а просто умеют колесико мышки крутить. Почему-то у людей которые работают за токарным и фрезерным станками не возникает вопросов в духе "ой, не знаю как подачу СОЖ включить. Я не обязан в этом разбираться".
Люди в массе своей всегда выбирают более простой путь. Если проще скинуть задачу на админов - значит так и будут делать. Это не хорошо или плохо, просто таков порядок вещей и его нужно учитывать.
То как решили задачу в этом кейсе - тоже вариант, хотя несколько спорный :) Подозреваю что в компании топикстартера через какое то время маятник качнется в обратную сторону - админы станут недоступными полумифическими существами и их будут поворачивать лицом к пользователям.
Наняли бы эникейщиков на скромные деньги разруливать дурацкие вопросы пользователей, оставив админам содержательные вопросы. И волки целы, и овцы сыты...
Я думал, такие проблемы остались где-то в двухтысячных. ITSM как свод знаний уже вроде устоялась, разделение на админов и эникейшиков стало общепринятым даже в небольших организациях, а на рынке доступно огромное количество специализированного софта.
Но находятся люди, для которых всего этого нет. Зато трелло.
Очень жестко.
В целом все нововведения можно свести вот к этой замечательной фразу:
>А всё потому, что стало проще и быстрее самому найти ответ, чем поставить задачу на админа.
Не мудрено, почему с вашей стороны это выглядит так, что "система взлетела". Людям и правда банально проще разобратьс самостоятельно или спросить коллегу по отделу, чем сидеть и обновлять борду, ожидая, когда там пустой слот освободится и не посчитают ли уважаемые админы мой вопрос "фигней".
Как писали выше, можно закрутить гайки еще сильнее, тогда времени на "качественную и стратегическую работу" станет еще больше.
Очень бы хотелось иметь какой-то CSAT в подобной системе. Или может разово поопрашивать ваших пользователей на предмет их удовлетворенности новой системой. Желательно анонимный, оно так эффиктивнее будет.
Как верно заметили выше, разделение на админов и эникейщиков - стандартная практика
Отказ от непрофильной работы - конечно логично отказываться кому-то писать SQL-скрипты, если это функция этого подразделения (то есть даже если сотрудник не знает, то он может обратится к кому-то в своем отделе)
Насчет лимитирования заявок в день - выглядит как-то.. Ну как у нас в поликлинике. Успел утром записаться к врачу - молодец. Нет, на сегодня талонов нет
Обычно заявки то все принимают, но просто они становятся в очередь. Но тут и обратное конечно, когда сотрудник месяц ждет решения своей проблемы - тоже плохо
Автор вот прям очень больную тему поднял, и звучит она как "разделение полномочий/задач между пользователями и саппортом" и легко этот вопрос не решается, только разговаривать с руководителями подразделений, курирующим заместителем директора или непосредственно гендиректором. И да, автор путает роль "сисадмин" и "саппорт", он же "первая линия".
Далее про саппорт (оставим в покое НАСТОЯЩИХ сисадминов, которые по служебным обязанностям должны общаться с консолью, а задачи им нарезает первая линия или руководитель).
1. Никогда задачи на саппорт не падают равномерно, по 2 важных, 4 неважных, далее по тексту. Всегда в пн с десяток пользователей после выходных забудут свой пароль, накануне сдачи отчета будет "зерг раш" бухгалтеров... А в пятницу после обеда наоборот, самые ушлые домой мигрируют и можно выдохнуть... Разделить ресурсы N саппортов на N*P задач - это головная боль и слёзы руководителя саппорта.
2. Всегда найдутся ВИП-пользователи, которым самим западло делать фильтр в почте, формулы в экселе и т.п. Причем сделать придётся с приоритетом "всё бросай и беги делать"
Короче, пойду тикеты закрывать. Если тема интересна - пинайте, я преподавал ITIL, ITSM, более 20 лет стажа в "саппорте широкого профиля", может наконец запилю свою статью с управленческим покером и куртизанками.
А может стоит ввести простое правило "админы не имеют права редактировать и даже просматривать данные, с которыми работают пользователи"?
Решает множество проблем от "помоги с фильтром/формулой/запросом бд" до "это мне админ Вася сделал неправильную формулу, если ошибка в результате его действий, то виноват Вася".
Поддержу. Идея хорошая. Напоминает систему вытягивания из lean. Я бы ещё порекомендовал почитать про барабан-буфер-канат из теории ограничений, чтобы был резерв. Хороший пост. Спасибо.
Автора большое спасибо за статью, показывает насколько просто поменять свою жизнь к лучшему просто поставив "простые запреты".
История борьбы с лишней работой и админский дзен