✅Завершаю цикл о базовом минимуме проектного офиса. Предыдущие посты: 1. Зачем это надо (и почему без него никак) 2. Инициация работ в ИТ (поток тут/проекты тут) 3. Ресурсы 4. Сроки 5. Изменения и остается 6. Дашборд - рабочее место РП/РПО и топов ✅ Зачем он нужен: 1. СЕО и прочим причастным топам: a. Понимать счет на табло – быстро и понятно, без опроса РПО/РП и прочих. b. Принимать решения на основании точных и актуальных данных (ибо решение, принятое на неточных данных, будет неточным. Неточное стратегическое решение может стоить десятки миллионов). c. Понимать, чем реально занято ваше АйТи. 2. РПО/CIO: a. отвечать СЕО и другим топам «чем реально вы заняты» и почему вы не можете «просто так взять и сделать вот этот проект послезавтра» b. контролировать свой портфель и РП реально просто и быстро c. контролировать заполнение учетных систем на которых строится дашборд d. использовать для эскалации проблем для их последующего решения. 3. РП: a. как механизм эскалации. b. как контроль самого себя (а я ничего не забыл?) ✅ Что обычно бывает, если он не формализован: - СЕО не понимает, кто и чем там у них занят - РПО/CIO во всем виноват – потому что банально не может показать кто и чем реально занят (инструмента то нет) - Перегрузка и выгорание: новые темы/проекты приходят без понимания пересечений с текущими. Итог: едут сроки и начинается хаос, который разруливается только за счет личного героизма участников. - СЕО не может нормально планировать стратегию – он думает, что контролирует, но на самом деле нет. ✅ Как формализовать минимально: Минимально тут не выйдет 🤷‍♂️ Чтобы Даш давал точную и полную информацию – она должна быть в ваших учетных системах. Все танцы про оценки задач, планирование, вехи, ресурсы и списания – нужны именно для дашборда. И чем лучше выстроены ваши ИТ процессы – тем точнее данные в системах – тем точнее дашборд. В идеале данные актуализируются автоматически, как только исполнители переводят задачу в Done или просто списывают время (Как это сделать – отдельная любопытная задачка, требующая отдельной статьи. Если интересно – пишите в каментах). Так что просто принимаю, что полная информация в системе есть 😎 Тогда хороший даш в моем понимании – это две страницы: 1️⃣ Общий статус всего портфеля проектов: в виде просто таблицы, где каждая строка дает статус по срокам, бабкам, рискам – все. Цель простая: если ОК – не глядим, идем дальше. Если не ОК – ныряем. 2️⃣ Детальный статус: a. все вехи (вехи, отклонения, прогнозы) b. детали по объему (сколько сделано, сколько остается, прогноз) c. детали по деньгам (потратили/получили/еще потратим/еще получим, маржа и вот это все) - в идеале расходы из часов надо тоже переводить в деньги. d. детали по рискам - если они у вас нормально ведутся e. метрики качества разработки по проекту (если трекаем) f. удовлетворенность клиента (собирается по факту, но нужна исторически) g. Визуализация - по вкусу. Светофоры вида "красный/желтый/зеленый" тут хороши и мне нравятся. Еще идеально сравнивать данные по разделам в формате "План/факт/отклонение/прогноз" выделяя прогноз нарушения как риски, а нарушения - как проблемы. На картинке - макет по этому подходу, но без дизайна. В реале это все делается нагляднее и приятнее глазу. А еще даш «в идеале» должен сам показывать все проблемы и риски, просто на данных и прогнозах - без РП ✅ Что получаем по итогу: 1. СЕО понимает, что происходит. И ему не надо бегать за РПО/РП, чтобы быстро понять статус проекта. 2. РПО теперь виноват только в нарушении того, что есть в дашборде. 3. РП получают четкие критерии и KPI для своих премий 4. Получаем практически идеальную систему мониторинга состояния проектов всей компании, которая показывает узкие места и способствует continuous improvement ✅ Мораль: Даш - вершина айсберга, которая дает Точную и Полную информацию по портфелю и каждому проекту. Если у вас не такой - это повод подумать, как его сделать. Если у вас такой, но не отражает реальности - доп