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

20.09.23

Управление продуктом - Продуктовый подход

Когда нужно увеличить скорость обработки запросов от бизнеса и быстро выводить новые продукты на рынок, на первый план выходит продуктовый подход. Расскажем, как решать архитектурные, организационные и методические вопросы, возникающие у продуктовых команд, и какие особенности есть у продуктового подхода применительно к решениям 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.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Запускаем новый продукт. С чего начать

Продуктовый подход Бесплатно (free)

При запуске нового продукта нужно проверить идею на прочность, оценить ваши возможности и определить позиционирование среди целевой аудитории. Расскажем о том, какие инструменты могут в этом помочь.

09.02.2024    807    0    comol    0    

8

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

Продуктовый подход Бесплатно (free)

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

22.01.2024    622    0    user1075439    8    

4

Запуск центра компетенции: ожидания и реальность

Продуктовый подход Бесплатно (free)

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

17.11.2023    700    0    user1949771    0    

6

Радио "Аналитик", выпуск 11. О создании продуктов с Сергеем Колосковым

Продуктовый подход Бесплатно (free)

В одиннадцатом выпуске подкаста Радио “Аналитик” обсудили, как найти актуальную проблему для создания продукта, как проверить идею продукта на востребованность и как сделать продукт привлекательным для потенциальной аудитории.

06.02.2023    567    0    Radio_Analyst    0    

3

Как превратить бизнес-заказчиков и разработчиков в единую команду?

Продуктовый подход Бесплатно (free)

Один из подходов, который помогает найти с бизнес-заказчиком общий язык и организовать сотрудничество – это использование принципа бережливой разработки (Lean Development). На митапе «Сбор требований и составление ТЗ» директор по проектам Инфостарта Мария Темчина рассказала, как с помощью этого принципа наладить взаимодействие с заказчиком, и показала практические инструменты, которые удобно применять при сборе требований.

26.05.2022    3592    0    MariaTemchina    0    

11

Как создать коробочный программный продукт

Продуктовый подход Бесплатно (free)

Создание коробочного продукта – процесс нелегкий и долгий. Помочь разработчикам, которые только начинают свой путь в этом направлении, решил Сергей Сорокин – основатель компании MoscowSoft, которая входит в топ-3 компаний-продавцов коммерческих продуктов на Инфостарте. Сергей рассказал, как выбрать и протестировать идею, объяснил, стоит ли бросать наемную работу ради собственной разработки, и поделился опытом, как Инфостарт помогает при продвижении продукта и в борьбе с пиратами.

05.10.2020    5083    0    primat    2    

26

Придет владелец продукта и решит все вопросы бизнеса!

Продуктовый подход Бесплатно (free)

Практически во всех крупных проектах есть отдельная роль – владелец продукта. Все чаще ее выполняют аналитик либо представители бизнеса, но насколько эффективно они работают, мало, кто задумывается. О том, что должен делать Product Owner, и какие ошибки чаще всего совершают такие специалисты, на конференции Infostart Event 2019 Inception рассказал управляющий партнер и Agile Coach компании Scrumtrek Иван Селеверстов.

24.07.2020    7603    0    iseleverstov    0    

18

Использование Lean-технологий

Продуктовый подход Бесплатно (free)

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

03.08.2017    18274    0    Dem1urg    19    

37
Оставьте свое сообщение