Привет, Хабр! Меня зовут Андрей Китов, я технический директор одного из доменов X5. Уже пару лет мы работаем с технологиями для бизнеса в рамках доменной структуры. Это необычный подход, как и мой опыт смены профессии внутри одной компании. Об этом я и решил рассказать. Статья, надеюсь, будет интересна тим-лидам, инженерам, менеджерам по сервисам и тем, кто хочет пойти в управление проектами.
Сразу оговорка – это не скучный рассказ о корпоративной иерархии. Я хочу поделиться своей историей, чтобы вы сами не ставили себе барьеров – можно не только освоить новую профессию, но и стать в ней одним из лучших.
Андрей Китов
Технический директор домена «Операции и эксплуатация "Пятёрочки"»
В Х5 всё начинается с «Пятёрочки». Вот и я пришел в торговую сеть в 2015 году на должность менеджера по сервисам. Тогда подразделение сервис-менеджеров только начинало формироваться в X5 под потребности «Пятёрочки», я стал пятым человеком в команде. Мне досталась работа с сервисами «Ведение мастер-данных о товарах», «Управление розничными ценами», «Управление ПРОМО» и другие.
Основная задача, которая перед нами тогда стояла – внедрить сервисный подход в компании. На тот момент в X5 уже был свой ИТ: поддержка, инфраструктура, разработка, проектный офис, даже были карточки сервисов и как-то считался SLA. Но каждое подразделение существовало в своих процессах, не поддерживая связь между собой, а заявки «футболились» между направлениями поддержки. Одним словом, не было чётких правил игры. Процесс передачи проектов в поддержку всегда превращался в «танцы с бубном» и напоминал «тушение пожара», потому что функционал разработан и внедрён, а вот процессы для решения инцидентов по нему не отлажены. Получалось, что в случае аварии привлекаются разработчики проекта, которые уже давно занимаются другими активностями.
Первое, что нам предстояло сделать – это оценить уровень зрелости, как есть: понять, какие процессы уже работают, какие метрики есть и как они считаются, а также наладить взаимоотношения со смежными службами. И именно эти отношения стали для нас одним из главных вызовов. Изначально нас не воспринимали всерьёз, большинство не понимало, для чего мы вообще нужны. Поддержка работала, инциденты решались, у каждого руководителя была налажена какая-то своя отчетность. И в целом всё работало, а тут мы с метриками, процессами, задаём неудобные вопросы, предлагаем меняться.
Следующим шагом стал выбор методологии. Мы остановились на набирающей тогда популярность методологии ITIL (Information Technology Infrastructure Library), которая послужила базой и вектором нашего будущего развития. ITIL – это набор лучших практик, который предоставляет рекомендации по организации работы ИТ. Если вы с ней ещё не знакомы, очень рекомендую к изучению всем, кто связан с поддержкой или сервисами. Она помогает структурировать разрозненную информацию в голове. Плюсы ITIL, которые мы тогда для себя выделили – это лёгкость адаптации методологии под нас, понятный и общепринятый глоссарий, доступность обучения и простота внедрения. Так как какие-то процессы уже работали, нам надо было их просто слегка подтянуть.
Со временем у нас сформировалось чёткое понимание того, что такое сервис, для чего он нужен, какие у него параметры и т. д. Мы настроили отчётность, начали работать со смежными функциями по выстраиванию процессов и постоянно взаимодействовали с бизнес заказчиками по улучшению качества обслуживания.
Самым сложным было принять, что теперь у нас всё красное. SLA упал до 30% по некоторым сервисам, при том что работа поддержки не менялась – мы просто изменили методику расчёта. Из-за этого мы сталкивались с непониманием со стороны бизнеса. К счастью, нам удалось объяснить необходимость изменений и значимость прозрачного расчёта SLA. Сейчас у нас SLA примерно 98%, а показатель доступности не опускается ниже 99,8%.
На «наведение порядка» у нас ушло два года. Примерно в это же время я стал старшим сервис-менеджером, а затем менеджером направления. В моём подчинении было несколько сервис-менеджеров, у каждого из которых был свой пул сервисов. Я же выполнял роль старшего наставника и при этом отвечал за более критичные сервисы.
Что такое сервисы в «Пятёрочке»
Начну с очевидного: ИТ-сервис это набор инструментов и технологий, обеспечивающих работу бизнес-процессов. Если описывать, какие процессы предшествуют тому, чтобы вы могли купить свежие и вкусные помидоры в ближайшей к вашему дому «Пятёрочке», то можно выделить такие этапы:
Закупки
Управление магазинами (более чем 19 000 «Пятёрочек» в стране)
Маркетинг и реклама
Управление персоналом (более 300 000 сотрудников по всей России)
Финансовое управление
Логистика и доставка
Впечатляет, правда?
Если коротко, то сервисы можно сравнить со слоёным пирогом: первый уровень – бизнес-процессы и бизнес-операции, второй уровень – это программное обеспечение, в котором эти процессы и операции происходят, третий – платформы, и под этим всем идёт инфраструктура. Каждому уровню присваиваются индивидуальные SLA: за какое время, по каким маршрутам, что и как мы должны чинить. Сервис-менеджер отвечает за то, чтобы это всё работало, как часы, и чтобы все сроки соблюдались. Он также проектирует эти сервисы, модернизирует и отвечает за их вывод из эксплуатации.
Если изобразить схематично, то выглядит это так:
Помимо этого, каждому из сервисов и уровней должен быть присвоен свой уровень качества и это должно между собой биться. Нельзя выстроить сервис таким образом, чтобы инцидент по системе решался за два часа, а инцидент по инфраструктуре в рамках того же сервиса – за четыре. Это приведёт к тому, что SLA будет постоянно в просадке.
Как пример:
Мой рост внутри сервис-менеджмента
Через три года работы мой начальник получил повышение внутри компании и рекомендовал меня на должность начальника отдела сервисов в «Пятёрочке». С этого момента я стал руководить подразделением. Не скажу, что мой уровень экспертизы был выше, чем у ребят, работающих со мной. Но я точно знал, как реализовать разработанную ранее стратегию. Команда меня поддерживала, и это придавало уверенности. Наше подразделение на тот момент состояло из 12 менеджеров по сервисам, но уже через два года мы выросли в управление, состоящие из менеджеров по сервисам, методологов, инженеров поддержки проектов и аналитиков данных.
В это время в компании был запущен проект по замене ITSM системы в рамках миграции на новую ИС. Наконец наступил момент, когда мы могли реализовать все наши наработки на новой системе. Мы обновили все справочники и сразу внедрили правильные процессы управления каталогом сервисов, инцидентами, конфигурациями, запросами на обслуживание, проблемами и т. д. Так, спустя 1,5 года мы перешли на новую ИС, с совершенно новыми процессами, с полностью переделанным каталогом сервисов, которыми мы пользуемся до сих пор.
Для меня это был важный проект. Именно здесь я столкнулся с сопротивлением и ситуациями, когда есть сроки и нужно внедрить хоть как-то. Но тебе-то надо не абы как, а чтобы стало лучше. Тогда я отстаивал переход на новые каталоги и новые подходы, участвовал в проработке материалов, регламентов, очень детально был погружен во все аспекты и нюансы. Думаю, именно моя погруженность и помогла отстоять разработанные подходы. С этого момента я начал понимать, что границ нет. Если веришь, то работай с сопротивлением, улучшай аргументацию, будь вовлечён.
Ещё одна проблема, которую надо было решить – это поддержка продуктов и проектов на стадии разработки. У нас был выстроен процесс передачи проектов на поддержку, но с продуктами мы столкнулись впервые. Магазины писали о своих проблемах, команды бросали всё и начинали выявлять причины, искать баги. Количество обращений только увеличивалось и это приводило к неприятным последствиям. Мы поняли, что таким командам при выходе на определённые объёмы пользователей, нужна постоянная поддержка. Но так как функционал постоянно развивается, простая схема поддержки (1, 2, 3 линии поддержки) нам не подходила. Нам нужны были инженеры уровня 2, 3 линии поддержки, которых мы сможем оперативно подключать в команды. Ребята должны были сами общаться с разработчиками, готовить инструкции для себя и для будущей передачи в поддержку, решать обращения от пользователей и давать обратную связь команде. Мы искали заряженных бойцов, которым было бы интересно ковыряться в новом и которые не были бы связаны жёсткими рамками. Так у нас появилась служба поддержки проектов/продуктов.
В этот момент мы также задумались о том, что мы мониторим много параметров, и с этим огромным количеством данных можно и нужно работать. К примеру, логи с касс могут рассказать о том, с какой скоростью работает тот или иной производитель оборудования, как быстро выполняются бизнес-операции, как влияет то или иное изменение на производительность, как быстро пробивается тот или иной товар. С их помощью также можно измерить скорость работы кассиров. В результате мы начали развивать бизнес-мониторинг, и у нас появились аналитики данных.
В целом, опыт работы в сервисах дал мне чёткое представление о том, как работает ИТ, как все процессы связаны между собой и как этим можно управлять. Конечно, пробелы в навыках и знаниях были. Я закрывал их не только в процессе работы. Изучая ITIL, я прошёл все курсы по третьей версии, учил проектную и продуктовую методологию и никогда не стеснялся спрашивать, если что-то не понимал. Иногда даже у своей команды. У многих экспертиза была выше, и я не видел в этом ничего зазорного для руководителя.
На самом деле, я считаю, что команда – это главный рычаг. Если доверие на высоком уровне, открытость – это норма, а люди не боятся предлагать идеи, то вместе вы точно сможете свернуть горы.
Переход в домены и что это такое
В 2020 году Х5 Group решила сосредоточить экспертизу по цифровому развитию в отдельной бизнес-единице – Х5 Tech, и ДИТы торговых сетей перешли туда. Многие ребята из сервисов «Пятёрочки» стали начальниками управлений и отделов внутри компании.
В рамках этой трансформации моё подразделение сервисов ушло в другое направление – в функцию поддержки. А я выбрал другой вектор развития и пошёл в новую для компании структуру – домены, руководителем направления «Технологии продаж в домене «Операции и эксплуатация торговой сети «Пятёрочка».
Домен – это единая точка взаимодействия бизнеса и IT. Главная задача доменов – это максимально реализовать технологический потенциал в бизнес-подразделении.
В рамках своей деятельности мы взаимодействуем с бизнес-подразделениями по вопросам технологического развития, формируем оптимальный технологический ландшафт, реализуем портфель инициатив технологической составляющей, обеспечиваем устойчивость и масштабируемость ИТ-систем и сервисов.
Домены тогда были новой функцией, и они только формировалась в компании. Мне досталось интересное направление в рамках операционной деятельности бизнеса. В него входило всё, что связано с технологиями в магазинах: кассы, торговое оборудование, программное обеспечение, то, что имеет отношение к росту производительности магазина.
Для меня переход не был простым решением. До этого я работал в поддержке и не занимался напрямую проектной/продуктовой деятельностью, а тут и управление бюджетами, и запуск инициатив, и многое другое, с чем я не сталкивался вплотную. Но я понимал, что дальнейший путь в поддержке или сервисах уже не даст мне нового развития, а кусок с проектной деятельностью у меня сильно выпадает. Так что подумал, решил и пошёл.
Страха не было. Я знал, что хорошо ориентируюсь в компании, понимал, кто за что отвечает и к кому с каким вопросом можно обратиться. Да и с бизнесом у меня был налажен контакт ещё со времен сервисов. Довольно быстро получилось разобраться во всех процессах, что-то переделать под себя, наладить работу и начать в полной мере помогать бизнесу становиться лучше. Так что сейчас я о своём решении нисколько не жалею.
Позже я стал техническим директором домена «Операции и эксплуатация "Пятёрочки"». И тут мой мир изменился. Уровень ответственности был повышен многократно, мне досталось одно из самых больших направлений бизнеса. Сейчас объём портфеля ИТ-инициатив составляет порядка 15 запущенных проектов и продуктов и ещё 40 находятся в проработке.
Что для меня было самым сложным в смене профессии
Домены для меня были новым направлением – в этом и заключалась главная сложность. Несмотря на то, что я занимался сервисами, очень плотно взаимодействовал с проектным офисом и хорошо разбирался во всех проектах, я не запускал их. Моя ответственность заключалась в передаче этих проектов/продуктов на поддержку.
В новой роли мне нужно было становиться исполнителем, у меня появилось больше работы руками, нужно было детально погружаться в процесс проектного подхода, в новые agile-методы, в то, как строятся и запускаются продукты. То есть у меня переключился фокус, и это был некий переломный момент и, конечно, точка роста для меня. Примерно полтора года я занимался развитием этого направления и одновременно своим собственным развитием, максимально погружаясь во все рабочие процессы.
Тогда я начал изучать методологии Agile, Scrum, Kanban и др. Знакомился с лучшими практиками проектного управления, Prince-2, PMBOK. Прошёл курс обучения MBA в РАНХиГС – там достаточно широкая программа, в которой есть управление организацией и проектами в том числе. Все эти курсы помогли мне структурировать знания и лучше понимать, какие методики и где стоит применять.
К слову, почти все курсы я посещал при поддержке компании. В X5 не только оплачивают обучение, но и предлагают немало курсов и программ развития внутри самой компании, которыми я до сих пор с удовольствием время от времени пользуюсь.
Управление командой – что я вынес из опыта работы с людьми
Сейчас моя команда состоит из 12 человек: три руководителя направления, два менеджера развития информационных технологий, два аналитика домена и руководители проектов, которые отвечают за реализацию задач с IT-составляющей. Но это только верхушка айсберга: если посчитать, сколько ресурсов выделено под наш домен для реализации инициатив и сопровождения систем в эксплуатации, то цифра перевалит за 500 человек: это и разработчики, и аналитики, и тестировщики, архитекторы, дизайнеры, сервис-менеджеры, Devops, инженеры и многие другие. Всё это центры компетенций, которые управляют людьми административно и обеспечивают нас высококвалифицированными ресурсами.
Управление командой – это, скорее, философская тема, рассуждать на которую можно очень долго. И тут нет какого-то одного гениального совета или волшебной пилюли. Здесь самое важное, на мой взгляд, опираться на внутреннюю эмпатию и чутьё. Руководитель должен чётко понимать свои цели и задачи, а команда – куда она идёт и зачем.
Лично я сформулировал для себя ряд принципов в работе с командой, которые доказали свою эффективность. Уверен, вы слышите о них постоянно, но они и правда работают, я убедился в этом на своём опыте.
Открытость и честность. Пожалуй, для меня это два самых главных принципа в работе. Я следую им сам и транслирую своей команде. Важно не бояться признавать свои ошибки и делать так, чтобы твоя команда тоже этого не боялась. Если тебе открыто говорят об ошибках, вы всегда можете их вместе исправить.
Взаимопомощь. Я всегда пытаюсь донести до своих ребят мысль: если к тебе пришли с какой-то проблемой, помоги её решить. Если пришли к тебе, а не к кому-то другому, значит, в тебе увидели того человека, который может помочь. Если ты не знаешь, как решить эту проблему, найди того, кто знает, подключи его к задаче и проконтролируй до финального решения.
-
Делегирование. В роли руководителя я всегда стараюсь максимально делегировать полномочия своим ребятам, потому что, если всё время брать на себя ответственность за них, это ни к чему хорошему не приведёт. Ты замкнёшь на себе процесс принятия всех решений, и в итоге не будешь получать интересных идей и суждений со стороны, которые могли не прийти тебе в голову. Соответственно, и результаты работы будут адаптированы под тебя.
Отдавая больше полномочий и ответственности людям из своей команды, ты прокачиваешь их скиллы. Чем чаще они принимают самостоятельные решения, тем стремительнее развиваются. При этом они должны знать, что руководитель всегда поможет, если к нему прийти с вопросом или проблемой. И это очень важный момент.
Я не прокачивал скилл делегирования специально. Просто я не боюсь брать в команду людей сильнее меня. Это моё кредо. К ним больше доверия, соответственно, им даётся и больше свободы в выборе действий. С ними я постоянно развиваюсь и как профессионал, и как руководитель.
Командность. Крайне важно, чтобы у команды были единые цели и задачи, чтобы все знали, куда они идут, кто чем занимается, у кого какой опыт. Один в поле не воин, как говорится. Когда команда работает как чёткий механизм, когда она понимает, зачем она это делает, то это всегда втройне эффективнее. Это даёт заряд мотивации даже внутри самой команды.
Приведу пример. Когда я стал руководителем домена, я столкнулся с тем, что команда совсем не подходила под мои принципы. Не были отлажены процессы взаимодействия, ребята общались только по необходимости и каждый выполнял исключительно свой кусок задач, не понимая ни целей, ни стратегии. Мотивация также была на очень низком уровне. Мы были завалены потоком входящих задач, времени и сил ни на что не хватало. И всё это надо было срочно исправлять.
Первое, что мы сделали – запланировали еженедельные двухчасовые встречи и начали оцифровывать свою работу. На первой встрече мы разбирали всё, что связано с инициативами, на второй – всё, что связано с операционной деятельностью. Мы собрали в одном месте все наши задачи, инициативы, проекты, релизы и выбрали для себя подходы по их проработке. На этих встречах мы начали рассказывать друг другу про свои задачи, оценили нагрузку, перераспределяли её при необходимости, выстроили процессы работы с воронкой входящих задач, подключали к встрече смежные подразделения.
В итоге процессы начали работать. Ребята начали помогать друг другу, если кто-то был перегружен или не знал, что делать. Сейчас команда работает, как живой механизм, поэтому у нас нет потребности встречаться каждую неделю: раз в две недели теперь более чем достаточно. Я вижу, что мои люди заряжены, у них горят глаза, они понимают, что приносят пользу, уровень мотивации значительно вырос, в том числе и у меня.
Почему не нужно бояться смены профессии
Любой рост – горизонтальный, вертикальный – это всегда хорошо. Ведь на любой должности в какой-то момент ты оказываешься в зоне комфорта. Ты становишься профессионалом своего дела, чётко знаешь все процессы, можешь ответить на любой вопрос, с которым к тебе приходят.
В такие моменты ты можешь, конечно, показывать классные результаты, но при этом тебе самому становится скучно. Всё, что можно выстроить, ты уже выстроил. Всё, что можно было сделать, сделал. Ничего нового для тебя в этом уже нет. В такие моменты я всегда задаюсь вопросом, как мне выйти из зоны комфорта. В результате беру на себя какой-то новый вид деятельности и новые задачи.
Так произошло, когда я работал в отделе сервисов. Когда мы полностью выстроили работу, нужно было начинать что-то новое. Так мы начали развивать службу поддержки. И для меня это был интересный опыт.
Человеку, наверное, свойственно всегда искать пути дальнейшего развития. Но развиваться ты можешь только там, где чего-то не знаешь. И этого не нужно бояться. Пройдёт год, и ты снова все будешь знать, снова окажешься в зоне комфорта. Но будешь уже сильнее, профессиональнее, у тебя расширится кругозор, появится больше возможностей.
Советы начинающим руководителям
Не претендуя на истину, вот что могу посоветовать, опираясь на свой опыт:
Не бойтесь ответственности и выхода за рамки своих должностных обязанностей. В современных реалиях всё постоянно меняется. Сегодня у тебя были одни обязанности, завтра задачи вроде бы не поменялись, но работать ты уже должен по-другому. В этом нет ничего страшного.
Беритесь за сложные задачи. Лично для меня, чем сложнее задача, тем интереснее. Я получаю удовольствие, когда удаётся сделать то, что изначально выглядит практически невыполнимым. Никто не осмеливается, а ты вместе со своей командой просто берёшь и делаешь… Такие победы мотивируют и приносят чувство уверенности в том, что ты можешь больше и лучше.
Выстраивайте отношения с членами команды, как с партнёрами. Модель «руководитель – подчинённый» часто превращается в барьер. Будьте гибким, чтобы добиться комфортной и эффективной командной работы.
Выполняйте обещания, которые вы даёте другим людям. Надо уметь договариваться, находить компромиссы и достигать стратегии win-win.
Старайтесь как можно больше общаться с людьми, выходить из зоны комфорта, чаще выступать на конференциях. Расширяйте свой круг общения не только внутри компании, но и за её пределами, изучая новые технологии на рынке.
alexhott
Вы называете "Доменом" вашу внутреннюю организационную единицу? Отдел?
Читая фразу "Домены для меня были новым направлением " ни одно из значений слова "Домен" которое я знаю с дальнейшим повествованием не укладывается.
X5Tech Автор
Здравствуйте! Конечно, здесь мы используем слово "домен" не в привычном, первом значении слова. С одной стороны, как Вы верно подметили, это наше внутреннее обозначение оргструктуры. Но с другой – это название означает определённый подход к организации работы (agile, трайбы, домены).
И, если говорить немного скучно, то задача дирекции по технологическому развитию бизнеса (которая состоит из различных направлений – доменов) – выстраивать взаимодействие между X5 Tech, торговыми сетями («Пятёрочка», «Перекрёсток», «Чижик» и пр.) и бизнес-единицами компании, тем самым помогая им в создании продуктов, проектов и технологических инициатив.
Технический директор того или иного домена (направления) выступает в роли проводника для бизнеса в бескрайнем мире технологий и IT-решений – он знает, куда идти, как развивать бизнес с точки зрения IT, помогает устранять препятствия на пути к цели и т. д. Для этого у него есть огромная команда IT-специалистов из Х5 Tech.