Критика современных систем управления проектами

    Когда я писал статью об управлении проектами с помощью MS Project, меня не покидало устойчивое ощущение, что я пишу что-то неправильное. «Ну не может такого быть,» — думал я, «чтобы такие простые вещи так сложно делались в программе, являющейся одним из самых распространенных инструментов для управления проектами.» Я проверял себя, раз за разом оценивал актуальность своих потребностей, изучал другие программные решения. И все равно приходил к неутешительному выводу: *у меня, как руководителя проекта, существуют потребности, которые то ли забыты, то ли сознательно игнорируются разработчиками*. Несмотря на впечатляющий список возможностей современных систем управления проектами, есть задачи, которые я просто не могу решить без помощи вспомогательных средств в силу естественных ограничений человеческого мышления.

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

    Нет внятных средств, помогающих составить план проекта


    Любая система позволяет запланировать исполнение задач, указать исполнителей, сроки и т.п. Как правило, это означает, что есть возможность ввести задачу в систему. Только почему-то предполагается, что пользователи таких систем ясновидящие и заранее знают, какие задачи планируются к выполнению.
    Нет ни одного внятного предложения, как от смутных идей перейти к списку или даже дереву задач из 100500 наименований. Некоторые элементы такого подхода наблюдаются в системах класса Application Life Cycle Management, однако, во всех таких системах серьезно провисает такой аспект, как календарное планирование.

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


    Неудобно работать с изменяющимся планом


    Когда план регулярно изменяется, то вносимые изменения, как правило, затирают прошлые значения. MS Project позволяет сохранить версию плана (т.н. базовый план), чтобы потом сравнивать его с текущим. Это немножко помогает, когда структура задач сильно не изменяется. На практике часто случаются декомпозиции одной задачи на несколько других, добавление и удаление связей между задачами, переоценка сроков. Довольно часто возникает потребность немного «поиграть», т.е. внести изменения в план, чтобы посмотреть как это отразится на конечных сроках или стоимости проекта: добавить исполнителей в проект, перераспределить задачи между исполнителями, добавить или удалить задачи. Когда таких изменений много, то простого сравнения с базовым планом недостаточно для понимания сути происходящих изменений.

    Мне очень не хватает журнала изменений плана, в котором видно — что, когда, и как было изменено. Также хочется иметь возможность вносить в него комментарии, объясняющие, зачем было сделано то или иное изменение. Иногда полезно посмотреть, как изменялась во времени оценка на ту или иную задачу, оценить скорость появления новых, неучтенных задач. Видится, что должна быть возможность зафиксировать несколько различных состояний плана, чтобы потом можно было к ним возвращаться и сравнивать друга другом. План — это инструмент руководителя проекта. Мы живем в изменяющемся мире, поэтому важно иметь возможность регулярно вносить изменения в план, который является моделью реальности. В каждый момент времени план проекта состоит из двух частей:
    1. Что было — фактические данные о сроках задач, трудозатратах и т.п.
    2. Что стало — как мы себе видим дальнейшее развитие событий от текущего момента.

    С течением времени план должен изменяться, чтобы в соответствовать этим требованиям. При этом должна быть возможность посмотреть, каким план был раньше.

    Не учитывается тот факт, что все люди разные


    Практически во всех системах исполнители воспринимаются как что-то легко взаимозаменяемое. В то время как на самом деле люди сильно отличаются и с точки зрения производительности, и с точки зрения специализации, а также еще по множеству факторов. Моделирование подобных различий активно используется в компьютерных играх, а в системах управления проектами различия между людьми попросту игнорируются.

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

    Мало внимания уделяется диагностике проблемных мест


    Системы управления проектами вываливают на РП кучу информации и предлагают ему самому с ней возиться, извлекая нужные сведения из бездны чисел и графиков. Максимум, на что можно рассчитывать — это некоторые суммарные показатели, типа общей успеваемости проекта или диаграммы сгорания. А ведь известно, что дьявол кроется в деталях. Что толку видеть, что проект *сейчас* выполняется в срок, в то время как *динамика* скорости выполнения — отрицательная. Ведь это означает, что уже в ближайшее время проект начнет отставать от графика, и действия по предотвращению этой проблемы можно (и нужно) осуществлять уже сейчас, а не тогда, когда уже все случится.

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

    Системы уходят в облака


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

    Я понимаю, что исчезновение локальной копии данных обусловлено серьезными причинами. Если несколько человек одновременно внесут изменения в одну и ту же часть плана, то объединить их в облаке может оказаться проблематичным. Однако, тот факт, что проблема сложная, не означает, что она не решаемая.

    Мне кажется, для любой облачной системы управления проектами должна быть возможность работать с проектными данными локально, с последующей синхронизацией, как это делает, к примеру, Evernote.

    Заключение


    У кого-то может сложиться впечатление, что я хочу систему, которая будет сама все делать за руководителя проекта, и тогда его должность будет попросту упразднена. Это совершенно не так. Я хочу такую систему, которая автоматизирует рутинные операции, сопровождающие деятельность руководителя проекта, разгружает его мозг от лишних деталей и позволяет сосредоточиться на вещах существенно более важных. Бесконечные списки задач и таблицы успеваемостей мешают руководителю выделить главное, заставляют его тратить свое время крайне непродуктивно. Система автоматизации управления проектами должна не только упростить выполнение элементарных операций с сущностями, но должна также уменьшить количество сущностей, с которыми одновременно оперирует руководитель. Это должно делаться за счет объединения элементарных сущностей в более высокоуровневые, абстрактные.

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

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

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 23

      0
      Вот ещё одна проблема в дополнение описанным в статье.

      Часто бывает так, что в плане проекта на некоторые работы невозможно назначить в данный момент определённого сотрудника, но из типа работы понятно, кому её предстоит делать. Например, написание документации предстоит делать одному из сотрудников Отдел технической документации. Но начало этой работы только через 3 месяца и сейчас трудно указать, кто конкретно её будет писать. При этом есть и другие проекты, в которых заняты писатели. Хочется иметь в плане агрегирующий ресурс, который привязан к списку конкретных сотрудников и позволяет проверить есть ли у какого-нибудь сотрудника (не важно, какого именно) из данного списка свободное время в интересующий период времени и произвести выравнивание плана в соответствии с предполагаемой загрузкой.
      Мне не попадались системы управления проектами, в которых я мог бы решить эту задачу. По крайней мере, сделать это просто.
        –2
        Я буду груб но это (цитата):

        Я мечтаю об инструменте, позволяющем управлять набором прецедентов, компонентов, требований, задач и исполнителей в едином информационном пространстве, с наложением на шкалу времени, с учетом занятости сотрудников и зависимостей между задачами

        несостоятельное утверждение. Так как нет на самом деле управления. Есть только контроль. Всё что делает менеджер в большинстве случаев это контроллирует деятельность, более ни-че-го. Продумывают внутренности — техспециалисты, реализуют — техспециалисты, тестируют — техспециалисты. Менджер только контроллирует.
          +2
          Мне очень грустно развеивать Ваши заблуждения, но управление на самом деле бывает. Действительно, специалисты решают конкретные технические задачи, а менеджеры контролируют их деятельность. Но кроме них еще существуют руководители, которые весь этот бардак пытаются вести в некотором направлении. И при отсутствии управления все почему-то очень быстро превращается в иллюстрацию к басне «Лебедь, рак и щука». Случается, конечно, такое чудо, как самоуправляемые команды, но это очень большая редкость.
            –1
            Если комманда «встанет в позу», то менеджер тутже понимает, что он ничего не управляет (увы и такое тоже бывает). И Вы сами правильно сказали «менеджеры КОНТРОЛЛИРУЮТ их деятельность».
              0
              Если команда под управлением менеджера становится в позу, то это означает только одно — надо гнать в шею либо команду, либо менеджера. А контроль — это не цель. Это лишь один из инструментов управления.
                0
                Ага. А если автомобиль «встанет в позу» (да хоть кончится бензин), то водитель тут же понимает, что он «ничего не управляет» :)
            +3
            Соглашусь — у меня те же запросы, уже много лет постоянно изучаю рынок на предмет предлагаемых решений — пока тишина и спокойствие.

            В дополнение к вышесказанному могу предложить возможность автоматизировать проведение налога «покера» в scrum: после установки задачи в системе плонирования было бы неплохо, если бы разработчики смогли выставить свои субъективные оценки сроков, не видя оценок других. Это позволило бы руководителю для больших команд лучше выбирать исполнителей и полуавтоматически выделять зоны риска — если для какой-то задачи сильно разнятся оценки сроков или большая часть разработчиков не готовы ее вообще выполнять — значит там явно сконцентрированы риски.
              +1
              Интересная мысль… Я вообще больше думал в сторону автоматизации способа мышления, а это движение в сторону применения для планирования социальных инструментов — очень в духе времени :-)
              +1
              спасибо за статью. не могли бы вы перечислить системы управления проектами, которые вы использовали в своей работе?
                +1
                близко имел дело с:
                MS Project (+MS Project Server)
                Jira
                TFS
                Basecamp
                Trac
                Asana

                Издалека смотрел на Redmine, Мегаплан, LiquidPlanner.

                Много читал про разные другие системы (конкретных названий уже не скажу, все смешалось, уж больно они все похожи).
                Не упоминаю разнообразные персональные органайзеры, которые претендуют на управление проектами.
                  0
                  А чем, если не секрет, не подошла JIRA?
                    +1
                    JIRA — это issue tracker в своей сущности. Для управления проектов еще меньше подходит чем MS Project.
                    Я из всего этого не использовал TFS, Trac и Asana. Но и остальные быстро демонстрировали свои узкие места, из-за которых использовать их не удавалось кроме как для узких задач. Применимость в широком круге задач более или менее возможна у MS Project, но не слишком удобна. В какой-то момент приходится подстраивать все процессы под ограничения системы и выдумывать лишние сущности, чтобы скомпенсировать систему управления проектами. Она начинает не помогать, а мешать.
                0
                в свое время, я тоже рассматривал некоторые системы, т.к. это всегда головная боль digitalmanagers.ru/blog/software/9.html
                  0
                  Между системами управления задачами и системами управления проектами в самом деле есть серьезная разница: наименьшая единица управления у первых — действия (задачи), а у вторых — результаты действий (артефакты).
                  Из-за этого в системах управления проектами может использоваться 100% rule, а в системах управления задачами новые задачи прибывают неожиданно и в самый неподходящий момент.

                  Из этого следует такой вывод: из системы управления задачами невозможно сделать годную систему планирования в принципе — там просто нет нужной информации. Я видел разные попытки реализовать планирование на базе анализа истории (сколько в среднем такие задачи занимали раньше, насколько разработчики ошибались в оценках и т.п.), но ИМХО все это пустое. Проблема не в том, что мы неверно оцениваем длительность известных задач, а в том, что мы не можем предсказать количество и темп появления неизвестных задач.

                  Несколько подробнее об этом писал тут
                  www.trackstudio.ru/ms-project-issue-tracking.html
                  maximkr.livejournal.com/11192.html

                    0
                    На самом деле, важно смотреть не только на то как мы оценивали задачи, а смотреть в динамике на изменение планируемого срока окончания работ. Пока у нас нет таких данных мы ни о чем не можем говорить, но у меня есть устойчивое ощущение, что скорость движения планируемого «хвоста» проекта (т.е. даты окончания) — величина достаточно стабильная. В частности, подобные наблюдения были сделаны в процессе анализа множества проектов, управляемых по методике освоенного объема. Было замечено, что коэффициент эффективности вложений (по сути отношение фактического результата к планируемым затратам) сильно не меняется после отметки 20% завершения. Это позволяет использовать эту величину для корректирования планируемого срока. Но беда это методики в том, что она требует очень точного расчета всех затрат, что почти невозможно когда проекты не очень большие и их много. Мне кажется, что оценка скорости движения хвоста проекта приведет к тем же результатам при существенно меньших затратах на получение этой оценки.
                    0
                    MS Project не стоит воспринимать как систему управления проектом, фактически это средство для построения графика проекта и ничего более. Не стоит ждать помощи в определении «какие задачи планируются к выполнению». Впрочем Вы здесь же приводите и решение «после того как мы посмотрели на проект со всех точек зрения и убедились, что ничего не забыли — мы получаем довольно пристойный план».

                    Многие из приведённых Вами проблем решены в российском Spider Project: удобное сравнение различных вариантов графика, с комментированием, назначение ролей ресурсов (когда непонятно кто из отдела будет выполнять задачу), отличное отслеживание состояния.

                    Из моего опыта scheduling: самое важное — знать на что способен (и не способен) выбранный инструмент, и применять его в соответствии. Лучше необходимый минимум, чем хаотический максимум.

                    Вы правы, уповать на программы в управлении людьми не приходится. Должно ведь быть наоборот ;)
                    0
                    Давно уже мечтаю создать свою систему управления проектами. По тем-же причинам. Много всего перепробовал — все не то.
                      +1
                      Вы знаете, а я не хочу создавать систему управления проектами. Есть куча систем, которые с этой задачей справляются. Мне хочется создать инструмент планирования, который позволит создать приемлемый план, а потом скормить задачи из полученного плана в какой-нибудь issue-tracker типа Jira и отслеживать их выполнение. Мне кажется, что это в несколько раз проще, чем делать очередную систему управления проектами, и при этом даст заметный эффект.
                        0
                        На мой взгляд, эта «куча» справляется не очень хорошо. Т. е. вообще никак. Task-manager или issue-tracker — это далеко не все управление, поддающееся автоматизации, да Вы и сами об этом пишите. А планировать можно маркером на доске, в гугл-доксах, в календаре или на салфетках в баре которые можно инстаграммить с определенными хэш-тегами. Инструментов тоже достаточно, при наличии фантазии. Но нет простого и понятного инструмента для объединения всех управленческих задач в одну систему, хотя в этом также нет ничего особенно сложного. Я придумал как сделать такую штуку и мне моя идея кажется достаточно остроумной.
                          0
                          Ну, поделитесь ;-) посмеемся вместе (в хорошем смысле).
                          0
                          а что мешает скрестить Jira и MSProject посредством плагина?
                          Насколько помню к Jira был платный плагин для MSP, позволявший практически привязать задачи проекта в задачи Jira с миграцией в обе стороны.
                            0
                            Скрестить ничего не мешает, как видите, это даже кто-то уже сделал.
                            Только толку от этого, к сожалению, немного :-(.
                            Если Jira вообще не является системой планирования, то MS Project, конечно, пытается это делать, но до того туманным способом… Вспоминается цитата из Р.Хайнлайна — «Демократия плохая система. Её единственное достоинство — она в 8 раз лучше любой другой.» Т.е. большинство достоинств Project кроются в недостатках других систем, он лучше их. Но не становится от этого хорошей системой.

                      Only users with full accounts can post comments. Log in, please.