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

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

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

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

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

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

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

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

    А вот чего я еще нигде и никогда не видел, так это чтобы бездумное внедрение таких вещей и требование им слепо следовать без оглядки на масштаб и специфику организации — а главное на реальную необходимость всего этого — приводило к чему-нибудь хорошему.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 194

      +2

      А почему руководство решило все это внедрять? Может, у них есть какие-то цели, которых они хотели этим достичь, и эти методы им показались наиболее правильными?

        +2
        Руководство обычно решает это сделать с чей-то подачи. Они же в большинстве своем финансисты и управленцы, и в этих ваших IP адресах совершенно не понимают.
        А некто во второй-третьей линии начальствующих решает укрепить свои позиции инициативами, берет красивые презентации, статистику популярности и готовится к повышению.
        Была ситуация, когда некто писал кандидатскую про КПИ и приКПИшных чудесах, и тут-же экспериментировали на сотрудниках внедряя их в жизнь. Особенно забавно было смотреть, как искали/выдумывали эти показатели для разных групп сотрудников.
          +14
          Я как-то видел вообще прекрасное — KPI одного отдела зависел от работы другого, который ему не подчинялся…
            0
            Бывает и запущеннее: манагер накручивает свой показатель по количеству подаренных скидок, а вознаграждение исполнителя работ вычисляется как продажный объем нетто)
              +2

              Менеджерам нужны метки — временные и количественные, по которым они ориентируются. Например сделано — не сделано, Если не сделано, то насколько и когда будет результат. Им не надо понимать как всё устроено под капотом. Им нужны флажки, столбики, сегменты диаграмм как показатели готовности. Это их среда и инструменты. Их они используют для общения с руководством. Это абсолютно нормально. Не нормально простаивать и затягивать коммерческий проект. Но не всё зависит от тебя. Для этого и нужны менеджеры. У которых главная задача это слежение за исполнением проекта. Это достаточно нервная работа. Ну или мне такие менеджеры попадались. Но это все равно были высококлассные менеджеры. Процент срывов обычных проектов у которых был минимален. А топовых вообще равен 0. Маразма нет никакого. Кесарю — кесарево как говорится. Как пример проекта. Презентация для госструктуры. 2 программиста и 10-15 дизайнеров и 1 видеомонтажер. Сроки не жмут. На каком языке должны общаться дизайнеры и программисты. Если и те и другие далеки друг от друга в предметных областях и даже физически недоступны. Каковы должны быть скиллы у менеджера для успешной реализации проекта? Сколько их должно быть.

                +3
                Каковы должны быть скиллы у менеджера для успешной реализации проекта? Сколько их должно быть.

                Ровно два: рот открыть и рот закрыть.

                Для не умеющих в юмор поясню: Обеспечить коммуникацию и не выносить мозг. Баланс тонок, но возможен. И именно это отличает хорошего менеджера от плохого.
                  +3

                  Нет не это отличает. Отличает умение доводить проекты до конца. Часто менеджеры это просто подрядчики, которым не хватает собственных ресурсов и они нанимают профи на рынке. Коммуницируют. Выносят мозг. В реале всё бывает. Главное чтобы дело двигалось. А есть балаболы. Но это чаще в крупных компаниях. Где на одного работягу 5 балаболов. Да вы и сами знаете. Пример — у компании много проектов. Их надо кому вести и взаимодействовать по некритичным вопросам с клиентами. Кто этим должен заниматься? Ну не разработчики же.

                0
                Это что-то типа — обслуживающие подразделения получат премию, только если продажники выполнят план продаж?
                Сплошь и рядом такое…
                  +1
                  Ну узнают обслуживающие подразделения, что мир устроен сложней, чем хотелось бы. Кто-то примет новую реальность и сделает выводы, а кто-то просто будет в курилке рассказывать: «эти там получают гигантские зарплаты, а пашем мы».
                +1
                Ну и всякие шильдики добавляют сейлс поинтов в глазах не особо опытных клиентов. Но вот в организациях, которые свои процессы наружу не продают, чаще всего это обычный карго культ и чьёто-то раздутое эго.
                  +3

                  Ну финансисты выкладывают деньги за что? Видимо, тот руководитель, который инициировал все это, что-то им пообещал?
                  Может им недостаточно предсказуемости вашей работы? Или SLA недостаточный? Или их идеи не реализуются?
                  Просто это как-то не по-финансистски, выделить деньги просто так, без цели.

                    +7
                    Ну тогда заходили неправильно. Технарям нужны не возвышенные цели и мир во всём мире, а конкретные задачи. Нужно SLA — говори что нужно SLA. Нужен учёт — говори что нужен учёт. Но внедрение ITIL ради корочки о внедрении ITIL — это уже совсем другое. Ничто так не демотивирует инженера, как бессмысленная работа.
                      +3

                      Ну попросят у вас SLA — откуда вы его возьмете, придумаете из головы? А канбан позволяет SLA высчитать.
                      Это ваша точка зрения — что ITIL внедряется ради корочки. А с точки зрения бизнеса это упорядочивание непрозрачной работы админов, введение четких правил и процедур, на которые они могут ориентироваться при аудите, при планировании, при создании отчетов.
                      Мне если вдруг кажется, что сразу много людей занимаются не тем, чем надо, то я сразу настораживаюсь, потому что обычно это значит, что я не понимаю чего-то, а не то, что все другие вредители.

                  +4
                  Цели там есть: показать вышестоящей организации и партнерам «смотрите, какие мы офигенные, мы сертифицированы по бла-бла, тыр-пыр и фыр-быр, а еще мы работаем по ITIL и у нас все по фен-шую».
                    –7
                    Складывается впечатление, что вы не только не помогли компании наладить процессы но и вставляли свои палки в колеса. Бизнес — не благотворительность, абсолютно нормальное желание у менеджмента знать за что вам и вашим коллегам платят деньги, что вы делали вчера, что делаете сегодня, и, примерно, что будете делать в понедельник. Канбан/другие подходы делают процессы прозрачными, что приносит много плюшек, например: имея организованные процессы разработки, можно разрабатывать систему регулярных ревью для поощрения сотрудников.
                      +15
                      Не вопрос, только что бизнесу будет от того, что он узнает, что вчера я весь день составлял стратегию развития свича на 5 этаже, сегодня делаю отчёт по внедрению KPI среди самого себя, а в понедельник буду занят Scrum-митингом по постановке задач из утверждённого месяц назад квартального плана регламентных работ (который уже 3 года не менялся)?
                      Складывается впечатление, что некоторые непонимают, что управление работой — это тоже работа, и она тоже требует время и денег на своё выполнение.
                        –6

                        Канбан это немножко не то. Представьте, что у вас та система где вы учитываете заявки будет визуализировать их в том числе в виде доски. Будет установлен четкий лимит сколько вы можете брать заявок в работу, а если их будет больше вы будете не брать новые пока их число не уменьшится.

                          +12
                          А теперь представьте, что этим управляет девочка-гуманитарий, которая абсолютно не разбирается в том, чем вы занимаетесь, но при этом имеет право лезть к вам с требованиями расписать задачи более феншуйно или объяснить ей то и это.
                            +3
                            Ну так проблема-то не в канбане тогда, а в том что скрам-мастер (так это называется?) неправильно выбран. А теперь представьте что этим управляет грамотный технически подкованный менеджер, задача которого создать оптимальную работу, чтобы к админам не лазили со всякой фигней когда у них важные дела, и чтобы админы могли одним взглядом отличить задачу которая нужна бизнессу прямо сейчас от задачи которая не понадобится еще год, и чтобы сразу было видно если на админе и так висит девять очень срочных задач и придумывать стратегию развития свича ему сейчас не с руки
                              +1
                              Именно, как я вижу упорядочивание и правильная приоретизация задач только поможет в работе и отчасти устранит вот это «АААА, СРОЧНО ПРЯМО СЕЙЧАС» которое прилетает со всех сторон.
                                0

                                Как тут не вспомнить присказку, что хороший админ — это тот, который играет контру, а не тот, у которого рожа в мыле. (при условии, что всё работает конечно)

                                  0

                                  И при не менее обязательном условии что его руководство это тоже понимает.

                              +11
                              Если Вам непонятен посыл статьи, можно я немножко перефразирую? Спасибо.
                              Вот отдел. В нем 2 человека. Всего 4 руки. И если эти руки, вместо непосредственной работы, будут заполнять бесчисленные канбаны, производительность труда отдела упадёт.
                              Единственный профит для бизнеса (на примере сервис деска) — понимание того, что 10% юзеров генерирует 90% проблем. Так это, во-первых, очевидно для всех (как правило, кроме самого руководства), а во-вторых это в 99% случаев родственники этого самого руководства!
                                0
                                Спасибо :) В нашем случае речь идет не о юзерах конечно, но все примерно так и есть.
                                  +1

                                  Насколько я понял они по факту выбрали сами пользоваться досками в итоге — т.е. заполнять их вручную или автоматически.


                                  Единственный профит для бизнеса

                                  А зачем вообще нужен канбан? С точки зрения его сторонников?

                                    0
                                    Правильно поняли. Мы и до того трекали внутренние задачи в гилтабе, а потом стали в нем же раскидывать их по доскам. Но это чисто внутренняя кухня, а не навязанное и контролируемое сверху решение, как оно изначально предполагалось.
                                      +3

                                      Канбан позволяет определять узкие места при выполнении многоэтапных задач. Например, что разработчики делают задачи быстрее чем тестировщики их тестируют.

                                        +1
                                        Если своими словами – ускорение работы команды с потоком заявок за счёт фокусировки на меньшем количестве заявок в единицу времени и на работе по выявлению и устранению узких мест.
                                          0

                                          не обязательно устранению, узкое место будет всегда. Узкое место надо передвинуть на ту операцию, которую вы можете легко регулировать, и тогда вы можете регулировать пропускную способность всей системы.

                                            +1
                                            Узкое место передвигается в новую точку исключительно путём устранения его в предыдущей. Но да, в какой-то момент теоретически можно прекратить оптимизацию. Хотя в реальности постоянно что-то меняется. Кто-то приболел, внедрили новую фиговину, поменяли процесс – и вот узкое место там, где не ждали.

                                            Конечно, если вспомнить книгу Голдратта, то когда система начала справляться со всем входящим потоком и всеми заявленными целями, они объявили узким местом цели компании и канал продаж. У меня так в какой-то момент багфикс легаси продукта превратился в его рефакторинг, когда кончились все баги, что можно починить без него.
                                              0

                                              В идеале узкого места быть не должно, у всех этапов пропускная способность должна быть равной скорости входа задач.

                                                0

                                                Сложный вопрос. В идеале есть два чувака, которые работают в паре. И нагрузка по ним распределяется по 50%. Все освободившееся время от рутины они тратят на улучшение процессов и работу на перспективу. Все счастливы. Проблема только в том, что это дорого, и это могут позволить себе либо стартапы, которые жгут деньги инвесторов, либо технологические компании. Остальные — жестко экономят ФОТ, в результате нагрузка на одного составляет 100-150-200%

                                                  0

                                                  Ну в таких условиях просто на всех этапах равная пропускная способность, чтоб нагрузка равно распределялась. Хотя, конечно, бывает, что разработчики по 8 часов работают, а тестировщики по 12 тестируют, чтоб не накапливались задачи "готово к тестированию". Но формально количество задач в сутки одинаково, узеи мест нет:(

                                          +2
                                          . И если эти руки, вместо непосредственной работы, будут заполнять бесчисленные канбаны, производительность труда отдела упадёт.

                                          Так «эти руки» как раз таки ничего заполнять и не должны. Канбан это грубо говоря система тикетов, которая имеет определённые правила. То есть вещи вроде «нельзя одновременно обрабатывать больше чем Х тикетов» или «Если статус у тикета из категории А не меняется Y дней, то на него надо повнимательнее посмотреть».

                                          И вопрос в том как вообще сейчас организованы процессы в этом отделе. Ну то есть какие у них задания, кто их даёт, кто и как распределяет, кто оценивает объём работ, кто и как отчитывается о проделанной работе и т.д. и т.п. И только тогда уже можно думать надо там что-то менять и если надо, то канбан там нужен или что-то другое.
                                            0
                                            Ну вот в примере выше нашлись деньги на покупку инструктора по курсам канбан, но не нашлись на человека для двух админов. который будет все эти тикеты заполнять.
                                            Суть как раз в том, что чем больше в компании сотрудников, тем активней система подавляет обратную связь от конечных исполнителей. И это что-то на уровне древней психологии стаи обезьян, а не заговора рептилоидов.
                                              0
                                              Ну во первых «инструктор на канбан» это одноразовая выплата. И вряд ли за него заплатили даже годовую зарплату «заполнятеля тикетов».

                                              А во вторых тикеты по хорошему должны заполнять конкретно те кому что-то нужно от админов. В конце-концов сейчас же админы откуда-то задания получают. Неужели они их исключительно сами себе придумывают?
                                                0
                                                А во вторых тикеты по хорошему должны заполнять конкретно те кому что-то нужно от админов. В конце-концов сейчас же админы откуда-то задания получают. Неужели они их исключительно сами себе придумывают?

                                                Вы правда не понимаете различий между скрамом, карточками канбан и сервис-деском?
                                                То, что вы сейчас упомянули — это ТИКЕТ в сервис-деск, который должен заполнить пользователь, чтобы получить УСЛУГУ от отдела ИТ.
                                                Карточки канбан это внутренние дела отдела ИТ, заводятся тогда, когда задача (карточка) имеет более одного этапа работы и/или отрабатывается несколькими людьми/отделами.
                                                Так вот, возвращаясь к сервис-деску, 99% неудачных внедрений SD из-за того, что юзеры НЕ ЖЕЛАЮТ сами ничего заполнять, им ПРОЩЕ позвонить/прийти, чем формулировать своё мычание «тут у меня это, в полу подземный стук».
                                                  +2
                                                  Вы правда не понимаете различий между скрамом, карточками канбан и сервис-деском?

                                                  Я бы сказал что это вы не понимаете что при нормальном тулинге и нормально поставленных процессах эти самые «внешние» тикеты/таски/задачи превращаются во «внутренние» банально одним нажатием кнопки или даже автоматом.

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

                                                  Так вот, возвращаясь к сервис-деску, 99% неудачных внедрений SD из-за того, что юзеры НЕ ЖЕЛАЮТ сами ничего заполнять, им ПРОЩЕ позвонить/прийти, чем формулировать своё мычание «тут у меня это, в полу подземный стук».

                                                  То что там кому-то что-то проще совсем не означает что им это надо позовлять так делать. Ну а если уж позволяете, то тогда наверное не стоит и жаловаться что админы работать не успрвают потому что им надо «карточки заполнять».
                                                    0
                                                    > Карточки канбан это внутренние дела отдела ИТ
                                                    они вполне могут приходить снаружи, от других отделов — дать/забрать доступ, чтонибудь насетапить и тп
                                                      0
                                                      > Карточки канбан это внутренние дела отдела ИТ
                                                      они вполне могут приходить снаружи, от других отделов — дать/забрать доступ, чтонибудь насетапить и тп

                                                      На самом деле нет :-)
                                                      «По учебнику» это называется «запрос на изменение» и является стандартным процессом в сервис-деске. То, что этот процесс можно натянуть на канбан и реализовать в виде карточек, не значит что это правильно и оптимально.
                                              0

                                              Это не совсем так. Производительность даже двух рук зависит от головы, от того, что и когда в эти руки дают. Я сам свидетель истории, когда выстроенный процесс увеличил производительность команды почти в три раза без каких-либо кадровых изменений.

                                                +2
                                                Я сам свидетель истории, когда выстроенный процесс увеличил производительность команды почти в три раза без каких-либо кадровых изменений

                                                Это всего лишь значит, что в результате пересмотра бизнес-процессов часть задач принято решение делать чужими руками. Увы, волшебных пилюль не бывает и обычно «выстраивание процесса» сводится к анекдоту, когда сенокосцу на лоб цепляют фонарик, а к заднице грабли.

                                                PS: Возможно я где-то излишне пессимистичен в оценках, но сейчас я переживаю момент, когда у руля производственной компании оказались мало того, что гуманитарии, так еще и маркетологи с коучингом на всю голову и в целом мы стремительным домкратом несёмся в успешный-успех.
                                                  +2

                                                  Я сожалею по поводу вашей ситуации, но не соглашусь с вашим первым утверждением: результат был достигнут не за счет "чужих рук", а за счет уменьшения простоя, уменьшения частоты переключения контекста, и за счет использования более удобных инструментов. И первые два пункта были достигнуты исключительно за счет улучшения процесса.

                                                    +1

                                                    Просто приоритетами можно увеличивать производительность за счёт группировки задач по контекстам, за счёт минимизации количества переключений.

                                                      0
                                                      Плюс к вышесказанному, выстраивание процесса иногда позволяет понять, что некоторые задачи или совсем не надо делать, или требуют мощнейшей оптимизации.
                                                +2
                                                управление работой — это тоже работа, и она тоже требует время и денег на своё выполнение.

                                                Золотые слова! Эффект рекурсивной ловушки в чистом виде. Потом появляется управление управлением работой, а потом управление управлением управлением…
                                                В 15 веке в Англии было 50 тысяч военных кораблей, а в адмиралтействе работало 5 человек. И справлялись.
                                                В 19 веке кораблей осталось 500, зато в Адмиралтействе работало уже 5 000 чел. И справлялись с работой с большим напряжением.
                                                Сейчас от военного флота осталось 5 кораблей, зато в Адмиралтействе работает уже 50 000 человек и не справляются с работой совсем.
                                                  +1
                                                  Хм, а вы уверены что одинаковое количество кораблей во все времена создавало одинаковое количество работы? И что английское Адмиралтейство занимается исключительно кораблями и ничем больше?
                                                    +1

                                                    50 тысяч военных кораблей? Да не может быть так много!

                                                      +1
                                                      Ну, цифры условные, наверно, это весь флот насчитывал такое количество кораблей. Но тенденция отражена правильно. Любая бюрократическая организация заинтересована в росте и увеличении, вне зависимости от внешней функции, для которой она создавалась.
                                                        +1

                                                        Военные лодки, лол. Шучу

                                                          +1
                                                          Ну, эта история и рассказывается как шутка. Это из какой-то юмористической книги типа законов Мерфи или Паркинсона.
                                                            0
                                                            Не типа, а именно Паргинсона. Именно он подмечал экспоненту в числе сотрудников адмиралтейства. В книге 1 как гипотезу, в книге 2 через 10 лет — как наблюдение, совпавшее с ней.
                                                    +7

                                                    Ровно такое же есть желание не тратить собственные усилия на то, чтобы помогать другим людям выполнять их KPI.


                                                    Хотят — пусть выполняют. Не хотят — пусть не выполняют. Хотят, чтобы я им помогал — пусть мотивируют. Можно деньгами, можно статусом, можно блестящей игрушкой. Если кто-то хочет, чтобы я занимался унылым, скучным, непрестижным забесплатно, то я не могу запретить ему хотеть. Но и помогать в исполнении желаний тоже не буду.


                                                    Можно попробовать от противного — заставить под угрозой увольнения.


                                                    Но, повоторю, если кто-то хочет, чтобы я занимался скучным, неинтересным, непрестижным под угрозой увольнения, то он может попробовать. А я могу стряхнуть пыль с резюме в ответ.

                                                      +5
                                                      абсолютно нормальное желание у менеджмента знать за что вам и вашим коллегам платят деньги

                                                      Абсолютно глупое желание. Если у тебя, как у менеджера, есть цели и задачи — именно за них и нужно платить. Не нужно "знать, за что платишь", нужно "платить, за то, что требуется". А если ты не знаешь, что требуется, спроси у того, кто знает.


                                                      Контроль и прозрачные процессы нужны для того, что бы проверить, делается ли то, что требуется.

                                                  0
                                                  «для отчета» или «потому что модно»

                                                  видимо, поэтому

                                                    +4
                                                    к сожалению это типичный майндсет
                                                    — руководители в кои то веки решили выделить денег — обучить сотрудников
                                                    — возможно они выбрали не лучшего тренера и не лучшую методику,

                                                    внимание вопрос, что сделает наш Васян?
                                                    1. постарается извлечь максимум пользы даже их среднего материала с плохой подачей
                                                    2. изо всех сил будет показывать руководству что они, которые ему деньги платят и, видимо, хотят вкладывать — тупые, а он Вася — умный?
                                                      +6
                                                      Не, не так. Вася понял, что если предлагаемую сервис-манагерами методологию пропихнут в том виде и в том объеме, как это описывается — то она не заменит существующие системы трекинга задач и отчетности, а добавится к ним, что даст манагерам очередную возможность трахать мозги технарям и выльется в еще больший разгул бюрократии и необходимости описывать каждый чих. Поэтому Вася, воспользовавшись своим положением «этого странного русского», донес до присутствующих абсурдность этой идеи в заведомо гротескной форме. Судя по тому, что тема в итоге тихо заглохла, к Васе все же прислушались и поняли, что это уже чересчур.

                                                      При этом IT отдел для себя сделал выводы и стал юзать GitLab Boards — это действительно удобно. Но только когда все это — внутренний инструмент, который контролируется начальником отдела, понимающим кто чем занимается, а не девочкой с гуманитарным образованием, не отличающей ping от fuck.
                                                        +5
                                                        Подписываюсь, все так.
                                                        У нас была своя система учета рабочего времени — в тебя бросают куском работы, ты говоришь крайний срок когда будет готова (ну или за тебя решает руководитель). Далее задача билась на подзадачи и в систему вписывалось фактическое время выполнения подзадач. По итогу руководитель знал среднее время выполнения работ по всем и каждому, что давало возможность оценивать сроки с +- адекватной погрешностью.

                                                        Но тут решили внедрять… сначала добавили ежемесячный отчет о том что сделано. Потом воткнули одну популярную CRM и обязали ставить там таски, запускать трекеры времени и пр. в общем использовать как таск-трекер.
                                                        По итогу я теперь пишу отчеты в 4 (ЧЕТЫРЕ) мать их системы. Одна для финансистов, вторая для планирования, третья в опытной эксплутации, но без заполнения четвертой не работает.
                                                        Вишенка на торте что в одной из систем нельзя проставить затраченное время «задним» числом(только кнопки старт и стоп). На мой вопрос — что делать с прерываниям, т.е когда мне звонит заказчик и я выпадаю на час разговоров, никто ничего ответить не может.

                                                        На фоне всего этого проталкивают канбан. Который хорошо работает на поточном производстве, но нифига не работает на штучном. У меня висят таски 2-3 летней давности которые будут выполнены примерно никогда, потому что денег они уже не принесут и всегда есть более приоритетные задачи. Но таски висят снижая мою «эффективность». Раз в полгода на очередном совещании девочка-приносит отчет по сотрудникам и начинается «А что это мы на задачи забиваем?»
                                                          +4

                                                          Эти висячие задачи надо закрывать с каким-нибудь комментарием "obsoleted by...". И не волнует. Если надо — визу руководителя. Все счастливы.


                                                          Ну, действительно. Скажем, была задача "обновить хх до версии уу". А потом вышла версия zz > yy. Появилась задача "обновить хх до версии zz". Вы ее и сделали, а первую можно утилизировать.

                                                            +2
                                                            Там довольно длинная история вида: подрядчик выполнял разработку документации, по которой мы изготавливали систему.
                                                            Сроки были сжатыми, а объемы конскими. В нормальном режиме на разработку и изготовлении такой системы требуется около 9 месяцев. Мы сделали за 3.
                                                            Плюс в процессе участвовала еще пачка организаций согласующих и будущая эксплуатация. В процессе изготовления творился некоторый хаос уровня отправляем документацию в производство и согласование в параллель, тут бац что-то не подошло, меняем на месте, отправляем замечание, подрядчик правит, цикл повторяется N раз. Важный нюанс документация имеет нелинейные ссылки. И за всем уследить довольно тяжко.

                                                            По итогу систему сдали, отгрузили, документацию (600+ документов) отправили в архив. Через год провели аудит и выяснили, что отсутствуют 6(10) чертежей. Все эти
                                                            документы заказчику не отправлялись (не входили в договор), на эксплуатацию не влияют и нужны ТОЛЬКО для повторного изготовления. Мой 12 летний опыт говорит что мы еще НИ РАЗУ не делали 2 одинаковые системы. НИ_РА_ЗУ. О чем это я? А! Архив поставил задачу — сдать документы. Логично, чё, у них там тоже аудиты и проверки.
                                                            Задача прилетела мне — написал подрядчику, мол так и так дошлите пожалуйста. Подрядчик отморозился тем что договор закрыт, деньги получены и вообще мы вам все выдали.
                                                            Ну зашибись, действительно часть 3D-моделей есть, а чертежей (оформленных) нет. Даю оценку по времени и ресурсам, иду к руководителю отдела, мол вот таска. Получаю закономерный ответ: «к черту, сейчас важнее <проект_нейм>, сделай когда будет свободное время». Ну а дальше наступило сегодня.
                                                            Вот и получается, что я то задачу закрою, но через год при очередном аудите архив снова ее поставит, девочка опять будет вещать про невыполненные задачи, мы будем смотреть на менеджмент и спрашивать «да без проблем, бросаем все и делам?»,
                                                            менеджеры будут хмуриться, зыркать на девочку и говорить о том что срыв сроков по текущим проектам недопустим ибо штрафы.

                                                            Как итог: де юре, мы должны все бросить и выполнить таски. Де факто, это никому не нужно, ни нам, ни менеджменту, ни заказчику. Таска висит, денег(времени) не выделяют.

                                                            P.s. Можно было бы сказать что это нужно архиву, но они могли бы закрыться перед аудиторами бумажкой вида «утеряно при переезде».
                                                      +7
                                                      Правильная бюрократия упрощает работу. А у вас случился карго-культ.
                                                        +4
                                                        Мое мнение — подобные фреймворки улучшают ситуацию только при числе сотрудников в компании начиная примерно от тысячи человек. Если людей меньше — лишние бюрократические процедуры лишь замедлят рабочий процесс. В любом случае ITIL это не прямое руководство к действию, а описание best practice и внедрять их надо с учетом специфики той или иной компании, а не бездумно.
                                                          +2
                                                          Тысяча — это вы конечно загнули. Я для себя определяю этот порог «ненужности» — когда все лично друг друга знают и с любым вопросом можно просто подойти и спросить. Это, конечно, не отменяет необходимость в грамотном управлении, но на таких масштабах оно больше строится на личном участии руководства в процессе, а не абстрагировании на сферическое управление в вакууме.
                                                            0

                                                            Вы не поверите, но Канбан даже в семье, в домашних делах, улучшает продуктивность. :)

                                                              +2

                                                              Расскажите, пожалуйста! Я интуитивно понимаю, что это должно помочь, но как именно, хотелось бы подробностей.

                                                                0
                                                                Не для всех, и не всегда )
                                                                  +2

                                                                  Полагаю, там по факту ремонты-закупки-переделки заносятся? Но фантазия сразу попыталась представить Канбан с задачами вида "отвлечь ребёнка чтоб мама подремала" и "супружеский долг"...

                                                                  +1
                                                                  >Мое мнение — подобные фреймворки улучшают ситуацию только при числе сотрудников в компании начиная примерно от тысячи человек

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

                                                                  Я работал в стартапе где примерно на полсотне инженеров случился кризис — процессы были плохо построены, часто нарушались, в прод попадал неоттестированный код. Все это привело к тому что крупный клиент был на грани ухода, что привело бы к закрытию бизнеса или по меньшей мере, к массовым увольнениям. Я тогда саппортил прод и файры случались чуть ли не каждую неделю. Но мы смогли себя взять в руки, перенастроить процессы и преодолеть кризис, поднять качество, файры сократились до пары раз в год. А компания в это время продолжала расти, наращивать пользовательскую базу и количество сотрудников. Это я вам с не с позиции проповедника чего-то там пишу, а девопс инженера.
                                                                    +1
                                                                    ITIL это библиотека описывающая управление ИТ услугами. Там конечно есть раздел посвященный разработке ПО, но он далеко не главный. Описанная вами ситуация не требует «внедрения» ITIL. Здесь скорее надо изучать методологии SDLC и управление проектами по типу PMBok.
                                                                      +1
                                                                      Автор не только про ITIL написал но и про Kanban, поэтому я привел пример как SDLC может влиять на бизнес и сотрудников. Да и вообще, проблема глубже — постройка/настройка процессов в бизнесе.
                                                                  +1
                                                                  Так из комментариев автора тоже следует, что чем он будет заниматься завтра, он уже знает, а к примеру через неделю нет. Одно дело внедрять план отделу разработок ( и не забыть его корректировать с действительностью), а другое дело — для сотрудника, реагирующего на ЧП.
                                                                  План по ЧП — это уже какой-то Machine Learning получается ))
                                                                    +9
                                                                    Ну, не совсем так. У нас есть и «долгоиграющие» задачи по апгрейду, миграции и так далее.

                                                                    Но вот, к примеру наш недавний анекдот: отдел сервис-менеджмента начал катить на нас бочку за то, что по получению SMS от мониторинга о падении аплинков в ЦОД мы подорвались устранять аварию. А надо было, оказывается, сначала завести тикет, описать что случилось, потом создать emergency change, и только потом поднимать упавшую сеть. Не забывая в процессе писать в тикетную записки из горящего танка. Дискуссия была закончена предложением начальника IT «тогда наймите нам секретаршу» :)
                                                                      +2
                                                                      Change management на команде в два инженера?!
                                                                        +3
                                                                        Ага :)
                                                                        Change management внедрили глобально во всей конторе. И нас тоже заставили играть в эту игру. Например, на каждое изменение любой строчки конфига прода надо завести «Standard Change». Сами заводим, сами пишем туда что-то от фонаря, сами закрываем. Для кого? А хрен его знает.

                                                                        Естественно, периодически на это забивается болт, когда само изменение занимает времени меньше, чем заведение того тикета. И естественно, в случае проблем я просто спрашиваю коллегу, не делал ли он чего с продом — потому что искать что-либо в тикетной удовольствие крайне долгое и сомнительное.
                                                                          0
                                                                          Угу, а потом басфактор, а галочка поставлена на пятом экране вспомогательной системы, а развертывание встаёт раком.
                                                                            +3
                                                                            Ну, как сказать… У нас еще до всей этой ITSM-вакханалии была внутренняя вики, где описывались конфигурации систем и важная информация про изменения в них. Был простой трекер задач. И все прекрасно работало. А теперь внедрили Change Management, Incident Management, Problem Management, CMDB… Но инфраструктуру по-прежнему поддерживают Вася и Ганс. Которые как обходились, так и обходятся без всей этой мишуры, которая сделана так, что пользоваться ею решительно невозможно. А от количества прыгающих вокруг девочек-манагеров с тупыми вопросами и требованиями вероятность ошибки только возрастает.
                                                                              +1

                                                                              О, да. Как же бесили всякие incedent tracker-ы, в которых на закрытие задачи тратилось времени больше чем на ее решение.

                                                                          +1
                                                                          А что не так? Я видел не нулевое количество ситуаций, когда профессиональные админы делали «на живую», потому что «чего там писать, мы сейчас вам быстро сделаем». А потом приходил я и спрашивал: где бэкап, почему не подключили к мониторингу и т.д. А так-то да, всё корректно изменяли и оно работало.
                                                                            0
                                                                            Для этого в команде из двух человек достаточно той тикетной системы, что уже есть, умения задать вопрос «тут что-нибудь ещё надо?», и ретроспектив. Change management слишком громоздкий для таких масштабов. Хотя и он может быть полезен, если нужно держать высокий аптайм и количество правок исчисляется единицами в неделю. ИМХО, разумеется.

                                                                            А у вас есть примеры успешного Change management на таких масштабах?
                                                                          +1
                                                                          Вы слишком много болеете за судьбу компании, где работаете. Из кривой бюрократии есть два пути: или итальянская забастовка, или увольнение. Попытки работать в обход правил приведут к наслоению всё новых практик управления, что, в свою очередь, приведёт к участившимся авралам, т. к. времени на системное устранение проблем будет всё меньше, а дальше возможны варианты вплоть до отмены тайм-менеджмента, потому что он только мешает загружать сотрудников работой.
                                                                          Всё вышеописанное — с натуры. В общем, или давайте обратную связь, или ищите другое место работы, а на Хабре жаловаться бессмысленно, особенно на фирму в Германии.
                                                                            0
                                                                            Да нет, все не так плохо чтобы увольняться — наш начальник отдела адекватен и большей частью успешно отбивает нас от наиболее дебильных требований, но вести эту документацию в разных тикетных и прочих CMDB все же приходится, как и периодически более или менее вежливо отшивать манагеров с их «гениальными» вопросами. И пост был не про жалобы, а про бессмысленность таких вещей. По факту целый отдел набрали ради того, чтобы внедрить и поддерживать систему, которая функционирует только на бумаге.
                                                                              +1

                                                                              Бессмысленность бюрократии описана чудесным образом в т.н. "законах Паркинсонса". На примере роста сотрудников британского Адмиралтейства. Занятнейшее чтиво. Рекомендую.

                                                                                +1
                                                                                Бюрократия имеет тенденцию к переходу от обслуживания бизнес-процессов к обслуживанию самой себя.
                                                                                  +1

                                                                                  Это бессмысленность части бюрократии. Бессмысленность бюрократии можно было бы показать если бы рядом было Адмиралтейство такого же размера и настолько же успешное но вообще без бюрократии.

                                                                              0
                                                                              оказывается, сначала завести тикет, описать что случилось, потом создать emergency change, и только потом поднимать упавшую сеть

                                                                              Это очень странно. Либо вы не договариваете, либо у вас там действительно не очень профессиональные коллеги.
                                                                              Если упала сеть и если это классифицируется как критичный инцидент (что может быть не всегда так), то лучшие практики (которые писали не дураки) прямо так и говорят — сначала ремонтируем, потом оформляем тикет. Но не каждый инцидент требует изменений для своего разрешения. Если же требуется экстренное изменение, то очень часто оно проводится так же, как и разрешение критичного инцидента — сначала делаем, потом записываем. Но почему важно держать в голове такую декомпозицию — потому что запрос на изменение содержит в себе указание на затрагиваемые системы и план отката. Если об этом не подумать, то можно довольно криво экстренно наизменять. Так что потом и фиксировать особо нечего будет.
                                                                            +2
                                                                            В нашем infra отделе тоже изо всех сил внедряют Kanban. Хотя он нам не особо подходит. Да, в нем удобно делать планирование изменений (change requests), какие-то улучшения, апгрейды и т.п. Т.е. что-то плановое. Но большую (а иногда и львиную) часть работы таких отделов составляют не проактивный, а реактивные задачи из серии «Шеф! Всё пропало, гипс снимают, клиент уезжает». Т.е. инциденты и их устранение. И для бюрократии инцидентов Kanban ну никак не подходит, тут гораздо лучше старая добрая Jira управится.
                                                                            Но у нас упорно тянут сову на глобус, даже в ущерб эффективности устранения инцидентов.
                                                                              0
                                                                              для бюрократии инцидентов Kanban ну никак не подходит

                                                                              Почему?

                                                                                +1
                                                                                Потому что получится решение из серии «О пожаре сообщать за три дня».
                                                                                  +1

                                                                                  А почему вы решили что канбан этого требует?


                                                                                  Насколько я знаю, там просто живая очередь работ (в отличие, от, например, скрама, где есть спринты).

                                                                                    0
                                                                                    Потому что когда случается авария, технический специалист должен заниматься ее устранением, а не заполнением доски. А когда она уже устранена — вносить ее в канбан просто нет смысла.
                                                                                      0

                                                                                      Еще раз: откуда взялись три дня? Это на заполнение карточки с надписью "Авария" столько уходит?


                                                                                      когда она уже устранена — вносить ее в канбан просто нет смысла.

                                                                                      Это если вы знаете только одну вещь которую можно сделать с аварией — ее устранить. Если с карточкой аварии можно сделать, что-то еще то оно может приобрести смысл.

                                                                                        –4
                                                                                        А зачем что-то делать с карточкой? Зачем вообще карточка? Нет, ну если очень хочется — наймите секретаршу и пусть она заполняет карточки. Может даже их разрисовывать в розовый цвет. Только отстаньте от инженеров со всей этой галиматьей.

                                                                                        Как правило, любители красивой отчетности и прочих карточек сами заменить инженера не смогут. И в его задачах не разберутся. А вот отсутствия «менеджера по карточкам» никто и не заметит.
                                                                                          +7
                                                                                          А зачем что-то делать с карточкой?

                                                                                          Инцидент должен быть представлен, в какой-то форме, например в электронной. Если он просто сообщается в устной форме то потом трудно будет искать какие-нибудь детали по нему.


                                                                                          Если он представлен в электронной форме, его можно называть "карточкой".


                                                                                          Кроме того, чтобы решить инцидент можно использовать карточку:


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

                                                                                          А вот отсутствия «менеджера по карточкам» никто и не заметит.

                                                                                          Я не знаю, кто такой "менеджер о карточкам". В вашей команде наверное все играют его роль, так как она небольшая?

                                                                                            0
                                                                                            «Менеджер о карточкам» в моей терминологии это любой бездельник из команды сервис-менеджмента.

                                                                                            Что до инцидентов, то обычно это идет или от мониторинга (тогда есть алерт и он является триггером), либо это приходит извне в виде тикета. В первом случае тикет скорее всего будет заведен уже сильно постфактум, ибо не до того.

                                                                                            Чтобы смотреть текущий статус, надо чтобы его кто-то обновлял — у инженеров на это нет времени во время работы над инцидентом.

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

                                                                                            Чтобы понять кто раньше это делал, у кого можно узнать детали — ну, есть два варианта: либо я, либо мой коллега :)

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

                                                                                            Как видите, никаких тяжелых решений тут абсолютно не нужно.
                                                                                              +1
                                                                                              Сами инженеры количеством 2 штуки таким функционалом по понятным причинам не пользуются.

                                                                                              Два этих уволились. Два новых пришли. Никаких «бортовых журналов» нет. Весь наработанный опыт по ремонту смыт в унитаз. Два новых начинают накапливать опыт с 0.
                                                                                                –1
                                                                                                По контракту отработка при увольнении — 3 месяца. Как раз хватит чтобы привести в порядок документацию, которая, кстати, вполне присутствует.
                                                                                                  +6
                                                                                                  Как находившийся с обоих сторон передачи дел после почти полной смены команды, нет не хватит. Все после большого инцидента думают что ничего не забили и сделают выводы, а через полгода все забывается и ничего никому не передается. После одной такой передачи объекта мне еще несколько лет звонили с вопросами о тайных знаниях, которые мы забыли передать потому что как раз-таки не вели никаких карточек аварий.
                                                                                                    +1
                                                                                                    3 месяца это круто! А новые работодатели в Германии тоже ждут по 3-4 месяца выхода нового сотрудника?
                                                                                                      +1
                                                                                                      Три месяца это более-менее принятая норма, которую часто пишут в контрактах как минимальную. По закону там зависит от того как долго вы работаете на фирме .

                                                                                                      И да, новые работодатели ждут. От профессии конечно зависит, но местами и даже дольше ждут.
                                                                                                        +1
                                                                                                        А это в обе стороны работает? Сотрудника тоже нельзя уволить уведомив менее чем за 3 месяца?
                                                                                                          0
                                                                                                          В линке что я привёл как раз таки описаны правила как фирма может увольнять струдников. Сотрудники по умолчанию должны подавать заявление минимум за четыре недели. Но это по умолчанию. Обычно в конктрактах прописаны либо тоже те самые три месяца, либо написано что у сотрудника сроки растут вместе со сроками фирмы.
                                                                                                            +3
                                                                                                            В обе, причем для работодателя условия даже хуже. По ссылке выше (ГК): проработал два года — за месяц, пять лет — за два месяца, восемь лет — за три месяца, и т.д. 20 лет — за семь месяцев. Это минимальные сроки, в договоре может стоять и больше. На прошлой работе, когда сменилось руководство и вообще почти вся стратегия, то двух начальников отдела (отделов?) «освободили от работы» (т.е. уволили с отстрочкой). От работы их отстранили, а зарплату будут еще до середины-конца 2021 платить.
                                                                                                          0
                                                                                                          Да. В зависимости от уровня в иерархии может быть и до полугода.
                                                                                                      +3
                                                                                                      Что до инцидентов, то обычно это идет или от мониторинга (тогда есть алерт и он является триггером), либо это приходит извне в виде тикета. В первом случае тикет скорее всего будет заведен уже сильно постфактум, ибо не до того

                                                                                                      То есть инцидент есть, а в систему он не заведен. Его как бы нет. А зачем так? Почему не создавать инцидент автоматически при возникновении триггера? По крайней мере, будет общая очередь и понятно, что после чего делать и кто чем занимается.


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


                                                                                                      Чтобы понять кто раньше это делал, у кого можно узнать детали — ну, есть два варианта: либо я, либо мой коллега :)

                                                                                                      А не может это еще быть пользователь, для которого важно решение инцидента, его руководитель и так далее?

                                                                                                        +1
                                                                                                        А не может это еще быть пользователь, для которого важно решение инцидента, его руководитель и так далее?
                                                                                                        Нет, не может. Мы не занимаемся пользователями, это задачи саппортов. Мы занимаемся инфраструктурой. К примеру, прилетел алерт от мониторинга о глобальной недоступности сервиса X. Или прилетел тикет о его частичной недоступности от кастомера Y.
                                                                                                          +1

                                                                                                          Вы ранее, если я не путаю, писали что есть еще заявки от пользователей — или им занимается не ваш отдел?


                                                                                                          Например, может быть такое, что с инфраструктурой что-то не так, а алерт не прилетел? Или алерт прилетел, но надо посмотреть что происходит в системе и приходится узнавать зачем пользователь Х запустил Y можно ли его сейчас прервать для перезагрузки и так далее.

                                                                                                            +1
                                                                                                            Пользователями занимаются другие сотрудники моего отдела.

                                                                                                            Например, может быть такое, что с инфраструктурой что-то не так, а алерт не прилетел? Или алерт прилетел, но надо посмотреть что происходит в системе и приходится узнавать зачем пользователь Х запустил Y можно ли его сейчас прервать для перезагрузки и так далее.
                                                                                                            Ну, не совсем так, но бывает: к примеру, приходит внутренний или внешний пользователь с проблемой «коннект к сервису Х есть, но такая-то функция не работает». Тогда заводится тикет и это прилетает нам (админам) на диагностику. Мы смотрим логи и либо подтверждаем проблему на стороне инфраструктуры, либо передаем ее на диагностику разработчикам, либо возвращаем обратно саппорту с комментарием «ошибка пользователя».
                                                                                                +3
                                                                                                Vengant
                                                                                                А откуда специалист узнал об аварии? А кем запрещено авто-тесты инфраструктуры и тикеты пользователей ставить сразу в канбан доску?

                                                                                                Но вот, к примеру наш недавний анекдот: отдел сервис-менеджмента начал катить на нас бочку за то, что по получению SMS от мониторинга о падении аплинков в ЦОД мы подорвались устранять аварию

                                                                                                Ну и кроме посылки в смс-шлюз прикрутите простановку тикета на доску.
                                                                                                Менеджеру сразу станет понятно, чем вы занимаетесь при взгляде на эту доску. (ну, должно, менеджеры бывают не алё.)

                                                                                                У меня висят таски 2-3 летней давности которые будут выполнены примерно никогда, потому что денег они уже не принесут и всегда есть более приоритетные задачи.

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

                                                                                                FlyingDutchman
                                                                                                И для бюрократии инцидентов Kanban ну никак не подходит, тут гораздо лучше старая добрая Jira управится

                                                                                                Канбан это методология/процесс работы.
                                                                                                Jira — это расширенный таск-трекер.
                                                                                                Ваше высказывание звучит как: «И для забивания гвоздей быстрые монотонные удары не подходят, с этим гораздо лучше молоток справляется»

                                                                                                  0
                                                                                                  Ну и кроме посылки в смс-шлюз прикрутите простановку тикета на доску.
                                                                                                  Менеджеру сразу станет понятно, чем вы занимаетесь при взгляде на эту доску. (ну, должно, менеджеры бывают не алё.)

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

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

                                                                                                  Нет, я не спорю что бывает и правильное употребление всех этих методологий. Но как по мне — в коллективе с двумя админами все это просто излишне, потому что keep it stupid simple.
                                                                                                    +3
                                                                                                    А у вашего менеджмента есть другие адекватные способы понять:
                                                                                                    1) «Сколько рабочего времени в месяц занимают аварии?»
                                                                                                    2) «Как часто случаются аварии с полным/средним/частичным отказом функционала?»
                                                                                                    3) В каких системах/подсистемах случаются?

                                                                                                      0
                                                                                                      Рабочее время у нас нигде не трекается и задачи его подсчета не стоит. Ну, кроме как для внештатных сотрудников на почасовой оплате, но там я не в курсе, этим HR занимаются.

                                                                                                      Аварии у нас автоматически подтягиваются из мониторинга в таблицу сервисов, где прекрасно видно, когда/сколько/где именно/как часто. Потом туда же еще и SLA прикрутили, чтобы при угрозе его нарушения сыпались уведомления.
                                                                                                        +1
                                                                                                        Рабочее время у нас нигде не трекается и задачи его подсчета не стоит.


                                                                                                        А потом…
                                                                                                        Инженер Равшан: «Надо бы ещё пару человек нанять, что-то работы много стало»
                                                                                                        Насяльнике (вспоминает, что все вроде и так работает, особо никто не жалуется ни на что): «Денег нет, но вы держитесь… Постараюсь выбить у Главного Насяльнике повышение зп в 1000р тебе и 500 твоему помощнику Джамшуту»
                                                                                                          0
                                                                                                          Да нет, почему. Сейчас вот третьего админа ищем, потому что работы и правда много стало. Копейки наша контора не считает — понимает, что потери в случае факапа будут куда больше.
                                                                                                      +1
                                                                                                      > Я отказываюсь понимать, зачем тут вообще менеджер.
                                                                                                      Думаю, зависит от проекта, и много где нужно. Например, пожар на SaaS — пока инженеры смотрят и чинят проблему в фоне происходит много вещей — нотификация клиентов, эскалация, нотификация саппорт тим и выработка стратегии что делать им. Клиенты жуть как не любят наблюдать 502 в браузере не понимая сколько времени починка займет — 10 минут или до вечера, у них бизнес зависит от вашего проекта. Если такое повторяется — повод вообще разорвать контракт, а будет высокий churn rate — нечем вам зп будет платить.
                                                                                                        0
                                                                                                        Согласен. Но в моем конкретном случае эта публика занимается исключительно процессами и траханьем мозгов тем, кто посмел на священную корову процессов покуситься. К примеру, ко мне прибежали ругаться за то, что тикет с запросом на доступ я закрыл с комментарием «доступ предоставлен». Оказывается, надо было написать, кому и куда дан доступ. Хотя это уже и так написано в самом тикете… Но у девочки-манагера в process manual сказано что при закрытии тикета надо это копипастить, и хоть ты тресни. Я конечно более или менее вежливо шлю всю эту публику куда подальше, но это тупо мешает работать.

                                                                                                        А вот менеджеры проектов у нас являются сотрудниками ИТ отдела и занимаются примерно как раз тем, что вы описали.
                                                                                                          +2
                                                                                                          > К примеру, ко мне прибежали ругаться за то, что тикет с запросом на доступ я закрыл с комментарием «доступ предоставлен»
                                                                                                          сочувствую, такое, конечно, раздражает.
                                                                                          0
                                                                                          Автор, а книгу «Проект Феникс» вы читали? Мне кажется или там похожая вашей ситуация описана?
                                                                                            0
                                                                                            Не читал.
                                                                                              +2
                                                                                              Рекомендую (ее везде полно и на русском и на английском), возможно вы увидите свою ситуацию со стороны в новом ключе.
                                                                                            +3
                                                                                            Крик отчаянья услышан. Хотелось бы мнения противоположной стороны.
                                                                                              +8
                                                                                              Мнение противоположной стороны:
                                                                                              image
                                                                                              0

                                                                                              Boomburum, пользуясь случаем, реквестирую одну из фич)


                                                                                              1. добавить в мобильную версию сайта хабы под названием статьи
                                                                                              2. в причины минусов к статье добавить "заголовок неинформативен или вводит в заблуждение"

                                                                                              Вот правда, очень полезно будет.

                                                                                                +2
                                                                                                Насчёт причины — вряд ли. Когда мы составляли список, там было под сотню вариантов — мы отобрали самые частые. Согласен, что иногда такие «абстрактные» заголовки не дают сразу понять, о чём речь, но всё же иногда за ними скрываются интересные статьи. Если же вы прочитали статью и ожидания не оправдались, то можно выбрать «Не узнал ничего нового», например.

                                                                                                Что касается хабов в мобильной версии — передал коллегам )
                                                                                                  +2

                                                                                                  А что выбирать когда пост плохому учит?

                                                                                                    0
                                                                                                    Как писал ниже, всех причин мы тут уместить не сможем, поэтому лучше пользоваться комментариями. А так, «Не тематика Хабра», например.
                                                                                                      +2

                                                                                                      Ну кто-то в комментарии написал, и хочет минус поставить, а какую причину он должен выбрать? Если выбирать "Другое", то информативность этого блока теряется. Большинство таких постов это тематика Хабра, но написано в них неправильно. Мне кажется, показатель того, сколько людей не согласно с автором, это хорошая обратная связь для автора.

                                                                                                    0

                                                                                                    За передачу коллегам спасибо!


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

                                                                                                      0
                                                                                                      Во-первых, об этом попапе со статистикой знают далеко не все — уже не раз встречал «а где вы посмотрели причины минусов? → ого» в комментариях. А, во-вторых, как я уже написал чуть ниже — комментарий для решения этой задачи подойдёт больше — там и мысль можно раскрыть, и плюсиков от других пользователей собрать, чтобы подкрепить сказанное. Например, вот эти наши комментарии автор поста уже наверняка прочитал и, возможно, сделал выводы, а в причины минусов мог даже не заглянуть.
                                                                                                        +1
                                                                                                        Ещё бы для кармы такое сделали. Сколько моя колебалась, так и не смог понять, почему это происходило. Притом в обе стороны.
                                                                                                          +1
                                                                                                          я обычно примерно представляю, за что мне прилетает
                                                                                                          но да, хотелось бы конкретики, а то какая-то странная критика получается, what_did_we_learn_palmer.jpg
                                                                                                            +1

                                                                                                            Самое занятное, что тренды по карме и по оценкам комментариев могут не совпадать. Совсем.

                                                                                                        +1

                                                                                                        Почему бы не дать вписать причину в свободной форме, раз уж у человека есть такое желание?

                                                                                                          +1
                                                                                                          Если в причинах минусов сделать возможность вводить свой текст, то там точно будут попадаться анонимные «автор идиот», что приведёт лишь к росту числа тикетов в суппорте. Да и зачем плодить сущности, если есть комментарии под постом и личка? В обоих местах можно не только вписать нужную причину, но и раскрыть мысль более подробно.
                                                                                                          +2
                                                                                                          мы отобрали самые частые

                                                                                                          Добавьте пожалуйста причину "Не согласен с изложенным".

                                                                                                            0

                                                                                                            А, и вдогонку, "Статья слишком короткая".

                                                                                                        +3
                                                                                                        Вы не уточнили, какой именно «Канбан» у вас пытались внедрять: методологию для разработки софта, или же Тойотовский «процесс бережливого производства». Впрочем, в Вашем случае что то, что другое полностью бесполезно, или, скорее, вредно, ибо совершенно не предназначено для вашей области деятельности.

                                                                                                        Описанная Вами ситуация далеко не уникальна, к сожалению. Зачастую менеджмент «ведется» на лживые обещания «продавцов технологий» (преследующих, естественно, свой личный интерес), модные тенденции и «тренды», а также «прогибается» ради карьерного роста.
                                                                                                          +1
                                                                                                          Не могу поддержать разговор про ITIL и ITSM, ибо не имел опыта, но не могу не спросить: а чем Канбан-то вам не угодил? Это ж не более чем правила, по которым организуется обработка входящих заявок.
                                                                                                          К вам же каким-то образом заявки в отдел попадают? Небось, от разных людей, и каждый из них говорит что «моя заявка самая супер-пупер приоритетная!». Вот правильно внедренный Канбан и позволяет упорядочить этот бардак.
                                                                                                            +1

                                                                                                            Причем поставщиком заявок может быть та же система мониторинга и по вполне понятным причинам инцидент "авария" влетает с максимальным приоритет, приостанавливая очередь рутинных задач, скажем, по обслуживанию инфры.

                                                                                                              +2
                                                                                                              Трудно гадать по переписке, но любое позитивное изменение можно загубить на корню, если навязать его директивно и в формате, не вписывающимся в устоявшиеся процессы в команде.

                                                                                                              Был свидетелем противоположного процесса, когда доски в Trello вирусно плодились по компании. Люди видели их у соседней команды, проникались идеей, заводили себе.
                                                                                                              +1

                                                                                                              И никто не сказал, что канбан-то не про то, как организовать работу в вашем отделе, а про то, как организовать работу нескольких отделов, где работа одного человека зависит от работы другого...


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


                                                                                                              image


                                                                                                              А это — нет, это — карго-культ доски с карточками:


                                                                                                              image

                                                                                                                +1
                                                                                                                И даже это не канбан )
                                                                                                                  0
                                                                                                                  Сделать (анализ)-> В работе(проектирование, дизайн, разработка)-> готово(тестирование, деплой, фидбэк). Или я что-то не так понимаю?
                                                                                                                    0
                                                                                                                    И никто не сказал, что канбан-то не про то, как организовать работу в вашем отделе,

                                                                                                                    Можно ссылку на источник этих сведений?


                                                                                                                    Мне, например удобно видеть "Готово" потому, что иногда по недавно сделанным задачам возникают какие-то вопросы и если на электронной доске есть последние сделанные карточки их просто найти.


                                                                                                                    Также мне непонятно, почему, анализ / проектирование/ дизайн должны быть обязательно разными отделами.

                                                                                                                      0

                                                                                                                      Это у вас не "готово" на самом деле, а "приём работы". Карточкам, по которым никаких работ больше не предполагается, делать на доске нечего. А если предполагаются, то так и должно быть написано, какие именно работы, а не абстрактное "готово".


                                                                                                                      Проблемы, которые решает канбан, находятся на стыке отделов. В контексте данного топика, отдел — это группа работников, решающая одного рода задачи.


                                                                                                                      it2manager ну да, не хватает по бэклогу между всеми колонками. Лучше картинки я не нашёл в гугле.


                                                                                                                      Gizmich вот вы и натянули сову на глобус.

                                                                                                                        0
                                                                                                                        Карточкам, по которым никаких работ больше не предполагается, делать на доске нечего.

                                                                                                                        Тут спорно. мне нравится, когда карточки из "готово" переводятся в "архив" на регулярной основе, в конце отчётного периода. Как-то демотивирует, когда не видишь по умолчанию сколько команда в целом или ты конкретно сделал.

                                                                                                                          0

                                                                                                                          Для этого есть более наглядные способы представления, чем "кажется в этом месяце кучка меньше, чем в предыдущем". Например, график скользящего среднего дневной продуктивности. Он помогает оперативно отслеживать провалы, а не только лишь в конце месяца.


                                                                                                                          ApeCoder вы будете держать на доске все когда-либо выполненные задачи на случай вдруг потребуется, что-то посмотреть? В канбане один человек разными колонками не занимается иначе вся суть канбана рушится. Каждая колонка — это конкретная группа исполнителей, выступающая для одной соседней колонки потребителем, а для другой — провайдером.

                                                                                                                            +1
                                                                                                                            вы будете держать на доске все когда-либо выполненные задачи на случай вдруг потребуется, что-то посмотреть?

                                                                                                                            Доска электронная она сама держит n последних задач. Если мне не хочется видеть, я эту колонку сворачиваю


                                                                                                                            Каждая колонка — это конкретная группа исполнителей, выступающая для одной соседней колонки потребителем, а для другой — провайдером.

                                                                                                                            Вы поделитесь источником этих сведений? Я, например, слышал наоборот, что это не личности а роли по отношению к конкретной задаче и команда может быть кроссфункциональной и, в частности, узкие места могут быть устранены тем что команда перераспледеляется между работами (программисты начинают тестировать, если тестировщиков в конкретный момент не хватает)

                                                                                                                              0

                                                                                                                              Это вы про скрам рассказываете. Канбан для кроссфункционального работника — это действительно не более чем бессмысленная ролевая игра в стикеры.

                                                                                                                                0

                                                                                                                                Не согласен. Если я вижу, например, что задач в колонке "готово к разработке" нет, то вполне могу переключиться на колонку "готово к код-ревью" или даже "новая" или "готово к тестированию" (если тест-кейсы есть готовые).

                                                                                                                                  0

                                                                                                                                  То есть весь ваш процесс выглядит так:


                                                                                                                                  • Есть что потестировать? Тестирую.
                                                                                                                                  • Есть что проревьючить? Ревьючу.
                                                                                                                                  • Есть что покодить? Кодю.
                                                                                                                                  • Есть что поразбивать на таски? Разбиваю на таски.

                                                                                                                                  Какую проблему в этом процессе может решить канбан?

                                                                                                                                    0

                                                                                                                                    Суть канбана — доводить максимальное количество задач до конца. Если у задачи этап "тестирование", то она еще далека от завершения (в целом), и соответственно — бизнес не получит от нее ценности (т.к. ценность имеют только полностью сделанные задачи). Поэтому если мы собираем матричную систему, то нам очевидно нужно в первую очередь доводить до конца задачи в правых столбиках. Если они заблокированы чем-то — можно переходить к следующим задачам (если вообще блок фактор мы не сможем снять за разумное время).
                                                                                                                                    Хотя, конечно, в целом, похоже реально на натягивание совы на глобус.

                                                                                                                                      0

                                                                                                                                      Суть канбана в выявлении заторов и провисаний между исполнителями и балансировке нагрузки на них. Он вообще не про задачи и их статусы.

                                                                                                                                        0

                                                                                                                                        При таком раскладе его удастся "натянуть" только на типовые задачи с четким флоу по этапам.
                                                                                                                                        Ну, и опять же — один человек может выступать в нескольких ролях (плохо, но это терпимо и если нет большой команды — это необходимость).
                                                                                                                                        Что точно вне контекста — как в такую систему загнать условные примеры работы с чужим СД (или даже своим внутри компании, но вне рамок "своего" отдела)

                                                                                                                                      +1
                                                                                                                                      Какую проблему в этом процессе может решить канбан?

                                                                                                                                      Доска отвечает на вопрос чем именно занимается команда и "есть ли что потестить"


                                                                                                                                      WIP отвечает на вопрос стоит ли сейчас помогать тем, кто тестирует обычно или лучше покодить.

                                                                                                                                        +1

                                                                                                                                        Грубо говоря, да.


                                                                                                                                        Канбан позволяет выявить ситуации, когда, например, тестировщики перегружены, а разработчики им помочь не могут.

                                                                                                                                      0

                                                                                                                                      Почему?

                                                                                                                                    +1
                                                                                                                                    В канбане один человек разными колонками не занимается иначе вся суть канбана рушится.

                                                                                                                                    у одного человека может быть несколько ролей. Т.е. канбан нужен, когда явно имеется процесс с несколькими этапами.

                                                                                                                                  0

                                                                                                                                  Источник вы не сообщили.


                                                                                                                                  Это у вас не "готово" на самом деле, а "приём работы". Карточкам, по которым никаких работ больше не предполагается, делать на доске нечего. А если предполагаются, то так и должно быть написано, какие именно работы, а не абстрактное "готово".

                                                                                                                                  Оно готово, но, например надо посмотреть какие-то детали для выполнения следующей задачи.


                                                                                                                                  В контексте данного топика, отдел — это группа работников, решающая одного рода задачи.

                                                                                                                                  Если один человек занимается разными колонками в канбане он меняет отделы в зависимости от текущей колонки?

                                                                                                                                  0

                                                                                                                                  Не должны быть обязательны, столбцы прежде всего показывают, что задачей занимается другой человек, отдел или даже компания. Если у вас один человек занимается анализом и проектированием без формального разбиения этих этапов "час тебе на анализ и день на проектирование", то отдельные столбцы не нужны. Канбан не регулирует содержание и количество столбцов.

                                                                                                                                0
                                                                                                                                Когда встречаю такие «возгласы» вопиющего, всегда удивляюсь: куча ненужной отчетности — это что? Отчет о проделанной работе с затраченным временем? Или что?
                                                                                                                                  0
                                                                                                                                  Пример: у нас в тикетной по настоянию отдела сервис-менеджмента появилась колонка «доказательство того, что проблема решена», обязательная к заполнению при закрытии заявок. Объяснить идиотам, что они идиоты, не вышло — поэтому все это тихо саботируется ИТ отделом путем копипасты в эту колонку любой дичи с потолка — благо девочка-проверяльщица тикетов ничего не понимает в том, чем мы занимаемся.
                                                                                                                                    0
                                                                                                                                    Большинство видов цифровых или не очень работ оставляют после себя артефакты(или должны оставить). «доказательство того, что проблема решена» звучит, конечно, хуже, чем «критерии завершенности», которые обязаны быть вообще везде, тем не менее, почему идиоты?
                                                                                                                                      0
                                                                                                                                      Окей, приведу пример. Мне прилетает алерт от мониторинга: «недоступен сервис Х».
                                                                                                                                      В ходе диагностики обнаруживается и устраняется сетевая проблема на виртуальной машине.
                                                                                                                                      Дальше я обязан завести тикет вида «инцидент», описать в нем что случилось и как это было устранено. И отдельно при закрытии тикета есть обязательное поле «доказательство того, что проблема решена». Какое, к черту, еще нужно доказательство? Нотариально заверенный скриншот мониторинга? В итоге туда пишется какая-нибудь откровенная дичь вида копипасты вывода «systemctl status xxx». Зачем и для кого — хрен его знает.
                                                                                                                                        +1

                                                                                                                                        Мне кажется, что возможны две крайности:


                                                                                                                                        1. либо ставящий задачу должен проверить ее выполнение и поставить флажок (вопрос в том, что он может забить на это)
                                                                                                                                        2. либо исполнитель закрывает задачу, а если проблема все еще есть — изначально постановщик задачи просто откроет повторный тикет )
                                                                                                                                          0
                                                                                                                                          а как вы проверяете, что сервис в итоге доступен, и проблема, которая вызвала его недоступность — устранена?
                                                                                                                                            0
                                                                                                                                            Вы не поверите — руками.
                                                                                                                                              0
                                                                                                                                              Я обычно делаю пинг, например. Но да, руками проще и тут уже не поспоришь — как такое доказать?:)
                                                                                                                                            0
                                                                                                                                            Чтобы понять, что работа была сделана в итоге, а не вас отвлекли на пол-дороги другой срочной задачей.
                                                                                                                                        0

                                                                                                                                        В том числе. Я вот несколько раз "заставил" руководство снять с меня этот отчёт, когда стал добавлять в него "составление этого отчёта".

                                                                                                                                          +1
                                                                                                                                          Если я пригласил человека, который делает мне ремонт, и который отказывается каждую неделю давать мне отчет о работах и материалах, который я подписываю и по которому я ему плачу деньги — я с таким человеком не работаю. Может у вас специфика другая, что люди вам просто так платят деньги?
                                                                                                                                            0

                                                                                                                                            Так я же не отказывался, просто стал включать время составления отчётов в сами отчёты. Видимо посчитали сколько им мои отчёты стоят и сколько пользы они от них получают.

                                                                                                                                        +1
                                                                                                                                        Многие комментаторы, без разбора, высказывают «за» бюрократизацию IT-процессов в организациях, отмечая отдельные плюсы и игнорируя картину в целом. Я согласен с автором статьи: РАЗМЕР ИМЕЕТ ЗНАЧЕНИЕ. Причём размер по всем измерениям: кол-во сотрудников всего, по отделам, по каждому техническому направлению, кол-во сетевых звеньев, сегментов, кластеров, элементов, километров, кабинетов, точек доступа, запросов в секунду, гигобайт в день и прочее, прочее.

                                                                                                                                        Насколько я понял, Vengant работает в режиме «дежурного ожидания», а в свободное от работы над аварией время выполняет плановые рутинные задачи. Для такого режима менеджмент инцидентов имеет смысл, но (обращаю внимание!) здесь необходимо разделение на менеджмент и деятельность по устранению инцидента.

                                                                                                                                        В классическом варианте «уж триста лет» для координации работ по базовой текущей деятельности и устранению ЧС, контролю времени, заполнению отчётности, докладов и др. использовалась должность «диспетчер». Именно он мониторил дески с индикаторами, заполнял бумажные тикеты, принимал голосовые траблы, отправлял мессаджи вверх и в стороны с указанием статуса и прогресса по таску привязанному к тикету. И это нормально работало: пожарные тушили, врачи лечили, работяги грузили, электричество в проводах, вода в трубах, гомно в отстойниках на очистных, начальство в курсе, отчётность в порядке.

                                                                                                                                        В организации у Vengant роль диспетчера на себя взял начальник. Но чаще всего, в рамках пресловутой оптимизации, предполагая что координация деятельности автоматически вытекает из применяемой методологии: канбан, скрам, аджил или уже забываемые три сигма, бережливое производство, стратегическое бюджетирование, ISO 9000 и т.п. роль диспетчера не предусматривается вовсе. Если анонсировали и получили добро на оптимизацию молодые перспективные магистры из академии Хогвартс, то отсутствие результатов будет объяснено неверным исполнением заклинаний (бизнес-процедур, регламентов, протоколов, инструкций) и банальным сопротивлением изменениям, которые нужно просто перетерпеть, продолжая настаивать на полном всеобъемлющем исполнении заклинаний.

                                                                                                                                        Бред — это совмещать в одном лице диспетчера, пилота и стенографиста. Но волшебники нашли метод. Рефрейминг: пилот это не тот кто управляет воздушным судном для перелёта из А в Б, а тот кто обеспечивает реализацию потребностей по воздушному перемещению. Отсюда регламент: пилот должен принять заявки желающих, согласовать маршрут со всеми участниками воздушного движения как до, так и в процессе полёта, одновременно составляя отчёт о всех деталях управления воздушным судном в этом полёте. Если используется методика парного программирования, то второй пилот должен делать то же самое. И если регулярный менеджмент в компании поставлен должным образом, то любой новый пилот изучив белую книгу сможет без потери качества обеспечивать воздушное перемещение.

                                                                                                                                        Внедрение методики опирающейся на регулярный протокол необходимо только в случаях разветвлённой административной иерархии, либо в случаях внешнего контроля и отчётности. Например, не разумно использовать на посту охраны систему менеджмента инцидентов, достаточно архива видеозаписей и логов кодового замка.

                                                                                                                                        Я не представляю себе ситуацию в фельдшерском пункте малого населённого пункта (или например в университете): «Гражданин МAC A0 находящийся в ETH22/PORT14 сообщает о сильных частых прерывистых болях в области сердца, сопровождающихся затруднением дыхания». Конечно, первым делом бюрократия: фельдшер оформляет в тикет-системе инцидент, там выскакивают SLA, категории, приоритеты, списки уведомлений и согласований. Если лица принимающие решения инцидент согласовали, то изменяем статус, и заполняем первичку (антропология и на что жалуемся), смотрим архив инцидентов по адресу, по гражданину, по жалобам. Изучаем историю что было — что стало. Сообщаем по списку уведомлений о том, что будет предпринято, и сколько это займет времени. Выслушиваем замечания и вносим их в карточку инцидента. Формируем заявку на ресурсы (транспорт, лекарства, средства защиты), получаем согласование на ресурсы. Не забываем вовремя менять статус инцидента. По прибытию на место обязательный фотоотчёт, sms-кой дополнения в тикет о различиях в состоянии гражданина ожидаемом и фактическом. Получение от финансистов подтверждения о возможности использования реанимационных действий если что-то при осмотре пойдет не так. Осмотр, диагностика, фотоотчёт по завершению. По приезду в фельдшерский пункт помимо карточки инцидента заполнение «белой» (красной, черной, оранжевой) книги (базы знаний для потомков) с анализом причин инцидента, хронологией развития ситуации, докладом о предпринятых мерах с планом намеченных мероприятий по недопущению таких ситуаций в будущем, с обязательной регистрацией в системе управления изменениями и установкой контрольных сроков по реализации этих мероприятий.

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

                                                                                                                                          не смешно. Фельдшер приступил к лечению пациента, а он откинул копыта (пациент, но может и фельдшер). По документам лечения не было. Кто виноват? Т.е. вся эта отчетность не нужна при условии прозрачности процессов и точного понимания кто за что ответственен. И как только появляется необходимость процесс урегулировать и отмазаться от ответственности — происходит его формализация, оссификация и бюрократизация. И сам дух деятельности теряется, его заменяет форма.

                                                                                                                                            +1
                                                                                                                                            Ну тогда и в IT не смешно. Админ приехал и после перезагрузки коммутатор «отбросил копыта». Ущерб, однако! И кто-то должен за него ответить. Поэтому, админу лучше не доехать до коммутатора, пусть самостоятельно «ласты склеивает», а это может быть очень долго, особенно на гарантированном питании.
                                                                                                                                              0
                                                                                                                                              Если админ не бил его ломом, а перегрузил штатной процедурой — то какие к нему могут быть вопросы?
                                                                                                                                                +1
                                                                                                                                                Ну, Stas911, ну дорогой, Вы даёте!
                                                                                                                                                Конечно же, прежде чем приехать было «триста» попыток перегрузить удалённо, но «чихает» железяка и лечению не поддается. А вот глаза в глаза, чисто из любви к результату, никакого лома — холодная перезагрузка по питанию — самое то. Либо счастье админу, либо смерть коммутатору.

                                                                                                                                                Кстати, думаю, что админ дописал в тикет через смс — «индикация не нормальная, uplink обмена не показывает». Подключил консоль, попытался выполнить вход через фирмовую утилиту, потом телнетом, ещё раз смс-ка «отклика на консоли нет». В поле «причина» смс-кой скинул «сбой прошивки, возможно зависание». Телефоном запросил разрешение на холодную перезагрузку. Получил ответ «на твое усмотрение исходя из обстоятельств». Попутно получил по е-майлу ответ из службы поддержки вендора коммутатора «По указанному ip нет отклика. Помочь не можем.». Еще смс-ка в тикет «ответ вендора». Далее автомат по питанию выкл-15сек-вкл. Всё! Можно писать в тикет «индикация питания — норма, индикации линков и обмена — нет.»

                                                                                                                                                Вопросы к админу: «Штатной процедурой холодная перезагрузка не предусмотрена» и кнопки «ресет» на коммутаторе нет. «Твоё усмотрение» от начальника, если «упала» централизованная бухгалтерия превращается в «я не предлагал перезагрузку, можете посмотреть лог инцидента».

                                                                                                                                                Так вот. К чему городить огород с протоколом инцидента в системе управления инцидентами, когда достаточно обыкновенного ПЛА, тем более в небольшой компании. Понятно что менеджерам будет не по себе, что такой древний и простой механизм эффективно работает, без волшебства.

                                                                                                                                                План Ликвидации Аварии (ПЛА), регулярно обновляемый, закрывает всю эту дрочь с он-лайн протоколизацией решения проблем. Появился в мониторинге сигнал о неполадках, взял в руки ПЛА и выполнил по пунктам. Для обыденной деятельности примитивный график технического обслуживания на год/полугодие/квартал в который начальники могут вносить дополнительные хотелки.

                                                                                                                                                Оказывается! Вместо нагромождения коммуникаций/записей/сообщений достаточно двух таблиц: Инциденты(Элемент системы, ДатаВремя регистрации, ДатаВремя устранения) и Техническое обслуживание (Элемент системы, Дата план, Дата факт), всё остальное можно сбросить в поле «примечания».
                                                                                                                                                  +1
                                                                                                                                                  Собственно после «Получил ответ «на твое усмотрение исходя из обстоятельств»» никакие претензии не принимаются. Вышестоящий начальник расписался в своем бессилии разрешить ситуацию и дал санкцию на любые действия исполнителя, которые тот считает верными.
                                                                                                                                          +2

                                                                                                                                          Как-то тема не раскрыта. В статье одни жалобы в режиме «все дураки, а я умный!»


                                                                                                                                          1. Какие именно процессы ITIL мешают вам жить?
                                                                                                                                          2. Чем условная Канбан доска прикрученная к тикетам в условной жире Вас не устраивает?
                                                                                                                                          3. После вашей выходки на тренинге были ли предприняты попытки от менеджмента предоставить Вам обратную связь и, к примеру, отправить на курсы по развитию soft skills? Понимаете ли Вы как подобное поведение трактуют ваши менеджеры?
                                                                                                                                            +1
                                                                                                                                            1. Жить мне мешают не процессы, а их конкретная реализация. Примеры я тут уже в комментариях приводил.

                                                                                                                                            2. Доска меня устраивает всем и по факту мы внутри отдела ею пользуемся (GitLab Boards) — но исключительно для тех задач, к которым это применимо, и в том объеме, который нам нужен. Не устраивала меня изначальная идея принудительно внедрить доску для всех задач и поставить следить за ней надсмотрщика из отдела сервис-менеджмента с правом вмешиваться во все подряд. Потому что на примере тикетной я уже видел, к чему это в конкретно нашей конторе приводит.

                                                                                                                                            3. После моей выходки и явной неготовности «тренера» отвечать на конкретные вопросы последовало мое предложение (в личку руководителю) не тратить мое рабочее время на неприменимую к моей работе дичь. Начальник согласился, и я с облегчением вернулся к своим непосредственным задачам. Как кто трактует мое нежелание фальшиво улыбаться и подыгрывать адептам карго культа, мне если честно все равно. Мне вполне хватает того, что мой непосредственный руководитель меня поддерживает, а директор компании адекватный человек и поддерживает моего руководителя.
                                                                                                                                              0
                                                                                                                                              Не устраивала меня изначальная идея принудительно внедрить доску для всех задач и поставить следить за ней надсмотрщика из отдела сервис-менеджмента с правом вмешиваться во все подряд.

                                                                                                                                              Ну то есть у вас были проблемы с тем что начальство вам хотело посадить надсмотрщика, а виноват почему-то оказался именно канбан? :)
                                                                                                                                                0
                                                                                                                                                А где я сказал что виноват канбан? Я сказал, что не нужно натягивать сову на глобус :) Чем, увы, занимается у нас руководство ради внешних ачивок.
                                                                                                                                            +1
                                                                                                                                            Я так понимаю, возможно заблуждаюсь, дело тут еще и в том что биржевая стоимость компании, которая внедрила у себя кучу новомодных техник, заметно выше чем та, у которой этого нет. Инвесторам это нравится, а значит оно должно быть внедрено, пускай даже в этом нет никакого практического смысла.
                                                                                                                                              +2
                                                                                                                                              Прочитав второй абзац надеялся на короткое внятное описание управленца на каком масштабе ITIL (ITSM) оправдано внедрять. Когда эта мода начиналась в кулуарах слышал, что 7-8 инженеров техподдержки и уже начинает работать. Ну а сам видел как это хромает на мелком масштабе.

                                                                                                                                                +2
                                                                                                                                                Могу только посочувствовать автору, но по теме хочу сказать следующее:
                                                                                                                                                1. ITIL/ITSM прекрасно работает при любом размере команды. Из личного опыта — 4 года работал в аутсорсинговой командой (на позиции Oracle DBA), в составе смены было 6 инженеров, 1 технический писатель и 3 менеджера (включая начальника подразделения и старшего смена) и ITSM практики прекрасно использовались и работали. Чтобы было понятно — количество систем исчислялось сотнями. Это была самая хорошо построенная и организованная работа за все 16 лет, что я работаю в ИТ.
                                                                                                                                                2. Все существующие практики не работают если их внедрять как есть, они все требуют адаптации.
                                                                                                                                                3. Как известно эффективные менеджера способны угробить всё что угодно.
                                                                                                                                                4. Канбан в том или ином виде можно использовать даже в одиночку.
                                                                                                                                                  +1
                                                                                                                                                  ITSM практики

                                                                                                                                                  конкретные практики, а не весь "стандарт"? Можете перечислить, что именно было внедрено?

                                                                                                                                                    0
                                                                                                                                                    Спасибо за пример. Выскажу предположение, что именно количество систем делало это возможным, ну и культура эксплуатации сложных систем. Хотя и 6 инженеров уже почти «много».

                                                                                                                                                    Я все-таки ощущаю что 3 человека ИТ отдел (а не 3 инженера техподдержки в нем) и условных 15 серверов и 150 ПК с типичноистеричными запросами «У меня тут что-то не работает» плохо на этот глобус натягиваются во всяком случае механистично внедряя itsm совместимую helpdesk систему.
                                                                                                                                                    +1
                                                                                                                                                    в наших масштабах все это только мешает, добавляя кучу ненужной отчетности, избыточной писанины ради писанины
                                                                                                                                                    Это везде у нас так. Самое грустное, что половина занимается абсолютно бессмысленной работой, но получает за нее зп, хотя могли бы заняться чем-то дельным
                                                                                                                                                      0
                                                                                                                                                      Не только у вас, а везде в мире. Называется «правило 80-20», расшифровывается, в отличие от излюбленных менеджерами формулировок, как «80% работы делается 20% сотрудников, а оставшиеся 20% — остальными 80% персонала».

                                                                                                                                                      Очень, очень много бездельников!
                                                                                                                                                        +2

                                                                                                                                                        Часто бывает, что первые 20% сотрудников не заставишь делать вторые 20% задач, а первые 80% задач вторые 80% сотрудников сделать просто не в состоянии.

                                                                                                                                                          0
                                                                                                                                                          Да, бывает и так. Что, опять-таки, говорит не о том, что бездельников в офисах нет, а о том, что менеджмент непрофессионален, и не умеет правильно организовать бизнес-процессы.

                                                                                                                                                          Мне довелось за свою жизнь работать в разных компаниях; редко, но бывало такое, что 80-20 «переворачивались» — как правило, в небольших стартапах с очень толковым и успешным менеджментом. Но в больших компаниях, как правило, работает так, как я описал выше.

                                                                                                                                                          Кстати, agile-методологии могут быть очень мощными и полезными, но только с некоторыми обязательными условиями:
                                                                                                                                                          — применяются они именно там, где и должны
                                                                                                                                                          — применяются они именно так, как и задумано, умными людьми с опытом
                                                                                                                                                          — agile-методы используются именно по прямому значению словосочетания, а не догматически.

                                                                                                                                                          Говорю об этом не понаслышке, и не теоретизируя: довелось поработать в коллективе, где без правильного scrum-а мы бы тупо загнулись, и завалили все, что можно (было очень мало ресурсов), а так еще и времени вагон иногда оставался.
                                                                                                                                                      +1
                                                                                                                                                      Иногда такие карго-системы внедряются перед продажей бизнеса. Эффективность работы в этом случае охотно приносится в жертву красивой отчётности. Чтобы представитель владельца мог в любой момент легко отбивать «каверзные» вопросы представителя покупателя вроде: а какие у вас показатели тут? а какие расходы там? При этом оба представителя могли бы не вникать в содержательную сторону деятельности — они же тоже наёмные универсальные менеджеры. Им нужны именно «показатели». Желательно «стандартные».
                                                                                                                                                        0
                                                                                                                                                        Тут https://habr.com/ru/post/433514/ есть статья на похожую тему.
                                                                                                                                                          0
                                                                                                                                                          Разумеется, в наших масштабах все это только мешает, добавляя кучу ненужной отчетности, избыточной писанины ради писанины, и порождая бесконечную войну технарей, которые хотят чтобы им дали спокойно работать, со всякими менеджерами, половина из которых молится на разведенную ими же бюрократию, а в ИТ вообще не понимает.

                                                                                                                                                          Это не только в вашей сфере. У нас в фармкомпаниях ровно та же ситуация: приходит «эффективный менеджер» на зарплату в 100500 тугриков и начинает создавать видимость работы, внедряя всяческие геолокации, отчёты и прочую мешающую работе полевых сотрудников лабуду. И у отдела IT работы прибавляется, а в общем на продажи это влияет только негативно. И виноват не этот «эффективный менеджер», а медпреды.
                                                                                                                                                            0

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

                                                                                                                                                            Only users with full accounts can post comments. Log in, please.