Функциональные роли в коллективе разработчиков: Презентация на тему «Функциональные роли в коллективе разработчиков» – Функциональные роли в коллективе разработчиков

Функциональные роли — Прочее — СУЗ

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

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

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

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

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

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

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

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

Ролевые кластеры модели проектной групп MSF

Ролевая структура проекта

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

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

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

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

Ролевая структура проекта

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

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

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

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

5

Ролевая структура проекта

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

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

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

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

6

Роли

Характеристика совмещения ролей

Менеджер и архитектор

Желательно

Менеджер и руководитель команды

Противоречиво

Руководитель команды и архитектор

Возможно

Руководитель команды и проектировщик подсистемы

Нежелательно

Менеджер и разработчик

Не допускается

Для различных разработчиков

Эффективно с ограничениями (обычное дело)

Создание документации (все сотрудники)

Специалист по интерфейсу и менеджер

Успешно распределяется

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

Разумно

Специалист по интерфейсу и эксперт предметной области

Зачастую разумно

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

Редко бывает эффективно

Специалист по интерфейсу и разработчик

Бывает полезно

Библиотекарь и один из разработчиков

Часто полезно

Допустимо

Тестировщики и другие члены команды

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

Перекрестно

Оправданно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Полезно
сопоставить представленную схему с
тем, что обычно предлагается
в качестве методов для работы с кадрами.
В этом плане се­годня
чаще всего говорят об организации
стихийно складывающихся не­формальных
групп специалистов разного профиля.
По-видимому, это связано
с анализом формирования успешных
коллективов, с одной сто­роны,
а с другой — с разочарованием в
рекомендациях, которые предла­гались
ранее (см., например, обсуждение этого
вопроса у Брукса [7]). В соответствии с
такой точкой зрения строятся предложения
модели про­ектной
группы MSF,
в которых делается попытка определить
внешние требования,
предъявляемые к группам. Постулат о
неформальном обра­зовании
групп не позволяет говорить о внутренних
требованиях, как-то регламентирующих
этот процесс. И если следовать логике
этих предло­жений,
то кадровая политика менеджмента проекта
сводится к выбору подходящих
проектных групп. Когда это удается, есть
довольно высокие шансы
на успех. Однако, к сожалению, менеджеру
чаще всего нужно действовать
в иных условиях, в которых приходится
формировать ко­манду разработчиков.
И тогда задача определения кадровых
ресурсов проекта,
подбора исполнителей становится одной
из наиболее важных для
проекта. Хочется надеяться, что
представленные выше материалы помогут
в ее решении.

Вариант
1

1.
Априорное распределение кадровых
ресурсов проекта — это:

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

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

• предполагаемый
  состав коллектива исполнителей проекта

• план распределения
  ролей между исполнителями проекта

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

2. Противодействующий
лидер — это:

Q
тот, кто своим авторитетом заставляет
команду действовать деструктивно

• член
  коллектива, успешно оппонирующий
  принимаемым
  решениям

• лидер
  коллектива, который фактически
  препятствует
  действиям
  менеджера проекта

• достаточно
  авторитетный критик решений менеджера
  проекта

• противник
  общепринятых мнений, к которому
  прислушиваются
  в коллективе

3. Где
можно подбирать кадры для выполнения
проекта?

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

• менеджер
  может принять сотрудника со стороны
  только по
  личному
  впечатлению о нем

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

• менеджер
  может заранее знать возможных кандидатов.
  Это
  самый
  лучший вариант

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

Вариант
2

1. Ключевые
роли коллектива разработчиков — это:

2. Наличие
единственного лидера в группе, на
которого
может
положиться менеджер проекта, — это:

• одна из главных
  предпосылок формирования
  продуктивно
  работающего коллектива

• недостаток
  кадрового обеспечения проекта, поскольку
  реально
  требуется несколько
  ответственных персон

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

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

Q
возможность конфликтов с менеджером,
связанных с утверждением
лидерства

3. Чем
может помочь в подборе кадров сотрудник,
уже
принятый на ключевую роль?

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

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

• проведением
  экспертного собеседования с целью
  определения
  пригодности кандидатов
  для работы

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

Вариант
3

1. Ключевой
работник — это:

• тот, кто занимает
  в проекте ключевую роль

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

• незаменимый
  разработчик

• сотрудник,
  определяющий характер деятельности
  коллектива
  в целом

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

2. Какие
ключевые роли характеризуют наиболее
типичные
проектные
ситуации?

• архитектор проекта

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

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

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

• эксперт предметной
  области

3. График
привлечения сотрудников к проекту —
это:

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

• перечень
  кандидатов для приема на работу с
  указанием их
  условий
  и проектных возможностей эти условия
  удовлетворить

• план кадровой
  потребности проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.5. Задачи и цели процесса верификации

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

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

• требования высокого уровня правильно переработаны в архитектуру ПО и в спецификации требований к функциональным компонентам низкого уровня, которые удовлетворяют требованиям высокого уровня;

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

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

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

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

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

На выбор эффективных методов верификации и последовательность их применения в наибольшей степени влияют основные характеристики тестируемых объектов:

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

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

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

Определим некоторые понятия и определения, связанные с процессом тестирования, как составной части верификации. Майерс дает следующие определения основных терминов []:

Тестирование — процесс выполнения программы с целью обнаружения ошибки.

Тестовые данные – входы, которые используются для проверки системы.

Тестовая ситуация (testcase) – входы для проверки системы ипредполагаемые выходы в зависимости от входов, если система работает в соответствии с ее спецификацией требований.

Хорошаятестовая ситуация – та ситуация, которая обладает большой вероятностью обнаружения пока еще необнаруженной ошибки.

Удачныйтест — тест, который обнаруживает пока еще необнаруженную ошибку.

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

Отказ – непредсказуемое поведение системы, приводящее к неожидаемому результату, которое могло быть вызвано дефектами, содержащимся в ней.

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

• Проверка того, что программное обеспечение соответствует требованиям на него,

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

• Проверка программного обеспечения на предмет типичных ошибок, которые делают программисты.

1.6. Тестирование, верификация и валидация – различия в понятиях

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

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

Рис. 7 Тестирование, верификация и валидация

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

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

Если посмотреть на эти три процесса с точки зрения вопроса, на который они дают ответ, то тестирование отвечает на вопрос «Как это сделано?» или «Соответсвует ли поведение разработанной программы требованиям?», верификация – «Что сделано?» или «Соответствует ли разработанная система требованиям?», а валидация – «Сделано ли то, что нужно?» или «Соответствует ли разработанная система ожиданиям заказчика?».

1.7. Документация, создаваемая на различных этапах жизненного цикла

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

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

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

Рис. 8 Процессы и документы при разработке программных систем

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

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

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

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

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

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

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

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

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

1.8. Типы процессов тестирования и верификации и их место в различных моделях жизненного цикла

1.8.1. Модульное тестирование

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

1.8.2. Интеграционное тестирование

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

1.8.3. Системное тестирование

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

1.8.4. Нагрузочное тестирование

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

1.8.5. Формальные инспекции

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

1.9. Верификация сертифицируемого программного обеспечения

Дадим несколько определений, определяющих общую структуру процесса сертификации программного обеспечения:

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

Заявитель — организация, подающая заявку в соответствующий Сертифицирующий орган на получения сертификата (соответствия, качества, годности и т.п.) изделия.

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

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

Сертификация может быть направлена на получение сертификата соответствия, либо сертификата качества.

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

Во втором случае результатом является признание соответствия процессов разработки определенным критериям, гарантирующим соответствующий уровень качества выпускаемой продукции и его пригодности для эксплуатации в определенных условиях. Примером таких стандартов может служить серия международных стандартов качества ISO 9000:2000 (ГОСТ Р ИСО 9000-2001) [] или авиационные стандарты DO-178B [], AS9100 [], AS9006 [].

Тестирование сертифицируемого программного обеспечения имеет две взаимодополняющие цели:

• Первая цель — продемонстрировать, что программное обеспечение удовлетворяет требованиям на него.

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

Например, согласно требованиям стандарта DO-178B, для того, чтобы удовлетворить целям тестирования программного обеспечения, необходимо следующее:

• Тесты, в первую очередь, должны основываться на требованиях к программному обеспечению;

• Тесты должны разрабатываться для проверки правильности функционирования и создания условий для выявления потенциальных ошибок.

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

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

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

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

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

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

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

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

Существует 5 уровней отказных ситуаций от несущественной до критически опасной. Согласно этим уровням вводится понятие уровня критичности программного обеспечения. От уровня критичности зависит состав документации, предоставляемой в сертифицирующий орган, а значит и глубина процессов разработки и верификации системы. Например, количество типов документов и объем работ по разработке системы, необходимых для сертификации по самому низкому уровню критичности DO-178B могут отличаться на один-два порядка от количества и объемов, необходимых для сертификации по самому высокому уровню. Конкретные требования определяет стандарт, по которому планируется вести сертификацию.

Роли в команде: российский вариант

Эта статья представляет собой своеобразное продолжение дискуссии,
прошедшей в редакции журнала «Персонал-Микс», «Сотрудник: подчиненный
или партнер?» (см. «Персонал-Микс», № 1, 2003 г.). Ее участники
вышли на проблему командного взаимодействия и вспомнили концепцию, изложенную
в книге Мередита Белбина «Руководящие коллективы: почему они добиваются
успеха, почему терпят неудачи?». Русский перевод этой работы вышел в
1981 году в Москве.

Видимо, когда работа переводилась, точный смысл названия «Management
Teams. Why They Succeed or Fail» еще не был очевиден, а речь шла именно
о работе команд — сформированных групп, ориентированных на решение деловых
задач.

Елена Завьялова

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

Александра Логинова

магистрант кафедры инженерной педагогики и психологии Санкт-Петербургского
государственного политехнического университета

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

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

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

Эти восемь ролей условно (в литературе эти роли переводятся по-разному, поэтому
здесь даны их английские названия) были названы так: председатель (Сoordinator),
оформитель решений (Shaper), новичок со свежим взглядом (Plant), советник (судья)
(Monitor Evaluator), практик-организатор (Company Worker), разведчик ресурсов
(Resource Investigator), душа группы (Team Worker) и доводчик (Finisher). Краткие
характеристики всех ролей представлены в таблице 1.

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

Личностные характеристики людей, которых целесообразно включать в состав руководящих
групп (по М. Белбину)

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

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

Именно поэтому при комплектовании команды особое внимание следует уделить
подбору людей на роль председателя .

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

В начале ХХI века проблема комплектования работоспособных команд приобретает
практическую значимость и в нашей стране. Особенно это относится к малым предприятиям,
в которых весь штатный состав менеджеров, по сути, представляет собой единую
рабочую команду.

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

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

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

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

Организация «Бета» . Предприятие производит высокотехнологичное
оборудование для таких отраслей, как медицина, электротранспорт, газовая промышленность,
нефтехимия, пищевая промышленность. «Бета» зародилась более 40 лет
назад в рамках крупного промышленного объединения, самостоятельную деятельность
стала вести спустя 30 лет, в период упадка отечественного машиностроения. В
начале своей деятельности фирма активно использовала заемный капитал (Фонда
содействия малым предприятиям в научно-технической сфере), арендовала помещения
и производственные площади. Акционерный капитал фирмы распределялся между ее
менеджерами, контрольный пакет акций находится в руках генерального директора. «Бета» обладает
ноу-хау по материалам и конструкционным решениям: в России оборудование такого
класса не производится. Поскольку стоимость зарубежных аналогов на порядок
выше, позиция «Беты» в данном секторе рынка признается достаточно
устойчивой. Организация «Бета» сотрудничает с партнерами в городах
России, СНГ и Восточной Европы.

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

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

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

Очевидно, что отчасти такая «универсальность» работников — вынужденная
и связана с малочисленностью штата «Омеги».

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

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

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

Если в «Альфе» и «Бете» некоторые работники после соответствующего
тренинга могли бы играть роль председателя , то в «Омеге» даже
средний уровень баллов по этой роли был набран немногими испытуемыми.

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

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

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

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

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

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

Ролевая структура команды «Беты» наиболее пригодна для решения управленческих
проблем, стоящих перед организацией.

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

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

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

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

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

— образное мышление : преобразование информации осуществляется с помощью
действий с образами. Результатом является мысль, воплощенная в новом образе;

— знаковое мышление : преобразование информации осуществляется с помощью
умозаключений. Результатом является мысль в форме понятия или высказывания;

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

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

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

Значимые с точки зрения теории математической статистики коэффициенты приведены в
таблице 2 .

Таблица 2. Значимые корреляции признаков
№ п/п	Показатель № 1	Показатель № 2	Значение коэффициента корреляции	Уровень значимости
1	Роль I председатель	Роль IV cудья	0,453	0,05
2	Роль I председатель	Роль V практик-организатор	— 0,794	0,01
3	Роль I председатель	Предметное мышление	— 0,463	0,05
4	Роль I председатель	Символическое мышление	0,493	0,05
5	Роль II оформитель решений	Символическое мышление	— 0,450	0,05
6	Роль III новичок со свежим взглядом	Символическое мышление	0,542	0,05
7	Роль III новичок со свежим взглядом	Роль V практик-организатор	0,682	0,01
8	Роль III новичок со свежим взглядом	Роль VI душа группы	0,442	0,05
9	Роль III новичок со свежим взглядом	Роль VII разведчик ресурсов	0,555	0,05
10	Роль IV судья	Предметное мышление	0,640	0,01
11	Роль IV	Символическое мышление	0,436	0,05
12	Роль IV судья	Роль VIII доводчик	— 0,448	0,05
13	Роль V практик-организатор	Символическое мышление	— 0,465	0,05
14	Роль V практик-организатор	Роль VII разведчик ресурсов	— 0,461	0,05
15	Роль VI душа группы	Роль VII разведчик ресурсов	— 0,445	0,05
16	Роль VI душа группы	Роль VIII доводчик	— 0,537	0,05
17	Роль VII разведчик ресурсов	Экстраверсия	0,621	0,01
18	Роль VIII доводчик	Предметное мышление	0,564	0,01
19	Символическое мышление	Креативность	0,434	0,05

Из выявленных связей наибольший интерес для данного исследования представляют:
— прямая зависимость между символическим типом мышления и ролями: председателя,
новичка со свежим взглядом и судьи (советника) ; причем наиболее высокое
значение коэффициента корреляции у пары «новичок — символическое мышление» .
Кроме того, показатель «символическое мышление» связан
с показателем «креативность» . Для того чтобы играть какую-либо
из этих трех ролей в группе, необходимо обладать умением обобщать большие объемы
информации об исследуемом явлении. Способом такого обобщения для обладателя
символического типа мышления является формализация решаемой задачи в виде структур,
отображающих существенные связи между ее компонентами. Принципиально важным
для исполнителей трех названных ролей (аналитиков) является необходимость изложить
главное в доступной для всей группы форме;
— прямые связи между некоторыми ролями позволяют говорить об их сходстве —
это пары: председатель — судья и новичок со свежим взглядом -
разведчик ресурсов . Родственность второй пары ролей была отмечена выше:
и новичок, и разведчик призваны искать новые подходы к решению задач, поэтому
оба они имеют широкий круг интересов и контактов за пределами рабочей группы,
что иногда способно отвлечь их от оперативных проблем, решаемых группой;
— разведчик ресурсов обладает выраженной экстраверсией, однако роль новичка
со свежим взглядом с этим качеством не связана;
— между некоторыми ролями отмечаются обратные связи: председатель — практик-организатор,
новичок — практик-организатор, новичок — душа группы>, судья — доводчик,
практик-организатор — разведчик ресурсов, душа группы — разведчик и душа группы
— доводчик . Особенно сильная отрицательная связь — между ролями председателя
и практика-организатора ;
— для роли доводчика (завершителя) характерен предметный тип мышления.
Действительно, роль завершителя связана с овеществлением, доведением
до практической (предметной) реализации согласованных в группе задач;
— роли оформителя решений и практика-организатора отрицательно
связаны с такой характеристикой, как символическое мышление.

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

— первый кластер образован узлами: Роль III
(новичок со свежим взглядом), Роль IV (судья), Роль VII (разведчик ресурсов) , «Символическое
мышление» и «Креативность». Этому кластеру было дано условное
название «Творческий потенциал группы»: он связан с креативностью
и символическим мышлением, необходимыми для исполнения попавших в кластер ролей;

— второй кластер объединяет Роль I (председатель) и
корректурную шкалу теста Айзенка. Этот кластер можно назвать «Социальная
желательность». Высокий показатель по корректурной шкале связан с установкой
на социальную желательность роли и признания статуса председателя окружающими
людьми;

— третий кластер («Практическая реализация»)
— пара ролей: Роль VIII (доводчик) и Роль II (оформитель решений) .
Взаимосвязь этих ролей была рассмотрена выше.

Обобщая результаты исследования, можно сказать следующее:

1. Концепция «Роли в команде» и соответствующий ей опросник могут
быть применены не только в целях определения ролевой структуры, но и быть использованы
как инструмент анализа эффективности деятельности организации.

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

3. Психологическое содержание ролей, полученное на примере российских предприятий,
несколько отличается от описания, представленного М. Белбиным:

— акцент в роли председателя в большей мере делается на интеллектуально-аналитические,
чем на коммуникативные способности. Эта роль сближается с ролью судьи ;

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

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

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

Литература:

1. Белбин М. «Руководящие коллективы: почему они добиваются успеха, почему
терпят неудачи?» Москва, 1981.

2. Роли в команде. Пер. с англ. Н. Жаворонковой, И. Семенова. 1996, www.laser.ru

3. Самыгин С.И., Столяренко Л.Д. Психология управления. Ростов-на-Дону: издательство «Феникс»,
1997.

4. Цзе К.К. Методы эффективной торговли. Москва: издательство «Экономика»,
1988.

9 типов ролей в команде

Роли в команде делятся на 3 категории:

• активные роли, ориентированные на действия, которые включают в себя роли форматора (генератора идей), реализатора и завершителя/финишера;
• роли, ориентированные на работу с людьми, включающие в себя роли координатора, командного игрока и исследователя ресурсов;
• роли, ориентированные на мышление, которые включают в себя роли «тайного информатора», эксперта по мониторингу и специалиста.  

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

Роль форматора («генератора идей»)

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

Роль реализатора

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

Роль завершителя/финишера

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

Роль координатора

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

Роль командного игрока

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

Роль исследователя ресурсов

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

Роль эксперта по мониторингу

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

Роль специалиста

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

Благодаря экспертным знаниям, они являются незаменимыми членами команды.

Роль «тайного информатора»

«Тайные информаторы» являются инноваторами в команде. Они демонстрируют оригинальные подходы и идеи, что помогает команде в решении проблем и преодолении препятствий.  «Тайные информаторы» являются интровертами по своей природе и обладают плохими навыками общения. Они предпочитают работать в одиночку. Они хорошо воспринимают похвалу в свою сторону, но сильно поддаются негативной критике.

smallbusiness.chron.com/nine-types-team-roles-15566.html

 

Реферат Функциональные роли 📝 в коллективе разработчиков Информатика

1. Сколько стоит помощь?

Цена, как известно, зависит от объёма, сложности и срочности. Особенностью «Всё сдал!» является то, что все заказчики работают со экспертами напрямую (без посредников). Поэтому цены в 2-3 раза ниже.

2. Каковы сроки?

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

3. Выполняете ли вы срочные заказы?

Да, у нас большой опыт выполнения срочных заказов.

4. Если потребуется доработка или дополнительная консультация, это бесплатно?

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

5. Я разместил заказ. Могу ли я не платить, если меня не устроит стоимость?

Да, конечно — оценка стоимости бесплатна и ни к чему вас не обязывает.

6. Каким способом можно произвести оплату?

Работу можно оплатить множеством способом: картой Visa / MasterCard, с баланса мобильного, в терминале, в салонах Евросеть / Связной, через Сбербанк и т.д.

7. Предоставляете ли вы гарантии на услуги?

На все виды услуг мы даем гарантию. Если эксперт не справится — мы вернём 100% суммы.

8. Какой у вас режим работы?

Мы принимаем заявки 7 дней в неделю, 24 часа в сутки.

Вопросы для проверки

Вариант
1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вариант
2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вариант
3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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