Pert_example_network_diagram_visio.gif (984×711) - Google Chrome 2013-07-06 11.58.32 (2013-07-06 11.58.32)

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

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

И тут есть цепочка особенностей:

  1. Всю картину проекта и все задачи можно попробовать удержать в голове. Опять же в малых проектах это реально, а вот в крупных — голова может не выдержать. Нужен график для визуализации. Одним из лучших решений является PERT-диаграмма. Она лучше всего покажет граф проекта с вершинами и зависимостями. Лучше чем диаграмма Ганта, на мой взгляд.
  2. Проблема многих современных систем управления задачами является в том, что они путают понятие родителя и зависимости. Они думаю что если это подзадача, значит надзадача от нее зависима. Пример — Мегаплан. Это заблуждение архитектора. Родительское отношение не всегда приводит к зависимости. Очень часто потомок может быть закрыт совершенно отдельно от родителя. К тому же родителем может быть только одна задача, а зависимость может быть множественная. Может быть много задач, от которых зависит данная нам задача.
  3. Еще проблема, которая кроется в наукоемких проектах и во внутренних, административных проектах компаний, это то что задачи одного проекта могут быть раскиданы по всем отделам компании. Причем у каждого отдела может быть своя система реализации задач. Бухгалтера сидят в 1С, программисты в Trello, юристы в Excel и пошло поехало, связать все эти задачи в единую систему — задача не самая простая. Не уверен что эта проблема актуальная для строительных проектов, но всякое может быть.
  4. Также есть проблема с попыткой побороть неопределенность. Мы пытаемся спрогнозировать ход проекта и все зависимости в самом начале. В малых проектах это реально, а вот в наукоемких и сложных проектах где степень неопределенности зашкаливает и есть множество рисков зависимости от разных подразделений и людей, можно сойти с ума. Можно составить огромный план, но где-то через месяц, весь этот план уже имеет нулевую связь с реальным положением дел и его нужно перестраивать, так мы пытаемся угнаться за реальностью, что сделать достаточно сложно. К тому же в проекте по мере выяснения ситуаций возникают дополнительные условия и задачи, которые не были предусмотрены в начале, их нужно как-то записать и учесть, но большая часть методологий запрещает это делать, потому где-то к концу проекта мы имеем кривой результат, который был сделан по методологии, но без связи с реальностью.

Все эти проблемы решаются в рамках архитектуры ACM.

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

Еще одним преимуществом является то что в ACM может работать любой отдел, при этом по своей методологии. Юристы могут просто вести свой список дел и договоров, а программисты решать задачи по методологии SCRUM и/или ITIL. Даже бухгалтерия, которая так любит 1С, начинает вести задачи в этой системе, потому что это сокращает очереди к ним в кабинет и позволяет меньше отвлекаться на хаотичных посетителей. Все работают в единой системе, а не в зоопарке разных приложений.

И последнее преимущество, но может быть одно из самых важных: по ходу реализации проекта, мы можем дополнять данные о нем, добавляя возникающие условия и зависимости в проект, пополняя копилку данных и тем самым прогнозируя развитие событий. Это позволяет лучше держать связь с реальностью. Правда тут есть один нюанс, который будет мало приятен любителям детальных планов — эта практика покажет их бесполезность. Планы будут упрощены. От них не нужно отказываться, но их нужно упрощать, только так не придется тратить кучу времени на бесполезные попытки борьбы с неопределенностью. Тут конечно должен быть ограничитель в форме здравого смысла. Где та грань, при которой план это бесполезная трата времени, а где крайность, когда план это уже бесполезная информация, которая не дает возможности отследить ситуацию? Поиск баланса в этих двух крайностей — одна из ключевых задач руководителя проекта.