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