учебники, программирование, основы, введение в,

 

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

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

В этой схеме централизация достигается путем назначения главного менеджера проекта, который делегирует полномочия менеджерам по направлениям.
* 1.1 иллюстрирует три схемы организации менеджмента проекта.Здесь стрелки обозначают связи участников реализации проекта, обусловленные их взаимодействием с менеджером, жирность контура значков отражает менеджерские обязанности сотрудников. Как видно из рисунка, в схеме со службой менеджера помощники по своему статусу являются обычными работниками, тогда как при делегировании полномочий менеджеры по направлениям получают соответствующие полномочия в своих сферах ответственности (обозначены пунктирными овалами).
Делегирование можно считать основным инструментом разделения труда в проекте (не только в случае менеджмента), когда есть ответственность за некоторую функцию (работу и др.), но для ее выполнения нет собственных ресурсов, а потому приходится прибегать к помощи. Собственно говоря, различие схем работы менеджера связано с использованием механизмов поручений или делегирования.
В коллективах, выполняющих программные проекты, возможны самые разнообразные организационные структуры. Так, для сложных, объемных по трудозатратам проектов иерархические цепочки «менеджер — менеджер по направлению — исполнитель работ» целесообразно увеличивать, дифференцируя работы и сферы ответственности для некоторых менеджеров по направлению.
Иногда оправданно делегирование всех менеджерских обязанностей и полномочий менеджерам по направлениям. В результате ответственность за проект несет не один человек, она распределяется по менеджерской группе, т.е. возникает коллективная, деперсонифицированная ответственность. Возможны схемы, когда вместо менеджеров по направлениям деперсонифицированная ответственность назначается группе в целом, т.е. менеджер проекта выдает задания, контролирует их выполнение, осуществляет другие функции, обращаясь ко всей группе, внутри которой уже распределяются обязанности, в том числе и обязанности менеджера по направлению. Характерный пример — модель проектной группы, предлагаемая в концепции Microsoft Solution Framework (MSF) ].
Для небольших групп возможна следующая организация работ: обязанности главного менеджера распределяются по команде разработчиков, которая за счет внутренних механизмов решает, как планировать работы, как их распределять и контролировать. Это характерно для так называемого подхода быстрой разработки (agile development) программных систем, объединившего в себе несколько методологий программирования, которые отказываются от многих принципов традиционного менеджмента. Наиболее ярким примером подхода быстрой разработки является экстремальное программирование . Ему и другим методам данного направления мы уделим внимание в дальнейшем, а пока лишь отметим, что здесь, как и в других случаях, менеджерские задачи не исчезают, как могло бы показаться на первый взгляд. Просто форма и методы их решения приобретают другой характер.
По ряду причин может оказаться целесообразным сочетание схем организации менеджмента проекта. В результате появляются, например, коллективы, в которых главный менеджер берет на себя функции менеджера определенного направления, тем самым он отвечает и за весь проект в целом, и за некоторую его часть.
Все варианты организации менеджмента перечислить невозможно. Иногда они возникают стихийно, иногда планируются под определенную методологию производства программ. Бывает и так, что организация менеджмента и методология выбираются исходя из исторически сложившейся структуры коллектива. И ничего предосудительного в этом нет.
С точки зрения изучения задач менеджмента полезно представить их в функциональном стиле, т.е. абстрагируясь, когда это возможно, как от масштабов проектов, так и от организационной структуры коллектива исполнителей. Для этого мы связываем такие задачи с деятельностью абстрактной персоны, которая в конкретных случаях прибегает к распределению своих работ по схемам с поручениями или с делегированием полномочий. Конкретизироваться эта персона может по-разному: как единоличный начальник, как начальник с менеджерской группой, как распределенная между исполнителями роль в проекте и т.д. Как следствие, проблема разделения работ оказывается изолированной, допускающей отдельное рассмотрение вариантов решения.
Прием определения абстрактного менеджера следует считать методическим. В дальнейшем изложении он называется определением абстрактного действующего лица проекта и применяется к изучению задач, связанных с выполнением проекта, без привязки их деятельности к конкретным персоналиям или групповым ролям.


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

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

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

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

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

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

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

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

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

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

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

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

Первый из них поможет выявить функции менеджера в коллективе разработчиков и место этих функций среди других выполняемых при развитии проекта мероприятий. Он имеет два аспекта, непосредственно связанные с проведенным выше разграничением между управлением и руководством.
С точки зрения управления участники проекта — это абстрактные действующие агенты, которые выполняют заданные функции. Здесь под функцией понимается некое действие, при выполнении которого потребляются определенные ресурсы и производится определенный результат. Функциональный взгляд на участников разработки проекта делает их взаимозаменяемыми, обезличенными в пределах компетенции, соответствующей выполнимости функции. Он приводит к понятию роли, назначаемой работнику для выполнения соответствующих обязанностей.
Говоря о руководстве, нужно рассматривать персоналии, которым назначаются роли в проекте. Пожалуй, самая главная задача руководства — это формирование дееспособного коллектива, который в состоянии выполнить данный проект. Понятно, что основным требованием к коллективу является его компетентность и квалификационная обеспеченность, необходимые для выполнения проектного задания. Но глубоко ошибаются те, кто считает это достаточным. Если не отработаны способы общения членов коллектива между собой, с руководством, с заказчиками, то никакая компетентность не поможет. В то же время, как показывает практика, недостаточная стартовая квалификация коллектива может успешно преодолеваться совместным обучением сотрудников, проводимым параллельно с основной работой.
Ключевым качеством коллектива, определяющим его успешность, является слаженность. В идеальном коллективе все понимают друг друга с полуслова, есть взаимопонимание и уважение, не происходят или сведены к минимуму внутренние конфликты и противоречия. В реальности менеджеру редко приходится иметь дело с таким коллективом, а значит, необходимы меры, способствующие не только росту индивидуальной квалификации работников, но и дееспособности формируемой команды в целом. Эти меры следует рассматривать в качестве задач менеджера как руководителя коллектива.
Поскольку развитие проекта — работа, существенно зависящая от внешних по отношению к коллективу факторов, определяя место менеджера в коллективе разработчиков, полезно расширить круг участников этого процесса, включив в него, с одной стороны, заказчиков программного продукта, а с другой — руководство организации (компании, фирмы), под эгидой которой выполняется проект.
Вопрос об этапах развития проекта обозначает задачи менеджера как управляющего проектом. Он ставится, чтобы раскрыть, как распределяются функции менеджера и других исполнителей во времени. Неоднородность работ, выполняемых при производстве программных продуктов, зависимость этих работ друг от друга, коллективный характер их выполнения — вот основания для поэтапной организации развития проекта с выставлением заданий на этапы и менеджерским контролем хода работ. Все это связывается с понятием жизненного цикла программного обеспечения. К этому нужно добавить, что понятие жизненного цикла, заимствованное из традиционных отраслей промышленного производства, оказалось во многом (хотя и не во всем!) подобно тому, что принято считать жизненным циклом материального продукта.
К настоящему времени вполне сложилось представление о том, на какие этапы разбивается развитие проекта, какие функции связываются с выполнением этапов, как должен осуществляться контроль. Принципы построения жизненных циклов, которые соответствуют разным условиям развития проектов, — предмет специального изучения, к которому мы очень скоро вернемся. Здесь же стоит отметить, что исходя из дидактических соображений именно жизненный цикл целесообразно рассматривать в качестве концептуальной основы изложения материала по менеджменту программных проектов. Подобный подход к изложению применяется достаточно часто (см., например, .
По сути, жизненный цикл — это процесс конструирования программного обеспечения. Требования к проекту определяют цели и регламент данного процесса, а разработчики являются основной его движущей силой и одним из главных ресурсов. Другие главные ресурсы проекта — это время и финансы, выделяемые для выполнения проектного задания. Кроме главных ресурсов проекта, можно говорить о его производных и вспомогательных ресурсах. К производным ресурсам относятся технические средства, а также программы, используемые в качестве инструментов, заготовок и включаемых компонентов, а к вспомогательным — тепло и электроэнергия, служебные помещения, технические и организационные средства, которые непосредственно с процессом производства не связаны, но способствуют его успешному выполнению. Разделение неглавных ресурсов на производные и вспомогательные во многом зависит от специфики выполняемого проекта. Так, телефон, вообще говоря, нужно относить к вспомогательным ресурсам, но если проект связан, например, с автоматизацией работы телефонной станции, то этот ресурс следует считать производным.
Трудовой ресурс хорошего проекта является консервативным, т.е. не очень меняющимся в ходе выполнения проекта. При плохой организации дела есть риск текучести кадров, которая для программных проектов отрицательно сказывается на результатах. Время — ресурс невосполнимый, а потому планирование времени является одной из главных забот менеджера. Финансы — основной расходуемый ресурс, который, к сожалению, всегда ограничен. В частности, они идут не только на обеспечение заработной платы работников, но и расходуются на технические средства и используемые программы.
В менеджменте программных проектов приходится решать задачу составления и соблюдения оптимального баланса расходования ресурсов. Эти задачи характерны для деятельности менеджера практически любого проекта. Разумеется, на нее влияют и специфика проекта, и условия его выполнения. Как следствие, существует множество подходов, методов, методик и даже технологий, поддерживающих менеджмент. Очень часто они претендуют на универсальность поддержки. И хотя подобные претензии — не более чем реклама, разобраться в том, какова на самом деле область адекватного применения предлагаемых инструментов, без специальной подготовки довольно трудно. По этой причине мы пытаемся представить менеджмент программных проектов в виде, не зависящем от конкретных методик и технологий, с тем чтобы любая из них могла быть соответствующим образом интерпретирована и читатель смог осознанно подходить к выбору рекомендаций и подходов в своей практической деятельности.
Представленные выше общие положения, на которых базируется материал курса, сегодня практически всегда берутся за основу изложения в книгах по программной инженерии (см., например, . Но следовать им недостаточно. Требуется общий взгляд на предмет, который позволит систематизировать знания. Выработка такого взгляда у читателя — одна из основных целей данного курса.
Таким образом, при обсуждении задач менеджера в разработке программных изделий мы сталкиваемся с тремя взаимосвязанными направлениями его деятельности.

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

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

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика