Когда я читаю описание кейса компании МТС, то понимаю, что речь действительно идет об обучающейся организации и о людях, которые стремятся узнать, как и почему надо меняться. Приглашаю вас прочитать эту замечательную историю о том, как смелые люди смогли запустить бесконечный процесс обучения.
До обучения
Поглощение LiteBox компанией МТС
В 2017 году крупнейший российский оператор сотовой связи МТС приобрел контрольный пакет акций компании LiteBox. Компания занималась разработкой облачного ПО для автоматизации розничной торговли, которое включало в себя систему складского учета, управление закупками, аналитику
Став частью огромной корпорации МТС, насчитывающей около 70 000 сотрудников, команда LiteBox сохранила практически полную независимость. К моменту внедрения LeSS она действовала как отдельное бизнес-подразделение, штат которого превышал 200 человек.
Бизнес-возможности и понимание срочности изменений
Ко мне за помощью обратилось руководство МТС. Первые переговоры мы провели в конце 2017 года. С 1 июля 2018 года, как ожидали руководители LiteBox, должен был начаться огромный приток клиентов. Согласно их прогнозам, планировалось увеличение базы пользователей примерно в сто раз. В декабре 2017 года число клиентов LiteBox превысило 6 000, и ожидалось, что к осени 2018 года их численность перевалит за 100 000. Руководство LiteBox стремилось изменить процесс разработки продуктов, сделать его адаптируемым и легко масштабируемым. После нескольких непосредственных встреч с топ-менеджерами мы все согласились с тем, что необходимо начать с серии телефонных интервью, а затем провести тщательный аудит компании.
Изучение организационной структуры
Организационная структура оказалась достаточно предсказуемой — она основывалась на стандартных управленческих подходах. Компания была структурирована по функциональным направлениям: финансовый департамент, отдел снабжения, отдел продаж, IT-департамент, отдел маркетинга, HR-департамент. Каждое подразделение управлялось отдельной командой руководителей со своими KPI.
Структура IT-департамента
Несмотря на то, что нашей конечной целью была трансформация компании в целом, мы начали с того, что проинтервьюировали сотрудников 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.
