Про метод гемба

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

Знаю от знакомых совсем печальные примеры - когда в Москве разрабатывается софт, обязательный для использования в филиалах по всей стране, но техника, на которой работают в регионах, просто не тянет эти программы. Метрики использования софта 100% - при этом скорость работы на нем намного ниже, чем должна быть. И узнать о причинах кроме как на месте - невозможно (в отчеты такое по разным причинам не попадает).

В подобных случаях недостаточно отчетов, презентаций и исследований рынка, которые присылают агенства - иногда для получения полной картины нужно самому встать за кассу в магазине, обзвонить недовольных клиентов или попробовать оформить заказ в своем же приложении. Это и есть гемба (gemba, 現場) - в переводе с японского “реальное место”, там, где рождается продукт. Гемба пришла из философии бережливого производства Toyota - по этому методу руководители регулярно приходят на места работы своих команд, в цеха, где наблюдают за процессом и ищут возможные проблемы и точки роста. Это помогает не отрываться от реальности, вовремя замечать помехи и - что важно - не пытаться исправить то, что исправлять вообще не нужно.

Мне повезло - на всех местах работы так или иначе использовалась гемба (возможно, где-то не так глубоко, как хотелось бы, но получать инсайты из реальности это все равно помогало). Самый интересный опыт у меня был в Tom Tailor - когда я работала там, гемба для всех офисных сотрудников была обязательной. Раз в полгода ты выбирал себе день и магазин, в котором хочешь поработать, и выходил обычным консультантом. Инструкций для гембы не было - все зависело от того, какую информацию ты хотел бы получить. Хочешь - наблюдай за покупателями и помогай им с выбором одежды из новой коллекции. Или опрашивай консультантов на тему рекламы и акций, насколько хорошо они работают в офлайне. Или вообще переходи на склад и изучай складские процессы. Я так пару дней была в московском ТЦ Европейский 🛍 Было суперполезно - в ковид я полностью отвечала за операционный маркетинг в онлайне, и многое, что придумывала, было вдохновлено собственным опытом гембы.

Еще один классный пример гембы был в Авито - в формате “Eat your own dog food”: каждый сотрудник сам активно пользовался приложением и мог свободно передать собранный опыт в соответствующие отделы. Понятно, что дальше начинается приоритизация бэклога из сотни других задач. Но тем не менее - собранная информация всегда помогала быстрее находить реальные проблемы и не портить опыт пользователя при разработке нового продукта.

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

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