Согласен. Но в моем конкретном случае эта публика занимается исключительно процессами и траханьем мозгов тем, кто посмел на священную корову процессов покуситься. К примеру, ко мне прибежали ругаться за то, что тикет с запросом на доступ я закрыл с комментарием «доступ предоставлен». Оказывается, надо было написать, кому и куда дан доступ. Хотя это уже и так написано в самом тикете… Но у девочки-манагера в process manual сказано что при закрытии тикета надо это копипастить, и хоть ты тресни. Я конечно более или менее вежливо шлю всю эту публику куда подальше, но это тупо мешает работать.
А вот менеджеры проектов у нас являются сотрудниками ИТ отдела и занимаются примерно как раз тем, что вы описали.
«Менеджер о карточкам» в моей терминологии это любой бездельник из команды сервис-менеджмента.
Что до инцидентов, то обычно это идет или от мониторинга (тогда есть алерт и он является триггером), либо это приходит извне в виде тикета. В первом случае тикет скорее всего будет заведен уже сильно постфактум, ибо не до того.
Чтобы смотреть текущий статус, надо чтобы его кто-то обновлял — у инженеров на это нет времени во время работы над инцидентом.
Чтобы посмотреть как подобные инциденты были решены ранее — нужно чтобы это было кем-то востребовано. Сами инженеры количеством 2 штуки таким функционалом по понятным причинам не пользуются. А менеджеры не имеют профильной квалификации, поэтому ничего не поймут, даже если я им напишу, как что устранялось.
Чтобы понять кто раньше это делал, у кого можно узнать детали — ну, есть два варианта: либо я, либо мой коллега :)
Чтобы агрегировать данные по инцидентам, посмотреть какие области наиболее подвержены инцидентам и с цифрами предложить какие-то решения по предотвращению дальнейших инцидентов — как правило есть ежемесячные митинги внутри отдела, на которых разбираются причины имевших место быть аварий и вырабатываются методы их недопущения.
Как видите, никаких тяжелых решений тут абсолютно не нужно.
Рабочее время у нас нигде не трекается и задачи его подсчета не стоит. Ну, кроме как для внештатных сотрудников на почасовой оплате, но там я не в курсе, этим HR занимаются.
Аварии у нас автоматически подтягиваются из мониторинга в таблицу сервисов, где прекрасно видно, когда/сколько/где именно/как часто. Потом туда же еще и SLA прикрутили, чтобы при угрозе его нарушения сыпались уведомления.
Ну и кроме посылки в смс-шлюз прикрутите простановку тикета на доску.
Менеджеру сразу станет понятно, чем вы занимаетесь при взгляде на эту доску. (ну, должно, менеджеры бывают не алё.)
Я отказываюсь понимать, зачем тут вообще менеджер. Он никак не участвует в устранении аварии. Он не может мне отдавать прямых распоряжений, ибо не является моим начальником. Он даже не является техническим специалистом и поэтому не понимает сути аварии.
Вот что он хорошо умеет делать — это трахать мозг на тему, почему я во время аварии не бросил все и не побежал заполнять тикеты для бога тикетов, расписывая все в деталях непонятно для кого.
Нет, я не спорю что бывает и правильное употребление всех этих методологий. Но как по мне — в коллективе с двумя админами все это просто излишне, потому что keep it stupid simple.
А зачем что-то делать с карточкой? Зачем вообще карточка? Нет, ну если очень хочется — наймите секретаршу и пусть она заполняет карточки. Может даже их разрисовывать в розовый цвет. Только отстаньте от инженеров со всей этой галиматьей.
Как правило, любители красивой отчетности и прочих карточек сами заменить инженера не смогут. И в его задачах не разберутся. А вот отсутствия «менеджера по карточкам» никто и не заметит.
Да нет, все не так плохо чтобы увольняться — наш начальник отдела адекватен и большей частью успешно отбивает нас от наиболее дебильных требований, но вести эту документацию в разных тикетных и прочих CMDB все же приходится, как и периодически более или менее вежливо отшивать манагеров с их «гениальными» вопросами. И пост был не про жалобы, а про бессмысленность таких вещей. По факту целый отдел набрали ради того, чтобы внедрить и поддерживать систему, которая функционирует только на бумаге.
Ну, как сказать… У нас еще до всей этой ITSM-вакханалии была внутренняя вики, где описывались конфигурации систем и важная информация про изменения в них. Был простой трекер задач. И все прекрасно работало. А теперь внедрили Change Management, Incident Management, Problem Management, CMDB… Но инфраструктуру по-прежнему поддерживают Вася и Ганс. Которые как обходились, так и обходятся без всей этой мишуры, которая сделана так, что пользоваться ею решительно невозможно. А от количества прыгающих вокруг девочек-манагеров с тупыми вопросами и требованиями вероятность ошибки только возрастает.
Потому что когда случается авария, технический специалист должен заниматься ее устранением, а не заполнением доски. А когда она уже устранена — вносить ее в канбан просто нет смысла.
Правильно поняли. Мы и до того трекали внутренние задачи в гилтабе, а потом стали в нем же раскидывать их по доскам. Но это чисто внутренняя кухня, а не навязанное и контролируемое сверху решение, как оно изначально предполагалось.
Ага :)
Change management внедрили глобально во всей конторе. И нас тоже заставили играть в эту игру. Например, на каждое изменение любой строчки конфига прода надо завести «Standard Change». Сами заводим, сами пишем туда что-то от фонаря, сами закрываем. Для кого? А хрен его знает.
Естественно, периодически на это забивается болт, когда само изменение занимает времени меньше, чем заведение того тикета. И естественно, в случае проблем я просто спрашиваю коллегу, не делал ли он чего с продом — потому что искать что-либо в тикетной удовольствие крайне долгое и сомнительное.
Ну, не совсем так. У нас есть и «долгоиграющие» задачи по апгрейду, миграции и так далее.
Но вот, к примеру наш недавний анекдот: отдел сервис-менеджмента начал катить на нас бочку за то, что по получению SMS от мониторинга о падении аплинков в ЦОД мы подорвались устранять аварию. А надо было, оказывается, сначала завести тикет, описать что случилось, потом создать emergency change, и только потом поднимать упавшую сеть. Не забывая в процессе писать в тикетную записки из горящего танка. Дискуссия была закончена предложением начальника IT «тогда наймите нам секретаршу» :)
А теперь представьте, что этим управляет девочка-гуманитарий, которая абсолютно не разбирается в том, чем вы занимаетесь, но при этом имеет право лезть к вам с требованиями расписать задачи более феншуйно или объяснить ей то и это.
Не, не так. Вася понял, что если предлагаемую сервис-манагерами методологию пропихнут в том виде и в том объеме, как это описывается — то она не заменит существующие системы трекинга задач и отчетности, а добавится к ним, что даст манагерам очередную возможность трахать мозги технарям и выльется в еще больший разгул бюрократии и необходимости описывать каждый чих. Поэтому Вася, воспользовавшись своим положением «этого странного русского», донес до присутствующих абсурдность этой идеи в заведомо гротескной форме. Судя по тому, что тема в итоге тихо заглохла, к Васе все же прислушались и поняли, что это уже чересчур.
При этом IT отдел для себя сделал выводы и стал юзать GitLab Boards — это действительно удобно. Но только когда все это — внутренний инструмент, который контролируется начальником отдела, понимающим кто чем занимается, а не девочкой с гуманитарным образованием, не отличающей ping от fuck.
Цели там есть: показать вышестоящей организации и партнерам «смотрите, какие мы офигенные, мы сертифицированы по бла-бла, тыр-пыр и фыр-быр, а еще мы работаем по ITIL и у нас все по фен-шую».
А вот менеджеры проектов у нас являются сотрудниками ИТ отдела и занимаются примерно как раз тем, что вы описали.
Что до инцидентов, то обычно это идет или от мониторинга (тогда есть алерт и он является триггером), либо это приходит извне в виде тикета. В первом случае тикет скорее всего будет заведен уже сильно постфактум, ибо не до того.
Чтобы смотреть текущий статус, надо чтобы его кто-то обновлял — у инженеров на это нет времени во время работы над инцидентом.
Чтобы посмотреть как подобные инциденты были решены ранее — нужно чтобы это было кем-то востребовано. Сами инженеры количеством 2 штуки таким функционалом по понятным причинам не пользуются. А менеджеры не имеют профильной квалификации, поэтому ничего не поймут, даже если я им напишу, как что устранялось.
Чтобы понять кто раньше это делал, у кого можно узнать детали — ну, есть два варианта: либо я, либо мой коллега :)
Чтобы агрегировать данные по инцидентам, посмотреть какие области наиболее подвержены инцидентам и с цифрами предложить какие-то решения по предотвращению дальнейших инцидентов — как правило есть ежемесячные митинги внутри отдела, на которых разбираются причины имевших место быть аварий и вырабатываются методы их недопущения.
Как видите, никаких тяжелых решений тут абсолютно не нужно.
Аварии у нас автоматически подтягиваются из мониторинга в таблицу сервисов, где прекрасно видно, когда/сколько/где именно/как часто. Потом туда же еще и SLA прикрутили, чтобы при угрозе его нарушения сыпались уведомления.
Менеджеру сразу станет понятно, чем вы занимаетесь при взгляде на эту доску. (ну, должно, менеджеры бывают не алё.)
Я отказываюсь понимать, зачем тут вообще менеджер. Он никак не участвует в устранении аварии. Он не может мне отдавать прямых распоряжений, ибо не является моим начальником. Он даже не является техническим специалистом и поэтому не понимает сути аварии.
Вот что он хорошо умеет делать — это трахать мозг на тему, почему я во время аварии не бросил все и не побежал заполнять тикеты для бога тикетов, расписывая все в деталях непонятно для кого.
Нет, я не спорю что бывает и правильное употребление всех этих методологий. Но как по мне — в коллективе с двумя админами все это просто излишне, потому что keep it stupid simple.
Как правило, любители красивой отчетности и прочих карточек сами заменить инженера не смогут. И в его задачах не разберутся. А вот отсутствия «менеджера по карточкам» никто и не заметит.
Change management внедрили глобально во всей конторе. И нас тоже заставили играть в эту игру. Например, на каждое изменение любой строчки конфига прода надо завести «Standard Change». Сами заводим, сами пишем туда что-то от фонаря, сами закрываем. Для кого? А хрен его знает.
Естественно, периодически на это забивается болт, когда само изменение занимает времени меньше, чем заведение того тикета. И естественно, в случае проблем я просто спрашиваю коллегу, не делал ли он чего с продом — потому что искать что-либо в тикетной удовольствие крайне долгое и сомнительное.
Но вот, к примеру наш недавний анекдот: отдел сервис-менеджмента начал катить на нас бочку за то, что по получению SMS от мониторинга о падении аплинков в ЦОД мы подорвались устранять аварию. А надо было, оказывается, сначала завести тикет, описать что случилось, потом создать emergency change, и только потом поднимать упавшую сеть. Не забывая в процессе писать в тикетную записки из горящего танка. Дискуссия была закончена предложением начальника IT «тогда наймите нам секретаршу» :)
При этом IT отдел для себя сделал выводы и стал юзать GitLab Boards — это действительно удобно. Но только когда все это — внутренний инструмент, который контролируется начальником отдела, понимающим кто чем занимается, а не девочкой с гуманитарным образованием, не отличающей ping от fuck.