Организационные аспекты управления в проекте

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

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

Специалисты, которые наиболее подходят к выполнению каждой из перечисленных ролей, различаются между собой:

– способностью выполнять работу;

– интересом к работе;

– опытом работы с подобным проектом, инструментами, языками, технологиями и ОС;

– способностью к обучению;

– коммуникабельностью с другими сотрудниками;

– способностью разделить ответственность с другими;

– профессионализмом и знанием методов управления.

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

Стиль работы.Разным людям свойственны разные стили выполнения работы и коммуникации с другими сотрудниками [3]. Отличаются сотрудники тем, что одни сначала взвешивают все детали и собирают всю информацию, а потом принимают решения по всем вопросам. Другие разбивают работу на фрагменты и принимают решение постепенно для каждого фрагмента. Некоторые сотрудники предпочитают формировать рабочее решение путем высказывания своего мнения другим сотрудниками и принимать окончательное решение сообща (стиль экстраверта), другие предпочитают и интересоваться мнением других по тому или другому вопросу, а потом самостоятельно принимать решение (интроверты). Некоторые сотрудники полагаются на свою интуиции и профессиональный опыт при принятии решения (интуитивисты), другие – руководствуются только рациональными и логическими доводами (рационалисты). В реальной рабочей среде более часто встречаются смешанные типы сотрудников.

Рациональный экстраверт считается хорошим руководителем. Он стремится обсудить проблему, но не позволяет влиять на принятие окончательного решения. Стиль его работы – спрашивать у своих подчиненных то, что касается главной линии ведения проекта (их не интересуют подробности, частности, детали документации и т. д.).

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

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

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

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

Организация проекта.Для хорошей организации ведения проекта подбирается подходящая структура проекта на основании следующих данных:

– рабочие стили членов группы;

– число людей в группе;

– стиль работы с заказчиками и разработчиками.

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

Главный

программист

Ассистент

главного

программиста

Программисты Библиотекарь Администратор Группа тестовиков

Подчиненный

программист

Рис.10.5. Структура организации группы главного программиста

Ассистент главного программиста дублирует, замещает главного программиста, когда это необходимо. Библиотекарь – ответственный за всю документацию проекта: компилирование и тестирование всех модулей библиотеки. Введение этой должности позволяет сконцентрироваться программистам на их непосредственной работе, а не на поиске ошибок и создании необходимых материалов.

В группу входит администратор и группа тестировщиков. Старшие программисты и младшие непосредственно подчиняются старшим. Хотя структура такой рабочей группы иерархическая, каждый член группы может общаться непосредственно с главным программистом или с другими сотрудниками. Главный программист должен сам просматривать части основного проекта и программ.

Альтернативная структура ведения проекта описана Вейнбергом (Weinberg) [3], так называемое обезличенное программирование, при котором все несут одинаковую ответственность за качество продукта. В проекте не концентрируются на персоналиях, критике подвергается программный продукт, а не члены группы. Такая структура подходит для маленьких групп программистов.

Ответственность за моделирование работ в проекте.В[3] в рамках военного ведомства разработана общая структура команды для создания интегрированного продукта (Integrated Product Development Team). Модель ответственности команды приведена на рис.10.6.

ТРЕБУЕМЫЕ РЕЗУЛЬТАТЫ

Ответственность за

- планирование

- выполнение плана

- конечный результат

Команда Заказчик

Воздействие на проект:

- инспекция элементов /сборка

- содействие

- руководство

- пополнение

Рис. 10.6 Модель ответственности лиц в интегрированном проекте

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

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

В приведенной модели, группа – это комбинация разных сотрудников, ответственная за результат своей работы. Заказчик влияет на результат или на выбор пути для достижения результата. При разработке обязанности и роли сотрудников постоянно меняются. Это удобно для проекта, в котором требуется проведение оперативных процедур и часто меняются планы. Для планов устанавливаются сроки в пределах недели или даже часов. Для организации работ большого коллектива используются карты обязанностей, схемы, отражающие сроки выполнения работ для каждой части проекта. Показателем того, насколько выполнено задание является диаграмма планируемых и реально выполненных работ. Часто эта модель обязанностей объединяется с моделью «из рук в руки» (hand-off), которая предполагает использование сценариев и образцов взаимодействия между сотрудниками, при которых результат работы одной группы передается как исходное данное для работы другой группе.

Оценивание проекта

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

К дополнительным расходам относятся системы тестирования, кодирования или другие CASE системы. Центральной оценкой в проекте является оценка затрат на ведение проекта, выражаемая, например, в человеко-днях исполнителей работ в проекте. Эти оценки проводятся на ранней стадии ведения проекта и составления плана. Специалисты с опытом могут первоначально оценить стоимость проекта с погрешностью меньше 10%.

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

Когда такой возможности нет, эксперты проводят пессимистическую (x), оптимистическую, и реальную. Разные методы приближенного оценивания по отношению к реалистическим рассмотрены в [3]. Эксперт проводит опрос всех членов рабочей группы, и в дальнейшем проводит коррекцию каждой оценки, выводя на их основе наиболее правдоподобную.

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

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

Например, стоимость проекта определяется по формуле: E = (a+bS^c) m (X), где S - оценка размера системы, а, в, с – эмпирические константы, Х – вектор факторов стоимости размерностью n, m – регулирующий множитель, основанный на затратных факторах. В [3] предлагается модель в виде соотношения, полученного экспериментальным путем: E = 5.25S^0.91.

Эта модель применялась при оценке проекта, в котором программные системы имели размер от 4000 до 467000 строк кода, написанных на 28 различных языках программирования высокого уровня для 66 компьютеров и на которые затрачено от 12 до 11758 человека-месяцев.

В [4] предлагается техника моделирования, использующихся в уравнении затрат организации-разработчика:

E = 5.5+0.73S^1.16.

В большинстве моделей оценка зависит от размера системы в строках кода. Модель COCOMO Боєма [ ] собрала в себе три техники измерений по проекту. В первых моделях применялись показатели цены, учитывался персонал и свойства проекта, продукта и среды. Модель включает оценку трех стадий ведения проекта. На первой стадии строится прототип для задач повышенного риска (интерфейс пользователя, ПО, система взаимодействия, реализации и др.) и проводится оценка затрат (например, число таблиц в БД, экраны и отчетные формы др.).

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

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

Базовой моделью оценки служит следующее уравнение: E=bS^c m(X), где первичная оценка b S^c корректируется с помощью вектора стоимости m (X). Эта модель развивается с учетом анализа объектов (число старых и новых объектов). Параметр с в уравнении изменяется от 0 до 1.0 для первой стадии и от 1.01 до 1.26 для остальных.

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

1.Определение границ системы и точек выполнения разработки.

2. Формирование временного плана выполнения работ в точках проекта.

3. Определение структуру рабочей группы, периода, видов работ и ресурсов.

4. Техническое описание планируемой системы (аппаратное и ПО проекта, компиляторы, интерфейсы, оборудование и др.) и ограничений на время, безопасность и т.п.

5. Использование стандартов, процедур, техник и инструментов ведения проекта.

6. Разработка планов достижения качества, управления конфигурацией, подготовки документации.

7. Разработка плана управления данными и источниками информации.

8. Разработка плана тестирования, измерения и оценивания результатов работ.

9. Составления плана обучения пользователей системы.

10. Определения плана безопасности (конфиденциальность, пароли и др.)

11. Составление плана управления рисками.

12. План сопровождения с указанием ответственных за изменение кода, ремонт оборудования, использование документации и др.

13. Описание алгоритмов, инструментов, техники просмотра или инспекции кода, языков ведения проекта, языков кодирования и тестирования.