Управление программным проектом (упп)
АНАЛИЗ И ПЛАНИРОВАНИЕ
КОНТРОЛЬ И ВЫПОЛНЕНИЕ ПЛАНА
|
1.1. Точное определение цели 1.2. Обоснование цели (самомотивация) 1.3. Мотивация команды 1.4. Изменения цели и их контроль
|
|
-Лидерство -Ответственность -Полномочия
|
|
|
-Используйте подходящий стиль руководства |
-Знайте, что происходит |
-Сообщайте людям, что происходит |
|
|
Наглядное представление цели
Цель должна быть четкой, ясной и понятной как коллективу проектной группы, так и заказчику. Цель должна быть достаточно узкой и отграниченной от других замыслов. Цель должна быть обоснованной.
Так как проект по определению содержит в себе риски, команде проекта эти риски придется преодолевать. Что это означает на практике? Возможно, придется выполнять сверхурочную работу. Вполне вероятно, что придется решать новые, сложные задачи, учиться, претерпевать неудачи и искать из них выход. Чтобы команда проекта прошла через все трудности и добилась успеха, она должна быть мотивирована.
Одной из составляющих наглядного представления цели является ее цели для каждого из участников проектной команды. О”Коннел при этом оперирует такими «нетехническими» терминами, как «приз», «мечта», предлагая сформулировать ясные «картинки» будущего. В частности, «на берегу» проекта каждый из его участников должен ответить на следующие вопросы: Что в действительности производит проект? Куда денутся его результаты? Кто будет использовать их и как они будут воздействовать на пользователей? Почему вы хотите сделать это? Что вы будете делать в день, когда проект завершится? Каким будет ваш график? С кем вы встретитесь? О чем вы будете разговаривать с этими людьми? На что будет похожа ваша жизнь в день?
Те, кто интересуется прикладной психологией, наверное, уже догадались, что речь идет о методе визуализации: принимая решение об участии в проекте, его участник должен, в том числе, увидеть ясный образ «приза», ожидающего его при успехе проекта – будь то повышение по службе, путешествие или запись в резюме, позволяющая принять участие в новом проекте.
Формулировка списка задач
Метод решения задач через его декомпозицию на подзадачи известен давно. В теории искусственного интеллекта в этом контексте используется термин «PR-проблема»: общая задача делится на подзадачи, которые, в свою очередь, также делятся на подзадачи в итеративном процессе вплоть до того, когда не будет достигнут уровень терминальной задачи, при котором дальнейшее деление не имеет смысла.
Применительно к софтверным проектам, терминальная задача – как правило, такая задача, которую можно доверить одному исполнителю. Другие требования к терминальной задаче – ее ясные интерфейсы с другими задачами и требования к ресурсам, в первую очередь – к временным.
Результаты декомпозиции задаются в виде графа (И-ИЛИ графа). Вершины типа «ИЛИ» позволяют вводить альтернативы. В практике управления софтверными проектами обычно используются только вершины типа «И». Между задачами возникают зависимости. Простейший вид зависимости – последовательность: например, пока задача «А» (написание технического задания на модуль Х) не выполнена, задача «Б» (написание программного кода модуля X) не может начаться.
В теории управления проектами такое деление работ называется структурой пооперационного выполнения работ (Work breakdown structure, WBS). Хорошей абстракцией для результатов декомпозиции проекта является диаграмма Ганта [7.1], в которая позволяет в наглядной форме показать протяженность задач во времени и зависимости между задачами. Наиболее распространенный инструмент для автоматизации управления проектами – пакет MS Project.