Software Project Manager среднего проекта - кто он?

От маленьких проектов к средним проектам - было два программиста, а стало восемь

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

Общеизвестно, что понятие "проект" подразумевает под собой процесс, имеющий точные временные ограничения, т.е. дату начала и дату окончания. Ключевую роль в любом проекте играет так называемый Руководитель Проекта (Project Manager). Естественно, что Руководитель Программного Проекта (Software Project Manager) имеет специфические особенности, связанные с отраслью создания программного обеспечения. В этой статье я постараюсь рассказать о функциях руководителя средних проектов, а также о стадиях, через которые должен пройти проект под его руководством. В статье я делаю ставку на объектно-ориентированные проекты и упускаю из виду такие вещи как тестирование и управление рисками.

На мой взгляд, руководитель проекта должен обладать знанием технологий, на которых будет реализован проект. Представим, что во главе проекта стоит руководитель, который имеет только общее представление о работе своих подчиненных - программистов. В лучшем случае вы получите надзирателя, который всегда полагается на честность программистов, а в худшем - нахлебника, которому будут <пудрить мозги> <ушлые> программисты и проект будет, мягко говоря, отставать от графика, а, скорее всего, вообще не придет к стадии завершения. По какой причине я выставил такие требования к руководителю проекта, будет видно из последующего материала. Дело в том, что один квалифицированный программист с большим опытом работает в десять раз эффективнее начинающего, так утверждает Брукс или Йордан, но, как правило, фирмы не торопятся нанимать высокооплачиваемых программистов. В сложившейся ситуации намного эффективнее из такого специалиста сделать руководителя проекта и дать ему в подчинение не таких дорогостоящих программистов. Но ни в коем случае не нужно делать наоборот, так как забивать гвозди микроскопом это очень дорогое и не эффективное занятие. Другими словами, руководитель проекта должен иметь очень высокую квалификацию, а не мешать своими неразумными указаниями слишком умному исполнителю.

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

Анализ предметной области - концептуальная модель

Прежде чем приступить к реализации какого либо проекта, руководитель проекта должен хорошо представлять предметную область поставленной перед ним задачи. Настоятельно рекомендую начать с построения диаграмм вариантов использования системы (use case diagram). Пример такой диаграммы изображен на рис.1. Данная диаграмма была позаимствована мной из некоммерческого проекта "Агент Интеллектуальных Услуг", проект в котором я принимал участие.

На рис.1 изображены укрупненные прецеденты, которые можно будет в дальнейшем детализировать. Человечками обозначаются актеры, которые взаимодействуют с разрабатываемой системой и выполняют определенные роли. Овалы показывают виды этих взаимодействий или прецедентов использования системы. Актерами могут быть как пользователи, так и части самой системы, которые функционируют самостоятельно. Более подробную нотацию данного вида диаграммы можно найти в любой литературе по UML.

После того как руководитель проекта осознал, кто и как будет пользоваться будущей системой, необходимо переходить к разработке концептуальной (понятийной) модели системы или, другими словами, составить словарь понятий предметной области, с которыми работает разрабатываемая система и установить связи между понятиями. Для этой цели я предлагаю построить диаграмму классов (class diagram). Пример такой диаграммы изображен на рис.2.

Данную диаграмму я позаимствовал из того же проекта. Понятия из предметной области необходимо объединить в классы и показать между ними связи. Связи должны иметь названия и кратности. Например, потребитель может послать ноль или много сообщений, но каждое сообщение должно иметь одного потребителя, это видно из связи между классами Consumer и Message. Более подробную нотацию данного вида диаграммы также можно найти в литературе по UML.

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

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