Сейчас, до окончательного перехода на мониторинг ИТ-сервисов, по большинству ИТ-сервисов/ИТ-систем мы экспертно определяем, какие события и для каких КЕ приведут к влиянию на информационную систему/ИТ-сервис и в свою очередь на пользователей данных сервисов/систем.
Самая частая причина ошибки "Почему цифры не сходятся" - это как раз расписание ETL/ELT или некорректный сбор данных в скрипте. Дата-инженер сделает только так, как вы ему поставите задачу, а вот сформировать логику, чтобы с точки зрения бизнеса, было все корректно и на ваши цифры можно равняться другим - тут и пригодится опыт работы с ETL/ELT.
По своему опыту, как мы побеждали бюрократию с помощью Jira, может будет как доп.совет или нет:
Все встречи команды/отдела велись в Confluence, включая планы доработок по системе, типа добавить поле customfield, или договоренности по корректировке бизнес-процесса и правил по работе (чтобы никто не съехал с темы)
Учили JQL и творили дашборды для руководства с презентацией работы в режиме онлайн, без требования времени на подготовку отчетов. Отталкивались от стандартных метрик, типа заблокированной работы, потом делали кастомные под конкретный процесс. (это поможет внедрять инструменты сверху)
Учили Project Automation и облегчали работу команды по максимуму, в соответствии с правилами работы с досками. Например, когда шло подписание договора на новую позицию, то автоматом задача переводилась на коллег, которые занимаются сопровождением текущих сделок и одновременно задача падала коллегам, которые получали явный триггер, что можно идти строить и нет препятствий. По аналогии с Тойотой откуда все это растет, при подготовке к строительству объекта они на той же доске видели, когда будет подписан договор и к какому моменту уже можно заказывать оборудование.
Чтобы необходимая по кастомным полям информация собиралась и не оставляла дыр, делали условия перехода карточки в другой статус, что пока какая-то инфа не внесена, то jira не дает перевести карточку дальше.
Научили каждого члена команды отслеживать свои метрики через дашборды или фильтры.
Руководству продали со временем инфу, что более не используем эксель-менеджмент в отделе (помогло внедрить эту историю у коллег)
При внедрении этих же продуктов у коллег, получилось настроить интеграцию с автоматическими обменами задач, как только есть необходимость привлекать их в работу.
Одно из самых главных, чем "сманили немолодых", провели ретро и показали на конкретных примерах и тех же дашбордах, что некоторые элементы процесса стрельнули по времени отработки. У нас так сроки подписания договора сократились в 2 раза, по строительству объектов сократился срок подачи сервиса, что есть чистые денюжки. У нас большинство "немолодых" люди все-таки с системным мышлением, и такая конкретика структурировала хаос от непонятных изменений в их представлении.
Такая линия поведения приемлема, если ты готов уйти. Иногда нет альтернативы и уходишь в никуда и расходы очень огромные. Торги и предложения в этом случае идут против тебя. Это специфика бизнеса нашей страны, рубить сук на котором сидишь.
Работаю переговорщиком в телекоме более 5 лет. Из нескольких сотен переговоров вынес один единственный вывод, что иностранные книги о переговорах в России полная чушь, методы которых работают в 1% случаев.
Для примера один и тот же кейс: вторая сторона хочет повысить аренду
При этом в Дагестане если ты не поторгуешься, на тебя обидятся, и в 90% случаев ты договариваешься в свою пользу.
В Татарстане ни о каком сохранении или скидке не будет идти речи, если ты не татарин (в большинстве своем)
В Москве сразу отказ от сотрудничества и угрозы демонтажа оборудования с первого контраргумента.
Зашел аналитический разбор этого всего со всеми выводами и примерами. Спасибо большое
Спасибо за ваш пост и примеры ответов к каждому вопросу.
Чего не указано в посте, но тоже спрашивали меня в телекоме:
вопросы про Engine API,
написание своих экстеншенов,
mashup - дашборды,
настройка таски/потока/сетевой папки для QVD,
темы и CSS,
iframe - визуализации.
оптимизация скрипта, если там есть секция SQL ( не рекомендовалось выносить сложные SQL с оконками,with и тп. в скрипт загрузчика)
Слишком много сервисов (см.выше). Идея крутая.
Самая частая причина ошибки "Почему цифры не сходятся" - это как раз расписание ETL/ELT или некорректный сбор данных в скрипте. Дата-инженер сделает только так, как вы ему поставите задачу, а вот сформировать логику, чтобы с точки зрения бизнеса, было все корректно и на ваши цифры можно равняться другим - тут и пригодится опыт работы с ETL/ELT.
Привет, коллега из телекома!
По своему опыту, как мы побеждали бюрократию с помощью Jira, может будет как доп.совет или нет:
Все встречи команды/отдела велись в Confluence, включая планы доработок по системе, типа добавить поле customfield, или договоренности по корректировке бизнес-процесса и правил по работе (чтобы никто не съехал с темы)
Учили JQL и творили дашборды для руководства с презентацией работы в режиме онлайн, без требования времени на подготовку отчетов. Отталкивались от стандартных метрик, типа заблокированной работы, потом делали кастомные под конкретный процесс. (это поможет внедрять инструменты сверху)
Учили Project Automation и облегчали работу команды по максимуму, в соответствии с правилами работы с досками. Например, когда шло подписание договора на новую позицию, то автоматом задача переводилась на коллег, которые занимаются сопровождением текущих сделок и одновременно задача падала коллегам, которые получали явный триггер, что можно идти строить и нет препятствий. По аналогии с Тойотой откуда все это растет, при подготовке к строительству объекта они на той же доске видели, когда будет подписан договор и к какому моменту уже можно заказывать оборудование.
Чтобы необходимая по кастомным полям информация собиралась и не оставляла дыр, делали условия перехода карточки в другой статус, что пока какая-то инфа не внесена, то jira не дает перевести карточку дальше.
Научили каждого члена команды отслеживать свои метрики через дашборды или фильтры.
Руководству продали со временем инфу, что более не используем эксель-менеджмент в отделе (помогло внедрить эту историю у коллег)
При внедрении этих же продуктов у коллег, получилось настроить интеграцию с автоматическими обменами задач, как только есть необходимость привлекать их в работу.
Одно из самых главных, чем "сманили немолодых", провели ретро и показали на конкретных примерах и тех же дашбордах, что некоторые элементы процесса стрельнули по времени отработки. У нас так сроки подписания договора сократились в 2 раза, по строительству объектов сократился срок подачи сервиса, что есть чистые денюжки. У нас большинство "немолодых" люди все-таки с системным мышлением, и такая конкретика структурировала хаос от непонятных изменений в их представлении.
Для примера один и тот же кейс: вторая сторона хочет повысить аренду
При этом в Дагестане если ты не поторгуешься, на тебя обидятся, и в 90% случаев ты договариваешься в свою пользу.
В Татарстане ни о каком сохранении или скидке не будет идти речи, если ты не татарин (в большинстве своем)
В Москве сразу отказ от сотрудничества и угрозы демонтажа оборудования с первого контраргумента.