Учимся учиться в МТС Кассе

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

В 2017 году крупнейший российский оператор сотовой связи МТС приобрел контрольный пакет акций компании LiteBox. Компания занималась разработкой облачного ПО для автоматизации розничной торговли, которое включало в себя систему складского учета, управление закупками, аналитику и т. д.

Став частью огромной корпорации МТС, насчитывающей около 70 000 сотрудников, команда LiteBox сохранила практически полную независимость. К моменту внедрения LeSS она действовала как отдельное бизнес-подразделение, штат которого превышал 200 человек.

Ко мне за помощью обратилось руководство МТС. Первые переговоры мы провели в конце 2017 года. С 1 июля 2018 года, как ожидали руководители LiteBox, должен был начаться огромный приток клиентов. Согласно их прогнозам, планировалось увеличение базы пользователей примерно в сто раз. В декабре 2017 года число клиентов LiteBox превысило 6 000, и ожидалось, что к осени 2018 года их численность перевалит за 100 000. Руководство LiteBox стремилось изменить процесс разработки продуктов, сделать его адаптируемым и легко масштабируемым. После нескольких непосредственных встреч с топ-менеджерами мы все согласились с тем, что необходимо начать с серии телефонных интервью, а затем провести тщательный аудит компании.

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

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

Разработка в компонентных командах

Над продуктом работало более 30 разработчиков — они были разбиты на так называемые «проектные команды». Каждый «проект» соответствовал отдельному архитектурному компоненту, технологии или функции. Всего таких «проектов» было семь: «старый бэкенд», «новый бэкенд», «Android», «Windows», «тестирование», «аналитика» и «API».

Комплект технологий включал несколько языков программирования и соответствующих фреймворков: Javascript, Android, Python, SQL и Java.

Координирующие роли и иерархия

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

• руководитель отдела аналитики;
• руководитель отдела тестирования;
• архитектор;
• техлид по бэкенду;
• техлид по Android;
• техлид по Windows;
• релиз-инженер.

Это была обычная, традиционная организация, которая адаптировала терминологию Скрама. Другими словами, чисто фейковая аджайловая команда. После интервью я два дня провёл в офисе, практикуя принцип «Go See» (руководство «Go See»). Помимо механического подхода к Скраму, то есть простого Copy-Paste Scrum, я сразу же заметил еще две вещи:

• целью каждого «проекта» была максимальная утилизация — это определённо было основным фокусом каждого сотрудника;
• разработка в IT-департаменте страдала от огромного количества багов и инцидентов.

У компании была иерархичная и функциональная организационная структура со всеми известными проблемами.

Зависимости

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

Передача промежуточных результатов и каскадная модель управления

Промежуточные результаты неоднократно передавались между компонентами («проектами»), из-за чего возникали длинные очереди, а обратная связь от клиентов поступала с опозданием. Средняя продолжительность цикла создания фичи от момента начала разработки составляла 8–9 недель.

Монофункциональные специалисты

Организационная структура подразумевала роли одной функциональной направленности — бизнес-аналитик, тестировщик или разработчик. Поэтому организация была хрупкой и неустойчивой к изменениям рынка. Новая оргструктура оптимизирована под занятость («утилизацию») всех людей, а не для гибкости и быстрого создания ценностей.

Ограниченное понимание

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

Отсутствие прозрачности

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

Неоптимальное управление требованиями

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

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

• диаграмма Скотта Мортона, демонстрирующая связи между ключевыми элементами компании — стратегией, процессами, людьми и организационной структурой;
• взвешенный SWOT-анализ, создаваемый в смешанных группах, при котором все факторы оценивались по пятибалльной шкале важности;
• Value-Stream Mapping, который позволил нам наглядно увидеть количество потерь в разработке (начиная от запроса клиента и до поставки).

Результаты оценки

Детальная оценка компании подтвердила мои первоначальные выводы о компонентных командах и их проблемах. Value-Stream Mapping также показал, что средняя продолжительность полного цикла разработки фичи составляла 8–9 недель. Меня порадовало, что в ходе воркшопа у топ-менеджеров возникло несколько озарений:

• они согласились, что для компании среднего размера у них избыточная иерархия;
• пришло понимание, что в то время, как индивидуальные KPI и премии оптимизировали работу некоторых отделов компании (продажи и маркетинг), они вызывали конфликт мужду подразделениями;
• участники воркшопа согласились, что у компании нет единого видения и стратегического плана.

Предложения

Не удивительно, что после аудита я предложил следующее:

• провести несколько тренингов по Скраму для IT-разработчиков;
• провести тренинг по Скраму для топ-менеджеров;
• провести мастер-класс по стратегическому планированию, чтобы разработать миссию компании и стратегию на ближайшие 1–2 года;
• постепенно упростить оргструктуру компании и перейти от функциональной организации к линейной кросс-функциональной организации;
• запустить пилотную фиче-команду и в случае успеха продолжать внедрять LeSS.