Хабр, привет!
Все, кто работал хотя бы в одной крупной территориально распределенной компании с сетью филиалов по всей стране, сталкивался с проблемой: «Как проинформировать заинтересованные лица об услугах и сервисах, которые вы предоставляете в рамках своего подразделения? Как избежать дублирования разработки отчётов/функционала из-за разрозненности ИТ-команд из разных регионов необъятной страны, как централизовать данные и отчётность, как сократить издержки компании на разработку отчётности?».
Этот вопрос не миновал и нашу команду, команду бизнес-анализа по управлению данными. Но как донести информацию о том, что у нас сейчас есть, над какими проектами мы работаем и как с нами взаимодействовать? Мы расскажем о наших инструментах информирования и, надеюсь, вы поделитесь своими рекомендациями.
С чего мы начали — так это с построения портала. Для быстрого старта был поднят wiki, в котором отразили основные аспекты своих сервисов и процессов. После чего распараллелили свои активности. С одной стороны начали проработку полноценного портала с удобным и функциональным интерфейсом. С другой занимались наполнением контента на wiki c целью его дальнейшего переиспользования.
Так вот, давайте поговорим о контенте, который мы хотим транслировать. Основной нашей целью было сделать базу реализованных в компании отчетов – «Реестр отчетов». Идея прекрасная, но … тут же появляется вопрос: «А какие данные указывать в реестре, чтобы пользователь понял, что это за отчет и подходит ли он ему?».
Действительно, если мы укажем наименование, то этого явно будет недостаточно, а если укажем все, что мы знаем по отчету, включая технологический стек, это будет явный избыток информации, что может отпугнуть.
Тогда где же эта золотая середина, которая даст пользователю понять основную важную информацию по отчету, но не будет избыточной для него? Наверное, каждый ответит по-своему на этот вопрос, но мы делимся с вами нашим подходом при составлении списка:
А теперь по порядку.
В больших компаниях все говорят на разных языках. Для одного отдела адрес – это адрес по прописке, а для другого — адрес фактического проживания.
Как решить эту проблему? На помощь приходит единый словарь узкоспециализированных терминов, сокращений и понятий — глоссарий. К разработке которого мы и приступили.
В реестре мы отразили все отчеты, а их оказалось очень много. Рассчитывать, что пользователь посмотрит все, что в нем приведено, не приходится. Поиск по ключевым словам тоже может не всегда корректно сработать. Для помощи в поиске мы разделили все отчеты по предметным областям и вывели это поле в фильтры.
А что еще можно включить в реестр с целью информирования? Тут уже на ваше усмотрение, но вариантов еще много: заказчик отчетности (т.е. кто вообще выставлял требования на данную отчетность), первоначальные источники информации (т.е. откуда данные попадают в хранилище), инструмент визуализации и многое другое.
Достаточно ли реестра для решения потребностей пользователя без детального описания атрибутного состава? Конечно же, нет. И для каждого отчета мы стали готовить это описание.
Само собой, указать просто наименование атрибута будет мало. Поэтому мы решили указывать следующие моменты:
И вот у нас есть удобный инструмент для просмотра отчетности, реализованной в компании, и это уже огромная победа. И в который раз появляется НО…
А как же связаны между собой Реестр отчетов с общим описанием отчета, реестр отчетов с детализированным описанием отчета и глоссарий?
Чтобы ответить на этот вопрос, давайте посмотрим на схему:
Итак, пользователь может начать поиск либо с реестра отчетов с общим описанием, либо с глоссария.
А дальше настроены переходы:
Так мы смогли связать два основных инструмента информирования по реализованной отчетности и заложить основу под полноценный процесс Data Lineage.
Но это не все инфосервисы, которые мы реализовали. Помимо разработанной отчетности, мы захотели показать, какие данные у нас есть в хранилище и с какой периодичностью они загружаются. Для этих целей на портале мы опубликовали Карту данных.
Так как нам требовался простой, понятный инструмент, которым смог бы воспользоваться любой заинтересованный пользователь, мы сделали дашборд, состоящий из двух вкладок:
Судя по полученной обратной связи, этот инструмент оказался очень полезен для наших пользователей и бизнес-заказчиков. Они уже без обращения к специалистам нашего департамента смогли получить общее представление о данных, которыми мы оперируем в хранилище.
Что еще хотелось бы донести о портале? Помимо инфосервисов, которые рассказывают нам о том, что реализовано, на портал мы вынесли разделы о текущих активностях. Наши активности разделены на два больших стрима – это линейное развитие и проекты. В рамках линейного развития мы развиваем отчетность по текущим потребностям бизнес-заказчиков, в рамках проектов – крупные инфраструктурные активности, связанные с развитием самого хранилища. Вот и на портале публикуем всю информацию об этих активностях — цели, задачи, участники проекта, план работ, вехи.
Если вы подумали, что мы зациклились на портале, то это не так. Чтобы обеспечить прозрачность процессов и информировать заказчиков об этапах выполнения задач, мы взялись и за Jira. По своей сути Jira –система, которая больше подходит для организации поддержки и разработки. Но минусом Jira является то, что в ней практически отсутствуют возможности управления сроками. Планирование сроков приходится делать вовне, к примеру, в MS Project.
Как дать заказчику привычный формат планирования сроков в современном инструменте организации работ нашего подразделения? Для себя мы нашли решение в установке плагина BigGantt.
Какие новые функции привнёс данный плагин в функционал JIRA:
В результате заказчик получил возможность в любой момент времени видеть актуальную статистику по выполнению задач в виде отчета и диаграммы Ганта.
С инструментарием портала вроде бы все понятно. Но как сделать так, чтобы пользователи узнавали о наших продуктах по мере их появления и вывода на прод? Для решения этой задачи мы внедрили практику рассылки регулярных дайджестов. Формат и контент дайджеста перерабатывался несколько раз перед тем, как уйти в рассылку. Но в итоге мы пришли к наиболее удобному подходу:
Когда дайджест готов, встает вопрос с адресатами: кому его направлять и как сформировать список рассылки? Первоначально список адресатов мы готовили на основе обратной связи от бизнес-партнеров направлений. После чего запросили рекомендации по контактам от самих адресатов. Так мы получили список, охватывающий основную целевую аудиторию. Для остальных заинтересованных рассылке проработали возможность подписаться самостоятельно на портале DataOffice, либо подать обращение на единый почтовый ящик.
Следующий способ информирования, который мы у себя стали использовать — проведение вебинаров. На вебинарах мы рассказываем о наших процессах, подходах к реализации задач, об основных направлениях деятельности по линейному развитию отчётности, план/факт по реализации задач отчетности. Данный формат оказался очень удобен, так как можно было сразу получить обратную связь и обсудить открытые вопросы.
Чтобы полезная информация никуда не терялась и ее можно было оперативно получить, мы все вебинары сохраняем на портале.
Но и на этих способах информирования мы не остановились, мы стали активно взаимодействовать с коллегами в рамках Гильдий, самоорганизованных сообществ из специалистов разных направлений и проектов. В нашей компании уже запущены гильдии архитекторов, проектных менеджеров, аналитиков. Внутри гильдии мы обсуждаем общие практики, вырабатываем совместный инструментарий и подход. Сейчас активно развиваем проект «внутренняя митапная», призванный повысить эффективность митапов и заинтересовать остальных коллег подключаться к ним.
Пока это все, что мы хотели вам рассказать о наших инструментах. Но мы не останавливаемся на достигнутом и продолжаем работать над развитием наших коммуникаций. Будем рады, если наш опыт для вас окажется полезным!
Команда DataOffice
Все, кто работал хотя бы в одной крупной территориально распределенной компании с сетью филиалов по всей стране, сталкивался с проблемой: «Как проинформировать заинтересованные лица об услугах и сервисах, которые вы предоставляете в рамках своего подразделения? Как избежать дублирования разработки отчётов/функционала из-за разрозненности ИТ-команд из разных регионов необъятной страны, как централизовать данные и отчётность, как сократить издержки компании на разработку отчётности?».
Этот вопрос не миновал и нашу команду, команду бизнес-анализа по управлению данными. Но как донести информацию о том, что у нас сейчас есть, над какими проектами мы работаем и как с нами взаимодействовать? Мы расскажем о наших инструментах информирования и, надеюсь, вы поделитесь своими рекомендациями.
С чего мы начали — так это с построения портала. Для быстрого старта был поднят wiki, в котором отразили основные аспекты своих сервисов и процессов. После чего распараллелили свои активности. С одной стороны начали проработку полноценного портала с удобным и функциональным интерфейсом. С другой занимались наполнением контента на wiki c целью его дальнейшего переиспользования.
Так вот, давайте поговорим о контенте, который мы хотим транслировать. Основной нашей целью было сделать базу реализованных в компании отчетов – «Реестр отчетов». Идея прекрасная, но … тут же появляется вопрос: «А какие данные указывать в реестре, чтобы пользователь понял, что это за отчет и подходит ли он ему?».
Действительно, если мы укажем наименование, то этого явно будет недостаточно, а если укажем все, что мы знаем по отчету, включая технологический стек, это будет явный избыток информации, что может отпугнуть.
Тогда где же эта золотая середина, которая даст пользователю понять основную важную информацию по отчету, но не будет избыточной для него? Наверное, каждый ответит по-своему на этот вопрос, но мы делимся с вами нашим подходом при составлении списка:
- Наименование отчета – ну тут все понятно, не зная наименование, невозможно воспользоваться отчетом.
- Краткое описание отчета — здесь тоже все понятно, наименование не всегда полностью отражает суть отчета, поэтому в кратком описании мы указали основные показатели и разрезы, по которым он сделан.
- Система отчетности – этот пункт актуален, если у вас больше одной системы отчетности. Необходимо понимать в какой системе отчетности реализован отчет.
- Периодичность готовности данных – для пользователей это может быть действительно важно. Например, отчет обновляется ежемесячно, а для конкретных целей нужно ежедневное обновление.
- Глубина доступности данных – важно понимать, а за какой вообще период данные есть в отчете.
- Ссылка на документацию – если, посмотрев все, что мы указали до этого, пользователь заинтересовался отчетом, то можно зайти и посмотреть документ с более подробным описанием, где описаны все детальные требования.
- Контактное лицо – сотрудник, который может проконсультировать коллег в случае возникновения вопросов по отчету.
- Ссылка на отчет – если появляется понимание, что отчет подходит, то можно сразу кликнуть на ссылку и попасть в форму отчета.
А теперь по порядку.
1. Глоссарий
В больших компаниях все говорят на разных языках. Для одного отдела адрес – это адрес по прописке, а для другого — адрес фактического проживания.
Как решить эту проблему? На помощь приходит единый словарь узкоспециализированных терминов, сокращений и понятий — глоссарий. К разработке которого мы и приступили.
2. Реестр
В реестре мы отразили все отчеты, а их оказалось очень много. Рассчитывать, что пользователь посмотрит все, что в нем приведено, не приходится. Поиск по ключевым словам тоже может не всегда корректно сработать. Для помощи в поиске мы разделили все отчеты по предметным областям и вывели это поле в фильтры.
А что еще можно включить в реестр с целью информирования? Тут уже на ваше усмотрение, но вариантов еще много: заказчик отчетности (т.е. кто вообще выставлял требования на данную отчетность), первоначальные источники информации (т.е. откуда данные попадают в хранилище), инструмент визуализации и многое другое.
Достаточно ли реестра для решения потребностей пользователя без детального описания атрибутного состава? Конечно же, нет. И для каждого отчета мы стали готовить это описание.
Само собой, указать просто наименование атрибута будет мало. Поэтому мы решили указывать следующие моменты:
- Наименование атрибута — все понятно
- Описание атрибута – здесь указывается бизнес-смысл термина и, если он расчетный, то бизнес-логика расчета
- Тип атрибута – измерение или показатель
- Категория атрибута – атрибут просто фильтр, или только отражается в отчете, или вообще присутствует и как фильтр, и как атрибут отчета
Взаимодействие глоссария и реестра
И вот у нас есть удобный инструмент для просмотра отчетности, реализованной в компании, и это уже огромная победа. И в который раз появляется НО…
А как же связаны между собой Реестр отчетов с общим описанием отчета, реестр отчетов с детализированным описанием отчета и глоссарий?
Чтобы ответить на этот вопрос, давайте посмотрим на схему:
Итак, пользователь может начать поиск либо с реестра отчетов с общим описанием, либо с глоссария.
А дальше настроены переходы:
- Глоссарий – Детальное описание отчетов – при данном переходе при нажатии на наименование термина вы попадаете на страницу детального описания термина, на которой отображаются отчеты, в которых используется данный термин. Через наименование отчёта можно перейти в реестр отчётов.
- Реестр отчетов– Детальное описание отчетов – при данном переходе при нажатии на наименование отчета вы попадаете на лист с детальным описанием отчета, где указан атрибутивный состав. Через каждый атрибут можно перейти в глоссарий.
Так мы смогли связать два основных инструмента информирования по реализованной отчетности и заложить основу под полноценный процесс Data Lineage.
Но это не все инфосервисы, которые мы реализовали. Помимо разработанной отчетности, мы захотели показать, какие данные у нас есть в хранилище и с какой периодичностью они загружаются. Для этих целей на портале мы опубликовали Карту данных.
3. Карта данных
Так как нам требовался простой, понятный инструмент, которым смог бы воспользоваться любой заинтересованный пользователь, мы сделали дашборд, состоящий из двух вкладок:
- На основной вкладке, мы показали все источники, подключенные к нашему хранилищу. А их у нас немало – более 150 штук. Но информация о названии источников не была бы полезной, если бы мы не отразили регламент и плановые даты загрузки. Так что мы добавили и эту информацию.
- На второй вкладке мы уже детализировали информацию до таблиц и атрибутов по слоям хранилища. Структуры и описание таблиц операционного слоя, загружаемого в исходном формате с источника. И структуры аналитического слоя — слоя отчетных витрин.
Судя по полученной обратной связи, этот инструмент оказался очень полезен для наших пользователей и бизнес-заказчиков. Они уже без обращения к специалистам нашего департамента смогли получить общее представление о данных, которыми мы оперируем в хранилище.
Что еще хотелось бы донести о портале? Помимо инфосервисов, которые рассказывают нам о том, что реализовано, на портал мы вынесли разделы о текущих активностях. Наши активности разделены на два больших стрима – это линейное развитие и проекты. В рамках линейного развития мы развиваем отчетность по текущим потребностям бизнес-заказчиков, в рамках проектов – крупные инфраструктурные активности, связанные с развитием самого хранилища. Вот и на портале публикуем всю информацию об этих активностях — цели, задачи, участники проекта, план работ, вехи.
Не порталом единым
Если вы подумали, что мы зациклились на портале, то это не так. Чтобы обеспечить прозрачность процессов и информировать заказчиков об этапах выполнения задач, мы взялись и за Jira. По своей сути Jira –система, которая больше подходит для организации поддержки и разработки. Но минусом Jira является то, что в ней практически отсутствуют возможности управления сроками. Планирование сроков приходится делать вовне, к примеру, в MS Project.
Как дать заказчику привычный формат планирования сроков в современном инструменте организации работ нашего подразделения? Для себя мы нашли решение в установке плагина BigGantt.
Какие новые функции привнёс данный плагин в функционал JIRA:
- Появилась возможность иерархии для всех эпиков\задач\подзадач
- Появилась возможность выстраивать зависимости между задачами по принципу диаграммы Ганта
- Появилась возможность планирования предстоящего спринта непосредственно в интерфейсе плагина
- Появилась возможность наглядного отображения текущих активностей в формате диаграммы Ганта.
В результате заказчик получил возможность в любой момент времени видеть актуальную статистику по выполнению задач в виде отчета и диаграммы Ганта.
С инструментарием портала вроде бы все понятно. Но как сделать так, чтобы пользователи узнавали о наших продуктах по мере их появления и вывода на прод? Для решения этой задачи мы внедрили практику рассылки регулярных дайджестов. Формат и контент дайджеста перерабатывался несколько раз перед тем, как уйти в рассылку. Но в итоге мы пришли к наиболее удобному подходу:
- Отразили минимально полезную информацию о задаче, ссылку на бизнес-функциональные требования и контактное лицо по проекту.
- Разделили дайджесты на 2 типа: ежемесячные по линейному развитию и квартальные по проектной деятельности.
- Зафиксировали ответственных за подготовку, верификацию и согласовали регламент подготовки.
Когда дайджест готов, встает вопрос с адресатами: кому его направлять и как сформировать список рассылки? Первоначально список адресатов мы готовили на основе обратной связи от бизнес-партнеров направлений. После чего запросили рекомендации по контактам от самих адресатов. Так мы получили список, охватывающий основную целевую аудиторию. Для остальных заинтересованных рассылке проработали возможность подписаться самостоятельно на портале DataOffice, либо подать обращение на единый почтовый ящик.
Следующий способ информирования, который мы у себя стали использовать — проведение вебинаров. На вебинарах мы рассказываем о наших процессах, подходах к реализации задач, об основных направлениях деятельности по линейному развитию отчётности, план/факт по реализации задач отчетности. Данный формат оказался очень удобен, так как можно было сразу получить обратную связь и обсудить открытые вопросы.
Чтобы полезная информация никуда не терялась и ее можно было оперативно получить, мы все вебинары сохраняем на портале.
Но и на этих способах информирования мы не остановились, мы стали активно взаимодействовать с коллегами в рамках Гильдий, самоорганизованных сообществ из специалистов разных направлений и проектов. В нашей компании уже запущены гильдии архитекторов, проектных менеджеров, аналитиков. Внутри гильдии мы обсуждаем общие практики, вырабатываем совместный инструментарий и подход. Сейчас активно развиваем проект «внутренняя митапная», призванный повысить эффективность митапов и заинтересовать остальных коллег подключаться к ним.
Пока это все, что мы хотели вам рассказать о наших инструментах. Но мы не останавливаемся на достигнутом и продолжаем работать над развитием наших коммуникаций. Будем рады, если наш опыт для вас окажется полезным!
Команда DataOffice
