Привет, Хабр! Меня зовут Владимир, я бизнес-аналитик в офисе данных Ростелекома и занимаюсь развитием отчётности. Компания делает ставку на развитие data-driven культуры. Спрос на данные и аналитику со стороны бизнеса растёт, и соответственно развивается экосистема управления данными, в том числе организационная структура и бизнес-процессы.

К концу 2019 года объём задач отчётности очень сильно вырос и это стало своеобразным нагрузочным тестированием для наших процессов. Стало понятно, что работать по-старому и соблюдать SLA нам становится все сложнее. Были нужны новые правила игры, соблюдение которых сделает управление типовыми задачами проще, планирование – более предсказуемым, а выполнение обязательств – реалистичным даже в условиях, когда рост команды сильно ограничен, а рост количества заявок безграничен.

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

Введение

«Нужно бежать со всех ног, чтобы только оставаться на месте, а, чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!»,  — писал Льюис Кэрролл ещё во времена викторианской Англии. А сто лет спустя «принципом Черной королевы» назвали эволюционную гипотезу, сравнивающую борьбу за выживание с гонкой вооружений. Чем быстрее перемены окружающей среды, тем важнее скорость адаптации. Для организаций это правило работает так же: чтобы оставаться на плаву, нужно быстрее приспосабливаться к изменениям конкурентов, учиться и эффективнее перестраивать процессы.

Индустрия телекома и особенно управление данными бурно растут вместе со спросом на услуги, но этот же рост, вместе с возможностями, создает и множество проблем. Это особенно важно, когда деятельность организации разнообразна и содержит много специфики, из-за которой сложнее применять чужой опыт. Из-за этого приходится чаще импровизировать и вместо общепринятых хороших практик (почему в этом случае best practices скорее «хорошие», а не «лучшие» – рекомендую почитать у Романа Журавлева) искать альтернативы, оптимальные для конкретной ситуации.

Ситуация

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

В корпоративном центре Ростелекома все профильные направления, работающие с отчётностью, объединены в Офис Данных. Это более двух сотен сотрудников в Москве и регионах, которые занимаются развитием платформы управления данными, работают в направлении глубокого анализа и развитии аналитической отчётности.

Направление обширно: отчёты используют данные нескольких сотен систем-источников, запросы поступают от всех подразделений компании, в которых свои особенности, бизнес-процессы и действующие регламенты. География бизнеса – вся страна, разделенная на семь макрорегиональных филиалов, каждый из которых не так давно был отдельной компанией. Значение отчётности и требования к качеству аналитики растут, так как бизнес использует данные для принятия ежедневных управленческих решений и данные становятся важной частью операционных процессов компании.

Развитие отчётности организовано так: за сегментами бизнеса закреплены постоянные команды из 10-30 аналитиков и разработчиков, из которых формируют рабочие группы для отдельных задач. Различий в бизнес-процессах сегментов много и каждый раз в них разбираться – непродуктивно. У разработчиков с этим проще, но всё равно хочется сохранять сработавшиеся команды. Командой сегмента руководит фронт-менеджер, который объединяет роль ресурсного менеджера для команды и аккаунт-менеджера для заказчика.

Обычно в работе у фронт-менеджера есть 10-12 задач, с каждой задачей на различных этапах может работать от 2 до 5 человек. Длительность таких задач – от нескольких недель до полугода (это очень грубая оценка, чтобы показать масштабы). По каждой доработке требуется создать артефакты: комплект документов, которые будут использоваться сопровождением для работы над инцидентами, и отчётность в JIRA по объёмам трудозатрат, срокам работ и загруженности ресурсов, которая позволяет анализировать эффективность процессов.

Чтобы задача проходила маршрут и не буксовала, ей нужен владелец, погруженный в предмет и заинтересованный в её своевременном выполнении. Раньше этим занимались фронт-менеджеры, но к концу 2019 года объём задач вырос настолько, что на управление отдельными задачами у них уже не оставалось времени. У фронтов основные обязанности – взаимодействие с бизнес-заказчиками, маршрутизация поступающих запросов и управление командой, а управление отдельными задачами можно делегировать, иначе будет как на картинке.

Поиск решения

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

Мы поняли, что в нашем случае многие «классические» компетенции руководителя проектов окажутся невостребованными: например, не требуется управлять бюджетом или поставщиками, проекты будут выполняться по одному и тому же регламенту, а предметная область всегда будет ограничена отчётностью для конкретного бизнес-сегмента. Задачи чаще всего типовые, но требуют погружения в предметную область, понимания процесса разработки и содержания работ на всех этапах.

Мы сделали вывод, что РП с небольшим количеством задач обойдется неоправданно дорого и будет недогружен, а в большем объёме задач не будет успевать разобраться, и его руководство будет ограничено чисто административными функциями. С другой стороны, добавление к небольшой команде выделенного РП заметно усложнит коммуникации – придётся ещё одного начальника держать в курсе вопросов, которыми он непосредственно не занимается.

Расходы на команду увеличатся, но проблему это не решит. Исходя из этого, от выделенных исполнителей в роли РП мы отказались. С другой стороны, аналитики уже:

• погружены в предметную область, как никто другой;

• участвуют в выполнении задачи на всех этапах;

• выполняют интегрирующую роль для команды.

С этой перспективы идея совместить руководство проектом с ролью аналитика (бизнес или системного) стала выглядеть логичной.

Реализация

Дальше мы проектировали и документально оформляли процесс, совмещали с уже существующими операционными процессами, о некоторых из которых уже рассказывали мои коллеги (статьи на Хабре: раз, два). В общем процесс разработки приобрел вид:

Документацию составили в формате методики управления, скорее даже инструкции. Где-то брали собственные наработки, где-то транслировали рекомендации PMBoK на наше организационное окружение. Писали так, чтобы документа было достаточно для выполнения роли РП, и чтобы его мог использовать человек без опыта проектного управления.

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

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

К плюсам принятого решения можно отнести:

1. В первую очередь – сам подход к вопросу, когда команда аналитиков разрабатывает процесс с учетом имеющейся практики и наработок;

2. На коммуникации внутри команды времени тратим не больше, чем тратили раньше;

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

Трудности:

1. Есть нестыковки с операционными процессами, особенно в нетиповых ситуациях, но это ожидаемо – продолжаем шлифовать;

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

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

аналитика даёт больше плюсов, чем создает неудобств.

Вместо эпилога

«Минуточку, управление работами по задаче… Вы там что, открыли для себя дверь роль менеджера проекта и повесили на бизнес-аналитика?». Короткий ответ – «Да», ответ по существу длиннее – «Сначала мы оценили все, что нам нужно от роли, упростили её соответственно задачам и подготовили всё необходимое, чтобы даже начинающий РП мог её выполнять».

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

P.S. Только не «миниРП», пожалуйста :)