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

Так я открыла для себя Бережливое производство, заточенное под сервис и IT, с тех пор я углубилась исключительно в это направление.  Я порой работала на 5 проектах одновременно, и в некоторых оно было внедрено, а в других – нет. В каком-то проекте уровень Lean-практик был уже зрелым, в каком-то – все только-только начинало прорастать в людях и процессах, поэтому я могла сравнить и качество сервиса, и уровень вовлеченности команды. Мое мнение становилось все более утвердительным – там, где практики были внедрены, работа всегда делалась лучше, быстрее, качественнее, а общение с командой было эффективнее. Так ли это на самом деле? Хочу выяснить это на примере работы нашей команды поддержки.

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

Самому заказчику не так важно, кто именно что делает. Заказчик видит и оценивает сервис в целом, поэтому от слаженной работы команды и её боевого настроя зависит всё: особенно когда внезапно упали все базы данных, у пользователей по всему миру отвалился доступ, а заказчик ожидает решения проблемы прямо сейчас. Но философия Lean обеспечивает непрерывность и качество, а значит пока что Бережливому производству – быть.

…Или не быть?

Пробовали ли мы работать без практик Бережливого производства? О да, было дело.

Был один небольшой старый проект, который, как нам казалось, мы знаем от и до, все было тихо, мирно, спокойно, даже скучновато. Инструменты Бережливого производства были внедрены и использовались регулярно. Так что в один прекрасный момент команда предложила вовсе обойтись без командных звонков для поддержки качества сервиса («а чего время на них тратить?»), без специальных сессий по решению проблем («проблем-то нет»), просто работать, как нам работается.

Хорошо, принято, решили убрать. Ведь зачем мучить людей методологией, в которой они не заинтересованы? Через месяц SLA упало со 100% до 95%, потому что мы прошляпили одну проблему, команда не подняла вовремя этот вопрос (встреч по проблемам ведь больше нет, где это обсуждается), и сервис пострадал.

Казалось бы, 5% падения – это не слишком критично, мы даже укладывались в рамки допустимых метрик и наших соглашений с заказчиком. Но, во-первых, это ведь падение только за месяц, страшно представить, что было бы через полгода, а во-вторых, даже такое незначительное ухудшение ударило по нашей профессиональной гордости, как отличного поставщика услуг. Мы ведь привыкли быть лучшими, привыкли, что заказчик всегда хорошо о нас отзывается, привыкли работать на все 100% и быть в зеленой зоне. Как выяснилось, нашу спокойную жизнь и репутацию оберегали наши лучшие практики в виде инструментов Бережливого производства. Больше отменять его мы не пытались.

Lean starter pack

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

1. Кружок качества

Самый простой из них – общекомандные кружки качества, или, как мы их называем, CommCell.

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

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

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

Главный принцип CommCell – вовлекаем каждого, поэтому его также можно использовать для определения настроя команды: когда люди молчат, перестают генерировать идеи, участвовать в обсуждении, уходят в себя – это видно сразу. Так и наоборот – ясно, когда команда хорошо себя чувствует: люди вовремя делают таски, приходят со своими болями и идеями, шарят на команду новости и лайфхаки, поддерживают друг друга.

Важны icebreaking-практики, чтобы вовлечь людей в митинг, особенно если вы все работает удаленно. В нашей компании есть потрясающие примеры, как креативно, весело, а главное продуктивно можно проводить CommСell, в ход идет всё: и опросы в гугл-формах (как вы себя чувствуете сегодня?), и доски на ресурсе Miro (возьмите себе карточку и опишите вашу боль), и гугл-карты (я в командировке сегодня здесь, смотрите!).

2. Problem solving sessions, или Щелкаем вопросы как орешки

Другой мощный инструмент – Problem Solving, который естественным образом дополняет и обрамляет СommСell. Важно понимать, что на СommСell мы не обсуждаем проблемы (мы называем их concerns), мы их только регистрируем, затем на звонке спрашиваем, кто заинтересован в решении этой проблемы и вешаем на кого-нибудь таску – создать отдельную встречу для этой проблемы, Problem Solving Session.

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

У Problem Solving Session простая и внятная структура, которая позволяет нам максимально эффективно использовать время:

• 5 минут обсуждаем определение проблемы (Не смейтесь! Это ключевой момент, от того, как грамотно мы сформулируем проблему, зависит успех всего мероприятия),

• 10 минут мы определяем наше желаемое состояние (по методике SMART),

• 20 минут выясняем причины нашей проблемы по правилу «5 почему».

После определения корневых причин мы устраиваем брейншторм, предлагаем варианты решения, затем сортируем их по эффективности (затратам, срокам) и берем лучшие варианты в работу, выстраиваем план действий и затем на СommСell смотрим, как успешно решаются таски и достигли ли мы желаемого состояния. Если не достигли, то процесс повторяем, делаем работу над ошибками. Просто, со вкусом, эффективно. Однажды наша новенькая коллега вышла с Problem Solving Session с горящими глазами и воскликнула: «Ничего себе! Неужели все так быстро можно решить?». Слышать такое всегда очень приятно. Особенно, если это ты фасилитируешь такую сессию (хе-хе).

Немного заключительных слов

Разумеется, внедрять Бережливое производство с нуля, менять образ мышления сотрудников – это очень нелегкая задача, команды привыкают месяцами, это мучительный процесс. Зато результат превосходит все ожидания. Если на проекте до внедрения философии Бережливого производства пользователи могли ждать ответа неделями, тикеты (и инженеры) краснели как помидоры в огороде, постоянно прилетали высокоприоритетные инциденты, везде был хаос и бардак, но уже одно только внедрение СommСell и Problem Solving Session помогло сократить количество инцидентов (стек команды упал в 3-4 раза), а заказчик отметил, насколько сильно выросла команда.

Кроме упомянутых инструментов есть множество других, которые мы внедряли – например, Demand Analysis, 5S, Standardization. Они помогли сделать качество сервиса стабильным, и после их внедрения мы уже больше не возвращались в красную зону. 100% SLA стал нормой жизни, а количество высокоприоритетных инцидентов упало с 10-15 до 1-2 в год. Благодаря философии постоянных улучшений были внесены предложения, которые позволили сократить рутину, снизить вероятность человеческих ошибок и помогли компании сэкономить сотни тысяч рублей. И мы уже не представляем, как так можно было бы работать по-другому.