Основы менеджмента программных проектов
Покупка
Тематика:
Управление проектами
Издательство:
ИНТУИТ
Автор:
Скопин И. Н.
Год издания: 2016
Кол-во страниц: 221
Дополнительно
Вид издания:
Учебное пособие
Уровень образования:
ВО - Бакалавриат
ISBN: 5-9556-0013-2
Артикул: 055594.04.99
Обсуждаются понятия и методы менеджмента в объеме, необходимом для общего образования программиста.
Вводится система понятий менеджмента программных проектов, достаточная для того, чтобы обучаемый смог самостоятельно осваивать существующие методы и технологии проектирования для их применения в практической деятельности. Изложение строится в привязке деятельности менеджера к этапам жизненного цикла проекта. Особое внимание обращается на разграничение аспектов руководства и управления в деятельности менеджера.
Тематика:
ББК:
- 3297: Вычислительная техника
- 6505: Управление экономикой. Экономическая статистика. Учет. Экономический анализ
УДК:
ОКСО:
- ВО - Бакалавриат
- 09.03.04: Программная инженерия
- 38.03.05: Бизнес-информатика
ГРНТИ:
Скопировать запись
Фрагмент текстового слоя документа размещен для индексирующих роботов
Основы менеджмента программных проектов 2-е издание, исправленное Скопин И.Н. Национальный Открытый Университет “ИНТУИТ” 2016 2
УДК 004.4:005 ББК 20 С-44 Основы менеджмента программных проектов / Скопин И.Н. - M.: Национальный Открытый Университет “ИНТУИТ”, 2016 (Основы информационных технологий) ISBN 5-9556-0013-2 Обсуждаются понятия и методы менеджмента в объеме, необходимом для общего образования программиста. Вводится система понятий менеджмента программных проектов, достаточная для того, чтобы обучаемый смог самостоятельно осваивать существующие методы и технологии проектирования для их применения в практической деятельности. Изложение строится в привязке деятельности менеджера к этапам жизненного цикла проекта. Особое внимание обращается на разграничение аспектов руководства и управления в деятельности менеджера. (c) ООО “ИНТУИТ.РУ”, 2004-2016 (c) Скопин И.Н., 2004-2016 3
Менеджмент в разработке программных изделий Вводятся основные понятия проблематики менеджмента разработки программных изделий, определяется метод и направление курса в целом. Разработка программного обеспечения в большинстве случаев должна рассматриваться как коллективный труд специалистов, направленный на удовлетворение потребности пользователей в автоматизации их деятельности. Как и любой другой коллективный труд, она требует организации, в частности — управления. Это процесс, порою длительный, связывающий производственными и иными отношениями тех, кого в той или иной степени можно рассматривать в качестве производителей программы. Как и любой труд, тесно связанный с неоднозначными потребностями тех, кто будет использовать продукты труда, необходимым элементом разработки программ является решение задач изучения пользователей, с одной стороны, а с другой — обеспечения обратной связи с ними, направляющей производство. Это составляющие, из которых формируются главные задачи управления производством программ. Чаще всего решение таких задач осуществляется руководителем, или, как принято говорить, менеджером проекта . Понятие ” менеджер проекта ” не обязательно соотносится с конкретной персоной, отвечающей за управление производством программной системы в целом. В небольшом проекте такое единоначалие чаще всего оправданно: оно позволяет концентрировать все нити управления, исключает проблемы внутреннего для проекта согласования противоречий, обеспечивает централизованную ответственность за проект перед теми, кто заинтересован в его выполнении. Однако по мере перехода к более масштабным проектам менеджерские обязанности становится невозможно концентрировать в одних руках. Обычно в таких случаях поступают в соответствии с одной из двух схем организации производства. Первая схема — это образование службы менеджера, состоящей из его помощников, которым он может поручать различные задания, освобождая себя от рутины постоянного контроля. Этот путь, по существу, является лишь паллиативом. Для еще более сложных проектов появляется необходимость следовать второй схеме, т.е. образовывать группу менеджеров, ответственных за разные разграниченные сферы проекта. В этой схеме централизация достигается путем назначения главного менеджера проекта, который делегирует полномочия менеджерам по направлениям. 4
Рис. 1.1. Схемы организации менеджмента проекта Рис. 1.1 иллюстрирует три схемы организации менеджмента проекта. Здесь стрелки обозначают связи участников реализации проекта, обусловленные их взаимодействием с менеджером, жирность контура значков отражает менеджерские обязанности сотрудников. Как видно из рисунка, в схеме со службой менеджера помощники по своему статусу являются обычными работниками, тогда как при делегировании полномочий менеджеры по направлениям получают соответствующие полномочия в своих сферах ответственности (обозначены пунктирными овалами). Делегирование можно считать основным инструментом разделения труда в проекте (не только в случае менеджмента ), когда есть ответственность за некоторую функцию (работу и др.), но для ее выполнения нет собственных ресурсов, а потому приходится прибегать к помощи. Собственно говоря, различие схем работы менеджера связано с использованием механизмов поручений или делегирования . В коллективах, выполняющих программные проекты, возможны самые разнообразные организационные структуры. Так, для сложных, объемных по трудозатратам проектов иерархические цепочки “менеджер — менеджер по направлению — исполнитель работ” целесообразно увеличивать, дифференцируя работы и сферы ответственности 5
для некоторых менеджеров по направлению. Иногда оправданно делегирование всех менеджерских обязанностей и полномочий менеджерам по направлениям. В результате ответственность за проект несет не один человек, она распределяется по менеджерской группе, т.е. возникает коллективная, деперсонифицированная ответственность. Возможны схемы, когда вместо менеджеров по направлениям деперсонифицированная ответственность назначается группе в целом, т.е. менеджер проекта выдает задания, контролирует их выполнение, осуществляет другие функции, обращаясь ко всей группе, внутри которой уже распределяются обязанности, в том числе и обязанности менеджера по направлению. Характерный пример — модель проектной группы, предлагаемая в концепции Microsoft Solution Framework (MSF) [44]. Для небольших групп возможна следующая организация работ: обязанности главного менеджера распределяются по команде разработчиков, которая за счет внутренних механизмов решает, как планировать работы, как их распределять и контролировать. Это характерно для так называемого подхода быстрой разработки (agile development) программных систем, объединившего в себе несколько методологий программирования, которые отказываются от многих принципов традиционного менеджмента [24]. Наиболее ярким примером подхода быстрой разработки является экстремальное программирование [3]. Ему и другим методам данного направления мы уделим внимание в дальнейшем, а пока лишь отметим, что здесь, как и в других случаях, менеджерские задачи не исчезают, как могло бы показаться на первый взгляд. Просто форма и методы их решения приобретают другой характер. По ряду причин может оказаться целесообразным сочетание схем организации менеджмента проекта. В результате появляются, например, коллективы, в которых главный менеджер берет на себя функции менеджера определенного направления, тем самым он отвечает и за весь проект в целом, и за некоторую его часть. Все варианты организации менеджмента перечислить невозможно. Иногда они возникают стихийно, иногда планируются под определенную методологию производства программ. Бывает и так, что организация менеджмента и методология выбираются исходя из исторически сложившейся структуры коллектива. И ничего предосудительного в этом нет. С точки зрения изучения задач менеджмента полезно представить их в функциональном стиле, т.е. абстрагируясь, когда это возможно, как от масштабов проектов, так и от организационной структуры коллектива исполнителей. Для этого мы связываем такие задачи с деятельностью абстрактной персоны, которая в конкретных случаях прибегает к распределению своих работ по схемам с поручениями или с делегированием полномочий. Конкретизироваться эта персона может по-разному: как единоличный начальник, как начальник с менеджерской группой, как распределенная между исполнителями роль в проекте и т.д. Как следствие, проблема разделения работ оказывается изолированной, допускающей отдельное рассмотрение вариантов решения. Прием определения абстрактного менеджера следует считать методическим. В 6
дальнейшем изложении он называется определением абстрактного действующего лица проекта и применяется к изучению задач, связанных с выполнением проекта, без привязки их деятельности к конкретным персоналиям или групповым ролям. В работе менеджера всегда присутствуют и неразрывно связаны друг с другом два аспекта: управление проектом как деятельность, продвигающая процесс производства к определенным целям, руководство людьми, участниками разработки. Для первого из этих аспектов можно указать методические приемы и иногда даже организационные технологии, обеспечивающие получение приемлемых результатов в заданное и вполне оцениваемое время. Но что касается руководства людьми, то оно всегда было и остается в значительной степени искусством. Тем не менее важно подчеркнуть, что управление проектом ведется через персоналии его участников, через работу с ними и их взаимодействие между собой, а потому игнорировать аспект руководства для любого проекта ни в коем случае нельзя. Ставя задачу изучения менеджмента, приходится обсуждать как управление, так и руководство. Эта двойственность характерна для любого менеджмента, но для менеджмента программных проектов она играет решающую роль, поскольку данная отрасль направлена на получение не материальных, а идеальных “мыслительных” продуктов, так называемых артефактов. С организационной точки зрения в разработке программного обеспечения можно выделить три варианта целей, определяющие деятельность менеджера: Во-первых, это производство программ не для продажи, напрямую не связанное с получением дохода. Во-вторых, это производство рыночного продукта, обеспечивающего прибыль за счет распространения (продажи) получаемых результатов. В-третьих, разработка ведется под заказ, когда все производство программы, от стадии замысла до передачи в эксплуатацию, финансируется внешними по отношению к разработчикам, но весьма заинтересованными агентами, обычно называемыми заказчиками. Варианты существенно различаются и по уровню ответственности разработки, и по требованиям к качеству продукции, и по другим параметрам, которые необходимо отслеживать. Однако, если отвлечься от персоналий и абстрагироваться от различий ресурсов, необходимых для реализации программ в каждом из этих случаев, то в менеджменте производства программ можно найти много общего, того, что в любом случае должен или не должен делать руководитель проекта. По этой причине полезно считать заказными любые разработки программ, быть может, доопределяя “заказчика” как фактический общий регламент производственного процесса, выделяя в руководстве аспекты деятельности, внешним образом организующие проект, с одной стороны, а с другой — направляющие производство в соответствии с конкретными обстоятельствами развития проекта. 7
Главная и постоянная задача менеджмента разработки программного обеспечения — продвижение проекта к обозначенным в начале его развития результатам. Если оставить в стороне приемы и методы, с помощью которых достигается решение этой задачи, то она сводится к распределению и контролю эффективного использования имеющихся ресурсов проекта: времени, финансов, технических средств и производственного потенциала работников. Множественность критериев, необходимость согласования интересов участников проекта и его заказчиков, разнообразие видов деятельности, составляющих развитие проекта, — вот тот организационный и производственный контекст, который вынужден учитывать менеджер. На фоне получения программного продукта как результата появляется ряд дополнительных задач, за решение которых должен отвечать менеджер проекта. Здесь уместно отметить два дополнительных направления развития. Характерной особенностью разработки программного обеспечения является стремление к переиспользованию ранее созданных программных компонентов. Задачи переиспользования — это: во-первых, определение программных продуктов или каких-либо иных изделий и инструментов, имеющихся в распоряжении разработчиков, использование которых могло бы способствовать прогрессу развития проекта, а во-вторых, выявление компонентов данного проекта, которые было бы полезно задействовать в других разработках. Второе дополнительное направление — это задача распространения построенного программного продукта. Если с самого начала не рассматривать ее и относить распространение лишь к этапам, следующим за разработкой, есть опасность сделать не то, что нужно потребителю продукции, и выпустить из рук рычаги, с помощью которых можно влиять на сферу возможного применения создаваемых программных продуктов. Получение программного продукта как результата развития проекта — это процесс, который регламентируется и направляется пользовательскими потребностями, возможностями применяемого оборудования и другими условиями, как внешними по отношению к проекту, так и внутренними. Все эти аспекты принято рассматривать как требования к проекту. Изучению понятия требований и методов работы с ними в свое время будет уделено особое внимание, а пока отметим общепризнанное деление требований на два класса: пользовательские и системные требования. Вот как эти два класса требований определяет И. Соммервилл [23]: Пользовательские требования — описание на естественном языке (плюс поясняющие диаграммы) функций, выполняемых системой, и ограничений, накладываемых на нее. Системные требования — детализированное описание системных функций и ограничений, которое иногда называют функциональной спецификацией. Оно служит основой для заключения контракта между покупателем системы и 8
разработчиками программного обеспечения. Ориентируя свое определение на то, что приходится различать требования разных уровней, Соммервилл вводит еще один класс требований: Проектная системная спецификация — обобщенное описание структуры программной системы, которое будет основой для более детализированного проектирования системы и ее последующей реализации. Эта спецификация дополняет и детализирует спецификацию системных требований. Приведенные определения дают представление о том, что понимается под требованиями разных классов, однако они не выдерживают критики с точки зрения точности и применимости к различным ситуациям. Неправомерно относить проектные системные спецификации к разряду требований, поскольку это не внешнее по отношению к проекту описание, а один из первых продуктов выполнения проекта; и то, что такой продукт нуждается в согласовании, что он регламентирует разработку, недостаточно, чтобы считать спецификации требованиями. Что же касается требований первых двух классов, то Соммервилл явно делает акцент лишь на способе и точности описания программной системы, оставляя без внимания необходимое разграничение между описанием того, что должна предоставлять пользователю система — пользовательские требования в нашем понимании, и как она должна работать — системные требования. Разумеется, в этих определениях нужно говорить и о функциях, и об ограничениях, но разделение между “что” и “как” является действительной границей между рассматриваемыми классами. Применительно к менеджменту это важно, поскольку при организации процесса производства программного продукта требования указанных классов приходится согласовывать с разными людьми, заинтересованными в разрабатываемой системе. Итак, с точки зрения целей программный проект можно рассматривать как деятельность по реализации системы, удовлетворяющей вполне определенным требованиям. Требования не обязательно формулируются все сразу. Более того, очень часто они поступают при развитии проекта и даже уже при использовании полученной программной системы. И это характерно практически для всех программных разработок. Естественно, деятельность менеджера должна учитывать, что работа над проектом ведется в условиях большой неопределенности относительно конечного результата. Перечисленные аспекты разработки программного обеспечения определяют специфику этой деятельности в самых общих чертах с точки зрения конкретного ее участника — менеджера программного проекта. Чтобы разобраться в том, какие задачи решает менеджер для организации целенаправленного эффективного развития проекта, мы рассмотрим два вопроса: кто участвует в разработке; какие этапы проходит проект в своем развитии. 9
Первый из них поможет выявить функции менеджера в коллективе разработчиков и место этих функций среди других выполняемых при развитии проекта мероприятий. Он имеет два аспекта, непосредственно связанные с проведенным выше разграничением между управлением и руководством. С точки зрения управления участники проекта — это абстрактные действующие агенты, которые выполняют заданные функции. Здесь под функцией понимается некое действие, при выполнении которого потребляются определенные ресурсы и производится определенный результат. Функциональный взгляд на участников разработки проекта делает их взаимозаменяемыми, обезличенными в пределах компетенции, соответствующей выполнимости функции. Он приводит к понятию роли, назначаемой работнику для выполнения соответствующих обязанностей. Говоря о руководстве, нужно рассматривать персоналии, которым назначаются роли в проекте. Пожалуй, самая главная задача руководства — это формирование дееспособного коллектива, который в состоянии выполнить данный проект. Понятно, что основным требованием к коллективу является его компетентность и квалификационная обеспеченность, необходимые для выполнения проектного задания. Но глубоко ошибаются те, кто считает это достаточным. Если не отработаны способы общения членов коллектива между собой, с руководством, с заказчиками, то никакая компетентность не поможет. В то же время, как показывает практика, недостаточная стартовая квалификация коллектива может успешно преодолеваться совместным обучением сотрудников, проводимым параллельно с основной работой. Ключевым качеством коллектива, определяющим его успешность, является слаженность. В идеальном коллективе все понимают друг друга с полуслова, есть взаимопонимание и уважение, не происходят или сведены к минимуму внутренние конфликты и противоречия. В реальности менеджеру редко приходится иметь дело с таким коллективом, а значит, необходимы меры, способствующие не только росту индивидуальной квалификации работников, но и дееспособности формируемой команды в целом. Эти меры следует рассматривать в качестве задач менеджера как руководителя коллектива. Поскольку развитие проекта — работа, существенно зависящая от внешних по отношению к коллективу факторов, определяя место менеджера в коллективе разработчиков, полезно расширить круг участников этого процесса, включив в него, с одной стороны, заказчиков программного продукта, а с другой — руководство организации (компании, фирмы), под эгидой которой выполняется проект. Вопрос об этапах развития проекта обозначает задачи менеджера как управляющего проектом. Он ставится, чтобы раскрыть, как распределяются функции менеджера и других исполнителей во времени. Неоднородность работ, выполняемых при производстве программных продуктов, зависимость этих работ друг от друга, коллективный характер их выполнения — вот основания для поэтапной организации развития проекта с выставлением заданий на этапы и менеджерским контролем хода работ. Все это связывается с понятием жизненного цикла программного обеспечения. К этому нужно добавить, что понятие жизненного цикла, заимствованное из традиционных отраслей промышленного производства, оказалось во многом (хотя и не 10