Цифровые технологии копирования.. Урок. Урок 60. Тема урока. Обязанности членов бригады

• Название: Урок 60. Тема урока. Обязанности членов бригады
• Анкор: Цифровые технологии копирования
• Дата: 08.10.2020
• Размер: 142.83 Kb.
• Имя файла: Урок.docx
• Тип: Урок; #141772

Дисциплина ПРОЕКТИРОВАНИЕ И ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Урок 60. Тема урока. Обязанности членов бригады.

1. Функции, роли и должности

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

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

В модели предусматриваются следующие основные функции.

Администрирование. Внешнее: ведение договоров; разговоры с заказчиком; составление внешних (полу)формальных документов. Внутреннее: доклады начальству; столы, стулья, компьютеры.

Проектирование. Составление бумажных и/или электронных человеко- и/или машинно- читаемых концепций, моделей, спецификаций и планов.

Замечание по конструированию

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

Кодирование. Ручная и/или полуавтоматическая генерация кода на языке программирования. Автономная (поблочная) отладка кода. Рисование и тестирование интерфейсных эле- ментов (форм).

Замечание по конструированию

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

Тестирование. Пробное использование приложения с целью сломать его, а не решить задачу.

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

Замечание по конструированию

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

2. 
   
   Роль³⁰— это временное назначение сотруднику набора функций в рамках конкретного проекта.
   Роли

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

Аналитик. Функции: планирование, администрирование. Вехи: Концепция, Обследование, Техническое задание, Функциональные спецификации, Внутренний язык, Дополнительные требования, План тестирования, План внедрения, Логический проект, Схема базы данных, Документация.

Замечание по конструированию

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

Администратор. Функции: администрирование, планирование. Вехи: Техническое задание, Календарный план-график, План тестирования, План внедрения, Документация.

Программист. Функции: проектирование, кодирование, тестирование, сопровождение. Вехи: Прототип, Логический проект, Схема базы данных, Дизайн интерфейса, Физический проект, Код готов, Нет известных ошибок, Исходные тексты, Документация.

Тестировщик. Функции: тестирование. Вехи: Выпуск, Нет известных ошибок, Исходные тексты, Документация.

Эксплуатационник. Функции: сопровождение, тестирование. Вехи: Документация, Решение развернуто, База данных загружена, Пользователи обучены.

Замечание по конструированию

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


Перечисленный список ролей может быть расширен в соответствии со спецификой проекта.

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

Таблица 5. Соотношение фаз, ролей и функций

Состояние приложения	Роль	Выполняемые функции
Еще не существует	Аналитик	Анализ (существующей ситуации) и Проектиро- вание (будущего приложения)
Находится в процессе разработки	Программист	Кодирование (в широком смысле )
Уже существует	Тестировщик / Эксплуатационник	Тестирование (проверка работоспособности и других характеристик приложения), Развертыва- ние, Документирование (и другие действия с имеющимся приложением)

Замечание по конструированию

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

Замечание по конструированию

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

3. 
   
   Должность — это сертифицированная способность играть определенные роли и выпол- нять определенные функции.
   Должности

Замечание по конструированию

Порядок определения должностного соответствия (или несоответствия) и назначения на должность моделью команды не охватывается.

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

Начальник (отдела).

Руководитель (группы).

Исполнитель (инженер, технический специалист).

Замечание по конструированию

Наличие именно трех уровней иерархии должностей обусловлено ограничением на масшта- бируемость: 10-50 человек и наличием известной константы, ограничивающей ширину ветв- ления в дереве субординации: 72. Т.е. в иерархической структуре руководитель любого уровня должен иметь не менее 5 и не более 9 прямых подчиненных.

Замечание по конструированию

Высшее руководство (дирекция) моделью команды не охватывается.

2. 
   Статико-динамическая структура команды
   

Конструируемая модель команды предусматривает назначение каждому участнику проекта функции, роли и должности, причем это назначение не является постоянным, а меняется со временем по определенным правилам:

• 
  функция (функции) назначается динамически на каждую фазу,
  
• 
  роль (роли) назначается статически на время проекта
  
• 
  должность назначается статически, т.е. постоянно.
  

Замечание по конструированию

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

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


Замечание по конструированию

Изобразить на одной диаграмме статико-динамическую структуру модели команды оказы- вается затруднительным. Поэтому ниже приведены примеры трех указанных структур для некоторого условного проекта. В приведенных на рис. 33-35 диаграммах латинские буквы A, B, C… обозначают конкретных людей, одних и тех же на всех диаграммах. Таким образом, из примеров видно, как может меняться функция и роль конкретного человека по ходу про- екта.

1. Должностная структура

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

Должностная структура (дерево)

A Начальник отдела

B Руководитель группы

C Руководитель группы

D Руководитель группы

E Инженер

F Инженер

G Инженер

H Инженер

I Инженер

J Инженер

Рис. 33. Пример должностной структуры

2. Руководитель проекта

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

Замечание по конструированию

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

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

Организационный порядок назначения Руководителя проекта описан в разделе Порядок проведения типового проекта.

3. Бригада проекта

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

Рис. 34. Пример бригады проекта

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

4. Команда фазы

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

A Календарный план-график			C Функциональные спецификации
D План внедрения			G Притотип интерфейса

Рис. 35. Пример команды фазы

Замечание по конструированию

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

3. 
   Распределение полномочий и ответственностиРаспределение полномочий и ответственности в модели команды имеет статико- динамический характер.
   

Руководитель проекта назначается руководством организации. Процедура назначения

описана в разделе Порядок проведения типового проекта.

Замечание по конструированию

Смена Руководителя проекта в ходе проекта является чрезвычайным событием и не реко- мендуется моделью команды.

Бригада проекта назначается по представлению Руководителя проекта и утверждается руководством организации.

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

Замечание по конструированию

Согласование по транзитивности (т.е. только со старшим начальником, а не с непосредст- венным начальником) не рекомендуется моделью команды.

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

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

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

Моральное и материальное стимулирование (как поощрение, так и наказание) производится руководством организации по результатам законченного проекта по представлению Руководителя проекта.

4. Достоинства и недостатки модели команды

Предлагаемая модель команды имеет следующие преимущества.

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

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

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

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

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

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

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

Вопросы для самоконтроля

Какие достоинства и недостатки модели команды бывают?

Кто отвечает за материально-техническое, финансовое и организационную проекта?

Команда фазы строится по модели?

Узкий специалист где может быть задействован?

Что такое Роль?

Функция — это вид?

Перечислите список ролей?