И вот при таких масштабах наше руководство уже пару лет как активно играется в ITIL. Наняли орду сервис-, продакт- и прочих менеджеров, внедрили ITSM, сертифицировались по разным стандартам и стали на полном серьезе требовать от технических сотрудников соблюдения всех описанных в этих стандартах процедур.
Разумеется, в наших масштабах все это только мешает, добавляя кучу ненужной отчетности, избыточной писанины ради писанины, и порождая бесконечную войну технарей, которые хотят чтобы им дали спокойно работать, со всякими менеджерами, половина из которых молится на разведенную ими же бюрократию, а в ИТ вообще не понимает.
Так вот, руководству этого показалось мало, и захотелось внедрить еще что-нибудь эдакое, модное. По каковой причине зимой нам прямо в офисе организовали тренинг по Kanban. Напыщенный «тренер» в костюмчике и с айфончиком два дня подряд распинался, как «построить сильную команду», «приоритизировать задачи» и «повысить эффективность». Рисовал графики, показывал красивые картинки, приводил примеры из кровавого энтерпрайза и крутил мотивирующие ролики. Сервис-, продакт- и прочие менеджеры радостно кивали и потирали лапки. Разработчики скептично молчали. А дальше «тренер» совершил фатальную ошибку — предложил высказаться отделу инфраструктуры, хотя мы тихо занимались своими делами, пропуская его распинательства мимо ушей. Но раз человек просит — мне не жалко:
— Скажите, а как изменится лично моя работа, если мы внедрим описываемое? Эта методология не будет за меня работать. И ITIL не будет. И толпа менеджеров не будет. В конце концов все равно нужен специалист, который знает, как нажать кнопку. И от того, что я ее буду нажимать не рукой, а ногой в прыжке с разворотом, и отмечать нажатие кнопки не во внутреннем трекере, а на этой вашей доске, быстрее она не нажмется.
— Ну, дело в том, что организация работы в команде…
— У нас всего 2 админа, занимающихся инфраструктурой.
— А… Эм… Нууу, в общем… Я не готов прямо сейчас ответить на ваш вопрос.
После этого выступления мне разрешили удалиться с тренинга и больше не участвовать в театре абсурда. С тех пор прошло уже несколько месяцев, но про Kanban у нас что-то больше не слышно — видимо, дошло даже до самых твердолобых.
Никто не спорит, управление проектами, методологии и стандарты — вещи полезные. Но я довольно часто видел — что в России, что в Германии — случаи, когда все это внедрялось «для отчета» или «потому что модно». Причем в первом случае таким внедренцам иногда (но нечасто) все же хватало мозгов «внедрить» стандарты чисто на бумаге и не мешать сотрудникам заниматься реальной работой.
А вот чего я еще нигде и никогда не видел, так это чтобы бездумное внедрение таких вещей и требование им слепо следовать без оглядки на масштаб и специфику организации — а главное на реальную необходимость всего этого — приводило к чему-нибудь хорошему.
ctacka
А почему руководство решило все это внедрять? Может, у них есть какие-то цели, которых они хотели этим достичь, и эти методы им показались наиболее правильными?
dvserg
Руководство обычно решает это сделать с чей-то подачи. Они же в большинстве своем финансисты и управленцы, и в этих ваших IP адресах совершенно не понимают.
А некто во второй-третьей линии начальствующих решает укрепить свои позиции инициативами, берет красивые презентации, статистику популярности и готовится к повышению.
Была ситуация, когда некто писал кандидатскую про КПИ и приКПИшных чудесах, и тут-же экспериментировали на сотрудниках внедряя их в жизнь. Особенно забавно было смотреть, как искали/выдумывали эти показатели для разных групп сотрудников.
Vengant Автор
Я как-то видел вообще прекрасное — KPI одного отдела зависел от работы другого, который ему не подчинялся…
d-stream
Бывает и запущеннее: манагер накручивает свой показатель по количеству подаренных скидок, а вознаграждение исполнителя работ вычисляется как продажный объем нетто)
babylon
Менеджерам нужны метки — временные и количественные, по которым они ориентируются. Например сделано — не сделано, Если не сделано, то насколько и когда будет результат. Им не надо понимать как всё устроено под капотом. Им нужны флажки, столбики, сегменты диаграмм как показатели готовности. Это их среда и инструменты. Их они используют для общения с руководством. Это абсолютно нормально. Не нормально простаивать и затягивать коммерческий проект. Но не всё зависит от тебя. Для этого и нужны менеджеры. У которых главная задача это слежение за исполнением проекта. Это достаточно нервная работа. Ну или мне такие менеджеры попадались. Но это все равно были высококлассные менеджеры. Процент срывов обычных проектов у которых был минимален. А топовых вообще равен 0. Маразма нет никакого. Кесарю — кесарево как говорится. Как пример проекта. Презентация для госструктуры. 2 программиста и 10-15 дизайнеров и 1 видеомонтажер. Сроки не жмут. На каком языке должны общаться дизайнеры и программисты. Если и те и другие далеки друг от друга в предметных областях и даже физически недоступны. Каковы должны быть скиллы у менеджера для успешной реализации проекта? Сколько их должно быть.
HiMem-74
Ровно два: рот открыть и рот закрыть.
Для не умеющих в юмор поясню: Обеспечить коммуникацию и не выносить мозг. Баланс тонок, но возможен. И именно это отличает хорошего менеджера от плохого.
babylon
Нет не это отличает. Отличает умение доводить проекты до конца. Часто менеджеры это просто подрядчики, которым не хватает собственных ресурсов и они нанимают профи на рынке. Коммуницируют. Выносят мозг. В реале всё бывает. Главное чтобы дело двигалось. А есть балаболы. Но это чаще в крупных компаниях. Где на одного работягу 5 балаболов. Да вы и сами знаете. Пример — у компании много проектов. Их надо кому вести и взаимодействовать по некритичным вопросам с клиентами. Кто этим должен заниматься? Ну не разработчики же.
usego
Ну и всякие шильдики добавляют сейлс поинтов в глазах не особо опытных клиентов. Но вот в организациях, которые свои процессы наружу не продают, чаще всего это обычный карго культ и чьёто-то раздутое эго.
ctacka
Ну финансисты выкладывают деньги за что? Видимо, тот руководитель, который инициировал все это, что-то им пообещал?
Может им недостаточно предсказуемости вашей работы? Или SLA недостаточный? Или их идеи не реализуются?
Просто это как-то не по-финансистски, выделить деньги просто так, без цели.
adictive_max
Ну тогда заходили неправильно. Технарям нужны не возвышенные цели и мир во всём мире, а конкретные задачи. Нужно SLA — говори что нужно SLA. Нужен учёт — говори что нужен учёт. Но внедрение ITIL ради корочки о внедрении ITIL — это уже совсем другое. Ничто так не демотивирует инженера, как бессмысленная работа.
ctacka
Ну попросят у вас SLA — откуда вы его возьмете, придумаете из головы? А канбан позволяет SLA высчитать.
Это ваша точка зрения — что ITIL внедряется ради корочки. А с точки зрения бизнеса это упорядочивание непрозрачной работы админов, введение четких правил и процедур, на которые они могут ориентироваться при аудите, при планировании, при создании отчетов.
Мне если вдруг кажется, что сразу много людей занимаются не тем, чем надо, то я сразу настораживаюсь, потому что обычно это значит, что я не понимаю чего-то, а не то, что все другие вредители.
Vengant Автор
Цели там есть: показать вышестоящей организации и партнерам «смотрите, какие мы офигенные, мы сертифицированы по бла-бла, тыр-пыр и фыр-быр, а еще мы работаем по ITIL и у нас все по фен-шую».
eugene08
Складывается впечатление, что вы не только не помогли компании наладить процессы но и вставляли свои палки в колеса. Бизнес — не благотворительность, абсолютно нормальное желание у менеджмента знать за что вам и вашим коллегам платят деньги, что вы делали вчера, что делаете сегодня, и, примерно, что будете делать в понедельник. Канбан/другие подходы делают процессы прозрачными, что приносит много плюшек, например: имея организованные процессы разработки, можно разрабатывать систему регулярных ревью для поощрения сотрудников.
adictive_max
Не вопрос, только что бизнесу будет от того, что он узнает, что вчера я весь день составлял стратегию развития свича на 5 этаже, сегодня делаю отчёт по внедрению KPI среди самого себя, а в понедельник буду занят Scrum-митингом по постановке задач из утверждённого месяц назад квартального плана регламентных работ (который уже 3 года не менялся)?
Складывается впечатление, что некоторые непонимают, что управление работой — это тоже работа, и она тоже требует время и денег на своё выполнение.
ApeCoder
Канбан это немножко не то. Представьте, что у вас та система где вы учитываете заявки будет визуализировать их в том числе в виде доски. Будет установлен четкий лимит сколько вы можете брать заявок в работу, а если их будет больше вы будете не брать новые пока их число не уменьшится.
Vengant Автор
А теперь представьте, что этим управляет девочка-гуманитарий, которая абсолютно не разбирается в том, чем вы занимаетесь, но при этом имеет право лезть к вам с требованиями расписать задачи более феншуйно или объяснить ей то и это.
Nalivai
Ну так проблема-то не в канбане тогда, а в том что скрам-мастер (так это называется?) неправильно выбран. А теперь представьте что этим управляет грамотный технически подкованный менеджер, задача которого создать оптимальную работу, чтобы к админам не лазили со всякой фигней когда у них важные дела, и чтобы админы могли одним взглядом отличить задачу которая нужна бизнессу прямо сейчас от задачи которая не понадобится еще год, и чтобы сразу было видно если на админе и так висит девять очень срочных задач и придумывать стратегию развития свича ему сейчас не с руки
Stas911
Именно, как я вижу упорядочивание и правильная приоретизация задач только поможет в работе и отчасти устранит вот это «АААА, СРОЧНО ПРЯМО СЕЙЧАС» которое прилетает со всех сторон.
rjhdby
Как тут не вспомнить присказку, что хороший админ — это тот, который играет контру, а не тот, у которого рожа в мыле. (при условии, что всё работает конечно)
ardraeiss
И при не менее обязательном условии что его руководство это тоже понимает.
HiMem-74
Если Вам непонятен посыл статьи, можно я немножко перефразирую? Спасибо.
Вот отдел. В нем 2 человека. Всего 4 руки. И если эти руки, вместо непосредственной работы, будут заполнять бесчисленные канбаны, производительность труда отдела упадёт.
Единственный профит для бизнеса (на примере сервис деска) — понимание того, что 10% юзеров генерирует 90% проблем. Так это, во-первых, очевидно для всех (как правило, кроме самого руководства), а во-вторых это в 99% случаев родственники этого самого руководства!
Vengant Автор
Спасибо :) В нашем случае речь идет не о юзерах конечно, но все примерно так и есть.
ApeCoder
Насколько я понял они по факту выбрали сами пользоваться досками в итоге — т.е. заполнять их вручную или автоматически.
А зачем вообще нужен канбан? С точки зрения его сторонников?
Vengant Автор
Правильно поняли. Мы и до того трекали внутренние задачи в гилтабе, а потом стали в нем же раскидывать их по доскам. Но это чисто внутренняя кухня, а не навязанное и контролируемое сверху решение, как оно изначально предполагалось.
VolCh
Канбан позволяет определять узкие места при выполнении многоэтапных задач. Например, что разработчики делают задачи быстрее чем тестировщики их тестируют.
dpyzhov
Если своими словами – ускорение работы команды с потоком заявок за счёт фокусировки на меньшем количестве заявок в единицу времени и на работе по выявлению и устранению узких мест.
ctacka
не обязательно устранению, узкое место будет всегда. Узкое место надо передвинуть на ту операцию, которую вы можете легко регулировать, и тогда вы можете регулировать пропускную способность всей системы.
dpyzhov
Узкое место передвигается в новую точку исключительно путём устранения его в предыдущей. Но да, в какой-то момент теоретически можно прекратить оптимизацию. Хотя в реальности постоянно что-то меняется. Кто-то приболел, внедрили новую фиговину, поменяли процесс – и вот узкое место там, где не ждали.
Конечно, если вспомнить книгу Голдратта, то когда система начала справляться со всем входящим потоком и всеми заявленными целями, они объявили узким местом цели компании и канал продаж. У меня так в какой-то момент багфикс легаси продукта превратился в его рефакторинг, когда кончились все баги, что можно починить без него.
VolCh
В идеале узкого места быть не должно, у всех этапов пропускная способность должна быть равной скорости входа задач.
gecube
Сложный вопрос. В идеале есть два чувака, которые работают в паре. И нагрузка по ним распределяется по 50%. Все освободившееся время от рутины они тратят на улучшение процессов и работу на перспективу. Все счастливы. Проблема только в том, что это дорого, и это могут позволить себе либо стартапы, которые жгут деньги инвесторов, либо технологические компании. Остальные — жестко экономят ФОТ, в результате нагрузка на одного составляет 100-150-200%
VolCh
Ну в таких условиях просто на всех этапах равная пропускная способность, чтоб нагрузка равно распределялась. Хотя, конечно, бывает, что разработчики по 8 часов работают, а тестировщики по 12 тестируют, чтоб не накапливались задачи "готово к тестированию". Но формально количество задач в сутки одинаково, узеи мест нет:(
Kanut
Так «эти руки» как раз таки ничего заполнять и не должны. Канбан это грубо говоря система тикетов, которая имеет определённые правила. То есть вещи вроде «нельзя одновременно обрабатывать больше чем Х тикетов» или «Если статус у тикета из категории А не меняется Y дней, то на него надо повнимательнее посмотреть».
И вопрос в том как вообще сейчас организованы процессы в этом отделе. Ну то есть какие у них задания, кто их даёт, кто и как распределяет, кто оценивает объём работ, кто и как отчитывается о проделанной работе и т.д. и т.п. И только тогда уже можно думать надо там что-то менять и если надо, то канбан там нужен или что-то другое.
dravor
Ну вот в примере выше нашлись деньги на покупку инструктора по курсам канбан, но не нашлись на человека для двух админов. который будет все эти тикеты заполнять.
Суть как раз в том, что чем больше в компании сотрудников, тем активней система подавляет обратную связь от конечных исполнителей. И это что-то на уровне древней психологии стаи обезьян, а не заговора рептилоидов.
Kanut
Ну во первых «инструктор на канбан» это одноразовая выплата. И вряд ли за него заплатили даже годовую зарплату «заполнятеля тикетов».
А во вторых тикеты по хорошему должны заполнять конкретно те кому что-то нужно от админов. В конце-концов сейчас же админы откуда-то задания получают. Неужели они их исключительно сами себе придумывают?
HiMem-74
Вы правда не понимаете различий между скрамом, карточками канбан и сервис-деском?
То, что вы сейчас упомянули — это ТИКЕТ в сервис-деск, который должен заполнить пользователь, чтобы получить УСЛУГУ от отдела ИТ.
Карточки канбан это внутренние дела отдела ИТ, заводятся тогда, когда задача (карточка) имеет более одного этапа работы и/или отрабатывается несколькими людьми/отделами.
Так вот, возвращаясь к сервис-деску, 99% неудачных внедрений SD из-за того, что юзеры НЕ ЖЕЛАЮТ сами ничего заполнять, им ПРОЩЕ позвонить/прийти, чем формулировать своё мычание «тут у меня это, в полу подземный стук».
Kanut
Я бы сказал что это вы не понимаете что при нормальном тулинге и нормально поставленных процессах эти самые «внешние» тикеты/таски/задачи превращаются во «внутренние» банально одним нажатием кнопки или даже автоматом.
Да и вообще вас никто не заставляет таски в канбане держать в виде бумажных карточек. Делайте это всё в электронном виде, в чём проблема? Или у вас админы вообще без всяких тасков/тикетов работают и просто делают что им сказали мимо проходящие люди?
То что там кому-то что-то проще совсем не означает что им это надо позовлять так делать. Ну а если уж позволяете, то тогда наверное не стоит и жаловаться что админы работать не успрвают потому что им надо «карточки заполнять».
eugene08
> Карточки канбан это внутренние дела отдела ИТ
они вполне могут приходить снаружи, от других отделов — дать/забрать доступ, чтонибудь насетапить и тп
HiMem-74
На самом деле нет :-)
«По учебнику» это называется «запрос на изменение» и является стандартным процессом в сервис-деске. То, что этот процесс можно натянуть на канбан и реализовать в виде карточек, не значит что это правильно и оптимально.
ctacka
Это не совсем так. Производительность даже двух рук зависит от головы, от того, что и когда в эти руки дают. Я сам свидетель истории, когда выстроенный процесс увеличил производительность команды почти в три раза без каких-либо кадровых изменений.
HiMem-74
Это всего лишь значит, что в результате пересмотра бизнес-процессов часть задач принято решение делать чужими руками. Увы, волшебных пилюль не бывает и обычно «выстраивание процесса» сводится к анекдоту, когда сенокосцу на лоб цепляют фонарик, а к заднице грабли.
PS: Возможно я где-то излишне пессимистичен в оценках, но сейчас я переживаю момент, когда у руля производственной компании оказались мало того, что гуманитарии, так еще и маркетологи с коучингом на всю голову и в целом мы стремительным домкратом несёмся в успешный-успех.
ctacka
Я сожалею по поводу вашей ситуации, но не соглашусь с вашим первым утверждением: результат был достигнут не за счет "чужих рук", а за счет уменьшения простоя, уменьшения частоты переключения контекста, и за счет использования более удобных инструментов. И первые два пункта были достигнуты исключительно за счет улучшения процесса.
VolCh
Просто приоритетами можно увеличивать производительность за счёт группировки задач по контекстам, за счёт минимизации количества переключений.
Nalivai
Плюс к вышесказанному, выстраивание процесса иногда позволяет понять, что некоторые задачи или совсем не надо делать, или требуют мощнейшей оптимизации.
tivita
Золотые слова! Эффект рекурсивной ловушки в чистом виде. Потом появляется управление управлением работой, а потом управление управлением управлением…
В 15 веке в Англии было 50 тысяч военных кораблей, а в адмиралтействе работало 5 человек. И справлялись.
В 19 веке кораблей осталось 500, зато в Адмиралтействе работало уже 5 000 чел. И справлялись с работой с большим напряжением.
Сейчас от военного флота осталось 5 кораблей, зато в Адмиралтействе работает уже 50 000 человек и не справляются с работой совсем.
Kanut
Хм, а вы уверены что одинаковое количество кораблей во все времена создавало одинаковое количество работы? И что английское Адмиралтейство занимается исключительно кораблями и ничем больше?
ctacka
50 тысяч военных кораблей? Да не может быть так много!
tivita
Ну, цифры условные, наверно, это весь флот насчитывал такое количество кораблей. Но тенденция отражена правильно. Любая бюрократическая организация заинтересована в росте и увеличении, вне зависимости от внешней функции, для которой она создавалась.
gecube
Военные лодки, лол. Шучу
tivita
Ну, эта история и рассказывается как шутка. Это из какой-то юмористической книги типа законов Мерфи или Паркинсона.
amarao
Ровно такое же есть желание не тратить собственные усилия на то, чтобы помогать другим людям выполнять их KPI.
Хотят — пусть выполняют. Не хотят — пусть не выполняют. Хотят, чтобы я им помогал — пусть мотивируют. Можно деньгами, можно статусом, можно блестящей игрушкой. Если кто-то хочет, чтобы я занимался унылым, скучным, непрестижным забесплатно, то я не могу запретить ему хотеть. Но и помогать в исполнении желаний тоже не буду.
Можно попробовать от противного — заставить под угрозой увольнения.
Но, повоторю, если кто-то хочет, чтобы я занимался скучным, неинтересным, непрестижным под угрозой увольнения, то он может попробовать. А я могу стряхнуть пыль с резюме в ответ.
Hardcoin
Абсолютно глупое желание. Если у тебя, как у менеджера, есть цели и задачи — именно за них и нужно платить. Не нужно "знать, за что платишь", нужно "платить, за то, что требуется". А если ты не знаешь, что требуется, спроси у того, кто знает.
Контроль и прозрачные процессы нужны для того, что бы проверить, делается ли то, что требуется.