Продуктовый подход и создание центра компетенции 1С в компании

Поговорим о том, что стало предпосылками для создания центра компетенций, что хотели получить в результате, как ведут себя заказчики и что сейчас получается.

Проблематика создания ценности в крупной компании

Кто не знает, группа компаний «Спортмастер» состоит не только из спортивных магазинов, это еще и магазины FunDay и Ostin.

Был такой период, когда мы открывали более 100 магазинов в год. В тот момент задача ИТ была только одна: просто не мешать рознице развиваться. И поддержать, насколько это возможно.

Но это вылилось в проблему с точки зрения ИТ, потому что:

• в какой-то момент у нас обнаружилось 250 с лишним информационных систем;

• многие кусочки этого лоскутного одеяла были не то что лоскутами… они просто лежали рядом;

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

Конечно же мы пытались с этим что-то сделать.

• У нас была программа модернизации технологий.

• В рамках этой программы мы делали управление проектами по классике – сбор требований, предпроект, внедрение, эксплуатация. Планирование по диаграмме Ганта, бюджет – все как надо.

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

• Особенностью нашего экстенсивного роста также стало то, что требования пользователей превыше всего – интерфейс подгонялся под желания конкретного человека на конкретном участке работы.

• Когда бюджет (или время) проекта заканчивался, мы могли сказать:: «Ок, бюджет проекта закончился, проект мы закрываем, а что не доделали, доделаем на этапе эксплуатации».

Что в той ситуации нас не устраивало:

• Первое: мы это делали долго.

• Второе: заказчик не всегда себя ассоциировал с тем, что мы делали: «Нам сделали что-то странное, но это не мое». Так получалось из-за того, что заказчик взаимодействовал с бизнес-аналитиком, бизнес-аналитик с системным аналитиком, системный аналитик с разработчиком, разработчик что-то делает, системный аналитик тестирует, иногда это показывает бизнес-аналитику, а в конце это показывают заказчику. Заказчик смотрит и говорит: «Вы что?! Зачем?! Как это?! Почему вообще так получилось?!»

• Еще одной проблемой было то, что техдолг никто особо не считал. На него не обращали внимание.

Продуктовый подход и особенности его применения для продуктов 1С

В 2018 году мы решили, что это надо исправлять, и достаточно срочно.

Цели внедрения продуктового подхода именно такие:

• Увеличить скорость выполнения запросов.

• Заняться техдолгом.

• Обеспечить масштабирование всей этой конструкции, чтобы выводить новые продукты на наш спортмастеровский рынок – новые сервисы, новые продукты должны быстро встраиваться в эту систему.

На слайде написаны базовые вещи, что считать продуктом:

• продукт должен быть понятен и IT-специалистам, и бизнесу;

• он должен поддерживать одну или несколько бизнес-областей;

• у него в идеале должен быть свой собственный релизный цикл, который ни от чего больше не зависит;

• и в идеале продукт должен иметь одного владельца продукта.

Здесь сразу возникает противоречие, потому что:

• Одна бизнес-область – чаще всего будет один заказчик, но несколько бизнес-областей – это точно несколько заказчиков. Это разные департаменты в компании.

• Собственный релизный цикл тоже вызывает некоторые сложности. Например, 1С:ERP поддерживает несколько бизнес-областей, имеет несколько заказчиков и общий релизный цикл. В такой ситуации даже новый типовой релиз будет затрагивать всех этих людей.

В итоге, каждый продукт для нас – это некая конструкция, которая имеет:

• функциональную и техническую архитектуру;

• у нее есть план развития;

• есть backlog;

• и, в идеале, один владелец.

Например, у нас есть тендерная площадка «Портал поставщика», где мы публикуем наши коммерческие тендеры. За этот продукт отвечают: Product Lead (это аналитик с расширенными функциями обычного аналитика), разработчик 1С, разработчик Битрикс и заказчик.

Второй пример. Была у нас транспортная система Gate для 1С:ERP, где производился сбор информации из разных источников данных для использования в ERP. Сначала она была реализована внутри 1С:ERP, как модуль, как компонент, но когда там появилась своя бизнес-логика и планы по собственному развитию, не зависящие от ERP, оказалось, что это проще выделить в отдельный продукт. Чтобы иметь на этот продукт отдельный план развития, свой backlog и дальше развивать свою архитектуру.

Принципы организации команд и организации работы

Какие мы взяли принципы организации команд:

• Команда отвечает за все. И за создание, и за эксплуатацию. Не получится такого, что одни внедряют, а другие потом разгребают ошибки. Все всё вместе.

• Команда должна быть полнофункциональной.

• Участники команды в идеале не ограничены жесткой зоной ответственности внутри команды. Взаимозаменяемость приветствуется. Понятно, что мы не всегда можем сказать разработчику ERP: «Пойди, пожалуйста, и поправь что-нибудь в Битриксе» Но иногда, например, вопрос тестирования можно как-то закрыть совместными усилиями.

• Команды создаются не на неделю, а на длительное время и имеют достаточно небольшой управляемый размер. По классике менеджмента – 5-9 человек.

Какие у команды принципы организации работы?

• Команда сама отвечает за организацию своей работы.

• Она сама выстраивает и оптимизирует поток создания ценности.

• Мы все это делаем, чтобы поток создания ценности был ритмичен, регулярен, част и предсказуем. Ритм определяют совместно команда и владелец продукта. Кому-то и раз в неделю – редко, а кому-то раз в месяц нормально.

• Разработка функциональности не имеет приоритета над автотестами.

• Проектное управление не имеет более высокого приоритета над всеми остальными задачами. Если раньше к нам приходил руководитель проекта и говорил: «Есть задача, делаем ее!», то сейчас проектное управление отходит немного в сторону, и задачи руководителя проекта приходится встраивать в общий пул работ данной команды.

Сложности в работе команды и взаимодействии с заказчиком

Внезапно оказалось, что демократия при выборе методов и подходов у нас не работает.

• По методикам команда продукта может выбрать только Scrum или Канбан. Также у них команды особого выбора, если они хотят нарисовать для проекта свой собственный статус на Jira. Возможно, для одной команды это хорошо, но на уровне департамента мы это потом не соберем.

• В идеале продукт – это некая обособленная конструкция, которая мало от кого зависит. Но в случае с ERP – это несколько продуктов на одной платформе, и с этим приходится считаться.

• И про одного мифического заказчика я уже говорил. Заказчиков несколько. Поэтому их тоже приходится координировать и с ними считаться.

Это слайд-боль. Потому что наши заказчики привыкли работать по-старому:

• «Нужно, чтобы мне сделали красиво»

• «Вы мне сделайте, а я посмотрю»

• «Что это вы мне сделали? Я не так хотел!»

• «Раньше было лучше (а трава зеленее)» и т. д.

У меня в голове все эти фразы звучат с интонациями, потому что это реальные цитаты.

Что с этим можно сделать?

• Вы не поверите, но для смены отношения заказчика помогает смена заказчика. Я без шуток. Вот был уважаемый человек, который работал по-старому 20 предыдущих лет. На его место приходит новый человек. Мы ему рассказываем, как он будет работать с нами. И он это принимает как правила игры. Старый сопротивлялся, а новый нет, потому что ему сравнивать не с чем. И он сразу работает по-новому.

• Да, есть нюансы. Мы не можем так напрямую этим процессом управлять. Поэтому терпение, настойчивость, уверенность в выбранном пути. Объяснять, объяснять, объяснять и договариваться.

• Вообще вся эта штука работает, только если все участники процесса со всех сторон согласны договариваться. Потому что как только кто-то занимает жесткую позицию, это уходит на эскалацию на больших менеджеров, и все становится как обычно.

Структура и роли центров компетенции

Что у нас в итоге получилось по продуктовому подходу и центрам компетенции.

Есть такая матрица (на слайде).

• Вертикальные полоски – это продукты.

• Ресурсными центрами для них выступают горизонтальные полоски – это разные центры компетенции.

• Несколько продуктов могут быть объединены в одну бизнес-область.

• Чтобы внутри бизнес-области была нормальная координация, нам нужна FAST-команда – Functional Area Special Team. Это наши IT-эксперты по функциональной области. Эти люди знают, что происходит в этой бизнес-области, понимают, какой продукт как работает, и они в состоянии это координировать.

  • Если к нам поступает понятная задача, она сразу идет в продукт, где выполняется в соответствии с backlog, приоритетами и т.д.

  • Непонятные задачи идут на FAST-команду, и они определяют, что мы вообще с этим делаем.

• Если совсем новое направление, идеи или несколько функциональных областей, это идет на команду верхнего уровня. Мы это назвали СГА – Совет Главных Архитекторов. Это топ-менеджеры, которые отвечают за несколько бизнес-областей.

Также у нас здесь возникло две новых роли.

• Про Product Lead я уже упоминал – это лидер продукта со стороны IT, наш сотрудник.

• И Product Owner – он со стороны бизнеса.

Центр компетенции 1С – немного специфичный центр компетенции. На слайде нарисованы Product Lead-ы, аналитики, тестировщики и так далее. Но получается так, что если продукт 1С-овский, то у нас и аналитик, и тестировщик тоже 1С-овские, потому что особенности платформы накладывают свои ограничения. Получается, что у нас точно такая же своя матрица в миниатюре: свои тестировщики, свои аналитики и, тем более, свои разработчики.

Какие же задачи у центра компетенции?

• Нам нужно быть ресурсным центром, обеспечивать наличие ресурса в нужном качестве и в нужном количестве.

• Нам нужно развивать компетенции тех сотрудников, которые у нас в центре компетенции.

• Нам нужно поддерживать в актуальном состоянии стек технологий: старое выводим, новое добавляем, проверяем (что-то вроде исследовательской деятельности).

• Нам нужно помогать быстро создавать новые продукты и выводить их на наш внутренний рынок.

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

Вот так примерно выглядит структура.

У нас есть ресурсы.

• То, что не выделено зеленым – это те люди, которых мы выделяем в продукт и надолго.

• То, что выделено зеленым – это те люди, которых мы в продукты не выделяем. Они занимаются именно исследовательской деятельностью, организационной, архитектурной и т.д. Потому что если мы оставим продукты наедине с архитектурой, то вместо Миланского собора рискуем получить бразильские фавелы. Нужно контролировать.

• Обычный наш сотрудник – это член центра компетенций.

• И дополнительно появляются две новые роли: куратор и ментор:

  • Задача куратора – присутствовать в FAST-командах, в продуктах, контролировать, как все устроено архитектурно, насколько это можно улучшить. В общем, он – консультант.

  • И есть ментор, который тоже консультант, но для конкретного сотрудника или для группы сотрудников.

Куратор занимается архитектурными, организационными, методическими вопросами, а ментор занимается адаптацией новых сотрудников в центре компетенции.

Что изменилось?

Что сейчас поменялось?

• Конечно же, походы в отпуск никто не отменял. Но теперь, поскольку команда отвечает за результат, то разработчику, например, нужно сначала договориться с PL, что у него будет отпуск, а потом с непосредственным руководителем (то есть со мной). В данном случае меня не интересует результат, у нас другие задачи как у центра компетенции, поэтому в основном пусть даёт добро PL, чтобы там ничего не просело.

• У нас идет стандартизация подходов. Мы меняем процессы.

• Люди адаптируются к самоорганизации команд – ко всему этому разнообразию, хотя и с ограничениями. При этом плохо понимают ответственность каждого за общий результат – как на той картинке, когда лодка тонет, а люди сидят на носу и говорят: «Как хорошо, что проблемы не на нашей стороне», а в это время на корме воду ведрами выкачивают. Такого уже не будет. Проблемы на общей стороне, и это осознание должно дойти до каждого.

• Так же у нас в планах внедрение ресурсного планирования на базе Jira. Это не очень тривиальная задача, приходится дробить задачи, чтобы каждый ресурс планировать: аналитика, тестировщика, разработчика отдельно.

• Ну и, по сути, новые возможности центра компетенции: развитие, клубы, выступления. Здесь каждый решает сам, пользоваться или нет.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.