Склад знаний по управлению проектами

https://baguzin.ru/wp/dennis-shervud-videt-les-za-derevyami/ неплохо про системное мышление, но никак не могу дочитать

Если кратко, то здесь можно посмотреть https://tocpeople.com/terminy/status-bufera/

Вместе с ребятами из Make Sense подготовили лонгрид про проектирование дашбордов. Я прям доволен, давно хотел написать подобный гайд, но всё никак не доходили руки. А тут получился большой полезный материал, который можно использовать в качестве шпаргалки или узнать как и что, если вы только знакомитесь с дашбордами.

В статье:
— Рассказываю про алгоритм Dashboard Canvas и базовые принципы верстки;
— Обсуждаем какие BI-инструменты бывают и какие задачи они решают;
— Говорим про мобильные версии дашбордов, детализацию данных и частоту обновления.

А если вам интересна тема управления продуктом, то присмотритесь к каналу Make Sence и их подкасту, очень толковые.
#статья

​​Как упорядочить встречи в команде?

Знакомы ли вам ситуации, когда:

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

Это признаки того, что участники по-разному понимают cуть конкретной встречи. Вы можете предложить синхронизировать это понимание, используя один очень простой канвас (см.картинку). Он состоит из следующих разделов:

Название встречи
— Как мы называем эту встречу?

Цель
— Для чего мы проводим эту встречу?

Участники
— Кто обязательный участник, без кого нет смысла проводить встречу?
— Кого можно позвать, но не обязательно?

Вход
— Что нужно принести на встречу?
— Что нужно подготовить к этой встрече?

Выход
— Что мы унесем с этой встречи?
— Что должно получиться на выходе встречи?

Параметры встречи
— Сколько длится встреча?
— Как часто проходит?
— Где проходит?

Агенда
— Как проходит встреча?
— Что должно случиться на встрече, чтобы мы достигли ее цели?

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

Как заполнять канвас?

1️⃣Определите список встреч, по которым вы хотите синхронизироваться.

2️⃣ Дайте участникам 5 минут, чтобы заполнить канвас по встрече индивидуально.

3️⃣Последовательно обсудите каждый раздел. Если есть противоположные идеи, выслушайте их и попробуйте привести группу к единому понимаю по каждому пункту. Это самый важный этап, и вам потребуется все ваше фасилитаторское мастерство. Обязательно зафиксируйте итоговую договоренность и проверьте, что все согласны c ней.

4️⃣Заполните канвасы по всем встречам.

5️⃣Обсудите как и когда вы будете возвращаться к этим договоренностям.

Мы вешали итоги прямо на стену в комнате команды. Также можно разместить их в Miro, на доске конкретной встречи, чтобы было удобно возвращаться к ним прямо на встрече.

Как еще использовать?

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

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

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

❓А какие дополнительные вопросы вы бы включили в этот канвас?

#командные_договоренности

Оксана💜

Очень хорошая статья про Olap куб. Что это такое. Мне они никогда не нравились, так как я очень рано в своей карьере поработал с продуктами Microsoft SSAS, где нужно строить реальный куб поверх хранилища данных на SQL Server. У куба вместо SQL - MDX, и вообще это другой мир для BI разработчика.

Главный + для куба - прямой коннектор для Excel, и бизнес пользователи могут slice and dice данные и строить кросс таблички. Все работает как часы, да ещё практически бесплатно.

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

Но это лишь одна сторона слова OLAP. В модуле 6.2 я специально упомянул другие значения слов.

В общем автор круто расписал все значения и рассмотрел история вопроса.

По мне кубы (которые molap с MDX) - зло🤬

Из соседнего чатика на всякий пожарный:

Если вы искали словарь с ключевыми техническими терминами из области разработки ПО, то вот один из таких источников.


https://alekseisnuff.medium.com/%D1%82%D0%B5%D1%85%D0%BD%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F-%D0%B1%D0%B0%D0%B7%D0%B0-%D0%B4%D0%BB%D1%8F-%D0%BC%D0%B5%D0%BD%D0%B5%D0%B4%D0%B6%D0%B5%D1%80%D0%BE%D0%B2-%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%B0-%D1%87%D0%B0%D1%81%D1%82%D1%8C-1-7fc3f674a517

https://www.google.com/amp/s/habr.com/ru/amp/post/567546/

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

https://github.com/power-bi/PowerBI-book-ru Неофициальное, открытое методическое пособие к программе Power BI и надстройкам над Excel Power Query и Power Pivot

Сегодня на Ретроспективах в четырех командах работали с Causal Loop Diagram. Работали с потерями. Для начала мы выявили самые затратные по времени действия, которых можно было избежать и которые явились для команды Muda (термин из Lean, означающий потери). Команды сами отобрали такие действия и ранжировали их. Выбрали самые затратные из них. А потом уже мы вместе рисовали саму диаграмму с прямыми и обратными связями (P и N на моей диаграмме соответственно). В трех из четырех команд мы выявили самоусиливающиеся петли обратной связи, завязанные на одну из причин потерь. Самоусиливающиеся это когда одна из причин усиливаясь, влияет на другую причину, та на еще ряд причин и последняя из них влияет на исходную. Петля усиливается, если равновесие нарушается. Интересный инструмент системного мышления. Но рисовать в такие диаграммы в одиночку бессмысленно - только с командой. Подробно на русском об этом рассказано в переводе https://less.works/ru/less/principles/systems-thinking

Интересная небольшая статья, на мой взгляд. https://habr.com/ru/company/domclick/blog/565468/

Бомбанул статейку про парное программирование
http://agilemindset.ru/парное-программирование/

Кто читал? https://docs.google.com/document/d/1s1BH5Gdi448qpeM_NB5KPsXQXavO5h0H9pQX4sU4f1Q/edit — книга

https://www.sheidaei.com/article/challenge-estimate-or-override-ceo-game-for-effective-estimations/ Challenge, Estimate or Override (CEO)
1. Этап 1 - раскладываешь в ряд все задачи, от менее затратных\сложных\больше усилий к более
2. Этап 2 - Кладёшь сверху оценки, тоже челленджа, какая оценка к какой группе задач подходит, а какие - пограничные.

Вот скриншот с воркшопа (пример выдуманный)

Механика подробнее - по ссылке)