Когда я писал статью об управлении проектами с помощью MS Project, меня не покидало устойчивое ощущение, что я пишу что-то неправильное. «Ну не может такого быть,» — думал я, «чтобы такие простые вещи так сложно делались в программе, являющейся одним из самых распространенных инструментов для управления проектами.» Я проверял себя, раз за разом оценивал актуальность своих потребностей, изучал другие программные решения. И все равно приходил к неутешительному выводу: *у меня, как руководителя проекта, существуют потребности, которые то ли забыты, то ли сознательно игнорируются разработчиками*. Несмотря на впечатляющий список возможностей современных систем управления проектами, есть задачи, которые я просто не могу решить без помощи вспомогательных средств в силу естественных ограничений человеческого мышления.
В этой статье я хочу описать некоторые важные, на мой взгляд, пробелы в функциональности и предложить возможные способы реализации.
Нет внятных средств, помогающих составить план проекта
Любая система позволяет запланировать исполнение задач, указать исполнителей, сроки и т.п. Как правило, это означает, что есть возможность ввести задачу в систему. Только почему-то предполагается, что пользователи таких систем ясновидящие и заранее знают, какие задачи планируются к выполнению.
Нет ни одного внятного предложения, как от смутных идей перейти к списку или даже дереву задач из 100500 наименований. Некоторые элементы такого подхода наблюдаются в системах класса Application Life Cycle Management, однако, во всех таких системах серьезно провисает такой аспект, как календарное планирование.
Я мечтаю об инструменте, позволяющем управлять набором прецедентов, компонентов, требований, задач и исполнителей в едином информационном пространстве, с наложением на шкалу времени, с учетом занятости сотрудников и зависимостей между задачами. Простого списка и даже иерархии задач недостаточно для получения полной картины. Ведь на структуризацию задач можно смотреть с разных точек зрения. Важность и очевидность задач меняется, в зависимости от того, под каким углом мы на них смотрим. Например, когда мы смотрим с точки зрения сценариев использования — мы, скорее всего, не забудем про тестирование сценария, а когда с точки зрения компонентов — естественным образом всплывает задача проектирования протоколов взаимодействия компонентов. И вот после того как мы посмотрели на проект со всех точек зрения и убедились, что ничего не забыли — мы получаем довольно пристойный план.
Неудобно работать с изменяющимся планом
Когда план регулярно изменяется, то вносимые изменения, как правило, затирают прошлые значения. MS Project позволяет сохранить версию плана (т.н. базовый план), чтобы потом сравнивать его с текущим. Это немножко помогает, когда структура задач сильно не изменяется. На практике часто случаются декомпозиции одной задачи на несколько других, добавление и удаление связей между задачами, переоценка сроков. Довольно часто возникает потребность немного «поиграть», т.е. внести изменения в план, чтобы посмотреть как это отразится на конечных сроках или стоимости проекта: добавить исполнителей в проект, перераспределить задачи между исполнителями, добавить или удалить задачи. Когда таких изменений много, то простого сравнения с базовым планом недостаточно для понимания сути происходящих изменений.
Мне очень не хватает журнала изменений плана, в котором видно — что, когда, и как было изменено. Также хочется иметь возможность вносить в него комментарии, объясняющие, зачем было сделано то или иное изменение. Иногда полезно посмотреть, как изменялась во времени оценка на ту или иную задачу, оценить скорость появления новых, неучтенных задач. Видится, что должна быть возможность зафиксировать несколько различных состояний плана, чтобы потом можно было к ним возвращаться и сравнивать друга другом. План — это инструмент руководителя проекта. Мы живем в изменяющемся мире, поэтому важно иметь возможность регулярно вносить изменения в план, который является моделью реальности. В каждый момент времени план проекта состоит из двух частей:
- Что было — фактические данные о сроках задач, трудозатратах и т.п.
- Что стало — как мы себе видим дальнейшее развитие событий от текущего момента.
С течением времени план должен изменяться, чтобы в соответствовать этим требованиям. При этом должна быть возможность посмотреть, каким план был раньше.
Не учитывается тот факт, что все люди разные
Практически во всех системах исполнители воспринимаются как что-то легко взаимозаменяемое. В то время как на самом деле люди сильно отличаются и с точки зрения производительности, и с точки зрения специализации, а также еще по множеству факторов. Моделирование подобных различий активно используется в компьютерных играх, а в системах управления проектами различия между людьми попросту игнорируются.
Использование даже элементарной информации о специальностях и производительности сотрудников могло бы очень сильно помочь в составлении плана.
Мало внимания уделяется диагностике проблемных мест
Системы управления проектами вываливают на РП кучу информации и предлагают ему самому с ней возиться, извлекая нужные сведения из бездны чисел и графиков. Максимум, на что можно рассчитывать — это некоторые суммарные показатели, типа общей успеваемости проекта или диаграммы сгорания. А ведь известно, что дьявол кроется в деталях. Что толку видеть, что проект *сейчас* выполняется в срок, в то время как *динамика* скорости выполнения — отрицательная. Ведь это означает, что уже в ближайшее время проект начнет отставать от графика, и действия по предотвращению этой проблемы можно (и нужно) осуществлять уже сейчас, а не тогда, когда уже все случится.
Я убежден, что хорошая система управления проектом должна анализировать ряд важных показателей, характеризующих как свойства проекта к в целом, так и отдельных его частей (например, это может быть успеваемость отдельных сотрудников, или скорость реализации отдельных компонентов). Причем анализ должен быть не только статический, но и учитывающий динамику изменения (см. выше про изменяющиеся планы).
Это даст возможность руководителю реагировать на проблемы в проекте не только постфактум, но и до того, как они возникнут, тем самым значительно уменьшая степень их влияния.
Системы уходят в облака
Все системы управления проектами в соответствии с модным современным трендом уходят в облака. Облака — это хорошо, это правильно. Но только как дополнение к обычным решениям. Очень важно иметь возможность взять план проекта и поиграться с ним на досуге, даже не имея доступа к сети. Очень удобно, когда после внесения изменений можно опубликовать план в облаке, и он станет доступным всем. Но ужасно неудобно, когда данные *доступны только в облаке*, это означает что если у меня нет доступа к интернет, то у меня нет доступа к моим данным.
Я понимаю, что исчезновение локальной копии данных обусловлено серьезными причинами. Если несколько человек одновременно внесут изменения в одну и ту же часть плана, то объединить их в облаке может оказаться проблематичным. Однако, тот факт, что проблема сложная, не означает, что она не решаемая.
Мне кажется, для любой облачной системы управления проектами должна быть возможность работать с проектными данными локально, с последующей синхронизацией, как это делает, к примеру, Evernote.
Заключение
У кого-то может сложиться впечатление, что я хочу систему, которая будет сама все делать за руководителя проекта, и тогда его должность будет попросту упразднена. Это совершенно не так. Я хочу такую систему, которая автоматизирует рутинные операции, сопровождающие деятельность руководителя проекта, разгружает его от лишних деталей и позволяет сосредоточиться на вещах существенно более важных. Бесконечные списки задач и таблицы успеваемостей мешают руководителю выделить главное, заставляют его тратить свое время крайне непродуктивно. Система автоматизации управления проектами должна не только упростить выполнение элементарных операций с сущностями, но должна также уменьшить количество сущностей, с которыми одновременно оперирует руководитель. Это должно делаться за счет объединения элементарных сущностей в более высокоуровневые, абстрактные.
Мне кажется, что такой качественный скачок возможен только при наличии теоретической модели представления проекта, которая будет включать в себя разные уровни абстракции и все необходимые показатели. Эта модель не должна явно требовать применения той или иной методологии управления. Система будет автоматизировать действия с проектом в рамках этой модели. Без сомнения, от руководителя проекта потребуется четкое понимание модели, ведь иначе он не сможет эффективно использовать систему, напротив, она будет ему казаться бесконечно сложной и непонятной.
А чего Вам не хватает в системах управления проектами?
Какие возможности Вы хотели бы к ним добавить?
Автор: ganouver
