Хватит натягивать сову на глобус

Работаю я админом сетевой и серверной инфраструктуры в немецкой конторе околофинансового сектора. Количество сотрудников — меньше 100, из которых ИТ отдел занимает довольно малый процент, а разработчиков можно пересчитать по пальцам одной руки.

И вот при таких масштабах наше руководство уже пару лет как активно играется в ITIL. Наняли орду сервис-, продакт- и прочих менеджеров, внедрили ITSM, сертифицировались по разным стандартам и стали на полном серьезе требовать от технических сотрудников соблюдения всех описанных в этих стандартах процедур.

Разумеется, в наших масштабах все это только мешает, добавляя кучу ненужной отчетности, избыточной писанины ради писанины, и порождая бесконечную войну технарей, которые хотят чтобы им дали спокойно работать, со всякими менеджерами, половина из которых молится на разведенную ими же бюрократию, а в ИТ вообще не понимает.

Так вот, руководству этого показалось мало, и захотелось внедрить еще что-нибудь эдакое, модное. По каковой причине зимой нам прямо в офисе организовали тренинг по Kanban. Напыщенный «тренер» в костюмчике и с айфончиком два дня подряд распинался, как «построить сильную команду», «приоритизировать задачи» и «повысить эффективность». Рисовал графики, показывал красивые картинки, приводил примеры из кровавого энтерпрайза и крутил мотивирующие ролики. Сервис-, продакт- и прочие менеджеры радостно кивали и потирали лапки. Разработчики скептично молчали. А дальше «тренер» совершил фатальную ошибку — предложил высказаться отделу инфраструктуры, хотя мы тихо занимались своими делами, пропуская его распинательства мимо ушей. Но раз человек просит — мне не жалко:

— Скажите, а как изменится лично моя работа, если мы внедрим описываемое? Эта методология не будет за меня работать. И ITIL не будет. И толпа менеджеров не будет. В конце концов все равно нужен специалист, который знает, как нажать кнопку. И от того, что я ее буду нажимать не рукой, а ногой в прыжке с разворотом, и отмечать нажатие кнопки не во внутреннем трекере, а на этой вашей доске, быстрее она не нажмется.
— Ну, дело в том, что организация работы в команде…
— У нас всего 2 админа, занимающихся инфраструктурой.
— А… Эм… Нууу, в общем… Я не готов прямо сейчас ответить на ваш вопрос.

После этого выступления мне разрешили удалиться с тренинга и больше не участвовать в театре абсурда. С тех пор прошло уже несколько месяцев, но про Kanban у нас что-то больше не слышно — видимо, дошло даже до самых твердолобых.

Никто не спорит, управление проектами, методологии и стандарты — вещи полезные. Но я довольно часто видел — что в России, что в Германии — случаи, когда все это внедрялось «для отчета» или «потому что модно». Причем в первом случае таким внедренцам иногда (но нечасто) все же хватало мозгов «внедрить» стандарты чисто на бумаге и не мешать сотрудникам заниматься реальной работой.

А вот чего я еще нигде и никогда не видел, так это чтобы бездумное внедрение таких вещей и требование им слепо следовать без оглядки на масштаб и специфику организации — а главное на реальную необходимость всего этого — приводило к чему-нибудь хорошему.

Теги:

Хабы:

Комментарии 79

ctacka вчера в 12:34
+2
А почему руководство решило все это внедрять? Может, у них есть какие-то цели, которых они хотели этим достичь, и эти методы им показались наиболее правильными?
- dvserg вчера в 12:48
  +1
  Руководство обычно решает это сделать с чей-то подачи. Они же в большинстве своем финансисты и управленцы, и в этих ваших IP адресах совершенно не понимают.
  А некто во второй-третьей линии начальствующих решает укрепить свои позиции инициативами, берет красивые презентации, статистику популярности и готовится к повышению.
  Была ситуация, когда некто писал кандидатскую про КПИ и приКПИшных чудесах, и тут-же экспериментировали на сотрудниках внедряя их в жизнь. Особенно забавно было смотреть, как искали/выдумывали эти показатели для разных групп сотрудников.
  - Vengant вчера в 13:07
    
    +9
    Я как-то видел вообще прекрасное — KPI одного отдела зависел от работы другого, который ему не подчинялся…
    - d-stream вчера в 23:06
      
      0
      
      Бывает и запущеннее: манагер накручивает свой показатель по количеству подаренных скидок, а вознаграждение исполнителя работ вычисляется как продажный объем нетто)
  - usego вчера в 13:14
    
    +1
    Ну и всякие шильдики добавляют сейлс поинтов в глазах не особо опытных клиентов. Но вот в организациях, которые свои процессы наружу не продают, чаще всего это обычный карго культ и чьёто-то раздутое эго.
  - ctacka вчера в 14:29
    
    +1
    Ну финансисты выкладывают деньги за что? Видимо, тот руководитель, который инициировал все это, что-то им пообещал?
    Может им недостаточно предсказуемости вашей работы? Или SLA недостаточный? Или их идеи не реализуются?
    Просто это как-то не по-финансистски, выделить деньги просто так, без цели.
    - adictive_max вчера в 14:37
      
      +5
      
      Ну тогда заходили неправильно. Технарям нужны не возвышенные цели и мир во всём мире, а конкретные задачи. Нужно SLA — говори что нужно SLA. Нужен учёт — говори что нужен учёт. Но внедрение ITIL ради корочки о внедрении ITIL — это уже совсем другое. Ничто так не демотивирует инженера, как бессмысленная работа.
- Vengant вчера в 13:10
  +2
  Цели там есть: показать вышестоящей организации и партнерам «смотрите, какие мы офигенные, мы сертифицированы по бла-бла, тыр-пыр и фыр-быр, а еще мы работаем по ITIL и у нас все по фен-шую».
  - eugene08 вчера в 13:22
    
    –5
    Складывается впечатление, что вы не только не помогли компании наладить процессы но и вставляли свои палки в колеса. Бизнес — не благотворительность, абсолютно нормальное желание у менеджмента знать за что вам и вашим коллегам платят деньги, что вы делали вчера, что делаете сегодня, и, примерно, что будете делать в понедельник. Канбан/другие подходы делают процессы прозрачными, что приносит много плюшек, например: имея организованные процессы разработки, можно разрабатывать систему регулярных ревью для поощрения сотрудников.
    - adictive_max вчера в 13:55
      
      +8
      
      Не вопрос, только что бизнесу будет от того, что он узнает, что вчера я весь день составлял стратегию развития свича на 5 этаже, сегодня делаю отчёт по внедрению KPI среди самого себя, а в понедельник буду занят Scrum-митингом по постановке задач из утверждённого месяц назад квартального плана регламентных работ (который уже 3 года не менялся)?
      Складывается впечатление, что некоторые непонимают, что управление работой — это тоже работа, и она тоже требует время и денег на своё выполнение.
      - ApeCoder вчера в 14:08
        
        –3
        
        Канбан это немножко не то. Представьте, что у вас та система где вы учитываете заявки будет визуализировать их в том числе в виде доски. Будет установлен четкий лимит сколько вы можете брать заявок в работу, а если их будет больше вы будете не брать новые пока их число не уменьшится.
        
        Vengant вчера в 15:08
        
        +9
        
        А теперь представьте, что этим управляет девочка-гуманитарий, которая абсолютно не разбирается в том, чем вы занимаетесь, но при этом имеет право лезть к вам с требованиями расписать задачи более феншуйно или объяснить ей то и это.
        
        Nalivai вчера в 18:14
        
        +2
        
        Ну так проблема-то не в канбане тогда, а в том что скрам-мастер (так это называется?) неправильно выбран. А теперь представьте что этим управляет грамотный технически подкованный менеджер, задача которого создать оптимальную работу, чтобы к админам не лазили со всякой фигней когда у них важные дела, и чтобы админы могли одним взглядом отличить задачу которая нужна бизнессу прямо сейчас от задачи которая не понадобится еще год, и чтобы сразу было видно если на админе и так висит девять очень срочных задач и придумывать стратегию развития свича ему сейчас не с руки
        
        Stas911 вчера в 18:16
        
        +1
        
        Именно, как я вижу упорядочивание и правильная приоретизация задач только поможет в работе и отчасти устранит вот это «АААА, СРОЧНО ПРЯМО СЕЙЧАС» которое прилетает со всех сторон.
        
        rjhdby вчера в 22:12
        
        0
        
        Как тут не вспомнить присказку, что хороший админ — это тот, который играет контру, а не тот, у которого рожа в мыле. (при условии, что всё работает конечно)
        
        HiMem-74 вчера в 15:09
        
        +7
        
        Если Вам непонятен посыл статьи, можно я немножко перефразирую? Спасибо.
        Вот отдел. В нем 2 человека. Всего 4 руки. И если эти руки, вместо непосредственной работы, будут заполнять бесчисленные канбаны, производительность труда отдела упадёт.
        Единственный профит для бизнеса (на примере сервис деска) — понимание того, что 10% юзеров генерирует 90% проблем. Так это, во-первых, очевидно для всех (как правило, кроме самого руководства), а во-вторых это в 99% случаев родственники этого самого руководства!
        
        Vengant вчера в 15:21
        
        0
        
        Спасибо :) В нашем случае речь идет не о юзерах конечно, но все примерно так и есть.
        
        ApeCoder вчера в 16:42
        
        +1
        
        Насколько я понял они по факту выбрали сами пользоваться досками в итоге — т.е. заполнять их вручную или автоматически.
        
        Единственный профит для бизнеса
        А зачем вообще нужен канбан? С точки зрения его сторонников?
        
        Vengant вчера в 16:55
        
        0
        
        Правильно поняли. Мы и до того трекали внутренние задачи в гилтабе, а потом стали в нем же раскидывать их по доскам. Но это чисто внутренняя кухня, а не навязанное и контролируемое сверху решение, как оно изначально предполагалось.
        
        Kanut вчера в 23:40
        
        +1
        
        . И если эти руки, вместо непосредственной работы, будут заполнять бесчисленные канбаны, производительность труда отдела упадёт.
        
        Так «эти руки» как раз таки ничего заполнять и не должны. Канбан это грубо говоря система тикетов, которая имеет определённые правила. То есть вещи вроде «нельзя одновременно обрабатывать больше чем Х тикетов» или «Если статус у тикета из категории А не меняется Y дней, то на него надо повнимательнее посмотреть».
        
        И вопрос в том как вообще сейчас организованы процессы в этом отделе. Ну то есть какие у них задания, кто их даёт, кто и как распределяет, кто оценивает объём работ, кто и как отчитывается о проделанной работе и т.д. и т.п. И только тогда уже можно думать надо там что-то менять и если надо, то канбан там нужен или что-то другое.
        
        dravor сегодня в 00:02
        
        0
        
        Ну вот в примере выше нашлись деньги на покупку инструктора по курсам канбан, но не нашлись на человека для двух админов. который будет все эти тикеты заполнять.
        Суть как раз в том, что чем больше в компании сотрудников, тем активней система подавляет обратную связь от конечных исполнителей. И это что-то на уровне древней психологии стаи обезьян, а не заговора рептилоидов.
        
        Kanut сегодня в 00:07
        
        0
        
        Ну во первых «инструктор на канбан» это одноразовая выплата. И вряд ли за него заплатили даже годовую зарплату «заполнятеля тикетов».
        
        А во вторых тикеты по хорошему должны заполнять конкретно те кому что-то нужно от админов. В конце-концов сейчас же админы откуда-то задания получают. Неужели они их исключительно сами себе придумывают?
    - amarao вчера в 18:31
      
      +3
      
      Ровно такое же есть желание не тратить собственные усилия на то, чтобы помогать другим людям выполнять их KPI.
      
      Хотят — пусть выполняют. Не хотят — пусть не выполняют. Хотят, чтобы я им помогал — пусть мотивируют. Можно деньгами, можно статусом, можно блестящей игрушкой. Если кто-то хочет, чтобы я занимался унылым, скучным, непрестижным забесплатно, то я не могу запретить ему хотеть. Но и помогать в исполнении желаний тоже не буду.
      
      Можно попробовать от противного — заставить под угрозой увольнения.
      
      Но, повоторю, если кто-то хочет, чтобы я занимался скучным, неинтересным, непрестижным под угрозой увольнения, то он может попробовать. А я могу стряхнуть пыль с резюме в ответ.
    - Hardcoin вчера в 23:02
      
      +2
      
      абсолютно нормальное желание у менеджмента знать за что вам и вашим коллегам платят деньги
      Абсолютно глупое желание. Если у тебя, как у менеджера, есть цели и задачи — именно за них и нужно платить. Не нужно "знать, за что платишь", нужно "платить, за то, что требуется". А если ты не знаешь, что требуется, спроси у того, кто знает.
      
      Контроль и прозрачные процессы нужны для того, что бы проверить, делается ли то, что требуется.
andToxa вчера в 12:47
0
«для отчета» или «потому что модно»
видимо, поэтому
Mimus_spb вчера в 13:59
+1
к сожалению это типичный майндсет
— руководители в кои то веки решили выделить денег — обучить сотрудников
— возможно они выбрали не лучшего тренера и не лучшую методику,

внимание вопрос, что сделает наш Васян?
1. постарается извлечь максимум пользы даже их среднего материала с плохой подачей
2. изо всех сил будет показывать руководству что они, которые ему деньги платят и, видимо, хотят вкладывать — тупые, а он Вася — умный?
- Vengant вчера в 15:02
  +4
  Не, не так. Вася понял, что если предлагаемую сервис-манагерами методологию пропихнут в том виде и в том объеме, как это описывается — то она не заменит существующие системы трекинга задач и отчетности, а добавится к ним, что даст манагерам очередную возможность трахать мозги технарям и выльется в еще больший разгул бюрократии и необходимости описывать каждый чих. Поэтому Вася, воспользовавшись своим положением «этого странного русского», донес до присутствующих абсурдность этой идеи в заведомо гротескной форме. Судя по тому, что тема в итоге тихо заглохла, к Васе все же прислушались и поняли, что это уже чересчур.
  
  При этом IT отдел для себя сделал выводы и стал юзать GitLab Boards — это действительно удобно. Но только когда все это — внутренний инструмент, который контролируется начальником отдела, понимающим кто чем занимается, а не девочкой с гуманитарным образованием, не отличающей ping от fuck.
  - NAI вчера в 16:38
    
    +4
    Подписываюсь, все так.
    У нас была своя система учета рабочего времени — в тебя бросают куском работы, ты говоришь крайний срок когда будет готова (ну или за тебя решает руководитель). Далее задача билась на подзадачи и в систему вписывалось фактическое время выполнения подзадач. По итогу руководитель знал среднее время выполнения работ по всем и каждому, что давало возможность оценивать сроки с +- адекватной погрешностью.
    
    Но тут решили внедрять… сначала добавили ежемесячный отчет о том что сделано. Потом воткнули одну популярную CRM и обязали ставить там таски, запускать трекеры времени и пр. в общем использовать как таск-трекер.
    По итогу я теперь пишу отчеты в 4 (ЧЕТЫРЕ) мать их системы. Одна для финансистов, вторая для планирования, третья в опытной эксплутации, но без заполнения четвертой не работает.
    Вишенка на торте что в одной из систем нельзя проставить затраченное время «задним» числом(только кнопки старт и стоп). На мой вопрос — что делать с прерываниям, т.е когда мне звонит заказчик и я выпадаю на час разговоров, никто ничего ответить не может.
    
    На фоне всего этого проталкивают канбан. Который хорошо работает на поточном производстве, но нифига не работает на штучном. У меня висят таски 2-3 летней давности которые будут выполнены примерно никогда, потому что денег они уже не принесут и всегда есть более приоритетные задачи. Но таски висят снижая мою «эффективность». Раз в полгода на очередном совещании девочка-приносит отчет по сотрудникам и начинается «А что это мы на задачи забиваем?»
    - gecube вчера в 23:36
      
      0
      
      Эти висячие задачи надо закрывать с каким-нибудь комментарием "obsoleted by...". И не волнует. Если надо — визу руководителя. Все счастливы.
      
      Ну, действительно. Скажем, была задача "обновить хх до версии уу". А потом вышла версия zz > yy. Появилась задача "обновить хх до версии zz". Вы ее и сделали, а первую можно утилизировать.
McDuk вчера в 14:09
+5
Правильная бюрократия упрощает работу. А у вас случился карго-культ.
Foggy4 вчера в 14:10
+3
Мое мнение — подобные фреймворки улучшают ситуацию только при числе сотрудников в компании начиная примерно от тысячи человек. Если людей меньше — лишние бюрократические процедуры лишь замедлят рабочий процесс. В любом случае ITIL это не прямое руководство к действию, а описание best practice и внедрять их надо с учетом специфики той или иной компании, а не бездумно.
- adictive_max вчера в 14:30
  +2
  Тысяча — это вы конечно загнули. Я для себя определяю этот порог «ненужности» — когда все лично друг друга знают и с любым вопросом можно просто подойти и спросить. Это, конечно, не отменяет необходимость в грамотном управлении, но на таких масштабах оно больше строится на личном участии руководства в процессе, а не абстрагировании на сферическое управление в вакууме.
- ctacka вчера в 14:32
  0
  Вы не поверите, но Канбан даже в семье, в домашних делах, улучшает продуктивность. :)
  - aml вчера в 20:58
    
    0
    Расскажите, пожалуйста! Я интуитивно понимаю, что это должно помочь, но как именно, хотелось бы подробностей.
- eugene08 вчера в 14:33
  +1
  >Мое мнение — подобные фреймворки улучшают ситуацию только при числе сотрудников в компании начиная примерно от тысячи человек
  
  интересно, как бы вы управляли проектом где, например 10-20 разрабов, несколько девопсов и куа. Все что то пилят пилят, а на эелементарные вопросы ответить невозможно — а когда выпустят фичу X, что по ресерчу фичи Y и вообще сколько у нас новых багов в проде с прошлого релиза? А еще новые люди приходят, увольняются, уходят в отпуск/на больничный — придется звонить Васе в больницу чтоб понять в каком состоянии его таски, ничего ж не трекается.
  
  Я работал в стартапе где примерно на полсотне инженеров случился кризис — процессы были плохо построены, часто нарушались, в прод попадал неоттестированный код. Все это привело к тому что крупный клиент был на грани ухода, что привело бы к закрытию бизнеса или по меньшей мере, к массовым увольнениям. Я тогда саппортил прод и файры случались чуть ли не каждую неделю. Но мы смогли себя взять в руки, перенастроить процессы и преодолеть кризис, поднять качество, файры сократились до пары раз в год. А компания в это время продолжала расти, наращивать пользовательскую базу и количество сотрудников. Это я вам с не с позиции проповедника чего-то там пишу, а девопс инженера.
  - Foggy4 вчера в 15:32
    
    +1
    ITIL это библиотека описывающая управление ИТ услугами. Там конечно есть раздел посвященный разработке ПО, но он далеко не главный. Описанная вами ситуация не требует «внедрения» ITIL. Здесь скорее надо изучать методологии SDLC и управление проектами по типу PMBok.
    - eugene08 вчера в 15:38
      
      +1
      
      Автор не только про ITIL написал но и про Kanban, поэтому я привел пример как SDLC может влиять на бизнес и сотрудников. Да и вообще, проблема глубже — постройка/настройка процессов в бизнесе.
dravor вчера в 15:10
+1
Так из комментариев автора тоже следует, что чем он будет заниматься завтра, он уже знает, а к примеру через неделю нет. Одно дело внедрять план отделу разработок ( и не забыть его корректировать с действительностью), а другое дело — для сотрудника, реагирующего на ЧП.
План по ЧП — это уже какой-то Machine Learning получается ))
- Vengant вчера в 15:27
  +7
  Ну, не совсем так. У нас есть и «долгоиграющие» задачи по апгрейду, миграции и так далее.
  
  Но вот, к примеру наш недавний анекдот: отдел сервис-менеджмента начал катить на нас бочку за то, что по получению SMS от мониторинга о падении аплинков в ЦОД мы подорвались устранять аварию. А надо было, оказывается, сначала завести тикет, описать что случилось, потом создать emergency change, и только потом поднимать упавшую сеть. Не забывая в процессе писать в тикетную записки из горящего танка. Дискуссия была закончена предложением начальника IT «тогда наймите нам секретаршу» :)
  - dpyzhov вчера в 15:40
    
    +2
    Change management на команде в два инженера?!
    - Vengant вчера в 15:42
      
      +2
      
      Ага :)
      Change management внедрили глобально во всей конторе. И нас тоже заставили играть в эту игру. Например, на каждое изменение любой строчки конфига прода надо завести «Standard Change». Сами заводим, сами пишем туда что-то от фонаря, сами закрываем. Для кого? А хрен его знает.
      
      Естественно, периодически на это забивается болт, когда само изменение занимает времени меньше, чем заведение того тикета. И естественно, в случае проблем я просто спрашиваю коллегу, не делал ли он чего с продом — потому что искать что-либо в тикетной удовольствие крайне долгое и сомнительное.
      - Ndochp вчера в 17:19
        
        0
        
        Угу, а потом басфактор, а галочка поставлена на пятом экране вспомогательной системы, а развертывание встаёт раком.
        
        Vengant вчера в 17:31
        
        +3
        
        Ну, как сказать… У нас еще до всей этой ITSM-вакханалии была внутренняя вики, где описывались конфигурации систем и важная информация про изменения в них. Был простой трекер задач. И все прекрасно работало. А теперь внедрили Change Management, Incident Management, Problem Management, CMDB… Но инфраструктуру по-прежнему поддерживают Вася и Ганс. Которые как обходились, так и обходятся без всей этой мишуры, которая сделана так, что пользоваться ею решительно невозможно. А от количества прыгающих вокруг девочек-манагеров с тупыми вопросами и требованиями вероятность ошибки только возрастает.
  - Loggus66 вчера в 17:41
    
    0
    Вы слишком много болеете за судьбу компании, где работаете. Из кривой бюрократии есть два пути: или итальянская забастовка, или увольнение. Попытки работать в обход правил приведут к наслоению всё новых практик управления, что, в свою очередь, приведёт к участившимся авралам, т. к. времени на системное устранение проблем будет всё меньше, а дальше возможны варианты вплоть до отмены тайм-менеджмента, потому что он только мешает загружать сотрудников работой.
    Всё вышеописанное — с натуры. В общем, или давайте обратную связь, или ищите другое место работы, а на Хабре жаловаться бессмысленно, особенно на фирму в Германии.
    - Vengant вчера в 17:46
      
      +1
      
      Да нет, все не так плохо чтобы увольняться — наш начальник отдела адекватен и большей частью успешно отбивает нас от наиболее дебильных требований, но вести эту документацию в разных тикетных и прочих CMDB все же приходится, как и периодически более или менее вежливо отшивать манагеров с их «гениальными» вопросами. И пост был не про жалобы, а про бессмысленность таких вещей. По факту целый отдел набрали ради того, чтобы внедрить и поддерживать систему, которая функционирует только на бумаге.
      - gecube вчера в 23:39
        
        0
        
        Бессмысленность бюрократии описана чудесным образом в т.н. "законах Паркинсонса". На примере роста сотрудников британского Адмиралтейства. Занятнейшее чтиво. Рекомендую.
FlyingDutchman вчера в 16:56
+1
В нашем infra отделе тоже изо всех сил внедряют Kanban. Хотя он нам не особо подходит. Да, в нем удобно делать планирование изменений (change requests), какие-то улучшения, апгрейды и т.п. Т.е. что-то плановое. Но большую (а иногда и львиную) часть работы таких отделов составляют не проактивный, а реактивные задачи из серии «Шеф! Всё пропало, гипс снимают, клиент уезжает». Т.е. инциденты и их устранение. И для бюрократии инцидентов Kanban ну никак не подходит, тут гораздо лучше старая добрая Jira управится.
Но у нас упорно тянут сову на глобус, даже в ущерб эффективности устранения инцидентов.
- ApeCoder вчера в 17:01
  0
  для бюрократии инцидентов Kanban ну никак не подходит
  Почему?
  - FlyingDutchman вчера в 17:04
    
    +1
    Потому что получится решение из серии «О пожаре сообщать за три дня».
    - ApeCoder вчера в 17:11
      
      +1
      
      А почему вы решили что канбан этого требует?
      
      Насколько я знаю, там просто живая очередь работ (в отличие, от, например, скрама, где есть спринты).
      - Vengant вчера в 17:13
        
        0
        
        Потому что когда случается авария, технический специалист должен заниматься ее устранением, а не заполнением доски. А когда она уже устранена — вносить ее в канбан просто нет смысла.
        
        ApeCoder вчера в 18:38
        
        –1
        
        Еще раз: откуда взялись три дня? Это на заполнение карточки с надписью "Авария" столько уходит?
        
        когда она уже устранена — вносить ее в канбан просто нет смысла.
        Это если вы знаете только одну вещь которую можно сделать с аварией — ее устранить. Если с карточкой аварии можно сделать, что-то еще то оно может приобрести смысл.
        
        Vengant вчера в 18:42
        
        –1
        
        А зачем что-то делать с карточкой? Зачем вообще карточка? Нет, ну если очень хочется — наймите секретаршу и пусть она заполняет карточки. Может даже их разрисовывать в розовый цвет. Только отстаньте от инженеров со всей этой галиматьей.
        
        Как правило, любители красивой отчетности и прочих карточек сами заменить инженера не смогут. И в его задачах не разберутся. А вот отсутствия «менеджера по карточкам» никто и не заметит.
        
        ApeCoder вчера в 18:56
        
        +1
        
        А зачем что-то делать с карточкой?
        Инцидент должен быть представлен, в какой-то форме, например в электронной. Если он просто сообщается в устной форме то потом трудно будет искать какие-нибудь детали по нему.
        
        Если он представлен в электронной форме, его можно называть "карточкой".
        
        Кроме того, чтобы решить инцидент можно использовать карточку:
        
        чтобы посмотреть текущий статус и не отвлекать инженера от этого
        
        чтобы посмотреть как подобные инциденты были решены ранее
        
        чтобы понять кто раньше это делал, у кого можно узнать детали
        
        чтобы агрегировать данные по инцидентам, посмотреть какие области наиболее подвержены инцидентам и с цифрами предложить какие-то решения по предотвращению дальнейших инцидентов
        
        А вот отсутствия «менеджера по карточкам» никто и не заметит.
        Я не знаю, кто такой "менеджер о карточкам". В вашей команде наверное все играют его роль, так как она небольшая?
        
        Vengant вчера в 19:02
        
        0
        
        «Менеджер о карточкам» в моей терминологии это любой бездельник из команды сервис-менеджмента.
        
        Что до инцидентов, то обычно это идет или от мониторинга (тогда есть алерт и он является триггером), либо это приходит извне в виде тикета. В первом случае тикет скорее всего будет заведен уже сильно постфактум, ибо не до того.
        
        Чтобы смотреть текущий статус, надо чтобы его кто-то обновлял — у инженеров на это нет времени во время работы над инцидентом.
        
        Чтобы посмотреть как подобные инциденты были решены ранее — нужно чтобы это было кем-то востребовано. Сами инженеры количеством 2 штуки таким функционалом по понятным причинам не пользуются. А менеджеры не имеют профильной квалификации, поэтому ничего не поймут, даже если я им напишу, как что устранялось.
        
        Чтобы понять кто раньше это делал, у кого можно узнать детали — ну, есть два варианта: либо я, либо мой коллега :)
        
        Чтобы агрегировать данные по инцидентам, посмотреть какие области наиболее подвержены инцидентам и с цифрами предложить какие-то решения по предотвращению дальнейших инцидентов — как правило есть ежемесячные митинги внутри отдела, на которых разбираются причины имевших место быть аварий и вырабатываются методы их недопущения.
        
        Как видите, никаких тяжелых решений тут абсолютно не нужно.
        
        wolfparanoya вчера в 19:41
        
        0
        
        Сами инженеры количеством 2 штуки таким функционалом по понятным причинам не пользуются.
        
        Два этих уволились. Два новых пришли. Никаких «бортовых журналов» нет. Весь наработанный опыт по ремонту смыт в унитаз. Два новых начинают накапливать опыт с 0.
        
        Vengant вчера в 20:51
        
        0
        
        По контракту отработка при увольнении — 3 месяца. Как раз хватит чтобы привести в порядок документацию, которая, кстати, вполне присутствует.
        
        Nalivai вчера в 22:30
        
        +2
        
        Как находившийся с обоих сторон передачи дел после почти полной смены команды, нет не хватит. Все после большого инцидента думают что ничего не забили и сделают выводы, а через полгода все забывается и ничего никому не передается. После одной такой передачи объекта мне еще несколько лет звонили с вопросами о тайных знаниях, которые мы забыли передать потому что как раз-таки не вели никаких карточек аварий.
        
        Stas911 вчера в 23:42
        
        +1
        
        3 месяца это круто! А новые работодатели в Германии тоже ждут по 3-4 месяца выхода нового сотрудника?
        
        Kanut вчера в 23:49
        
        0
        
        Три месяца это более-менее принятая норма, которую часто пишут в контрактах как минимальную. По закону там зависит от того как долго вы работаете на фирме .
        
        И да, новые работодатели ждут. От профессии конечно зависит, но местами и даже дольше ждут.
        
        nightwolf_du вчера в 18:43
        
        +1
        
        Vengant
        А откуда специалист узнал об аварии? А кем запрещено авто-тесты инфраструктуры и тикеты пользователей ставить сразу в канбан доску?
        
        Но вот, к примеру наш недавний анекдот: отдел сервис-менеджмента начал катить на нас бочку за то, что по получению SMS от мониторинга о падении аплинков в ЦОД мы подорвались устранять аварию
        
        Ну и кроме посылки в смс-шлюз прикрутите простановку тикета на доску.
        Менеджеру сразу станет понятно, чем вы занимаетесь при взгляде на эту доску. (ну, должно, менеджеры бывают не алё.)
        
        У меня висят таски 2-3 летней давности которые будут выполнены примерно никогда, потому что денег они уже не принесут и всегда есть более приоритетные задачи.
        
        С точки зрения канбана, их надо было выкинуть с доски куда-нибудь в бэклог ровно в тот момент, когда стало понятно что денег они уже не принесут.
        
        FlyingDutchman
        
        И для бюрократии инцидентов Kanban ну никак не подходит, тут гораздо лучше старая добрая Jira управится
        
        Канбан это методология/процесс работы.
        Jira — это расширенный таск-трекер.
        Ваше высказывание звучит как: «И для забивания гвоздей быстрые монотонные удары не подходят, с этим гораздо лучше молоток справляется»
        
        Vengant вчера в 18:47
        
        +1
        
        Ну и кроме посылки в смс-шлюз прикрутите простановку тикета на доску.
        Менеджеру сразу станет понятно, чем вы занимаетесь при взгляде на эту доску. (ну, должно, менеджеры бывают не алё.)
        Я отказываюсь понимать, зачем тут вообще менеджер. Он никак не участвует в устранении аварии. Он не может мне отдавать прямых распоряжений, ибо не является моим начальником. Он даже не является техническим специалистом и поэтому не понимает сути аварии.
        
        Вот что он хорошо умеет делать — это трахать мозг на тему, почему я во время аварии не бросил все и не побежал заполнять тикеты для бога тикетов, расписывая все в деталях непонятно для кого.
        
        Нет, я не спорю что бывает и правильное употребление всех этих методологий. Но как по мне — в коллективе с двумя админами все это просто излишне, потому что keep it stupid simple.
        
        nightwolf_du вчера в 18:52
        
        +1
        
        А у вашего менеджмента есть другие адекватные способы понять:
        1) «Сколько рабочего времени в месяц занимают аварии?»
        2) «Как часто случаются аварии с полным/средним/частичным отказом функционала?»
        3) В каких системах/подсистемах случаются?
        
        Vengant вчера в 18:56
        
        +1
        
        Рабочее время у нас нигде не трекается и задачи его подсчета не стоит. Ну, кроме как для внештатных сотрудников на почасовой оплате, но там я не в курсе, этим HR занимаются.
        
        Аварии у нас автоматически подтягиваются из мониторинга в таблицу сервисов, где прекрасно видно, когда/сколько/где именно/как часто. Потом туда же еще и SLA прикрутили, чтобы при угрозе его нарушения сыпались уведомления.
        
        eugene08 вчера в 19:13
        
        0
        
        > Я отказываюсь понимать, зачем тут вообще менеджер.
        Думаю, зависит от проекта, и много где нужно. Например, пожар на SaaS — пока инженеры смотрят и чинят проблему в фоне происходит много вещей — нотификация клиентов, эскалация, нотификация саппорт тим и выработка стратегии что делать им. Клиенты жуть как не любят наблюдать 502 в браузере не понимая сколько времени починка займет — 10 минут или до вечера, у них бизнес зависит от вашего проекта. Если такое повторяется — повод вообще разорвать контракт, а будет высокий churn rate — нечем вам зп будет платить.
        
        Vengant вчера в 19:18
        
        +1
        
        Согласен. Но в моем конкретном случае эта публика занимается исключительно процессами и траханьем мозгов тем, кто посмел на священную корову процессов покуситься. К примеру, ко мне прибежали ругаться за то, что тикет с запросом на доступ я закрыл с комментарием «доступ предоставлен». Оказывается, надо было написать, кому и куда дан доступ. Хотя это уже и так написано в самом тикете… Но у девочки-манагера в process manual сказано что при закрытии тикета надо это копипастить, и хоть ты тресни. Я конечно более или менее вежливо шлю всю эту публику куда подальше, но это тупо мешает работать.
        
        А вот менеджеры проектов у нас являются сотрудниками ИТ отдела и занимаются примерно как раз тем, что вы описали.
        
        eugene08 вчера в 19:51
        
        +1
        
        > К примеру, ко мне прибежали ругаться за то, что тикет с запросом на доступ я закрыл с комментарием «доступ предоставлен»
        сочувствую, такое, конечно, раздражает.
Stas911 вчера в 18:09
0
Автор, а книгу «Проект Феникс» вы читали? Мне кажется или там похожая вашей ситуация описана?
- Vengant вчера в 18:18
  0
  Не читал.
  - Stas911 вчера в 18:21
    
    +1
    Рекомендую (ее везде полно и на русском и на английском), возможно вы увидите свою ситуацию со стороны в новом ключе.
Andrey_Rogovsky вчера в 18:21
+2
Крик отчаянья услышан. Хотелось бы мнения противоположной стороны.
- Vengant вчера в 18:26
  +4
  Мнение противоположной стороны:
Newbilius вчера в 19:01
0
Boomburum, пользуясь случаем, реквестирую одну из фич)
1. добавить в мобильную версию сайта хабы под названием статьи
2. в причины минусов к статье добавить "заголовок неинформативен или вводит в заблуждение"
Вот правда, очень полезно будет.
- Boomburum вчера в 19:17
  0
  Насчёт причины — вряд ли. Когда мы составляли список, там было под сотню вариантов — мы отобрали самые частые. Согласен, что иногда такие «абстрактные» заголовки не дают сразу понять, о чём речь, но всё же иногда за ними скрываются интересные статьи. Если же вы прочитали статью и ожидания не оправдались, то можно выбрать «Не узнал ничего нового», например.
  
  Что касается хабов в мобильной версии — передал коллегам )
HabroUzer вчера в 22:25
+1
Вы не уточнили, какой именно «Канбан» у вас пытались внедрять: методологию для разработки софта, или же Тойотовский «процесс бережливого производства». Впрочем, в Вашем случае что то, что другое полностью бесполезно, или, скорее, вредно, ибо совершенно не предназначено для вашей области деятельности.

Описанная Вами ситуация далеко не уникальна, к сожалению. Зачастую менеджмент «ведется» на лживые обещания «продавцов технологий» (преследующих, естественно, свой личный интерес), модные тенденции и «тренды», а также «прогибается» ради карьерного роста.
Merrynose вчера в 23:33
+1
Не могу поддержать разговор про ITIL и ITSM, ибо не имел опыта, но не могу не спросить: а чем Канбан-то вам не угодил? Это ж не более чем правила, по которым организуется обработка входящих заявок.
К вам же каким-то образом заявки в отдел попадают? Небось, от разных людей, и каждый из них говорит что «моя заявка самая супер-пупер приоритетная!». Вот правильно внедренный Канбан и позволяет упорядочить этот бардак.
- gecube вчера в 23:43
  0
  Причем поставщиком заявок может быть та же система мониторинга и по вполне понятным причинам инцидент "авария" влетает с максимальным приоритет, приостанавливая очередь рутинных задач, скажем, по обслуживанию инфры.
nin-jin сегодня в 00:57
0
И никто не сказал, что канбан-то не про то, как организовать работу в вашем отделе, а про то, как организовать работу нескольких отделов, где работа одного человека зависит от работы другого...

Вот это канбан (разве что последняя колонка бессмысленна — выполненная карточка просто снимается):

А это — нет, это — карго-культ доски с карточками:
- it2manager сегодня в 01:41
  0
  И даже это не канбан )