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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответственность за моделирование работ в проекте

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

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

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