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

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

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

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

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

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

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

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

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

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

Некоторые из названных функций характерны как для отдельных библиотек, так и для библиотечных систем. Так, в ЦБС центральные библиотеки берут на себя выполнение функций управления, централизованного комплектования и аналитико-синтетической обработки, а на библиотеки- филиалы возлагается основная нагрузка по обслуживанию пользователей. Частичное выполнение названных функций осуществляют также областные и центральные отраслевые библиотеки, формируя свои фонды дорогостоящими и недостающими в ЦБС документами, осуществляя обслуживание пользователей, чьи потребности не смогли удовлетворить библиотеки системы. В ряде стран в связи с активным развитием компьютерных технологий получили распространение корпоративная каталогизация, совместное использование региональных или отраслевых информационных ресурсов, согласованные действия по обслуживанию пользователей. В названных случаях одна из библиотек, как правило центральная, выполняет функцию координации и кооперации совместной деятельности библиотек системы или корпорации.

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

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

Еще по теме ТЕХНОЛОГИЧЕСКИЕ ФУНКЦИИ:

1. 1.2 Технологические цели и критерии их достижения. Постановка технологической задачи ректификации нефти
2. 13. Компоновка операций и технологического оборудования при автоматизации технологических процессов. Последовательное, параллельное и смешанное агрегатирование
3. Кузнецов Виктор Георгиевич. АЛГОРИТМИЗАЦИЯ И ОПТИМИЗАЦИЯ ТЕХНОЛОГИЧЕСКОГО ПРОЦЕССА РЕКТИФИКАЦИИ НЕФТИ. ДИССЕРТАЦИЯ на соискание ученой степени кандидата технических наук. 05.13.06 - Автоматизация и управление технологическими процессами и производствами (промышленность). Самара-2005, 2005
4. Функции журналистики. Понятие функцию Многообразие социальных и информационных потребностей общества – объективная основа функций журналистики.

Ключевые роли коллектива разработчиков и задача определения кадровых ресурсов проекта

Лекция КС ЭК.

Функциональные роли в коллективе разработчиков......................................... 1

ВОПРОСЫ ДЛЯ ПРОВЕРКИ............................................................................... 12

Ключевые роли коллектива..................................................................................... 14

разработчиков и задача определения.................................................................. 14

кадровых ресурсов проекта.................................................................................... 14

Функциональные роли в коллективе разработчиков

Определяются функции, выполняемые сотрудниками в ходе развития проекта и типичные для программных проектов роли разработчиков; указы­вается, какие роли могут совмещаться при выполнении проекта. Представле­ны решения обсуждаемых вопросов, предлагаемые компанией Microsoft и Центром объектно-ориентированных технологий IBM.

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

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

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

Обычно роль объединяет родственные функции. Также принято обозначать роли их главными функциями. Продолжая только что при­веденную иллюстрацию функций, выполняемых разработчиками про­екта, укажем на следующие роли: кодировщик - действующее лицо, главной функцией которого является кодирование, аналитик - тот, кто занимается анализом требований. Подобную характеристику можно дать и тестировщику. Что же касается функции отладки, то в реальных проектах она обычно подразделяется на несколько видов: отладка ком­понентов, которой занимаются разработчики компонентов (например, те же кодировщики) и комплексная отладка, которая может поручаться специально выделенным сотрудникам или рассматриваться в качестве задачи группы разработчиков. Часто выполняются такие работы, как от­ладка спецификаций, декомпозиция проекта и др. Иными словами, функция отладки обычно не рассматривается как образующая роль, а распределяется по нескольким ролям в соответствии с принятой страте­гией развития проекта.

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

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

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

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

Понятно, что как состав, так и значимость ролей разработчиков и тех, кто с ними связан, различаются в зависимости от выполняемого проекта, от коллектива исполнителей, принятой технологии, от других факторов. Неоднозначность выбора ролей приводит к тому, что их спи­сок часто становится непомерно велик (иллюстрацией тому может слу­жить первая редакция документации по Rational Unified Processing (RUP), в которой определено свыше 20 ролей; в последующих версиях документа это число сокращено до обозримого уровня ). Чрезмер­ное увеличение числа есть следствие отождествления роли и функции и, соответственно, игнорирования понятия родственности функций. В то же время, если ролей выбрано недостаточно, есть опасность, что не все нужные в проекте функции будут охвачены планированием и управле­нием.

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

В модели проектной группы концепции Microsoft Solution Framework (MSF) предлагается образовывать небольшие мобильные коллективы как атомарные производственные единицы с общей ответ­ственностью за выполняемые задания - так называемые проектные группы . Такие группы строятся как многопрофильные команды, члены которых распределяют между собой ответственность и дополня­ют области компетентности друг друга. Группа состоит не более чем из 10 человек. Все они считаются обладающими сходным уровнем профес­сиональной подготовки, хотя и в разных областях индивидуальной спе­циализации. Провозглашается равноправие членов группы и коллек­тивная ответственность за выполняемые задания: проектная группа - команда равных. Все это позволяет сохранять внутри группы нефор­мальные отношения.

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

Определено шесть ролевых кластеров, которые соответствующим образом структурируют проектные функции разработчиков (рис. 2.1).

■ Управление продуктом (product management). Ключевая цель класте­ра - обеспечивать удовлетворение интересов заказчика. Для ее дос­тижения кластер должен содержать следующие области компетенции:

Планирование продукта,

Планирование доходов,

Представление интересов заказчика,

Маркетинг.

> Управление программой (program management). Задача - обеспечить
реализацию решения в рамках ограничений проекта, что может
рассматриваться как удовлетворение требований к бюджету проек­та и к его результату. Области компетенции кластера:

Управление проектом;

Выработка архитектуры решения;

Контроль производственного процесса;

Административные службы.

Разработка (development). Первостепенной задачей кластера является построение решения в соответствии со спецификацией. Обла­cти компетенции кластера:

Технологическое консультирование;

Проектирование и осуществление реализации;

Разработка приложений;

Разработка инфраструктуры.

Тестирование (test). Задача кластера - одобрение выпуска продукта только после того, как все дефекты выявлены и устранены. Обла­сти компетенции кластера:

Разработка тестов;

Удовлетворение потребителя (user experience). Цель кластера - по­вышение эффективности использования продукта. Области компетенции кластера:

Общедоступность (возможности работы для людей с недостатка­
ми зрения, слуха и др.);

Интернационализация (эксплуатация в иноязычных средах);

Обеспечение технической поддержки;

Обучение пользователей;

Удобство эксплуатации (эргономика);

Графический дизайн.

Управление выпуском (release management). Задача кластера - бес­препятственное внедрение и сопровождение продукта. Области
компетенции кластера:

Инфраструктура (infrastructure);

Сопровождение (support);

Бизнес-процессы (operations);

Управление выпуском готового продукта (commercial release
management).

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

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

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

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

Заказчик (Customer) - реально существующий (в организации, которой подчинена команда, или вне ее) инициатор разработки или
кто-либо иной, уполномоченный принимать результаты (как теку­щие, так и окончательные) разработки.

Планировщик ресурсов (Planner) - выдвигает и координирует требования к проектам в организации, осуществляющей данную раз­
работку, а также развивает и направляет план выполнения проекта
с точки зрения организации.

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

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

Архитектор (Architect) - отвечает за проектирование архитектуры
системы, согласовывает развитие работ, связанных с проектом.

Проектировщик подсистемы (Designer) - отвечает за проектирование подсистемы или категории классов, определяет реализацию и
интерфейсы с другими подсистемами.

Эксперт предметной области (Domain Expert) - отвечает за изуче­ние сферы приложения, поддерживает направленность проекта на
решение задач данной области.

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

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

Специалист по пользовательскому интерфейсу (Human Factors
Engineer) - отвечает за удобство применения системы. Работает с
заказчиком, чтобы удостовериться, что пользовательский интерфейс удовлетворяет требованиям.

Тестировщик (Tester) - проверяет функциональность, качество и
эффективность продукта. Строит и исполняет тесты для каждой
фазы развития проекта.

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

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

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

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

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

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

В зависимости от проекта и условий его выполнения роли участни­ков проекта могут совмещаться. Предельный случай - программист раз­рабатывает проект для себя (по собственному заказу), сам планирует

* Термин «инициаторы работ» - перевод английского слова «stakeholdes». В литературе можно встретить и другие его переводы: организаторы работ, заинтересованные лица и даже акционеры (последнее уводит далеко в сторону). Некоторые прибегают к транслитерации и говорят о степк-хапдерах проекта. Мы предпочитаем назыать всех тех, чьи интересы в той или иной мере затра­гивают проект и его результаты, инициаторами работ. Наряду с этим мы употребляем термин «заинтересованные лица», обозначая им всех тех, кто проявляет интерес к проекту и от действия которых может зависеть его развитие, пусть даже косвенно. Таким образом, инициаторы работ включают в себя заинтересованных лиц (в частности, разработчиков проекта), но обратное невер­но. К примеру, акционер проекта является инициатором работ, так как его интересы судьба про­екта, безусловно, затрагивает. Но полагаясь на своего брокера, он может позволить себе даже не думать о проекте, т.е. не быть его заинтересованным лицом (в нашей терминологии).

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

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

I.He следует допускать совмещения ролей, которые имеют кон­фликтные или противоречивые интересы. Если такое совмещение все-таки используется, то необходимо предусматривать механиз­мы, которые будут демпфировать противоречия.

2. Представление ролей с конфликтными интересами различным
людям обеспечивает равновесие противоречащих точек зрения.

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

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

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

Менеджер проекта по своему назначению является выделенным в команде. Он берет на себя взаимодействие с заказчиком и планировщи­ком ресурсов, с одной стороны, а с другой - распределяет работы среди членов команды. Последнее означает, что он должен обладать полной ин­формацией о декомпозиции проекта. Как следствие, совмещение его ро­ли с ролью архитектора проекта является весьма желательным, а потому довольно частым. Единственным условием для такого совмещения явля­ется требование четко знать, когда и чьи функции выполняет данное дей­ствующее лицо (см. общий для всех совмещений принцип 4).

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

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

Нежелательно совмещение ролей руководителя команды и проекти­ровщика какой-либо подсистемы. И это обусловлено противоречивостью их ролевых интересов.

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

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

Разделение ролей проектировщика и руководителя способствует
равновесию точек зрения пользователя и разработчика подсистемы
(см. принцип 2).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ВОПРОСЫ ДЛЯ ПРОВЕРКИ

Вариант 1

1. Функция, выполняемая разработчиком проекта, -это:

□ задание, поручаемое для выполнения

□ действия, выполняемые для достижения определенного
результата

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

П действия, предписанные для выполнения разработчиком в проекте

□ любые целенаправленные действия разработчика

2. Проектная группа модели Microsoft Solution Framework -
это:

□ производственный коллектив со строгим разделением
функций

□ мобильный производственный коллектив, создаваемый для
выполнения проекта

□ мобильный коллектив с общей ответственностью за
выполняемые задания

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

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

3. Внешние функции менеджера - это:

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

□ те функции, которые выполняет менеджер вне данного
проекта

□ те функции, выполнение которых обеспечивает требуемые
условия развития проекта

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

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

Вариант 2

1. Поручения, выполняемые разработчиком проекта, - это:

□ Задания, которые дает менеджер для выполнения

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

□ Действия, предписанные функцией разработчика

□ Действия, предписанные ролью разработчика в проекте

□ То же, что и функция разработчика

2. Ролевой кластер модели MSF - это:

□ Разработчики проектной группы, которые работают над
достижением одной из целей проекта

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

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

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

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

3. Внутренние функции менеджера - это:

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

□ Взаимодействие менеджера с разработчиками

информационную поддержку проекта

□ Взаимодействие менеджера с теми, кто отвечает за
декомпозицию проекта

О Любая работа, затрагивающая членов команды разработчиков проекта

Вариант 3

1. Функция называется технологической, если:

□ Для нее определен регламент выполнения поручений, из
которых она складывается

□ Для исполнителя не требуется дополнительных разъяснений
как ее выполнять

□ Необходимые для ее выполнения действия предписаны
принятой в проекте технологией разработки

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

□ Она поддержана средствами автоматизации

2. Какие ролевые кластеры предусматривает модель
проектной группы MSF?

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

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

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

О Управление программой, разработка, сопровождение, управление рисками, управление версиями, тестирование

□ Управление программой, разработка, тестирование, сопровож­дение, управление версиями, удовлетворение потребителя

3. Не следует допускать совмещения ролей, которые имеют
конфликтные или противоречивые интересы. Что делать,
если такое совмещение все-таки приходится использовать?

□ Привлечь к работе дополнительных исполнителей и тем
самым избежать совмещения ролей

□ Сократить объем работ, согласовав это с заказчиком

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

П Предусмотреть механизмы, которые будут демпфировать противоречия

□ Переделать ролевую структуру проектной команды

Ключевые роли коллектива разработчиков и задача определения кадровых ресурсов проекта

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

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

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

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

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

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

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

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

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

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

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

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

Архитектор проекта;

Проектировщики подсистем;

Руководители команд разработки подсистем;

Специалист по пользовательскому интерфейсу;

Эксперт предметной области.

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

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

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

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

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

Первый вопрос распределения ресурсов: где подбирать специали­стов на проект. Вариантов немного (см. рис. 3.1).

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

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

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

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

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

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

Об уровне квалификации сотрудника как претендента на ту или
иную роль;

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

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

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

1. У менеджера есть коллектив потенциальных исполнителей, гото­вый приступить к работе над проектом.

2. Менеджерский коллектив потенциальных исполнителей недостаточен: среди членов команды нет сотрудников, которые обладают
нужной квалификацией.

3. В поле зрения менеджера есть независимые потенциальные ис­полнители, из которых можно сформировать коллектив для рабо­ты над проектом.

4. Менеджеру приходится прибегать к найму рабочей силы со стороны.

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

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

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

Резюмируя решение задачи определения кадровых ресурсов проек­та, следует указать на следующую схему (см. рис. 3.2).

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

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

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

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

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

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

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

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

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

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

ТЕХНОЛОГИЯ И ЗАДАЧИ. Изменения в тесно связанных переменных - технологии и задачах - относятся к изменениям процесса и графика выполнения задач, внедрению нового оборудования или методов, изменениям нормативов и самого характера работы. Как и структурные изменения, изменения технологические часто разрушают социальные стереотипы, обычно вызывая пересмотр планов, - изменение в технологии может потребовать модификации структуры и рабочей силы . Когда, например, газеты начали заменять старый способ набора электронной системой верстки, им потребовалось больше специалистов по электронике и намного меньше наборщиков, чем ранее. Когда почти все газеты заявили о переходе на новый вид верстки, они встретились с сильным сопротивлением профсоюзов, которые опасались сокращения рабочих мест . Введение новых методов контроля за качеством и товарно-материальными запасами потребует большого количества изменений в задачах организации . Аналогичным образом использование вычислительной техники часто меняет многие функции персонала организации.  

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

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

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

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

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

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

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

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

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

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

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

МЕТОДЫ УПРАВЛЕНИЯ ПЕРСОНАЛОМ - способы воздействия на коллективы и отдельных работников с целью осуществления координации их деятельности в процессе функционирования организации. Наука и практика выработали три группы М.у.п. адм., экон. и соц.-психологические. Адм. методы ориентированы на такие мотивы поведения, как осознанная необходимость дисциплины труда , чувство долга, стремление человека трудиться в определенной организации, культура трудовой деятельности. Эти методы отличает прямой характер воздействия любой регламентирующий и адм. акт подлежит обязательному исполнению. Для адм. методов характерно их соответствие правовым нормам, действующим на определенном уровне управления, а и распоряжениям вышестоящих органов управления . Экон. и соц.-психологические методы носят косвенный характер управленческого воздействия . Нельзя рассчитывать на автоматическое действие этих методов и трудно определить силу их воздействия и конечный эффект. Экон. методы осуществляют материальное стимулирование коллективов и отдельных работников. Они основаны на использовании экон. механизма управления . Соц.-психологические методы управления основаны на использовании соц. механизма управления (система взаимоотношений в коллективе, соц. потребности и т.п.). Специфика этих методов заключается в значительной доле использования неформальных факторов, интересов личности, группы, коллектива в процессе управления персоналом. М.у.п. можно также классифицировать по признаку принадлежности к общей функции управления методы нормирования , организации, планирования, регулирования, стимулирования, анализа, учета. Более подробная классификация М.у.п. по признаку принадлежности к конкретной функции управления персоналом позволяет выстроить их в технологическую цепочку всего цикла работ с персоналом. Выделяются методы найма, отбора и приема

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

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

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

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

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

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

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

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

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

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

Так, в ЦБС центральные библиотеки берут на себя выполнение функций управления, централизованного комплектования и аналитико-синтетической обработки, а на библиотеки- филиалы возлагается основная нагрузка по обслуживанию пользователей. Частичное выполнение названных функций осуществляют также областные и центральные отраслевые библиотеки, формируя свои фонды дорогостоящими и недостающими в ЦБС документами, осуществляя обслуживание пользователей, чьи потребности не смогли удовлетворить библиотеки системы. В ряде стран в связи с активным развитием компьютерных технологий получили распространение корпоративная каталогизация, совместное использование региональных или отраслевых информационных ресурсов, согласованные действия по обслуживанию пользователей. В названных случаях одна из библиотек, как правило центральная, выполняет функцию координации и кооперации совместной деятельности библиотек системы или корпорации.

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

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

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

Управленческое решение - это продуманное действие, следствием которого является осуществление какого-либо действия для достижения цели организации или воздержание от него .

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

Требования, предъявляемые к управленческим решениям :

1. всесторонняя обоснованность;
2. правомерность;
3. непротиворечивость;
4. своевременность;
5. обеспеченность ресурсами;
6. ясность и лаконичность.

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

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

Значительное влияние на реализацию технологических функций менеджмента имеет также система коммуникаций .

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

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

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

Помимо этого, коммуникации могут быть вербальными и невербальными , и менеджер должен владеть ими обеими в совершенстве.

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

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

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