LeSS в МТС Кассе 1-я часть (аудит)

19 дек. 2018 г. 4 min read

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

До обучения

Поглощение 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.
Great! Next, complete checkout for full access to Scrum.ru Consulting.
Welcome back! You've successfully signed in.
You've successfully subscribed to Scrum.ru Consulting.
Success! Your account is fully activated, you now have access to all content.
Success! Your billing info has been updated.
Your billing was not updated.