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

В работе менеджера всегда присутствуют и неразрывно связаны друг с другом два аспекта:

• управление проектом как деятельность, продвигающая процесс производства к определенным целям,
• руководство людьми, участниками разработки.

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

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

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

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

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

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

Характерной особенностью разработки программного обеспечения является стремление к переиспользованию ранее созданных программных компонентов. Задачи переиспользования — это:

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

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

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

Вот как эти два класса требований определяет И. Соммервилл [23]:

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

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

• Проектная системная спецификация — обобщенное описание структуры программной системы, которое будет основой для более детализированного проектирования системы и ее последующей реализации.

Эта спецификация дополняет и детализирует спецификацию системных требований.

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