Гемба-менеджмент в ИТ: японский подход для поиска слабых мест в разработке без отчетов и метрик

Почему руководитель разработки ПО заходит в видеоконференцию и полтора часа наблюдает, как разработчик пишет код? Короткий ответ: он использует подход гемба — один из лучших способов найти слабые места в процессах.

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

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

В буквальном переводе gemba (現場) означает «реальное место» — точку, где рождается продукт: в производстве это цех, в ритейле — торговый зал, на стройке — площадка. В управлении этот термин стал напоминанием руководителю: чтобы понять, как устроена работа, нужно идти туда, где она действительно происходит, а не пытаться увидеть все по презентациям.

Отсюда и возникла практика gemba walk — «прогулка на место»: менеджер приходит в команду, наблюдает за процессом, задает вопросы, ищет проблемы и точки роста. Со временем этот инструмент стал одним из ключевых элементов Toyota Production System и основой философии бережливого производства, где главный принцип — устранять потери и усиливать ценность без лишних затрат.

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

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

Я поймал себя именно на этом ощущении. Решения становились все более стратегическими, а понимание реальности — менее детальным. А значит, появлялся риск оптимизировать «не туда»: чинить то, что на самом деле не болит, и не замечать того, что действительно тормозит команду.

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

Я не пытался внедрить гемба по канонам Toyota. Я взял главное — пойти туда, где создается ценность, и посмотреть на процесс глазами тех, кто эту ценность производит.

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

аналитика → разработка → тестирование → DevOps.

Для честной картины важно смотреть не на «звезд», а на обычных представителей каждой роли. Поэтому я приглашал аналитиков, бэкенд- и фронтенд-разработчиков, тестировщиков и DevOps-инженеров из разных проектов.

Созвон ставлю за одну-две недели. Этого достаточно, чтобы человек выделил время, но не успел подготовить «театральную постановку» вместо обычной работы.

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

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

Поэтому перед началом я всегда проговариваю три простые вещи:

Это ключевой момент. Если сотрудник чувствует, что его собираются оценивать, он начинает работать «на камеру»: нервничает, старается делать все идеально, прячет настоящие проблемы. В таком режиме гемба не работает.

Формат очень простой:

Важно не вмешиваться в саму работу: не просить «сделай иначе», не давать советов прямо в моменте. Если начинать оптимизировать «на лету», картинка искажается — человек уже не работает так, как привык.

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

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

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

В качестве примера приведу наблюдение за работой аналитика на крупном проекте. Его задача — подготовить программу и методику испытаний для проверки новой версии системы на пред-проде. У аналитика нет готового сценария тестирования — только требования из технического задания. Он формирует сценарий в ходе проверки функциональности.

На входе:

Инструменты:

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

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

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

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

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