На самом деле акцент в первом примере был сделан именно на «неудобства в использовании диаграммы Ганта», которая является одним из многих типов диаграмм, которые можно строить в MS Project. Просто так уж получилось, что по умолчанию, именно диаграмма Ганта отображается при старте работы с проектом и создалась стойкая ассоциация: MS Project = Gantt chart. Надеюсь, что если удастся хорошо проинтегрироваться с MS Project, работа в последнем станет еще удобнее и еще более наполненней смыслом.
А вот аргументированно высказываться «за» или «против» использования MS Project в управлении проектами связанных с разработкой ПО в целом я пока не буду. Это тема отдельного исследования и отдельного обсуждения.
К счастью в нашей компании любят пробовать новое, и считается делом чести доводить начатое до конца, так что уверен, что инструмент будет.
У меня есть все основания полагать, что инструмент будет удобен, как минимум, мне. Есть список требований, которые я, наверное, выложу в блоге (не думаю, что имеет смысл выкладывать требования на хабр, наверное, это не тот формат полноценной статьи — на хабре я опубликую описание готового инструмента, отчет по использованию в боевых условиях и информацию откуда скачать, чтобы попробовать).
Но если будут какие-то интересные предложения по функционалу — буду рад выслушать. Опять же, будет здорово, если это все поможет кому-то кроме нас.
Согласен, что тут еще на «думать, думать и пробовать» идей не на один месяц.
А вот с приведенным минусом не могу согласиться. Один из вариантов — объединять регионы-задачи в более крупные образования. Есть же аналогия: города, районы, области, федеральные округа, государства, континенты. Так же можно и поступать в управлении проектами при структурной декомпозиции работ (если о ней речь).
Второй вариант — использовать цвет для отображения различных типов задач.
Есть и другие варианты, но суть в том, что вот тут-то как раз и нет теоретических и практических наработок, чтобы сразу сходу сказать: «лучшая практика — такая! используйте вот такое разбиение по типам и такую цветовую гамму!». Нет, этого нет. Тут все пока будет зависеть от особенностей проекта. Мы планируем реализовать несколько вариантов, принципов формирования проектных карт, нечто вроде шаблонов и при старте можно будет выбрать один из них.
Насчет параллельных задач.
На самом деле есть вариант для отображения параллельных задач. Про отображение последовательных задач я рассказал в статье, а 2 параллельные задачи уже были отображены на картинках: обратите внимание на 2 «зеленые» задачи «СИР» и «ТЗ на ПГУ» — они могут выполняться параллельно (направление движение к цели — слева направо).
Спасибо за оценку. Будет здорово, если это реально начнет приносить пользу не только в нашей компании.
По поводу инструментария.
Да, правильно. Те картинки, что есть в статье, рисовались вручную. Но цитата про интеграцию «работает». Мы сделали прототип инструментария для построения таких диаграмм. Только есть проблема: быстро сделали то, что я рассказал при постановке задачи, но не то, что я хотел. Суть любой диаграммы — представлять числовую информацию в удобном для восприятия визуальном виде. Если информация представляется в визуальном, но в неудобном для меня виде, то я не считаю это вообще «диаграммой» (ну или считаю ее очень неудачной диаграммой). Она для меня бесполезна и использовать ЭТО я не хочу и не буду.
Поэтому когда встал вопрос: «что делаем: 1) мучаемся и используем неудобные диаграммы? 2) ждем когда выйдет второй прототип, и может он окажется лучше? 3) рисуем вручную?» выбрали вариант «рисовать вручную», а так как рисовать диаграммы считалось долгим и муторным делом, и руководители проектов как-то не очень хотели этим заниматься, то решили проблему просто — выделили из бюджета немного денег для «ручных автоматизаторов». И сейчас отрабатываем в режиме «свободного полета» методики расположения регионов, пробуем разные правила. Заодно пополняем требования к разрабатываемому прототипу №2.
По поводу «расчета площади регионов».
Конечно же, при рисовании вручную никто не вычисляет точно площади фигур. Проектные карты рисуются «на глазок». Более того, я категорически против затрат времени на вычисление точных площадей. Зачем? Если нужно будет сделать выбор между «точностью отображения соответствия площади фигур к числовым значениям» и «удобством использования», я без сомнений выберу второе. Главное, чтобы я мог по диаграмме быстро оценить представленную информацию в качественных характеристиках, а не в количественных. Если мне нужны будут точные числа, я просто загляну в табличные данные, где содержатся числа, и увижу, что на самом деле точное значение фактических трудозатрат: «6,7 часа», а не "~7 часов" как показалось сначала. Один из простых вариантов реализации — сделать диаграммы кликабельными, и по клику открывать карточку задачи (по URL'у в JIRA, например), где и будет вся точная информация.
Когда будет действительно удобный вариант составления диаграмм в автоматическом режиме, то там можно и точные площади использовать, но и в этом случае я не вижу особой пользы от такой точности. Ведь, как я уже говорил, любая диаграмма ценна в первую очередь не точностью отображения числовой информации, а удобством восприятия.
Про ситуационный центр.
Честно говоря, не понимаю, почему до сих пор нет удобных инструментов для реализации этого функционала для управления проектами (а может есть?). Ведь потребность очевидна. Всё по отдельности есть, а чтобы вместе всё собрать — нет времени кому-нибудь этим заняться? Думаю, что если идея «проектных карт» будет интересна не только нам, и возникнет интерес к этой теме среди руководителей проектов других компаний, то обязательно начнем делать и «ситуационный центр».
«Правовая оборона РПП» звучит грозно.
За картинку спасибо — подумалось, почему бы не начать собирать вообще все применения карт в отображении информации напрямую не связанной с топографией местности и военными действиями. Интересно посмотреть, как и где что-то было использовано — наверняка полно инфографики со схожей тематикой. А если такие «карты» разрабатывали профессионалы — вообще замечательно, наверное, можно оттуда подчерпнуть массу идей для оформления «проектных карт».
Так что если кто-то что-то где-то увидит похожее — буду благодарен, если бросите сюда ссылку или сразу картинку.
Да, хорошее практическое решение. Простое и действенное. Главное, что оно помогало и помогает кому-то.
Вообще, чем проще все выглядит на диаграммах, тем лучше, главное, чтобы внимание на лишние, никому не нужные детали не отвлекалось: только на то, что надо.
А вот аргументированно высказываться «за» или «против» использования MS Project в управлении проектами связанных с разработкой ПО в целом я пока не буду. Это тема отдельного исследования и отдельного обсуждения.
У меня есть все основания полагать, что инструмент будет удобен, как минимум, мне. Есть список требований, которые я, наверное, выложу в блоге (не думаю, что имеет смысл выкладывать требования на хабр, наверное, это не тот формат полноценной статьи — на хабре я опубликую описание готового инструмента, отчет по использованию в боевых условиях и информацию откуда скачать, чтобы попробовать).
Но если будут какие-то интересные предложения по функционалу — буду рад выслушать. Опять же, будет здорово, если это все поможет кому-то кроме нас.
А вот с приведенным минусом не могу согласиться. Один из вариантов — объединять регионы-задачи в более крупные образования. Есть же аналогия: города, районы, области, федеральные округа, государства, континенты. Так же можно и поступать в управлении проектами при структурной декомпозиции работ (если о ней речь).
Второй вариант — использовать цвет для отображения различных типов задач.
Есть и другие варианты, но суть в том, что вот тут-то как раз и нет теоретических и практических наработок, чтобы сразу сходу сказать: «лучшая практика — такая! используйте вот такое разбиение по типам и такую цветовую гамму!». Нет, этого нет. Тут все пока будет зависеть от особенностей проекта. Мы планируем реализовать несколько вариантов, принципов формирования проектных карт, нечто вроде шаблонов и при старте можно будет выбрать один из них.
Насчет параллельных задач.
На самом деле есть вариант для отображения параллельных задач. Про отображение последовательных задач я рассказал в статье, а 2 параллельные задачи уже были отображены на картинках: обратите внимание на 2 «зеленые» задачи «СИР» и «ТЗ на ПГУ» — они могут выполняться параллельно (направление движение к цели — слева направо).
Спасибо за оценку. Будет здорово, если это реально начнет приносить пользу не только в нашей компании.
По поводу инструментария.
Да, правильно. Те картинки, что есть в статье, рисовались вручную. Но цитата про интеграцию «работает». Мы сделали прототип инструментария для построения таких диаграмм. Только есть проблема: быстро сделали то, что я рассказал при постановке задачи, но не то, что я хотел. Суть любой диаграммы — представлять числовую информацию в удобном для восприятия визуальном виде. Если информация представляется в визуальном, но в неудобном для меня виде, то я не считаю это вообще «диаграммой» (ну или считаю ее очень неудачной диаграммой). Она для меня бесполезна и использовать ЭТО я не хочу и не буду.
Поэтому когда встал вопрос: «что делаем: 1) мучаемся и используем неудобные диаграммы? 2) ждем когда выйдет второй прототип, и может он окажется лучше? 3) рисуем вручную?» выбрали вариант «рисовать вручную», а так как рисовать диаграммы считалось долгим и муторным делом, и руководители проектов как-то не очень хотели этим заниматься, то решили проблему просто — выделили из бюджета немного денег для «ручных автоматизаторов». И сейчас отрабатываем в режиме «свободного полета» методики расположения регионов, пробуем разные правила. Заодно пополняем требования к разрабатываемому прототипу №2.
По поводу «расчета площади регионов».
Конечно же, при рисовании вручную никто не вычисляет точно площади фигур. Проектные карты рисуются «на глазок». Более того, я категорически против затрат времени на вычисление точных площадей. Зачем? Если нужно будет сделать выбор между «точностью отображения соответствия площади фигур к числовым значениям» и «удобством использования», я без сомнений выберу второе. Главное, чтобы я мог по диаграмме быстро оценить представленную информацию в качественных характеристиках, а не в количественных. Если мне нужны будут точные числа, я просто загляну в табличные данные, где содержатся числа, и увижу, что на самом деле точное значение фактических трудозатрат: «6,7 часа», а не "~7 часов" как показалось сначала. Один из простых вариантов реализации — сделать диаграммы кликабельными, и по клику открывать карточку задачи (по URL'у в JIRA, например), где и будет вся точная информация.
Когда будет действительно удобный вариант составления диаграмм в автоматическом режиме, то там можно и точные площади использовать, но и в этом случае я не вижу особой пользы от такой точности. Ведь, как я уже говорил, любая диаграмма ценна в первую очередь не точностью отображения числовой информации, а удобством восприятия.
Про ситуационный центр.
Честно говоря, не понимаю, почему до сих пор нет удобных инструментов для реализации этого функционала для управления проектами (а может есть?). Ведь потребность очевидна. Всё по отдельности есть, а чтобы вместе всё собрать — нет времени кому-нибудь этим заняться? Думаю, что если идея «проектных карт» будет интересна не только нам, и возникнет интерес к этой теме среди руководителей проектов других компаний, то обязательно начнем делать и «ситуационный центр».
За картинку спасибо — подумалось, почему бы не начать собирать вообще все применения карт в отображении информации напрямую не связанной с топографией местности и военными действиями. Интересно посмотреть, как и где что-то было использовано — наверняка полно инфографики со схожей тематикой. А если такие «карты» разрабатывали профессионалы — вообще замечательно, наверное, можно оттуда подчерпнуть массу идей для оформления «проектных карт».
Так что если кто-то что-то где-то увидит похожее — буду благодарен, если бросите сюда ссылку или сразу картинку.
Вообще, чем проще все выглядит на диаграммах, тем лучше, главное, чтобы внимание на лишние, никому не нужные детали не отвлекалось: только на то, что надо.