Приемы проектирования, которые повысят эффективность работы ваших пользователей и администраторов системы

Меня зовут Сергей Наумов, хочу поделиться опытом внутренней автоматизации отдела, которым я управлял в компании WiseAdvice. Расскажу о своих личных переживаниях, трудностях и ошибках.

Объектом автоматизации, с которым я работал, был отдел «Корпоративные финансы». Специализация отдела – крупные проекты по ERP и ERP.УХ. Отдел крупный, более пятидесяти человек – аналитики, разработчики, руководители проектов. Одновременно в пике выполнялось 11 проектов – одни завершаются, другие начинаются.

 

 

Когда я пришел в отдел, он был автоматизирован с использованием Jira и Confluence от Atlassian, оба этих инструмента – настраиваемые конструкторы.

 

 

Мы пытались их настроить под себя и разработали методологию работы в Jira – как вести этапы, как работать с задачами, проработали типы задач, которые должны ставить аналитики.

Но с точки зрения возможностей управления проектом у Jira+Confluence возникли определенные сложности – они не покрывали мои потребности как руководителя отдела:

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

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

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

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

• И важно контролировать финансовые показатели проекта – сколько мы потратили денег на сотрудников и сколько денег получили с клиентов.

 

 

Основные обязанности руководителя проектного отдела описаны на слайде:

• мне нужно было формировать портфель проектов;

• подбирать персонал для выполнения этих проектов;

• мониторить проекты в ходе выполнения;

• разрабатывать схемы мотивации и т.д.

Я думаю, объект автоматизации, который я автоматизировал, теперь совсем понятен. Начнем с боли.

 

Боли

 

 

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

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

 

 

Можно строить диаграмму план-факта, как на слайде – отдельно по сотруднику или в целом по проекту.

 

 

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

 

 

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

В Jira это в принципе можно настроить – там есть плагин ProjectData, который позволяет добавлять поля. На слайде скриншот с примером параметров нашего проекта.

 

 

У Jira есть ядро, которое предоставляет возможность работать с запросами (issues). Причем запрос в Jira – это универсальная сущность, имеющая разные типы. Задача – это запрос, ошибка – это запрос, этап проекта – это запрос, требование – тоже запрос. Использование единой сущности в качестве основы различных типов запросов вроде как должно позволять организовывать работу.

Запросы можно анализировать – например, на слайде отчет по факту трудозатрат. Jira позволяет делать группировки (это видно на слайде справа) и различные фильтры.

Но все же привыкли, что в группировку можно через плюсик провалиться и дочернее поле вытащить? Мне кажется это уже стандарт, как без этого жить? Jira не позволяет.

А чтобы в Jira сделать более-менее приличный отчет – например, вытащить все проекты по какому-то полю, приходится писать запрос на языке JQL. Вы даже не представляете, что мне приходилось делать, чтобы сгруппировать и агрегировать там все запросы с типом «Ошибка»…

 

 

И с контролем финансовых показателей там все совсем сложно.

Я уже сказал, что в Jira есть ядро с запросами, вокруг этого ядра ставятся плагины. Например, на слайде скрин плагина Tempo Budgets. Этот плагин предназначен для ведения финансовой информации.

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

И вы же понимаете, что когда есть ядро, а плагин ставится рядом, он не всегда хорошо с ядром дружит. И начинается… Это то же самое, что расширение в 1С, только расширение у нас лучше дружит с ядром.

 

О чем будет доклад

 

 

О чем я хочу рассказать:

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

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

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

• Еще поговорим про мое любимое – план коммуникаций. Знаете эту историю: «В этом отчете у нас запасы, в этом – продажи, а тут – себестоимость. Но смотреть можно только по-отдельности». Это очень неудобно – я предложу решение, как это исправить.

• И, конечно, поговорим о том, когда имеет смысл использовать БСП-шные отчеты с кучей настроек и вариантами. И какая у этого альтернатива. Я надеюсь, тот паттерн, который я предложу, вам понравится.

 

«Ползущая автоматизация» VS «революция»

 

 

Почему не получилось сделать для себя внутреннюю автоматизацию «революционно»?

• Потому что в Jira работали свыше 50 сотрудников – ставить процессы на «стоп» было довольно сложно.

• Моя главная боль тогда была – отсутствие в Jira таблички, где есть план, факт и срок. Но добиваться выделения ресурсов на полугодовой проект для получения этой таблички было бессмысленно – сами понимаете, какой ответ я получил бы от руководства. У меня просто не было возможности спланировать проект и сделать всё «как надо».

• Я долго пытался от Jira добиться того, чтобы она заработала. Мы мучили плагин Tempo, потом поставили к нему EasyBI, чтобы работать с BI-системами. EasyBI вроде как показывал нужные нам четыре колонки, но постоянно наглухо вис. Мы так и не поняли, почему.

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

 

 

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

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

Так появилась СПАП – «Система проектной аналитики и показателей».

Чтобы ее реализовать, мы взяли БСП, добавили метаданные и загружаем в них данные из Jira раз в пять минут.

В результате там можно строить нормальные отчеты с возможностью гибкой группировки и детализации.

 

 

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

Пришлось делать интеграции:

• Источником данных оперативного учета в нашем случае выступает Jira.

• А источником данных финансового учета выступает корпоративная учетная система.

Эти данные мы связываем и сопоставляем в нашей системе СПАП, которая стоит посередине.

 

Планирование интеграционных механизмов

 

 

Теперь о том, как мы реализовали эти интеграционные механизмы:

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

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

• Более того, когда мы копнули в API Jira, оказалось, что у ядра свои API, а у плагинов вокруг ядра – свои. При этом все эти API не позволяют получить то, что нам нужно. Была сумасшедшая идея сделать свой плагин с API, который будет предоставлять нам нужные данные. Но эту идею мы тоже похоронили.

• В итоге мы сделали технически неправильное решение. Но главное – результат.

  • Из Jira мы забираем данные запросом – напрямую из таблиц Jira. Раз в 5 минут система проверяет новые записи, ориентируясь по колонке «Дата обновления», и все работает.

  • И с получением данных из корпоративной учетной системы все тоже оказалось непросто. У WiseAdvice же группа компаний – есть юридические услуги, услуги по аутсорсу бухгалтерского учета. Если бы мы сразу пошли по «правильному пути» и организовали большой внутренний проект по интеграции через 1С:КД 2 – это надо согласовывать. А у меня времени не было – мне просто нужен был срочно отчет, поэтому сделали просто интеграцию через OData. Делается очень быстро. Мы запланировали, что потом сделаем эту интеграцию нормально – через «1С:Конвертацию данных» с планами обменов. Но «быстрое решение» прожило год – сначала у местных айтишников руки не доходили, потом они долго делали, потом сделали.

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

 

 

На слайде – техническая реализация выбранного решения. Запросы элементарные. Слева – загрузка данных из Jira, справа – получение данных из корпоративной учетной системы через OData. Тоже элементарно.

 

Организационно-технический процесс синхронизации данных из разных систем

 

 

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

Например, в корпоративной учетной системе сотрудник, если он уволился и принят опять – это тот же сотрудник, а в Active Directory из-за особенностей ИТ-процесса его учетная запись блокируется и при повторном приеме создается новая. Таким образом в Jira появляется дубликат сотрудника.

Сопоставление этих данных в НСИ – задача творческая. И здесь мы тоже сделали простое решение. Думали, что потом переделаем правильно, но в итоге так и оставили.

 

 

Рассматривали разные варианты.

• Хотели выбрать ответственного за синхронизацию НСИ в разных системах.

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

• В итоге мы сделали просто технический «костыль».

 

 

Технический костыль – это когда руководитель проектного отдела заходит в систему аналитики СПАП, и у него там табличка с гиперссылками по объектам, которые нужно сопоставить. Сюда входят справочники:

• Сотрудники – не сложно нажать кнопку, если в месяц принимаешь 2-3 сотрудника.

• Проекты – в месяц максимум 2-3 проекта запускается

• Этапы проектов – и этапов тоже немного стартует.

Поэтому зайти в систему и нажать гиперссылку – занимает пять минут раз в неделю. Вообще не проблема. Да, неудобно, некрасиво, но работает.

 

 

Технически это просто регистр сведений, где хранятся данные сопоставления по четырем видам объектов. Сопоставляются код с наименованием в Jira и наименование в 1С.

 

 

Естественно, возможны потенциальные конфликты – например, когда ИТ-специалист блокирует человека из Active Directory, а потом создает нового пользователя.

Либо когда руководитель проектов назвал этап в Jira одним способом, а финансовый специалист из договора переписал его в корпоративную систему как-то по-другому.

 

 

Такие конфликты мы тоже решили техническим «костылем». Очень просто.

• Когда данные загружаются в систему, ответственный специалист, которому эти данные нужны, ставит статус «Проверен».

• Если в какой-то из систем данные поменялись, у него появляется флаг «Есть ошибки». И дальше он идет к одним, ко вторым и спрашивает, какие данные правильные.

 

 

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

Задачу я решил – при этом получилась довольно универсальная архитектура, потому что в основу мы положили БСП.

Более того, система расширялась:

• Сначала мы сделали отчетность.

• Потом начали систему развивать – добавили к этому производственную программу (модуль планирования с возможностью расчета планов отдела на год вперед).

• Потом появились модули планирования стандартных проектов.

 

План коммуникаций – главная цель системы отчетности

 

 

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

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

Если кто не понял, я про планерки. Просто система планерок в моем понимании должна быть выстроена определенным образом.

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

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

 

 

Физически план коммуникации у меня выглядел так, как показано на слайде – это анализ списка проектов который я собирал на Jira по каждому РП.

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

На слайде план коммуникаций вторника – мы прямо по списку смотрели эти отчеты по гиперссылкам в Jira:

• смотрели список проектов;

• смотрели план-факт трудозатрат за прошлую неделю;

• смотрели планы на текущую неделю и т.д.

Я так полгода мучился.

 

 

Потом появился улучшенный план коммуникации – выглядит примерно так же, но уже ссылается на отчеты в 1С, в ту систему, в которую мы загрузили.

И здесь я придумал классную штуку. Мне же по каждому РП надо смотреть 9 отчетов – трудозатраты, бюджеты, планы и так далее. Открываешь один отчет, второй отчет, третий и т.д. И в каждом отчете еще нужно выбрать вариант отчета. Было не очень удобно.

 

 

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

Причем в этот документ загружаются именно в фиксированном виде именно те варианты отчетов, которые мы до этого отладили.

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

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

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

А тут прямо в документе сохраняем – всегда можно открыть документ посмотреть, что было.

На слайде выше – отчет руководителя проектов передо мной.

 

 

А здесь – план коммуникации отдела, мой отчет перед руководителем.

 

 

Итого, для получения плана коммуникаций по отделу:

• Мы сначала эти отчеты отладили – с помощью механизма вариантов отчетов БСП добились, чтобы всем было понятно, какие данные они отображают в тех аналитических разрезах, в которых удобно анализировать.

• И после этого собрали данные по нужным отчетам в документ.

 

 

Это делается очень просто – там реально 10 строк кода, которые формируют отчет и записывают его в хранилище значения.

А все эти сохраненные макеты хранятся в простом регистре сведений.

 

 

Если глобально смотреть на этот план коммуникации, то у нас есть:

• документ, который формируется еженедельно;

• и документ, который формируется ежемесячно.

Каждый документ содержит свой набор отчетов – 7-8 закладок в каждом документе.

И на каждую закладку формируется 2-3 отчета, о которых мне нужно переговорить либо с сотрудником, либо с руководителем.

 

 

По аналогии мы работаем с KPI для сотрудников, потому что визуализация – «наше все».

KPI для сотрудников я формирую по той же модели:

• мы берем отчеты, которые до этого отладили;

• итоги из них выводим на отдельную закладку;

• а дальше уже по закладкам идут расшифровки каждого из KPI.

 

Выводы

 

 

И в завершение.

• Не всегда стоит упираться в красивые решения. Представляете, что было бы, если бы я ради этой таблички пошел бы согласовывать доступ к корпоративной финансовой системе, стал бы писать обмен на 1С:КД 2, добавлять планы обмена и так далее? Если учесть, что с этой системой работают много сотрудников, как планы обмена себя поведут – вообще непонятно.
  А тут – простое решение: взяли OData, загрузили данные.

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

• И когда я делал план коммуникации, я постарался встать на место моего руководителя и подумать, что ему будет интересно. Почти все угадал. Тоже хороший прием.

 

Вопросы и ответы

 

В своем интервью Инфостарту вы рассказывали про планы использования СППР внутри отдела. Здесь вы озвучиваете другую систему автоматизации – СПАП. Сколько у вас систем для автоматизации деятельности отдела?

На самом деле я уже объединил СПАП с СППР. Потому что в СППР в принципе нет финансового учета, и для нее полностью подходит модель интеграции, которую мы выбрали – то, что мы фактически продублировали структуру нужных таблиц Jira в 1С. Для нас же неважно, мы грузим эти данные из Jira, либо эти данные поставляет СППР – мы записываем их туда же, и отчеты работают так же.

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

А дальше я хочу отказаться от Jira. Она не православная. Просто она была в компании до моего прихода. И почему в компании выбрали именно ее – я не знаю.

Причем расскажу мои наблюдения. С 2016 года я работал директором по развитию информационных систем. Когда я пришел, в отделе был один человек, а когда уходил – 50. Для автоматизации я там использовал СППР. И от нее прям все бесились. Требовали: «Убери эту СППР! Давай Jira, классная система! Убери!»

Я не понимал, почему, говорил: «Меня все устраивает – у меня хорошие отчеты и понятный план коммуникаций на планерках, все отчеты мне понятны». Причем когда я ушел из компании, там внедрили Jira.

А когда я пришел в WiseAdvice, я понял, почему сотрудники так любят Jira – там ничего не понятно! Там нет возможности проанализировать для задач план и факт по срокам. Поэтому сотрудники ее очень любят – им хочется все замылить.

 

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

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART Анализ & Управление в ИТ-проектах.