Эджайл – это модно или полезно? Не знаю, как бы мы ответили на этот вопрос года три назад, а сейчас однозначно: это полезно и нужно! Именно благодаря Agile-подходам нам удалось успешно воплотить довольно давнюю идею и запустить в компании важнейший проект по созданию хранилища мастер-данных «М.Каталог». Но дело не столько в нем – кардинально изменились мы сами, что еще не раз покажет себя на новых проектах. Попробуем описать, в чем заключаются эти перемены и чем они полезны.
Привет, хабр! Меня зовут Александр Иванов, я бизнес-аналитик по направлению мастер-данных в Группе М.Видео-Эльдорадо. Сегодня мне предоставили трибуну для рассказа о том, как мы все успешно «эджайлимся».
Все товары – в одном каталоге
Сначала в общих чертах напомню, что такое «М.Каталог» и почему именно этот проект спровоцировал наше глубокое «погружение в эджайл». Если представляете объем работы М.Видео-Эльдорадо, будет понятно, что сбор и хранение информации о десятках тысяч товарных наименований – задача, достойная Геракла и его тринадцатого подвига.
Разумеется, инструменты для этого (типа Description Keys) были уже давным-давно, но они не позволяли автоматизировать процесс, да и вообще оказались «в быту» очень неповоротливыми.
Между тем ассортимент неумолимо рос, появлялись новые каналы продаж. Скорость заведения новых товаров в систему должна была увеличиваться и измеряться не неделями, а часами – а старая архитектура, где любые запросы на изменения шли через поддержку, «ускоряться» не давала. Словом, нужно было что-то делать.
Любопытно, что идея создать современное глобальное хранилище мастер-данных (его мы и назвали «М.Каталог») пришла еще в 2016-м. Однако только в прошлом году удалось получить работающую версию, а «доводка напильником» идет и сейчас – и будет идти дальше параллельно с цифровой трансформацией компании и созданием единого OneRetail-пространства.
Тем не менее, мы получили хранилище, где характеристики всех товаров лежат в эталонном формате. Можно фильтровать по моделям, каким-то отдельным характеристикам (к примеру, отобрать все вентиляторы с синим корпусом), а в «предложку» к основному товару выкладываются только те, которые подходят потребителю – скажем, не все подряд батарейки для пульта, а только АА. На словах это выглядит просто, на деле при таком количестве разношерстных товаров труд реально большой. А продолжается он в ходе превращения «М.Каталога» в полноценный PIM.
Однако стоп: в технические детали проекта углубляться не будем – публикации на этот счет уже были, кто ищет – тот всегда найдет. А вот какие новые подходы помогли сдвинуть проект? Тот самый эджайл, о котором сейчас можно услышать из каждого утюга. Но для нас переход на новые рельсы оказался не данью моде или «указанием сверху» (в нашей компании движение идет наоборот, «снизу», от IT), а реальным решением массы рабочих задач. Обозначу несколько главных вех этой эджайл-трансформации, которая началась именно с команды проекта «М.Каталог» как создателей мега-инструмента для обработки всей товарной информации.
Бизнес и ИТ – в одной команде
Да, пусть названия главок будут спойлерами. Но это критически важно: без крепкой дружбы с бизнес-подразделениями никакой эджайл не запустишь. Ведь что было раньше: IT – в своей тарелке, бизнес – в своей, причем считает IT не более чем инструментом. Довольно дорогим инструментом. Но когда наша команда начала постигать основы Agile, пришло новое понимание: мы – не простые исполнители. IT имеет ту же цель, что и бизнес – приносить компании деньги. А значит, нужно объединяться!
Что это означает на практике? Прежде всего, активное общение, обмен мнениями, чего почти не было раньше. В крупных компаниях айтишники часто получают ТЗ, даже не видя в глаза заказчика. От этого появляются недопонимание и никому не нужная бюрократия. А ведь ничто не мешает встретиться и поговорить еще на этапе зарождения идеи. Мысль простая, но до нее нужно еще дойти.
Второе последствие такого объединения – Vision отдают нам, IT-специалистам: «Ребята, сами придумывайте что-то новое, но компания должна двигаться вперед». По сути, в нас инвестируют. И чем большую пользу мы приносим бизнесу, тем охотнее. Мы постепенно уходим от бюджета IT – есть бюджет продукта, который создается совместными усилиями. О других плюсах объединения IT с бизнесом буду рассказывать и дальше, а сейчас спойлер номер два.
Берите Star Map – и становитесь T-shaped
Это касается всех, а IT – в первую голову. Иначе какое видение будущего, какой Vision! Честно говоря, и внутри нашей команды внедрение эджайл-инструментов поначалу шло туго. Иные говорили: «Я и так нормально работаю, дают задание – я его выполняю. Зачем мне еще какой-то эджайл?!» Но все изменилось, когда наши скептики опробовали подходы и фреймворки, которые предлагает эджайл.
Во-первых, каждому стало намного яснее, зачем и для кого мы делаем «М.Каталог» и какие бонусы получаем от этого сами. Во-вторых, новые инструменты оказались удобнее. Так, мы освоили Star Map. Чего и вам желаем.
«Звездная карта» помогла не просто оценить компетенции каждого сотрудника. По ней ты ясно видишь, кто в состоянии тебе помочь или вообще заменить в случае необходимости. Скажем, тестировщик занят (они всегда заняты и их вечно не хватает) – тогда роль тестировщика берут на себя, например, разработчики, у которых на Star Map стоят звездочки в соответствующих столбцах. Менее загруженный специалист выполняет задачу, чтобы она не простаивала.
И вот тут мы возвращаемся к мысли про T-shaped. Узкий специалист – тот, кого называют I-shaped – конечно, не справится с «чужой» задачей. Но в Agile уже нет «чужих» задач. Напомню: есть общая цель, общий бюджет проекта и командная (не персональная, как некогда!) ответственность за результат. Поэтому и передача Vision в IT-подразделения не является «взваливанием» на плечи айтишников непрофильной работы – так мы доказываем, что инвестировать в нас можно и нужно.
Мы все – в одной лодке! «Ай-шейпы», копающие свой огород и не интересующиеся, что происходит за забором, в новую схему уже не вписываются. А вот «ти-шейпы» с более широким взглядом и набором компетенций оказываются главными двигателями прогресса.
Впрочем, речь не только о движении вперед: благодаря Star Map и хотя бы частичной взаимозаменяемости T-специалистов снижается общая нагрузка на систему. У тебя так много задач, что уже дым из ушей? ОК, вот тебе помощники! А если ты сам кому-то помогаешь – это тоже хорошо.
Любой айтишник поймет: когда наряду с собственными, часто рутинными и однообразными задачами, решаешь другие, новые для себя – это отодвигает опасность выгорания. И сам отвлекся, и команде помог. С T-shaped вообще неважно, кто ты сейчас в команде: можешь стать разработчиком, «фронтовиком», кем угодно. Специалисты не уходят из-за выгорания, а трансформируются вместе с компанией, это очень важно.
Часть продукта – тоже продукт
Это еще одна важная мысль, освоенная нами в ходе эджайл-трансформации. Чем, честно говоря, опасен Waterfall? При «водопадном», последовательном решении задач годный продукт появляется лишь в самом конце цепочки. Пока его передают из рук в руки, проходит довольно много времени – может оказаться, что он уже и не нужен. Или нужен, но совсем не такой. Подпрягается и проблема ответственности. На уровне аналитика вроде все нормально. Все хорошо у разработчика. Все звенья как будто в порядке – только в крепкую цепочку не собираются.
Эджайл – это совсем иные подходы. Не только в силу коллективной ответственности проектной команды. Образно говоря, Waterfall – это сбор «Моны Лизы» из паззлов. А теперь представьте, что заказчику показывают только несколько паззлов с фрагментом пейзажа. «Ну и где портрет?» – законно спросит он. Agile начинается с наброска – уже на этом этапе понятно, как будет выглядеть вся картина. То же самое с IT-продуктами.
Если раньше мы были вынуждены доводить их до полной готовности и только потом отдавать пользователям (и вот тут они начинали жаловаться на «не тот» функционал и прочие баги), то с Agile можно отдать «на поюзанье» уже прототип – первую, но вполне рабочую версию. И честно попросить: «Это еще не окончательный каталог, но посмотрите и скажите, что тут нужно, что – нет, какие кнопки куда переместить и вообще, как сделать продукт более удобным для вас?» Собираем ответы – и доводим до окончательной готовности только то, что правда нужно. Но всё это время продукт в доступе и работает.
Как отказ от «водопада» отражается на нашей работе и взаимодействии с бизнес-подразделениями? Самым положительным образом. Декомпозиция задач позволяет IT получать что-то полезное поэтапно и в короткие сроки. Раньше у бизнеса был главный вопрос к IT: когда вы покажете готовый продукт? А мы были готовы делать это, скажем, раз в полгода или вообще раз в год. Бизнес нервничал и думал, что зря дает IT столько денег.
Эджайл позволяет фактически каждые две недели демонстрировать результат – ждать его на таких условиях гораздо легче. Если говорить конкретно о нашей компании, то мы вообще уходим от ответа на вопрос «когда сделаем». Сейчас мы говорим, сколько успеем сделать за определенное время. Ново, непривычно, но такая работа намного эффективнее.
Обращайтесь к эджайл-коучам!
Хочется завершить вот этим «выстраданным» советом. Команда «М.Каталога» первой в компании «врубалась» в эджайл. Я был одним из инициаторов и могу сказать, что набил много шишек, пока не объяснил даже ближайшим помощникам, зачем все это нужно.
Но в начале 2021 года нам повезло: корпоративный отдел обучения включился в решение проблемы, и с нами начали заниматься профессиональные эджайл-коучи. Это уже совершенно не то, что втолковать плюсы Agile своими силами. Идите к коучам сразу, сэкономите массу времени и сил.
Конечно, пока далеко не все в компании вообще столкнулись с Agile, у нас и сейчас много Waterfall-проектов. Компания проживает переходный этап. Но новые эджайл-отношения связывают уже не только бизнес и IT. Мы начали синхронизироваться и с другими отделами. И если раньше просто сделали бы для них продукт по ТЗ и отдали им, то сейчас делаем его вместе.
Тот же принцип постепенной коллективной доводки проекта: есть проблема – все узнают о ней тотчас, сообща думаем, как быстро исправить. Лучше чинить мотор в дороге, чем на конечной остановке менять машину целиком.
