Часть II – разбор конкретного случая
Kanban в реальной жизни
Это история о том, как мы научились быть лучше, используя Kanban. Когда мы начинали, не так уж много информации было доступно, и даже "доктор Google" не мог нам ничего порекомендовать. Сегодня же Kanban успешно развивается, и число источников знаний постоянно растет. Я настоятельно рекомендую ознакомиться с работами Дэвида Андерсона, например, с "классами обслуживания" ("classes of service"). Еще мы хотим первый (и, обещаем, последний) раз предостеречь. Какие бы решения вы не применяли, убедитесь, что они относится к Вашей конкретной задаче. Все. Идем дальше. Вот наша история.
/ Маттиас Скарин
17
Суть технической поддержки
Если вы когда-нибудь круглосуточно дежурили на телефоне, вам хорошо знакомы чувства, возникающие при поддержке реальной системы, с которой работают клиенты. От вас ожидают, что вы сможете разрулить любую ситуацию в любое время дня и ночи, независимо от того, по вашей вине возникли проблемы или нет. Спрашивали у всех – никто ничего не знает, поэтому они и звонят вам. Ничего себе задачка, особенно если учесть, что это не вы создавали аппаратное обеспечение, не вы писали драйвера, ОС и специализированное ПО. Часто все ваши возможные действия сводятся к локализации проблемы, уменьшению ущерба, записи информации, необходимой для воспроизведения проблемы, и ожиданию, когда же некто, ответственный за эту проблему, соизволит еѐ воспроизвести и устранить.
Ключевые факторы успеха в этом случае – быстрота реакции на запрос и умение решать проблемы, в сочетании со скоростью и тщательностью.
18
Скакой стати вообще что-то менять?
В2008 году одним из наших клиентов была скандинавская компания, занимающаяся разработкой компьютерных игр. Они воплотили целый ряд процессных улучшений. Одно из нововведений состояло
в масштабировании Scrum-а на уровень всей компании и постепенном устранении препятствий, мешающих командам разработчиков поставлять ПО. Как только поставки программного обеспечения наладились, вся нагрузка сместилась дальше по цепочке – на отдел техподдержки. Ранее команда технической поддержки по большей части наблюдала за происходящим со стороны, теперь же они все больше и больше вовлекались в процесс разработки на правах полноценных участников.
Рисунок 1. В составе технической поддержки находилось три команды: инженеры баз данных (DBAs), системные администраторы и вторая линия поддержки.
Как оказалось, наша помощь разработчикам не решила всех проблем. Если бы мы продолжали уделять внимание лишь командам разработчиков, это привело бы к задержкам не менее важных улучшений инфраструктуры, находящейся под контролем команд техподдержки. Улучшения были необходимы в обеих областях.
Вдобавок, прогресс в командах разработчиков привел к тому, что менеджеров буквально завалили просьбами проанализировать те или иные идеи и предоставить по ним отзывы. Это означало, что у менеджеров оставалось все меньше времени на приоритизацию задач и решение различных проблем. Управленческая команда поняла, что им необходимо действовать, пока ситуация не вышла из-под контроля.