Менеджмент в разработке программных изделий

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

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

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

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

Рис. 1.1. Схемы организации менеджмента проекта

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

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

В коллективах, выполняющих программные проекты, возможны самые разнообразные организационные структуры. Так, для сложных, объемных по трудозатратам проектов иерархические цепочки "менеджер — менеджер по направлению — исполнитель работ" целесообразно увеличивать, дифференцируя работы и сферы ответственности для некоторых менеджеров по направлению.

Иногда оправданно делегирование всех менеджерских обязанностей и полномочий менеджерам по направлениям. В результате ответственность за проект несет не один человек, она распределяется по менеджерской группе, т.е. возникает коллективная, деперсонифицированная ответственность. Возможны схемы, когда вместо менеджеров по направлениям деперсонифицированная ответственность назначается группе в целом, т.е. менеджер проекта выдает задания, контролирует их выполнение, осуществляет другие функции, обращаясь ко всей группе, внутри которой уже распределяются обязанности, в том числе и обязанности менеджера по направлению. Характерный пример — модель проектной группы, предлагаемая в концепции Microsoft Solution Framework (MSF) [44].

Для небольших групп возможна следующая организация работ: обязанности главного менеджера распределяются по команде разработчиков, которая за счет внутренних механизмов решает, как планировать работы, как их распределять и контролировать. Это характерно для так называемого подхода быстрой разработки (agile development) программных систем, объединившего в себе несколько методологий программирования, которые отказываются от многих принципов традиционного менеджмента [24]. Наиболее ярким примером подхода быстрой разработки является экстремальное программирование [3]. Ему и другим методам данного направления мы уделим внимание в дальнейшем, а пока лишь отметим, что здесь, как и в других случаях, менеджерские задачи не исчезают, как могло бы показаться на первый взгляд. Просто форма и методы их решения приобретают другой характер.

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

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

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

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