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

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

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

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

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

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

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

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

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

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

приобретают другой характер.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• кто участвует в разработке;

• какие этапы проходит проект в своем развитии.

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

С точки зрения управления участники проекта — это абстрактные действующие агенты, которые выполняют заданные функции. Здесь под функцией понимается некое действие, при выполнении которого потреб­ляются определенные ресурсы и производится определенный результат. Функциональный взгляд на участников разработки проекта делает их вза­имозаменяемыми, обезличенными в пределах компетенции, соответству­ющей выполнимости функции. Он приводит к понятию роли, назначае­мой работнику для выполнения соответствующих обязанностей.

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

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

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

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

К настоящему времени вполне сложилось представление о том, на какие этапы разбивается развитие проекта, какие функции связываются с выполнением этапов, как должен осуществляться контроль. Принципы построения жизненных циклов, которые соответствуют разным условиям развития проектов, — предмет специального изучения, к которому мы очень скоро вернемся. Здесь же стоит отметить, что исходя из дидактиче­ских соображений именно жизненный цикл целесообразно рассматри­вать в качестве концептуальной основы изложения материала по менедж­менту программных проектов. Подобный подход к изложению применя­ется достаточно часто (см., например, [27]).

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

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

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

Представленные выше общие положения, на которых базируется материал курса, сегодня практически всегда берутся за основу изложения в книгах по программной инженерии (см., например, [27]). Но следовать им недостаточно. Требуется общий взгляд на предмет, который позволит систематизировать знания. Выработка такого взгляда у читателя — одна из основных целей данного курса.

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

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

• Второе направление — планирование и контроль хода проекта в
соответствии с жизненным циклом создаваемого программного
обеспечения.

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

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

Вариант 1

1. Менеджмент программных проектов — это:

□ управление и руководство в проекте

□ отслеживание жизненного цикла развития проекта

□ деятельность, организующая развитие программного проекта
во всех его аспектах

□ решение задач распределения ресурсов и контроля их
расходования

□ отслеживание этапов проекта

2. Служба менеджера проекта — это:

□ помощники менеджера, которым он поручает задания для
освобождения себя от рутины постоянного контроля

□ помощники менеджера, которым в проекте выделяются сферы
ответственности

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

□ помощники менеджера, которым в той или иной части
проекта делегируются полномочия менеджера

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

3. Источники, из которых появляются требования,
регламентирующие и направляющие развитие проекта:

Q будущие пользователи результатов выполнения проекта

□ заказчик и инвестор проекта
О программисты

□ конкуренты

□ подрядчики

Вариант 2

1. Менеджер программного проекта — это:

□ руководитель коллектива разработчиков проекта

□ административное лицо, ответственное за отслеживание
жизненного цикла развития проекта

□ организатор работ по развитию программного проекта и
ответственный за его выполнение

□ тот, кто заказывает разработку проекта

□ сотрудник компании, распределяющий ресурсы для проекта

2. Делегирование полномочий — это:

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

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

□ поручение работнику выполнение того или иного задания

□ назначение ответственного за определенный этап выполнения
проекта

□ назначение заместителя на время отсутствия основного
ответственного

3. Необходимость понятия жизненного цикла разработки связана с тем, что:

□ работы проекта взаимозависимы и разнородны

□ существует объективное требование разделения труда
разработчиков

□ работы проекта растянуты во времени

□ планируемые результаты выполнения проекта появляются по
мере его развития

□ есть аналогии с жизненным циклом из традиционных
отраслей промышленного производства

Вариант 3

1. Схемы организации менеджмента программного
проекта — это:

□ образование группы менеджера проекта

□ определение лиц, отслеживающих жизненный цикл развития
проекта

□ единоличное управление работами по развитию программного
проекта

□ образование службы менеджера проекта

□ распределение менеджерских обязанностей между
разработчиками проекта

2. Группа менеджера проекта — это:

□ помощники менеджера по различным видам работ в проекте

□ структура, создаваемая из работников для помощи в
выполнении задач менеджмента, без выделения этим
работникам сфер ответственности в проекте

□ структура, создаваемая из работников для помощи
выполнения задач менеджмента, с выделением этим
работникам сфер ответственности в проекте

□ лица, ответственные за выполнение определенных видов работ
в проекте

□ ответственные исполнители частей проекта

3. Что определяет жизненный цикл в процессе производства
программного обеспечения:

□ задачи, которые необходимо выполнить

□ цели и регламент выполнения этого процесса

□ этапы данного процесса

□ обязанности разработчиков в привязке к этапам производства

□ распределение времени на выполнение работ

Дата добавления: 2014-01-07