управление проектами

в том числе управление системными проектами

IMG_1588В условиях неопределенности

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

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

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

Баланс проектаIMG_1784

Менеджер проекта должен следить за балансом планов и балансом объектов. Для этого он должен занять промежуточную позицию между внутренними планами проекта и внешними планами, а также между объектом и внешней средой.

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

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

Аналогично с объектом. Некоторые процессы находятся в компетенции внешних менеджеров, но влияют на работу объекта. Например, поставка сырья на предприятие. Для того, чтобы детально обсуждать процессы приемки сырья, необходимо детально представлять и некоторые внешние процессы. Здесь менеджер также выбирает менее проработанную часть  направляет туда свои усилия.

Мы приходим к следующим выводам, справедливым для практики системных проектов:

  • У большинства разработчиков и пользователей нет мотивации для изучения системы как таковой. Им гораздо важнее получить локальную задачу, определить ее зависимость от других локальных задач (приоритеты, последовательность, технология) и выполнить ее в соответствии с требованиями лидера проекта.
  • Управление группой разработчиков будет существенно упрощено, если будет создана иерархия исполнителей, определенный цикл корректировки заданий, фиксация промежуточных результатов и так далее. Иерархия исполнителей может быть представлена в виде матрицы, образованной иерархией планов и иерархией объектов. см. также Системная матрица.
  • С этой точки зрения проектную группу в целом интересует не столько сама система, сколько шаг в ее развитии, который определяется сложным сочетанием внешних и внутренних факторов, прошлыми решениями, текущими решениями, и который влияет на поведение системы в будущем.
  • Для успешного движения вперед необходимо постоянно контролировать и устранять дисбаланс планов и дисбаланс объектов.

22Взаимодействие с заказчиком

Крупные и сложные проекты выполняются месяцами. За это время ситуация на объекте меняется. Да и сам проект был задуман как некоторый шаг в развитии системы, и она реагирует на появление новых правил, процессов, реорганизации административного управления. Это можно проиллюстрировать сложившейся практикой доработки проекта в процессе его внедрения.

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

В чем тут дело? А дело в том, что ход проекта оказывает воздействие на заказчика, который параллельно с усилиями программиста тоже развивает свои представления об алгоритмах, процедурах, правилах и нормативах. Повторять «один в один» существующую систему нецелесообразно, а подчас невозможно. Но улучшая ее, разработчик принимает определенные решения, которые как правило не согласованы с заказчиком. Однако если каждое решение согласовывать, выполнение проекта затянется до греческих календ.

Системный подход позволяет разработчику понять, что заказчик начал работать с проектом до появления технического задания, принял само решение о начале проекта, уже имея некоторые данные и некоторые представления о том, как это все должно быть. И все время разработки заказчик не сидит на месте, а продолжает работать, вникать в задачу и так далее. Если разработчик уходит в автономный трудовой процесс, ему трудно потом объяснить результаты заказчику. Настолько трудно, что проще переработать проект заново. Затем еще раз, и так до тех пор, пока оба не устанут.

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

Эволюция отношений между разработчиком и заказчиком подробно (даже слишком подробно) изложена в книге Л. Льноградского «Горизонты системного анализа». Там же показано (а за прошедшие 15 лет неоднократно подтверждено на практике), что использование системных технологий предполагает учет не только внутренней части проекта, но и обстановки, в которой он возникает, и причин, которые им управляют.

Тема будет продолжена.

социальный кластер
Методология, Общество, Экология
социальный кластер
тестирование
Логистика, Методология, Производство
тестирование
dashboard
Логистика, Методология, Производство
dashboard
параметры склада
Логистика, Методология
параметры склада
темы для студентов
Логистика, Университеты
темы для студентов
матрица
Методология
матрица
логистика
Логистика, Производство, Университеты
логистика
нейронные сети
Логистика, Методология, Производство
нейронные сети
агентные модели
Логистика, Производство, Университеты
агентные модели
управление проектами
Логистика, Производство, Университеты
управление проектами
мастер классы
Логистика, Университеты, Экология
мастер классы
сайт ЕСО 63
Общество, Экология
сайт ЕСО 63
системные ловушки
Методология
системные ловушки
сущность системы
Методология
сущность системы
BoardMaps
Общество, Производство, Университеты, Экология
BoardMaps
эволюция системы
Методология
эволюция системы
управление персоналом
Общество, Производство, Университеты
управление персоналом
рейтинг кафедры
Университеты
рейтинг кафедры
социальные системы
Общество
социальные системы
механический завод
Производство
механический завод
опыт работы
Логистика, Общество, Производство, Университеты, Экология
опыт работы
университеты
Университеты
университеты
ЮНИВОЛГА
Общество, Университеты
ЮНИВОЛГА
КАДАСТР ОТХОДОВ
Муниципалитетам
Производство, Экология
КАДАСТР ОТХОДОВ