Комментарии 200
А почему руководство решило все это внедрять? Может, у них есть какие-то цели, которых они хотели этим достичь, и эти методы им показались наиболее правильными?
А некто во второй-третьей линии начальствующих решает укрепить свои позиции инициативами, берет красивые презентации, статистику популярности и готовится к повышению.
Была ситуация, когда некто писал кандидатскую про КПИ и приКПИшных чудесах, и тут-же экспериментировали на сотрудниках внедряя их в жизнь. Особенно забавно было смотреть, как искали/выдумывали эти показатели для разных групп сотрудников.
Сплошь и рядом такое…
Ну финансисты выкладывают деньги за что? Видимо, тот руководитель, который инициировал все это, что-то им пообещал?
Может им недостаточно предсказуемости вашей работы? Или SLA недостаточный? Или их идеи не реализуются?
Просто это как-то не по-финансистски, выделить деньги просто так, без цели.
Ну попросят у вас SLA — откуда вы его возьмете, придумаете из головы? А канбан позволяет SLA высчитать.
Это ваша точка зрения — что ITIL внедряется ради корочки. А с точки зрения бизнеса это упорядочивание непрозрачной работы админов, введение четких правил и процедур, на которые они могут ориентироваться при аудите, при планировании, при создании отчетов.
Мне если вдруг кажется, что сразу много людей занимаются не тем, чем надо, то я сразу настораживаюсь, потому что обычно это значит, что я не понимаю чего-то, а не то, что все другие вредители.
Как бы, есть такая штука как "должностные инструкции".
А все эти кабаны, скамы, и прочие ЕТИТЬ хитровыдуманые - мало того что пытаются заменить собой должностную инструкцию а значит избыточны, так еще и внесут путаницу(грубо говоря обязаности прописаны, некий ЕТИТЬ в чем то им противоречит но требуют его, и мы опять пришли к извечной дилеме о двух стульях).
Складывается впечатление, что некоторые непонимают, что управление работой — это тоже работа, и она тоже требует время и денег на своё выполнение.
Канбан это немножко не то. Представьте, что у вас та система где вы учитываете заявки будет визуализировать их в том числе в виде доски. Будет установлен четкий лимит сколько вы можете брать заявок в работу, а если их будет больше вы будете не брать новые пока их число не уменьшится.
Как тут не вспомнить присказку, что хороший админ — это тот, который играет контру, а не тот, у которого рожа в мыле. (при условии, что всё работает конечно)
Вот отдел. В нем 2 человека. Всего 4 руки. И если эти руки, вместо непосредственной работы, будут заполнять бесчисленные канбаны, производительность труда отдела упадёт.
Единственный профит для бизнеса (на примере сервис деска) — понимание того, что 10% юзеров генерирует 90% проблем. Так это, во-первых, очевидно для всех (как правило, кроме самого руководства), а во-вторых это в 99% случаев родственники этого самого руководства!
Насколько я понял они по факту выбрали сами пользоваться досками в итоге — т.е. заполнять их вручную или автоматически.
Единственный профит для бизнеса
А зачем вообще нужен канбан? С точки зрения его сторонников?
Канбан позволяет определять узкие места при выполнении многоэтапных задач. Например, что разработчики делают задачи быстрее чем тестировщики их тестируют.
не обязательно устранению, узкое место будет всегда. Узкое место надо передвинуть на ту операцию, которую вы можете легко регулировать, и тогда вы можете регулировать пропускную способность всей системы.
Конечно, если вспомнить книгу Голдратта, то когда система начала справляться со всем входящим потоком и всеми заявленными целями, они объявили узким местом цели компании и канал продаж. У меня так в какой-то момент багфикс легаси продукта превратился в его рефакторинг, когда кончились все баги, что можно починить без него.
В идеале узкого места быть не должно, у всех этапов пропускная способность должна быть равной скорости входа задач.
Сложный вопрос. В идеале есть два чувака, которые работают в паре. И нагрузка по ним распределяется по 50%. Все освободившееся время от рутины они тратят на улучшение процессов и работу на перспективу. Все счастливы. Проблема только в том, что это дорого, и это могут позволить себе либо стартапы, которые жгут деньги инвесторов, либо технологические компании. Остальные — жестко экономят ФОТ, в результате нагрузка на одного составляет 100-150-200%
Ну в таких условиях просто на всех этапах равная пропускная способность, чтоб нагрузка равно распределялась. Хотя, конечно, бывает, что разработчики по 8 часов работают, а тестировщики по 12 тестируют, чтоб не накапливались задачи "готово к тестированию". Но формально количество задач в сутки одинаково, узеи мест нет:(
. И если эти руки, вместо непосредственной работы, будут заполнять бесчисленные канбаны, производительность труда отдела упадёт.
Так «эти руки» как раз таки ничего заполнять и не должны. Канбан это грубо говоря система тикетов, которая имеет определённые правила. То есть вещи вроде «нельзя одновременно обрабатывать больше чем Х тикетов» или «Если статус у тикета из категории А не меняется Y дней, то на него надо повнимательнее посмотреть».
И вопрос в том как вообще сейчас организованы процессы в этом отделе. Ну то есть какие у них задания, кто их даёт, кто и как распределяет, кто оценивает объём работ, кто и как отчитывается о проделанной работе и т.д. и т.п. И только тогда уже можно думать надо там что-то менять и если надо, то канбан там нужен или что-то другое.
Суть как раз в том, что чем больше в компании сотрудников, тем активней система подавляет обратную связь от конечных исполнителей. И это что-то на уровне древней психологии стаи обезьян, а не заговора рептилоидов.
А во вторых тикеты по хорошему должны заполнять конкретно те кому что-то нужно от админов. В конце-концов сейчас же админы откуда-то задания получают. Неужели они их исключительно сами себе придумывают?
А во вторых тикеты по хорошему должны заполнять конкретно те кому что-то нужно от админов. В конце-концов сейчас же админы откуда-то задания получают. Неужели они их исключительно сами себе придумывают?
Вы правда не понимаете различий между скрамом, карточками канбан и сервис-деском?
То, что вы сейчас упомянули — это ТИКЕТ в сервис-деск, который должен заполнить пользователь, чтобы получить УСЛУГУ от отдела ИТ.
Карточки канбан это внутренние дела отдела ИТ, заводятся тогда, когда задача (карточка) имеет более одного этапа работы и/или отрабатывается несколькими людьми/отделами.
Так вот, возвращаясь к сервис-деску, 99% неудачных внедрений SD из-за того, что юзеры НЕ ЖЕЛАЮТ сами ничего заполнять, им ПРОЩЕ позвонить/прийти, чем формулировать своё мычание «тут у меня это, в полу подземный стук».
Вы правда не понимаете различий между скрамом, карточками канбан и сервис-деском?
Я бы сказал что это вы не понимаете что при нормальном тулинге и нормально поставленных процессах эти самые «внешние» тикеты/таски/задачи превращаются во «внутренние» банально одним нажатием кнопки или даже автоматом.
Да и вообще вас никто не заставляет таски в канбане держать в виде бумажных карточек. Делайте это всё в электронном виде, в чём проблема? Или у вас админы вообще без всяких тасков/тикетов работают и просто делают что им сказали мимо проходящие люди?
Так вот, возвращаясь к сервис-деску, 99% неудачных внедрений SD из-за того, что юзеры НЕ ЖЕЛАЮТ сами ничего заполнять, им ПРОЩЕ позвонить/прийти, чем формулировать своё мычание «тут у меня это, в полу подземный стук».
То что там кому-то что-то проще совсем не означает что им это надо позовлять так делать. Ну а если уж позволяете, то тогда наверное не стоит и жаловаться что админы работать не успрвают потому что им надо «карточки заполнять».
> Карточки канбан это внутренние дела отдела ИТ
они вполне могут приходить снаружи, от других отделов — дать/забрать доступ, чтонибудь насетапить и тп
На самом деле нет :-)
«По учебнику» это называется «запрос на изменение» и является стандартным процессом в сервис-деске. То, что этот процесс можно натянуть на канбан и реализовать в виде карточек, не значит что это правильно и оптимально.
Это не совсем так. Производительность даже двух рук зависит от головы, от того, что и когда в эти руки дают. Я сам свидетель истории, когда выстроенный процесс увеличил производительность команды почти в три раза без каких-либо кадровых изменений.
Я сам свидетель истории, когда выстроенный процесс увеличил производительность команды почти в три раза без каких-либо кадровых изменений
Это всего лишь значит, что в результате пересмотра бизнес-процессов часть задач принято решение делать чужими руками. Увы, волшебных пилюль не бывает и обычно «выстраивание процесса» сводится к анекдоту, когда сенокосцу на лоб цепляют фонарик, а к заднице грабли.
PS: Возможно я где-то излишне пессимистичен в оценках, но сейчас я переживаю момент, когда у руля производственной компании оказались мало того, что гуманитарии, так еще и маркетологи с коучингом на всю голову и в целом мы стремительным домкратом несёмся в успешный-успех.
Я сожалею по поводу вашей ситуации, но не соглашусь с вашим первым утверждением: результат был достигнут не за счет "чужих рук", а за счет уменьшения простоя, уменьшения частоты переключения контекста, и за счет использования более удобных инструментов. И первые два пункта были достигнуты исключительно за счет улучшения процесса.
Просто приоритетами можно увеличивать производительность за счёт группировки задач по контекстам, за счёт минимизации количества переключений.
управление работой — это тоже работа, и она тоже требует время и денег на своё выполнение.
Золотые слова! Эффект рекурсивной ловушки в чистом виде. Потом появляется управление управлением работой, а потом управление управлением управлением…
В 15 веке в Англии было 50 тысяч военных кораблей, а в адмиралтействе работало 5 человек. И справлялись.
В 19 веке кораблей осталось 500, зато в Адмиралтействе работало уже 5 000 чел. И справлялись с работой с большим напряжением.
Сейчас от военного флота осталось 5 кораблей, зато в Адмиралтействе работает уже 50 000 человек и не справляются с работой совсем.
50 тысяч военных кораблей? Да не может быть так много!
Ровно такое же есть желание не тратить собственные усилия на то, чтобы помогать другим людям выполнять их KPI.
Хотят — пусть выполняют. Не хотят — пусть не выполняют. Хотят, чтобы я им помогал — пусть мотивируют. Можно деньгами, можно статусом, можно блестящей игрушкой. Если кто-то хочет, чтобы я занимался унылым, скучным, непрестижным забесплатно, то я не могу запретить ему хотеть. Но и помогать в исполнении желаний тоже не буду.
Можно попробовать от противного — заставить под угрозой увольнения.
Но, повоторю, если кто-то хочет, чтобы я занимался скучным, неинтересным, непрестижным под угрозой увольнения, то он может попробовать. А я могу стряхнуть пыль с резюме в ответ.
абсолютно нормальное желание у менеджмента знать за что вам и вашим коллегам платят деньги
Абсолютно глупое желание. Если у тебя, как у менеджера, есть цели и задачи — именно за них и нужно платить. Не нужно "знать, за что платишь", нужно "платить, за то, что требуется". А если ты не знаешь, что требуется, спроси у того, кто знает.
Контроль и прозрачные процессы нужны для того, что бы проверить, делается ли то, что требуется.
«для отчета» или «потому что модно»
видимо, поэтому
— руководители в кои то веки решили выделить денег — обучить сотрудников
— возможно они выбрали не лучшего тренера и не лучшую методику,
внимание вопрос, что сделает наш Васян?
1. постарается извлечь максимум пользы даже их среднего материала с плохой подачей
2. изо всех сил будет показывать руководству что они, которые ему деньги платят и, видимо, хотят вкладывать — тупые, а он Вася — умный?
При этом IT отдел для себя сделал выводы и стал юзать GitLab Boards — это действительно удобно. Но только когда все это — внутренний инструмент, который контролируется начальником отдела, понимающим кто чем занимается, а не девочкой с гуманитарным образованием, не отличающей ping от fuck.
У нас была своя система учета рабочего времени — в тебя бросают куском работы, ты говоришь крайний срок когда будет готова (ну или за тебя решает руководитель). Далее задача билась на подзадачи и в систему вписывалось фактическое время выполнения подзадач. По итогу руководитель знал среднее время выполнения работ по всем и каждому, что давало возможность оценивать сроки с +- адекватной погрешностью.
Но тут решили внедрять… сначала добавили ежемесячный отчет о том что сделано. Потом воткнули одну популярную CRM и обязали ставить там таски, запускать трекеры времени и пр. в общем использовать как таск-трекер.
По итогу я теперь пишу отчеты в 4 (ЧЕТЫРЕ) мать их системы. Одна для финансистов, вторая для планирования, третья в опытной эксплутации, но без заполнения четвертой не работает.
Вишенка на торте что в одной из систем нельзя проставить затраченное время «задним» числом(только кнопки старт и стоп). На мой вопрос — что делать с прерываниям, т.е когда мне звонит заказчик и я выпадаю на час разговоров, никто ничего ответить не может.
На фоне всего этого проталкивают канбан. Который хорошо работает на поточном производстве, но нифига не работает на штучном. У меня висят таски 2-3 летней давности которые будут выполнены примерно никогда, потому что денег они уже не принесут и всегда есть более приоритетные задачи. Но таски висят снижая мою «эффективность». Раз в полгода на очередном совещании девочка-приносит отчет по сотрудникам и начинается «А что это мы на задачи забиваем?»
Эти висячие задачи надо закрывать с каким-нибудь комментарием "obsoleted by...". И не волнует. Если надо — визу руководителя. Все счастливы.
Ну, действительно. Скажем, была задача "обновить хх до версии уу". А потом вышла версия zz > yy. Появилась задача "обновить хх до версии zz". Вы ее и сделали, а первую можно утилизировать.
Сроки были сжатыми, а объемы конскими. В нормальном режиме на разработку и изготовлении такой системы требуется около 9 месяцев. Мы сделали за 3.
Плюс в процессе участвовала еще пачка организаций согласующих и будущая эксплуатация. В процессе изготовления творился некоторый хаос уровня отправляем документацию в производство и согласование в параллель, тут бац что-то не подошло, меняем на месте, отправляем замечание, подрядчик правит, цикл повторяется N раз. Важный нюанс документация имеет нелинейные ссылки. И за всем уследить довольно тяжко.
По итогу систему сдали, отгрузили, документацию (600+ документов) отправили в архив. Через год провели аудит и выяснили, что отсутствуют 6(10) чертежей. Все эти
документы заказчику не отправлялись (не входили в договор), на эксплуатацию не влияют и нужны ТОЛЬКО для повторного изготовления. Мой 12 летний опыт говорит что мы еще НИ РАЗУ не делали 2 одинаковые системы. НИ_РА_ЗУ. О чем это я? А! Архив поставил задачу — сдать документы. Логично, чё, у них там тоже аудиты и проверки.
Задача прилетела мне — написал подрядчику, мол так и так дошлите пожалуйста. Подрядчик отморозился тем что договор закрыт, деньги получены и вообще мы вам все выдали.
Ну зашибись, действительно часть 3D-моделей есть, а чертежей (оформленных) нет. Даю оценку по времени и ресурсам, иду к руководителю отдела, мол вот таска. Получаю закономерный ответ: «к черту, сейчас важнее <проект_нейм>, сделай когда будет свободное время». Ну а дальше наступило сегодня.
Вот и получается, что я то задачу закрою, но через год при очередном аудите архив снова ее поставит, девочка опять будет вещать про невыполненные задачи, мы будем смотреть на менеджмент и спрашивать «да без проблем, бросаем все и делам?»,
менеджеры будут хмуриться, зыркать на девочку и говорить о том что срыв сроков по текущим проектам недопустим ибо штрафы.
Как итог: де юре, мы должны все бросить и выполнить таски. Де факто, это никому не нужно, ни нам, ни менеджменту, ни заказчику. Таска висит, денег(времени) не выделяют.
P.s. Можно было бы сказать что это нужно архиву, но они могли бы закрыться перед аудиторами бумажкой вида «утеряно при переезде».
Дано:
Васян - каой-никакой а специалист в своей области.
Васяну виднее КАК сделать хорошо.
Васяна заставляют делать не хорошо а красиво(причем не результат а сам процесс) и не то что он должен. Обмазывают несвежими отчетами и заставляют наяривать свой KPI.
Теперь васян кроме прямых обязанностей развлекает манагеров как цирковая собачка.
Вопрос: Почему Васян против?
Вы не поверите, но Канбан даже в семье, в домашних делах, улучшает продуктивность. :)
Расскажите, пожалуйста! Я интуитивно понимаю, что это должно помочь, но как именно, хотелось бы подробностей.
Полагаю, там по факту ремонты-закупки-переделки заносятся? Но фантазия сразу попыталась представить Канбан с задачами вида "отвлечь ребёнка чтоб мама подремала" и "супружеский долг"...
План по ЧП — это уже какой-то Machine Learning получается ))
Но вот, к примеру наш недавний анекдот: отдел сервис-менеджмента начал катить на нас бочку за то, что по получению SMS от мониторинга о падении аплинков в ЦОД мы подорвались устранять аварию. А надо было, оказывается, сначала завести тикет, описать что случилось, потом создать emergency change, и только потом поднимать упавшую сеть. Не забывая в процессе писать в тикетную записки из горящего танка. Дискуссия была закончена предложением начальника IT «тогда наймите нам секретаршу» :)
Change management внедрили глобально во всей конторе. И нас тоже заставили играть в эту игру. Например, на каждое изменение любой строчки конфига прода надо завести «Standard Change». Сами заводим, сами пишем туда что-то от фонаря, сами закрываем. Для кого? А хрен его знает.
Естественно, периодически на это забивается болт, когда само изменение занимает времени меньше, чем заведение того тикета. И естественно, в случае проблем я просто спрашиваю коллегу, не делал ли он чего с продом — потому что искать что-либо в тикетной удовольствие крайне долгое и сомнительное.
А у вас есть примеры успешного Change management на таких масштабах?
Всё вышеописанное — с натуры. В общем, или давайте обратную связь, или ищите другое место работы, а на Хабре жаловаться бессмысленно, особенно на фирму в Германии.
оказывается, сначала завести тикет, описать что случилось, потом создать emergency change, и только потом поднимать упавшую сеть
Это очень странно. Либо вы не договариваете, либо у вас там действительно не очень профессиональные коллеги.
Если упала сеть и если это классифицируется как критичный инцидент (что может быть не всегда так), то лучшие практики (которые писали не дураки) прямо так и говорят — сначала ремонтируем, потом оформляем тикет. Но не каждый инцидент требует изменений для своего разрешения. Если же требуется экстренное изменение, то очень часто оно проводится так же, как и разрешение критичного инцидента — сначала делаем, потом записываем. Но почему важно держать в голове такую декомпозицию — потому что запрос на изменение содержит в себе указание на затрагиваемые системы и план отката. Если об этом не подумать, то можно довольно криво экстренно наизменять. Так что потом и фиксировать особо нечего будет.
Но у нас упорно тянут сову на глобус, даже в ущерб эффективности устранения инцидентов.
для бюрократии инцидентов Kanban ну никак не подходит
Почему?
А почему вы решили что канбан этого требует?
Насколько я знаю, там просто живая очередь работ (в отличие, от, например, скрама, где есть спринты).
Еще раз: откуда взялись три дня? Это на заполнение карточки с надписью "Авария" столько уходит?
когда она уже устранена — вносить ее в канбан просто нет смысла.
Это если вы знаете только одну вещь которую можно сделать с аварией — ее устранить. Если с карточкой аварии можно сделать, что-то еще то оно может приобрести смысл.
Как правило, любители красивой отчетности и прочих карточек сами заменить инженера не смогут. И в его задачах не разберутся. А вот отсутствия «менеджера по карточкам» никто и не заметит.
А зачем что-то делать с карточкой?
Инцидент должен быть представлен, в какой-то форме, например в электронной. Если он просто сообщается в устной форме то потом трудно будет искать какие-нибудь детали по нему.
Если он представлен в электронной форме, его можно называть "карточкой".
Кроме того, чтобы решить инцидент можно использовать карточку:
- чтобы посмотреть текущий статус и не отвлекать инженера от этого
- чтобы посмотреть как подобные инциденты были решены ранее
- чтобы понять кто раньше это делал, у кого можно узнать детали
- чтобы агрегировать данные по инцидентам, посмотреть какие области наиболее подвержены инцидентам и с цифрами предложить какие-то решения по предотвращению дальнейших инцидентов
А вот отсутствия «менеджера по карточкам» никто и не заметит.
Я не знаю, кто такой "менеджер о карточкам". В вашей команде наверное все играют его роль, так как она небольшая?
Что до инцидентов, то обычно это идет или от мониторинга (тогда есть алерт и он является триггером), либо это приходит извне в виде тикета. В первом случае тикет скорее всего будет заведен уже сильно постфактум, ибо не до того.
Чтобы смотреть текущий статус, надо чтобы его кто-то обновлял — у инженеров на это нет времени во время работы над инцидентом.
Чтобы посмотреть как подобные инциденты были решены ранее — нужно чтобы это было кем-то востребовано. Сами инженеры количеством 2 штуки таким функционалом по понятным причинам не пользуются. А менеджеры не имеют профильной квалификации, поэтому ничего не поймут, даже если я им напишу, как что устранялось.
Чтобы понять кто раньше это делал, у кого можно узнать детали — ну, есть два варианта: либо я, либо мой коллега :)
Чтобы агрегировать данные по инцидентам, посмотреть какие области наиболее подвержены инцидентам и с цифрами предложить какие-то решения по предотвращению дальнейших инцидентов — как правило есть ежемесячные митинги внутри отдела, на которых разбираются причины имевших место быть аварий и вырабатываются методы их недопущения.
Как видите, никаких тяжелых решений тут абсолютно не нужно.
И да, новые работодатели ждут. От профессии конечно зависит, но местами и даже дольше ждут.
Что до инцидентов, то обычно это идет или от мониторинга (тогда есть алерт и он является триггером), либо это приходит извне в виде тикета. В первом случае тикет скорее всего будет заведен уже сильно постфактум, ибо не до того
То есть инцидент есть, а в систему он не заведен. Его как бы нет. А зачем так? Почему не создавать инцидент автоматически при возникновении триггера? По крайней мере, будет общая очередь и понятно, что после чего делать и кто чем занимается.
По остальному — лично я не смогу через неделю уже сказать точно, чем я занимался и сколько времени потратил. Либо вы не такой как я и все очень хорошо помните, либо какие-то детали со временем теряются.
Чтобы понять кто раньше это делал, у кого можно узнать детали — ну, есть два варианта: либо я, либо мой коллега :)
А не может это еще быть пользователь, для которого важно решение инцидента, его руководитель и так далее?
Нет, не может. Мы не занимаемся пользователями, это задачи саппортов. Мы занимаемся инфраструктурой. К примеру, прилетел алерт от мониторинга о глобальной недоступности сервиса X. Или прилетел тикет о его частичной недоступности от кастомера Y.
Вы ранее, если я не путаю, писали что есть еще заявки от пользователей — или им занимается не ваш отдел?
Например, может быть такое, что с инфраструктурой что-то не так, а алерт не прилетел? Или алерт прилетел, но надо посмотреть что происходит в системе и приходится узнавать зачем пользователь Х запустил Y можно ли его сейчас прервать для перезагрузки и так далее.
Например, может быть такое, что с инфраструктурой что-то не так, а алерт не прилетел? Или алерт прилетел, но надо посмотреть что происходит в системе и приходится узнавать зачем пользователь Х запустил Y можно ли его сейчас прервать для перезагрузки и так далее.
Ну, не совсем так, но бывает: к примеру, приходит внутренний или внешний пользователь с проблемой «коннект к сервису Х есть, но такая-то функция не работает». Тогда заводится тикет и это прилетает нам (админам) на диагностику. Мы смотрим логи и либо подтверждаем проблему на стороне инфраструктуры, либо передаем ее на диагностику разработчикам, либо возвращаем обратно саппорту с комментарием «ошибка пользователя».
А откуда специалист узнал об аварии? А кем запрещено авто-тесты инфраструктуры и тикеты пользователей ставить сразу в канбан доску?
Но вот, к примеру наш недавний анекдот: отдел сервис-менеджмента начал катить на нас бочку за то, что по получению SMS от мониторинга о падении аплинков в ЦОД мы подорвались устранять аварию
Ну и кроме посылки в смс-шлюз прикрутите простановку тикета на доску.
Менеджеру сразу станет понятно, чем вы занимаетесь при взгляде на эту доску. (ну, должно, менеджеры бывают не алё.)
У меня висят таски 2-3 летней давности которые будут выполнены примерно никогда, потому что денег они уже не принесут и всегда есть более приоритетные задачи.
С точки зрения канбана, их надо было выкинуть с доски куда-нибудь в бэклог ровно в тот момент, когда стало понятно что денег они уже не принесут.
FlyingDutchman
И для бюрократии инцидентов Kanban ну никак не подходит, тут гораздо лучше старая добрая Jira управится
Канбан это методология/процесс работы.
Jira — это расширенный таск-трекер.
Ваше высказывание звучит как: «И для забивания гвоздей быстрые монотонные удары не подходят, с этим гораздо лучше молоток справляется»
Менеджеру сразу станет понятно, чем вы занимаетесь при взгляде на эту доску. (ну, должно, менеджеры бывают не алё.)
Я отказываюсь понимать, зачем тут вообще менеджер. Он никак не участвует в устранении аварии. Он не может мне отдавать прямых распоряжений, ибо не является моим начальником. Он даже не является техническим специалистом и поэтому не понимает сути аварии.
Вот что он хорошо умеет делать — это трахать мозг на тему, почему я во время аварии не бросил все и не побежал заполнять тикеты для бога тикетов, расписывая все в деталях непонятно для кого.
Нет, я не спорю что бывает и правильное употребление всех этих методологий. Но как по мне — в коллективе с двумя админами все это просто излишне, потому что keep it stupid simple.
1) «Сколько рабочего времени в месяц занимают аварии?»
2) «Как часто случаются аварии с полным/средним/частичным отказом функционала?»
3) В каких системах/подсистемах случаются?
Аварии у нас автоматически подтягиваются из мониторинга в таблицу сервисов, где прекрасно видно, когда/сколько/где именно/как часто. Потом туда же еще и SLA прикрутили, чтобы при угрозе его нарушения сыпались уведомления.
Рабочее время у нас нигде не трекается и задачи его подсчета не стоит.
А потом…
Инженер Равшан: «Надо бы ещё пару человек нанять, что-то работы много стало»
Насяльнике (вспоминает, что все вроде и так работает, особо никто не жалуется ни на что): «Денег нет, но вы держитесь… Постараюсь выбить у Главного Насяльнике повышение зп в 1000р тебе и 500 твоему помощнику Джамшуту»
Почему бы манагеру и не бегать опрашивать\вести учет?
А вот менеджеры проектов у нас являются сотрудниками ИТ отдела и занимаются примерно как раз тем, что вы описали.
Вот что он хорошо умеет делать — это трахать мозг на тему, почему я во время аварии не бросил все и не побежал заполнять тикеты для бога тикетов, расписывая все в деталях непонятно для кого.
Вот может быть так и надо было поступить?
Если это соотносится с контрактом, должностной инструкцией и так далее.
Пусть бизнес увидит что у них грубо говоря серваки лежали 40 минут а не 2-5 потому что "нескучные отчеты".
С другой стороны, если этого нет в должностных инструкциях и так далее, не идет ли манагер-извращенец лесом(у него нет власти над тобой)?
Я к тому что важнее сакрального вопроса о том "кто пипидастр" - вопрос юридический.
Boomburum, пользуясь случаем, реквестирую одну из фич)
- добавить в мобильную версию сайта хабы под названием статьи
- в причины минусов к статье добавить "заголовок неинформативен или вводит в заблуждение"
Вот правда, очень полезно будет.
Что касается хабов в мобильной версии — передал коллегам )
А что выбирать когда пост плохому учит?
Ну кто-то в комментарии написал, и хочет минус поставить, а какую причину он должен выбрать? Если выбирать "Другое", то информативность этого блока теряется. Большинство таких постов это тематика Хабра, но написано в них неправильно. Мне кажется, показатель того, сколько людей не согласно с автором, это хорошая обратная связь для автора.
За передачу коллегам спасибо!
Что же до причин — мне просто кажется, что хабр как то их уж очень забит стал желтушным заголовками, и хотелось бы этот момент до авторов донести статистикой.
Почему бы не дать вписать причину в свободной форме, раз уж у человека есть такое желание?
мы отобрали самые частые
Добавьте пожалуйста причину "Не согласен с изложенным".
Описанная Вами ситуация далеко не уникальна, к сожалению. Зачастую менеджмент «ведется» на лживые обещания «продавцов технологий» (преследующих, естественно, свой личный интерес), модные тенденции и «тренды», а также «прогибается» ради карьерного роста.
К вам же каким-то образом заявки в отдел попадают? Небось, от разных людей, и каждый из них говорит что «моя заявка самая супер-пупер приоритетная!». Вот правильно внедренный Канбан и позволяет упорядочить этот бардак.
Причем поставщиком заявок может быть та же система мониторинга и по вполне понятным причинам инцидент "авария" влетает с максимальным приоритет, приостанавливая очередь рутинных задач, скажем, по обслуживанию инфры.
Был свидетелем противоположного процесса, когда доски в Trello вирусно плодились по компании. Люди видели их у соседней команды, проникались идеей, заводили себе.
И никто не сказал, что канбан-то не про то, как организовать работу в вашем отделе, а про то, как организовать работу нескольких отделов, где работа одного человека зависит от работы другого...
Вот это канбан (разве что последняя колонка бессмысленна — выполненная карточка просто снимается):
А это — нет, это — карго-культ доски с карточками:
И никто не сказал, что канбан-то не про то, как организовать работу в вашем отделе,
Можно ссылку на источник этих сведений?
Мне, например удобно видеть "Готово" потому, что иногда по недавно сделанным задачам возникают какие-то вопросы и если на электронной доске есть последние сделанные карточки их просто найти.
Также мне непонятно, почему, анализ / проектирование/ дизайн должны быть обязательно разными отделами.
Это у вас не "готово" на самом деле, а "приём работы". Карточкам, по которым никаких работ больше не предполагается, делать на доске нечего. А если предполагаются, то так и должно быть написано, какие именно работы, а не абстрактное "готово".
Проблемы, которые решает канбан, находятся на стыке отделов. В контексте данного топика, отдел — это группа работников, решающая одного рода задачи.
it2manager ну да, не хватает по бэклогу между всеми колонками. Лучше картинки я не нашёл в гугле.
Gizmich вот вы и натянули сову на глобус.
Карточкам, по которым никаких работ больше не предполагается, делать на доске нечего.
Тут спорно. мне нравится, когда карточки из "готово" переводятся в "архив" на регулярной основе, в конце отчётного периода. Как-то демотивирует, когда не видишь по умолчанию сколько команда в целом или ты конкретно сделал.
Для этого есть более наглядные способы представления, чем "кажется в этом месяце кучка меньше, чем в предыдущем". Например, график скользящего среднего дневной продуктивности. Он помогает оперативно отслеживать провалы, а не только лишь в конце месяца.
ApeCoder вы будете держать на доске все когда-либо выполненные задачи на случай вдруг потребуется, что-то посмотреть? В канбане один человек разными колонками не занимается иначе вся суть канбана рушится. Каждая колонка — это конкретная группа исполнителей, выступающая для одной соседней колонки потребителем, а для другой — провайдером.
вы будете держать на доске все когда-либо выполненные задачи на случай вдруг потребуется, что-то посмотреть?
Доска электронная она сама держит n последних задач. Если мне не хочется видеть, я эту колонку сворачиваю
Каждая колонка — это конкретная группа исполнителей, выступающая для одной соседней колонки потребителем, а для другой — провайдером.
Вы поделитесь источником этих сведений? Я, например, слышал наоборот, что это не личности а роли по отношению к конкретной задаче и команда может быть кроссфункциональной и, в частности, узкие места могут быть устранены тем что команда перераспледеляется между работами (программисты начинают тестировать, если тестировщиков в конкретный момент не хватает)
Это вы про скрам рассказываете. Канбан для кроссфункционального работника — это действительно не более чем бессмысленная ролевая игра в стикеры.
Не согласен. Если я вижу, например, что задач в колонке "готово к разработке" нет, то вполне могу переключиться на колонку "готово к код-ревью" или даже "новая" или "готово к тестированию" (если тест-кейсы есть готовые).
То есть весь ваш процесс выглядит так:
- Есть что потестировать? Тестирую.
- Есть что проревьючить? Ревьючу.
- Есть что покодить? Кодю.
- Есть что поразбивать на таски? Разбиваю на таски.
Какую проблему в этом процессе может решить канбан?
Суть канбана — доводить максимальное количество задач до конца. Если у задачи этап "тестирование", то она еще далека от завершения (в целом), и соответственно — бизнес не получит от нее ценности (т.к. ценность имеют только полностью сделанные задачи). Поэтому если мы собираем матричную систему, то нам очевидно нужно в первую очередь доводить до конца задачи в правых столбиках. Если они заблокированы чем-то — можно переходить к следующим задачам (если вообще блок фактор мы не сможем снять за разумное время).
Хотя, конечно, в целом, похоже реально на натягивание совы на глобус.
Суть канбана в выявлении заторов и провисаний между исполнителями и балансировке нагрузки на них. Он вообще не про задачи и их статусы.
При таком раскладе его удастся "натянуть" только на типовые задачи с четким флоу по этапам.
Ну, и опять же — один человек может выступать в нескольких ролях (плохо, но это терпимо и если нет большой команды — это необходимость).
Что точно вне контекста — как в такую систему загнать условные примеры работы с чужим СД (или даже своим внутри компании, но вне рамок "своего" отдела)
Какую проблему в этом процессе может решить канбан?
Доска отвечает на вопрос чем именно занимается команда и "есть ли что потестить"
WIP отвечает на вопрос стоит ли сейчас помогать тем, кто тестирует обычно или лучше покодить.
Грубо говоря, да.
Канбан позволяет выявить ситуации, когда, например, тестировщики перегружены, а разработчики им помочь не могут.
Почему?
В канбане один человек разными колонками не занимается иначе вся суть канбана рушится.
у одного человека может быть несколько ролей. Т.е. канбан нужен, когда явно имеется процесс с несколькими этапами.
Источник вы не сообщили.
Это у вас не "готово" на самом деле, а "приём работы". Карточкам, по которым никаких работ больше не предполагается, делать на доске нечего. А если предполагаются, то так и должно быть написано, какие именно работы, а не абстрактное "готово".
Оно готово, но, например надо посмотреть какие-то детали для выполнения следующей задачи.
В контексте данного топика, отдел — это группа работников, решающая одного рода задачи.
Если один человек занимается разными колонками в канбане он меняет отделы в зависимости от текущей колонки?
Не должны быть обязательны, столбцы прежде всего показывают, что задачей занимается другой человек, отдел или даже компания. Если у вас один человек занимается анализом и проектированием без формального разбиения этих этапов "час тебе на анализ и день на проектирование", то отдельные столбцы не нужны. Канбан не регулирует содержание и количество столбцов.
В ходе диагностики обнаруживается и устраняется сетевая проблема на виртуальной машине.
Дальше я обязан завести тикет вида «инцидент», описать в нем что случилось и как это было устранено. И отдельно при закрытии тикета есть обязательное поле «доказательство того, что проблема решена». Какое, к черту, еще нужно доказательство? Нотариально заверенный скриншот мониторинга? В итоге туда пишется какая-нибудь откровенная дичь вида копипасты вывода «systemctl status xxx». Зачем и для кого — хрен его знает.
Мне кажется, что возможны две крайности:
- либо ставящий задачу должен проверить ее выполнение и поставить флажок (вопрос в том, что он может забить на это)
- либо исполнитель закрывает задачу, а если проблема все еще есть — изначально постановщик задачи просто откроет повторный тикет )
В том числе. Я вот несколько раз "заставил" руководство снять с меня этот отчёт, когда стал добавлять в него "составление этого отчёта".
Насколько я понял, Vengant работает в режиме «дежурного ожидания», а в свободное от работы над аварией время выполняет плановые рутинные задачи. Для такого режима менеджмент инцидентов имеет смысл, но (обращаю внимание!) здесь необходимо разделение на менеджмент и деятельность по устранению инцидента.
В классическом варианте «уж триста лет» для координации работ по базовой текущей деятельности и устранению ЧС, контролю времени, заполнению отчётности, докладов и др. использовалась должность «диспетчер». Именно он мониторил дески с индикаторами, заполнял бумажные тикеты, принимал голосовые траблы, отправлял мессаджи вверх и в стороны с указанием статуса и прогресса по таску привязанному к тикету. И это нормально работало: пожарные тушили, врачи лечили, работяги грузили, электричество в проводах, вода в трубах, гомно в отстойниках на очистных, начальство в курсе, отчётность в порядке.
В организации у Vengant роль диспетчера на себя взял начальник. Но чаще всего, в рамках пресловутой оптимизации, предполагая что координация деятельности автоматически вытекает из применяемой методологии: канбан, скрам, аджил или уже забываемые три сигма, бережливое производство, стратегическое бюджетирование, ISO 9000 и т.п. роль диспетчера не предусматривается вовсе. Если анонсировали и получили добро на оптимизацию молодые перспективные магистры из академии Хогвартс, то отсутствие результатов будет объяснено неверным исполнением заклинаний (бизнес-процедур, регламентов, протоколов, инструкций) и банальным сопротивлением изменениям, которые нужно просто перетерпеть, продолжая настаивать на полном всеобъемлющем исполнении заклинаний.
Бред — это совмещать в одном лице диспетчера, пилота и стенографиста. Но волшебники нашли метод. Рефрейминг: пилот это не тот кто управляет воздушным судном для перелёта из А в Б, а тот кто обеспечивает реализацию потребностей по воздушному перемещению. Отсюда регламент: пилот должен принять заявки желающих, согласовать маршрут со всеми участниками воздушного движения как до, так и в процессе полёта, одновременно составляя отчёт о всех деталях управления воздушным судном в этом полёте. Если используется методика парного программирования, то второй пилот должен делать то же самое. И если регулярный менеджмент в компании поставлен должным образом, то любой новый пилот изучив белую книгу сможет без потери качества обеспечивать воздушное перемещение.
Внедрение методики опирающейся на регулярный протокол необходимо только в случаях разветвлённой административной иерархии, либо в случаях внешнего контроля и отчётности. Например, не разумно использовать на посту охраны систему менеджмента инцидентов, достаточно архива видеозаписей и логов кодового замка.
Я не представляю себе ситуацию в фельдшерском пункте малого населённого пункта (или например в университете): «Гражданин МAC A0 находящийся в ETH22/PORT14 сообщает о сильных частых прерывистых болях в области сердца, сопровождающихся затруднением дыхания». Конечно, первым делом бюрократия: фельдшер оформляет в тикет-системе инцидент, там выскакивают SLA, категории, приоритеты, списки уведомлений и согласований. Если лица принимающие решения инцидент согласовали, то изменяем статус, и заполняем первичку (антропология и на что жалуемся), смотрим архив инцидентов по адресу, по гражданину, по жалобам. Изучаем историю что было — что стало. Сообщаем по списку уведомлений о том, что будет предпринято, и сколько это займет времени. Выслушиваем замечания и вносим их в карточку инцидента. Формируем заявку на ресурсы (транспорт, лекарства, средства защиты), получаем согласование на ресурсы. Не забываем вовремя менять статус инцидента. По прибытию на место обязательный фотоотчёт, sms-кой дополнения в тикет о различиях в состоянии гражданина ожидаемом и фактическом. Получение от финансистов подтверждения о возможности использования реанимационных действий если что-то при осмотре пойдет не так. Осмотр, диагностика, фотоотчёт по завершению. По приезду в фельдшерский пункт помимо карточки инцидента заполнение «белой» (красной, черной, оранжевой) книги (базы знаний для потомков) с анализом причин инцидента, хронологией развития ситуации, докладом о предпринятых мерах с планом намеченных мероприятий по недопущению таких ситуаций в будущем, с обязательной регистрацией в системе управления изменениями и установкой контрольных сроков по реализации этих мероприятий.
Про фельдшера звучит смешно, но совместными малограмотными действиями ай-тишники и менеджеры среднего звена взгромоздили похожие регламенты в своих компаниях. И продолжают культивировать этот бред.
Про фельдшера звучит смешно, но совместными малограмотными действиями ай-тишники и менеджеры среднего звена взгромоздили похожие регламенты в своих компаниях. И продолжают культивировать этот бред.
не смешно. Фельдшер приступил к лечению пациента, а он откинул копыта (пациент, но может и фельдшер). По документам лечения не было. Кто виноват? Т.е. вся эта отчетность не нужна при условии прозрачности процессов и точного понимания кто за что ответственен. И как только появляется необходимость процесс урегулировать и отмазаться от ответственности — происходит его формализация, оссификация и бюрократизация. И сам дух деятельности теряется, его заменяет форма.
Конечно же, прежде чем приехать было «триста» попыток перегрузить удалённо, но «чихает» железяка и лечению не поддается. А вот глаза в глаза, чисто из любви к результату, никакого лома — холодная перезагрузка по питанию — самое то. Либо счастье админу, либо смерть коммутатору.
Кстати, думаю, что админ дописал в тикет через смс — «индикация не нормальная, uplink обмена не показывает». Подключил консоль, попытался выполнить вход через фирмовую утилиту, потом телнетом, ещё раз смс-ка «отклика на консоли нет». В поле «причина» смс-кой скинул «сбой прошивки, возможно зависание». Телефоном запросил разрешение на холодную перезагрузку. Получил ответ «на твое усмотрение исходя из обстоятельств». Попутно получил по е-майлу ответ из службы поддержки вендора коммутатора «По указанному ip нет отклика. Помочь не можем.». Еще смс-ка в тикет «ответ вендора». Далее автомат по питанию выкл-15сек-вкл. Всё! Можно писать в тикет «индикация питания — норма, индикации линков и обмена — нет.»
Вопросы к админу: «Штатной процедурой холодная перезагрузка не предусмотрена» и кнопки «ресет» на коммутаторе нет. «Твоё усмотрение» от начальника, если «упала» централизованная бухгалтерия превращается в «я не предлагал перезагрузку, можете посмотреть лог инцидента».
Так вот. К чему городить огород с протоколом инцидента в системе управления инцидентами, когда достаточно обыкновенного ПЛА, тем более в небольшой компании. Понятно что менеджерам будет не по себе, что такой древний и простой механизм эффективно работает, без волшебства.
План Ликвидации Аварии (ПЛА), регулярно обновляемый, закрывает всю эту дрочь с он-лайн протоколизацией решения проблем. Появился в мониторинге сигнал о неполадках, взял в руки ПЛА и выполнил по пунктам. Для обыденной деятельности примитивный график технического обслуживания на год/полугодие/квартал в который начальники могут вносить дополнительные хотелки.
Оказывается! Вместо нагромождения коммуникаций/записей/сообщений достаточно двух таблиц: Инциденты(Элемент системы, ДатаВремя регистрации, ДатаВремя устранения) и Техническое обслуживание (Элемент системы, Дата план, Дата факт), всё остальное можно сбросить в поле «примечания».
Как-то тема не раскрыта. В статье одни жалобы в режиме «все дураки, а я умный!»
- Какие именно процессы ITIL мешают вам жить?
- Чем условная Канбан доска прикрученная к тикетам в условной жире Вас не устраивает?
- После вашей выходки на тренинге были ли предприняты попытки от менеджмента предоставить Вам обратную связь и, к примеру, отправить на курсы по развитию soft skills? Понимаете ли Вы как подобное поведение трактуют ваши менеджеры?
2. Доска меня устраивает всем и по факту мы внутри отдела ею пользуемся (GitLab Boards) — но исключительно для тех задач, к которым это применимо, и в том объеме, который нам нужен. Не устраивала меня изначальная идея принудительно внедрить доску для всех задач и поставить следить за ней надсмотрщика из отдела сервис-менеджмента с правом вмешиваться во все подряд. Потому что на примере тикетной я уже видел, к чему это в конкретно нашей конторе приводит.
3. После моей выходки и явной неготовности «тренера» отвечать на конкретные вопросы последовало мое предложение (в личку руководителю) не тратить мое рабочее время на неприменимую к моей работе дичь. Начальник согласился, и я с облегчением вернулся к своим непосредственным задачам. Как кто трактует мое нежелание фальшиво улыбаться и подыгрывать адептам карго культа, мне если честно все равно. Мне вполне хватает того, что мой непосредственный руководитель меня поддерживает, а директор компании адекватный человек и поддерживает моего руководителя.
Не устраивала меня изначальная идея принудительно внедрить доску для всех задач и поставить следить за ней надсмотрщика из отдела сервис-менеджмента с правом вмешиваться во все подряд.
Ну то есть у вас были проблемы с тем что начальство вам хотело посадить надсмотрщика, а виноват почему-то оказался именно канбан? :)
Ели стоимость ЗНАЧИТЕЛЬНО выше, но при этом реально а не "была одна копейка, стал рубль, за 100% акций" - можно сделать спецотдел БДСМщиков из 5 человек под это.
И внедрить там всё вообще. Отчитаться что "наша компания применяет %ваще всё%".
Просто если полезть в уже работающее - можно и сломать с большой долей вероятности.
1. ITIL/ITSM прекрасно работает при любом размере команды. Из личного опыта — 4 года работал в аутсорсинговой командой (на позиции Oracle DBA), в составе смены было 6 инженеров, 1 технический писатель и 3 менеджера (включая начальника подразделения и старшего смена) и ITSM практики прекрасно использовались и работали. Чтобы было понятно — количество систем исчислялось сотнями. Это была самая хорошо построенная и организованная работа за все 16 лет, что я работаю в ИТ.
2. Все существующие практики не работают если их внедрять как есть, они все требуют адаптации.
3. Как известно эффективные менеджера способны угробить всё что угодно.
4. Канбан в том или ином виде можно использовать даже в одиночку.
ITSM практики
конкретные практики, а не весь "стандарт"? Можете перечислить, что именно было внедрено?
Я все-таки ощущаю что 3 человека ИТ отдел (а не 3 инженера техподдержки в нем) и условных 15 серверов и 150 ПК с типичноистеричными запросами «У меня тут что-то не работает» плохо на этот глобус натягиваются во всяком случае механистично внедряя itsm совместимую helpdesk систему.
в наших масштабах все это только мешает, добавляя кучу ненужной отчетности, избыточной писанины ради писаниныЭто везде у нас так. Самое грустное, что половина занимается абсолютно бессмысленной работой, но получает за нее зп, хотя могли бы заняться чем-то дельным
Очень, очень много бездельников!
Часто бывает, что первые 20% сотрудников не заставишь делать вторые 20% задач, а первые 80% задач вторые 80% сотрудников сделать просто не в состоянии.
Мне довелось за свою жизнь работать в разных компаниях; редко, но бывало такое, что 80-20 «переворачивались» — как правило, в небольших стартапах с очень толковым и успешным менеджментом. Но в больших компаниях, как правило, работает так, как я описал выше.
Кстати, agile-методологии могут быть очень мощными и полезными, но только с некоторыми обязательными условиями:
— применяются они именно там, где и должны
— применяются они именно так, как и задумано, умными людьми с опытом
— agile-методы используются именно по прямому значению словосочетания, а не догматически.
Говорю об этом не понаслышке, и не теоретизируя: довелось поработать в коллективе, где без правильного scrum-а мы бы тупо загнулись, и завалили все, что можно (было очень мало ресурсов), а так еще и времени вагон иногда оставался.
Разумеется, в наших масштабах все это только мешает, добавляя кучу ненужной отчетности, избыточной писанины ради писанины, и порождая бесконечную войну технарей, которые хотят чтобы им дали спокойно работать, со всякими менеджерами, половина из которых молится на разведенную ими же бюрократию, а в ИТ вообще не понимает.
Это не только в вашей сфере. У нас в фармкомпаниях ровно та же ситуация: приходит «эффективный менеджер» на зарплату в 100500 тугриков и начинает создавать видимость работы, внедряя всяческие геолокации, отчёты и прочую мешающую работе полевых сотрудников лабуду. И у отдела IT работы прибавляется, а в общем на продажи это влияет только негативно. И виноват не этот «эффективный менеджер», а медпреды.
Это называется отсутствие доверия к новому, тут продуктовый подход не причем, возьмите на заводе любое начинание, мол, давайте после 10 лет ходьбы в столовку вот так — изменим маршрут и будем ходить не через цех, а с другой стороны.
Тут же толпа набежит, которой доводы не нужны, у нее нет веры и авторитетного мнения, что это лучше. А уж доводы против толпа сама придумает.
Хватит натягивать сову на глобус