Да и масштаб непонятен, моё, например, наблюдение и эксперименты на моих ребятах – 15 человек (менеджеры, разработчики) показали, что кросс-функциональные команды – зло. Сколько промежуточных уровней (условных sem-ов) не вводи, производительность и эффективность выше, когда микро-команды побиты по «продуктам».
Классная статья! А сколько сейчас дата-инженеров (да и вообще специалистов) с вашей стороны поддерживают эту махину у Mediascope? Или обучили и полностью передали поддержку и развитие внутрь MS? Это тоже один из критериев зрелости конкретного low-code решения, по которому знания сконцентрированы внутри вендора, что формирует условный «vendor-lock» для клиента.
В любом случае все проекты и цели из верхнеуровневой матрицы должны быть разобраны/распределены. Если нет — то зачем они там? Зачем вы их туда вписали? Удаляйте их из верхнего уровня — и дело с концом)))
Не всё так просто. Может моё подразделение «на это не ответит», а подразделение моего коллеги сможет поддержать и ответить. Тут не как в дизайне — отрезаем всё лишнее, тут думать нужно :)
Если какой-то пункт оказался никак не закрытым, т.е. ни один Х не стоит — то да, опять таки мы себе где-то врём — удаляйте.
Опять же, есть разница: вы про «ни один X по всем квадрантам» или «хотя бы один X в квадрантах»?
Глобально, задача карты получить набор проектов(гипотез, проекты же гипотетически дадут нам реализацию этих метрик) и метрик.
Это мы вкурили. Но последовательность заполнения, кажется, что тоже важна. Страт.решение -> цель -> проект -> метрика -> страт.решение. Или нет?
Шея болит — можете сделать многостраничный документ, тогда шея не болит, но зато не очевидно как одно влияет на другое.
Да, тут согласен, с многостраничным документов потом голова болит или не болит, когда он в шкафу лежит :)
@gkarapet, ещё один вопрос. Сели мы вчера делать каскадирование с уровня отдела до уровня команд и вот алгоритма то у нас нет из статьи. Вроде всё понятно, бери цели вышестоящего уровня и делай их страт.решениями нижележащего. Но:
Точно ли нужно брать все цели или только те, что комплементарны/на которые можем влиять?
Их мы не переформулировать не можем, так, а то это другая цель получится?
Дальше алгоритм какой? Формулируем свои цели по одно и проходим полный круг от страт.решения -> цель -> проект -> метрика -> страт.решение?
Ещё мы поняли, что если прошли круг из п.3 и образовались «х» во всех квадрантов, то удалось засинхронизировать страт.решение с остальными клмпонентами, а если не можем поставить где-то «х», то что-то в процессе пошло не так, верно?
Есть где-то рабочий пример по каскадированию вышележащих целей на низлежащие подразделения? Нам будет достаточно одного уровня чтобы вкурить :)
И да, общекомандный фидбек на тему представления – удобно читать, но шея болит, если составлять 1,5-2 часа
gkarapet, большое спасибо за столь лаконичный и понятный фреймворк.
Сели с командной каскадировать верхнеуровневые цели до нашего подразделения и вот вопрос: мы всю тактику в кач-ве стратегических целей берём на свой уровень или только то, что применимо / на что можем повлиять? Вроде ответ очевиден, но хотелось бы получить пояснений.
Спасибо, но не всё конечно, только шаги с подготовкой и графиков и их «раскраску».
Про общую рентабельность замечание справедливое, считать нужно точнее, иногда лучше даже с таймером рядом с исполнителями до и после автоматизации :). Но поверьте, трудозатраты недели работы BI разработчика, сильно ниже трудозатрат клиентской команды, которая готовит слайды по 12 рег.представительствам.
Что до Tableau, то в данной задаче публиковали все дашборды на Tableau Server, просто потому, что у нас он уже был и используется и других проектов, но с таким же успехом могли бы и отдать проект, который может открыть Tableau Reader, а сам проект можно собрать и в бесплатном Tableau Public Desktop.
Вспомнился сервис дашбордов webjets.io
Про webjets.io не слышал, но насколько понял, он больше про структуризацию информации в целом, а тут задача в установленном формате выдать набор слайдов. В компании, кстати, был кейс, когда клиентская команды сами осваивают BI-инструменты, такие как Power BI, где порог входа сильно ниже и собрать обновляемый дашборд на файлах в OneDrive можно за считанные часы.
Отличная идея с проверкой востребованности!
А что стало первой версией? Какие сервисы выдали в бота и как рассказали о нём внутри? И как часто вы рассказываете про его обновления и через какой канал (почта/корп.мессенджеры/портал)?
И главный вопрос: до бота, как осуществлялся доступ к тем сервисам, что вы в него выдали? Через корп.портал? Непосредственно через людей (телефон/почта)?
ЗдОрово, было бы интересно послушать: как вы к этому пришли, как запускали и что стало отправной точкой? Просто решили попробовать или стояла цель – упростить/ускорить/дать доступ к сервисам с мобильного?
Как писал в статье, мы пока приостановили эксперименты с чат-ботами и платформами на которых их можно спроектировать и реализовать. Но как знать, если появится явная потребность внутри или для наших клиентов, обязательно вас рассмотрим ;-)
Не за что, hlogeon. Да, вы правы, мы пришли примерно к этому же. Есть даже такое направление дизайн чат-ботов, как-то рассказывал про это на Conversations AI.
Ну и старайтесь делать сценарии короткими, как делают ребята из Моя Москва, там даже текстовый ввод включается только тогда, когда нужен :)
Тот, что организовывал встречи, анализировал реплики — это виджет поставщика Just-AI, но с запрограммированным сценарием именно на это действие: «организация встреч».
А тот, что «Тайного санту» провести — да, реализация сценария через понятный API Telegram.
Ценность поставщика тут в том, что простого бота можно собрать и самому и «на коленке», а вот сделать его «умным» (хотя бы понимающим что от него хотят), тут уже нужны системы другого класса, потому как мессенджер, это всего-лишь канал доставки сообщений со своим UI и UX, без какой-либо логики.
cellmon, речь о платформах для создания «умных» чат-ботов, таких, н-р, как autofaq.ai, Just-AI, Chatme.ai и прочих, как правило они привносят дополнительную ценность и функциональность. Такую, например, как NLP или NER. И смысл обращения к ним как раз в том, чтобы быстрее получить ту экспертизу, которую предоставляет поставщик, чем развивать её годами у себя, оттягивая старт.
Это прекрасно, и метафора и подача!
Да и масштаб непонятен, моё, например, наблюдение и эксперименты на моих ребятах – 15 человек (менеджеры, разработчики) показали, что кросс-функциональные команды – зло. Сколько промежуточных уровней (условных sem-ов) не вводи, производительность и эффективность выше, когда микро-команды побиты по «продуктам».
Классная статья! А сколько сейчас дата-инженеров (да и вообще специалистов) с вашей стороны поддерживают эту махину у Mediascope? Или обучили и полностью передали поддержку и развитие внутрь MS? Это тоже один из критериев зрелости конкретного low-code решения, по которому знания сконцентрированы внутри вендора, что формирует условный «vendor-lock» для клиента.
Не всё так просто. Может моё подразделение «на это не ответит», а подразделение моего коллеги сможет поддержать и ответить. Тут не как в дизайне — отрезаем всё лишнее, тут думать нужно :)
Опять же, есть разница: вы про «ни один X по всем квадрантам» или «хотя бы один X в квадрантах»?
Это мы вкурили. Но последовательность заполнения, кажется, что тоже важна. Страт.решение -> цель -> проект -> метрика -> страт.решение. Или нет?
Да, тут согласен, с многостраничным документов потом голова болит или не болит, когда он в шкафу лежит :)
@gkarapet, ещё один вопрос. Сели мы вчера делать каскадирование с уровня отдела до уровня команд и вот алгоритма то у нас нет из статьи. Вроде всё понятно, бери цели вышестоящего уровня и делай их страт.решениями нижележащего. Но:
Точно ли нужно брать все цели или только те, что комплементарны/на которые можем влиять?
Их мы не переформулировать не можем, так, а то это другая цель получится?
Дальше алгоритм какой? Формулируем свои цели по одно и проходим полный круг от страт.решения -> цель -> проект -> метрика -> страт.решение?
Ещё мы поняли, что если прошли круг из п.3 и образовались «х» во всех квадрантов, то удалось засинхронизировать страт.решение с остальными клмпонентами, а если не можем поставить где-то «х», то что-то в процессе пошло не так, верно?
Есть где-то рабочий пример по каскадированию вышележащих целей на низлежащие подразделения? Нам будет достаточно одного уровня чтобы вкурить :)
И да, общекомандный фидбек на тему представления – удобно читать, но шея болит, если составлять 1,5-2 часа
ПОнято, спасибо ;)
Сели с командной каскадировать верхнеуровневые цели до нашего подразделения и вот вопрос: мы всю тактику в кач-ве стратегических целей берём на свой уровень или только то, что применимо / на что можем повлиять? Вроде ответ очевиден, но хотелось бы получить пояснений.
И простите, что нажал dislike :( UX у Хабра хромает, конечно, и теперь не забрать/не отменить голос нельзя.
Спасибо, но не всё конечно, только шаги с подготовкой и графиков и их «раскраску».
Про общую рентабельность замечание справедливое, считать нужно точнее, иногда лучше даже с таймером рядом с исполнителями до и после автоматизации :). Но поверьте, трудозатраты недели работы BI разработчика, сильно ниже трудозатрат клиентской команды, которая готовит слайды по 12 рег.представительствам.
Что до Tableau, то в данной задаче публиковали все дашборды на Tableau Server, просто потому, что у нас он уже был и используется и других проектов, но с таким же успехом могли бы и отдать проект, который может открыть Tableau Reader, а сам проект можно собрать и в бесплатном Tableau Public Desktop.
Про webjets.io не слышал, но насколько понял, он больше про структуризацию информации в целом, а тут задача в установленном формате выдать набор слайдов. В компании, кстати, был кейс, когда клиентская команды сами осваивают BI-инструменты, такие как Power BI, где порог входа сильно ниже и собрать обновляемый дашборд на файлах в OneDrive можно за считанные часы.
А что стало первой версией? Какие сервисы выдали в бота и как рассказали о нём внутри? И как часто вы рассказываете про его обновления и через какой канал (почта/корп.мессенджеры/портал)?
И главный вопрос: до бота, как осуществлялся доступ к тем сервисам, что вы в него выдали? Через корп.портал? Непосредственно через людей (телефон/почта)?
Ну и старайтесь делать сценарии короткими, как делают ребята из Моя Москва, там даже текстовый ввод включается только тогда, когда нужен :)
Тот, что отвечал на произвольные и семантически близкие вопросы — на базе движка autofaq.ai, но с интерфейсом через Telegram.
А тот, что «Тайного санту» провести — да, реализация сценария через понятный API Telegram.
Ценность поставщика тут в том, что простого бота можно собрать и самому и «на коленке», а вот сделать его «умным» (хотя бы понимающим что от него хотят), тут уже нужны системы другого класса, потому как мессенджер, это всего-лишь канал доставки сообщений со своим UI и UX, без какой-либо логики.