Бикеш Курмангалиева, Казахтелеком: гибкий подход — основа при выборе методик управления проектами

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

Agile достаточно распространен среди высокотехнологичных компаний. Кроме того, постепенно из методологии разработки программного обеспечения Agile трансформируется в целую философию ведения бизнеса. С прошлого года практики Agile стали активно внедряться в АО «Казахтелеком», где в рамках тестирования запущены две команды, нацеленные на создание новых продуктов и реализацию одного из инновационных проектов на основе Big Data.

Создание новых продуктов с применением Agile может значительно сократить их срок запуска, а значит — повысить степень удовлетворенности клиентов, что является одним из ключевых требований современного бизнеса. «Казахтелеком», являясь крупнейшим казахстанским оператором связи, в очередной раз подтверждает свое стремление к использованию самых передовых наработок и практик. Сегодня в «Казахтелекоме» происходит цифровая трансформация, которая затронет все подразделения и внесет большие изменения в бизнес-процессы. Одним из инструментов таких изменений и является Agile. О том, какие задачи планируется решить с помощью этого подхода, в интервью Profit.kz рассказала Бикеш Курмангалиева, управляющий директор по ИКТ-услугам АО «Казахтелеком».

— Бикеш Кайдаровна, как создавалась Agile-команда Казахтелекома? Почему у компании возникла такая необходимость?

— Сейчас у нас активно идет цифровизация продуктов. Для этих целей нами создаются Agile-команды: одни работают над цифровыми каналами продаж, а другие реализуют комплекс проектов на основе технологии Big Data. Как вы знаете, создание новых направлений бизнеса на основе Больших данных становится мировым трендом, для телекома это особенно актуально. Чтобы удовлетворять динамически изменяющиеся потребности наших клиентов, необходимо хорошо их знать, анализировать поведение, предпочтения, предвосхищать ожидания. То есть мы должны анализировать данные о клиентах, о рынке. Эти проекты являются новыми, в них у нас еще нет накопленного опыта, сами продукты только разрабатываются. И мы решили, что такие проекты являются лучшими кандидатами на реализацию по модели Agile.

В этом году кроме проекта на основе Big Data мы пилотируем много других проектов, таких как блокчейн, Интернет вещей, 5G. Уже буквально в следующем году планируется выводить в тираж новые продукты. К массовому тиражу должны быть готовы наши цифровые каналы продаж и обслуживания клиентов. По каждому активному проекту практически каждый день от бизнеса поступают новые запросы на изменение и развитие. Мы их собираем в так называемый единый «бэклог», после чего задачи разбиваются на блоки по приоритетам, и по этим блокам ведется реализация двух-трех-недельными спринтами. Если бизнес удовлетворен результатом, реализованный блок выводится на портал. Это кардинально отличается от прежнего процесса создания продуктов способом «водопада». Конечно, он был более полнофункциональный, но поступал в пользование только через год.

Представьте себе такой процесс: в начале года у какого-то подразделения появляется потребность в определенном функционале. Далее в течение года дополняются потребности от подразделений в части разработки ПО, а в конце года формируется и согласовывается техническая спецификация на разработку/доработку. На следующий год объявляется конкурс и определяется подрядчик, далее подрядчик реализует функционал по технической спецификации. В идеальной ситуации подрядчик делает все правильно и добросовестно. Но даже в этой ситуации от появления потребности до ее реализации проходит примерно год. За это время может поменяться все что угодно. Тем более сейчас, когда мы конкурируем за клиента не только с телеком-операторами, но и интернет-компаниями, банками. Именно поэтому мы решили провести эксперимент и перевести проектную деятельность в Agile-формат.

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

— Эти проекты очень важны для компании. В целом, телеком — это кандидат номер 1 на обслуживание через цифровые каналы, тем более, технологии автоматизации телекома сегодня уже все в цифровом формате. У нас и все технологические системы уже в цифре, естественно, что и обслуживание должно быть в цифре. Поэтому основная причина того, почему мы начали эти проекты — они высокоприоритетны. Теперь о том, почему мы решили их реализовывать именно по модели Agile. Такие системы очень сильно зависят от клиентского опыта, так называемого custom experience. Поэтому они должны делаться с учетом предпочтений, замеров и поведения клиента. Одно дело, когда клиент традиционно обслуживается в офисе: там оператор или менеджер сам управляет процессом взаимодействия с клиентом, т. е. он задает какие-то наводящие вопросы, видит реакцию клиента, какие-то его проблемы, боли. А при цифровом канале продаж клиент остается один на один с системой, и она должна привести его к покупке какой-то услуги. А если это уже существующий клиент, то провести по пути обслуживания, чтобы он остался удовлетворен. Допустим, это получение счета-фактуры, акта выполненных работ либо выписки, проверки оплаты, баланса и т. д. Именно поэтому, когда мы делаем дизайн или разработку функционала, очень важно постоянно производить замеры — насколько то, что мы внедряем, соответствует лучшим практикам обслуживания клиентов, и на ходу изменять что-то, если это не так. Естественно, это проще реализовать, когда команда делает весь комплекс работ маленькими итерациями, замеряет и улучшает — это и есть, собственно говоря, Agile, как модель разработки продукта.

А методология у нас называется Scrum. В чем отличие от традиционных, как мы говорим, «водопад-проектов»? В «водопаде» сначала тщательно разрабатывается техническое задание, где необходимо предусмотреть и описать в техническом задании все, вплоть до кнопочек, макетов, дизайна и т. д. Расписать весь функционал и дать это разработчикам, которые сдают работу согласно этого ТЗ. При таком подходе реализация может занять очень много времени.

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

Наш второй продукт, который мы развиваем по методологии Agile — это проект Big Data. Здесь история аналогичная — традиционный подход был бы попросту малоэффективен. «Казахтелеком» обладает огромным массивом данных, накопленных у себя, плюс данные, связанные с нашими клиентами, которые лежат в открытых источниках. Перед компанией стоит задача того, как все эти данные использовать на благо самих клиентов, сделать полезные сервисы. Естественно, это нетривиальная задача. Поэтому мы решили, что данный проект также должен двигаться по модели Agile. Тем более, мы все только погружаемся в огромный мир Big Data, и опыта еще недостаточно, в связи с чем здесь мы тоже идем таким итерационным методом.

— Что оказалось самым сложным при создании Agile-команды?

— Создание команды оказалось не самой простой задачей, потому что люди из разных подразделений должны были работать вместе в одной Scrum-команде с преимущественно полной загрузкой в рамках нового проекта, при этом они имели определенные задачи по текущей деятельности. Менталитет, культура работы — все нужно было менять в рамках Agile-проекта.

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

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

— При традиционной разработке у разработчиков есть какие-то метрики, КРI. А как вы измеряете целевые показатели эффективности команд в Agile-проектах?

— Здесь эффективность более ощутима и прозрачна, поскольку все разработчики на себе чувствуют показатели. Если при традиционном методе ты можешь допускать неэффективность в течение длительного периода, и это обнаруживается лишь на поздних стадиях, то здесь, учитывая, что у команды спринт и у каждого есть свои показатели и конкретные задачи, неэффективность видна сразу. Например, конкретный разработчик делает какие-то задачи, и это каждый день мониторится на своеобразных 15-минутных стендап-митингах. Scrum-мастер постоянно наблюдает за эффективностью членов команды, делает выводы. И если у разработчика не хватает квалификации или есть проблемы со взаимодействием, с пониманием задачи и т. д., то Scrum-мастер может очень оперативно отреагировать на задержки. То есть, учитывая публичность и наглядность, когда разработчик перед всей командой каждый день должен отчитываться о результатах своего прошедшего рабочего дня, естественно, появляется дополнительное чувство ответственности. Психологически такой подход «подстегивает» людей, поэтому здесь показатели работают очень четко и сразу видно, кто вписывается в команду, а кто — нет.

Вместе с тем, чувствуется, что в Казахстане культура разработки еще не стабилизирована так, чтобы все могли работать в Agile и Scrum. Есть люди, которые не чувствуют время, не могут правильно оценить трудоемкость — это тоже, кстати, проблема того, почему не исполняются планы. Обычно, если Scrum-команда новая, то первые 2-3 спринта идут на «раскачку». Но если примерно к пятому спринту члены команды не научились правильно планировать и оценивать производительность, значит что-то идет не так, есть проблемы в правильности подбора команды. И здесь уже надо принимать серьезные организационные меры. Этому подходу тоже надо учиться.

— Когда вы только сформировали свои команды, привлекали ли вы каких-то внешних консультантов? Все-таки, для работы в Agile нужно действительно перестроить всю структуру внутри команды, нужно научить людей…

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

— Использование столь инновационного подхода к созданию продуктов и сервисов, как Agile, можно было бы ожидать скорее от стартапа или небольшой компании. Как удалось перестроить бизнес-процессы такой большой структуры, как Казахтелеком? И каким образом удалось убедить топ-менеджмент в необходимости использования Agile?

— Топ-менеджмент состоит из достаточно прогрессивных людей, которые сами постоянно находятся в поиске лучших решений. Поэтому убеждать их не было нужды. Больше сложностей у нас возникло на уровне среднего менеджмента. Мы начали использовать Agile в рамках небольших атомарных проектов, которые можно назвать условными стартапами.

Вместе с тем нужно понимать, что Agile — это не «серебряная пуля», и этот подход не подойдет для всех проектов. Проекты по методологии реализации и внедрения условно можно разделить на два типа. Один тип — это крупные, реализованные на готовых решениях от мировых вендоров — Oracle, Amdocs, SAP. Они обеспечивают работоспособность основных процессов компании — биллинг, CRM, ERP. Эти проекты можно и нужно реализовывать по методике «водопад». Однако при их реализации необходимо придерживаться открытой архитектуры и предусматривать открытые интерфейсы (Application Programming Interface) для взаимодействия с другими системами. Реализация же фронт-эндовых приложений, продуктовых сервисов, требования к которым быстро меняются, можно реализовывать по Agile. Именно такой подход мы и взяли на вооружение.

— В Казахстане об опыте Agile в столь крупных компаниях рассказывают очень мало, возможно из-за малочисленности подобных проектов. Как вы решились на применение данной методологии? Не было страха, опасений?

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

— Существуют ли какие-то Agile-принципы, которые оказались неприменимы в структуре Казахтелекома?

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

— Оправдал ли себя новый подход? Можете привести промежуточные результаты, поделиться успешными кейсами?

— Agile, безусловно, приносит свои плоды. Ярким примером удачного кейса я могу назвать разработку системы электронного документооборота — СЭД — для клиентов АО «Казахтелеком», которая была реализована как часть Открытой цифровой платформы Ismet.kz. Идея создания СЭД появилась по ходу реализации проекта, и MVP (продукт с минимальным функционалом) был реализован и предоставлен клиентам в течение всего лишь полутора месяцев от момента появления идеи. Мы не смогли бы этого сделать при традиционном подходе. С радостью отмечу, что на текущий момент нашей системой электронного документооборота заинтересовались многие компании. И, конечно, нельзя не упомянуть проект по аналитике данных. Мы используем Big Data для повышения качества продаж, также интересный кейс использования Agile-подхода.

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

— Можно ли говорить о старте эпохи Agile в Казахтелекоме, или же вы пока присматриваетесь к методологии?

— Тут я могу сказать однозначно, поскольку у нас в компании уже принята новая стратегия, в основе которой при реализации новых продуктов лежит именно Agile-подход. Для нас это будет некий стандарт, и все бизнесы теперь будут инициаторами, а службы IT войдут в команду как часть реализации. Поэтому уверенно можно сказать, что в компании началась эпоха Agile.

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