Организация работы в команде

Вопросы семинара 1 "Организация работы в команде":

• Причины создания команды
• Принципы объединения ролей
• Процесс управления рисками (практический пример)

Причины создания команды

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

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

Осознавая эту потребность, компания Microsoft представила новейший пакет инструментальных средств - Microsoft Visual Studio Team System, который является инструментальным воплощением методологии MSF. Данный пакет тесно интегрирован с другими программными продуктами этой компании, такими как Microsoft Office, Windows SharePoint и др.

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

Принципы объединения ролей

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

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

Процесс управления рисками

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

Пример:

Основные сведения о рисках

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

Стадии процесса управления рисками

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

Планирование рисков (risk planning) выполняется исходя из информации, полученной на этапе их анализа, и имеет своей целью выработку стратегий, планов и конкретных шагов. Календарное планирование рисков (risk scheduling) интегрирует эти планы в повседневный процесс управления проектом, обеспечивая непрерывность управления рисками. Эта стадия напрямую увязывает планирование рисков с планированием проекта в целом.

Мониторинг рисков (risk tracking) выполняется для наблюдения за конкретными рисками и прогрессом в осуществлении составленных планов. Мониторингу должны быть подвергнуты сделанные оценки вероятности (probability) риска, его угрозы (impact), ожидаемая величина риска (exposure) и прочие факторы, способные повлиять на приоритет рисков. Наблюдению подвергаются также составленные планы, имеющиеся ресурсы и принятый календарный график. Мониторинг рисков обеспечивает прозрачность процесса управления рисками проекта на различных уровнях в дополнение к стандартному процессу управления проектом, отслеживающему степень завершенности проектных задач. Отчетность о рисках (risk reporting) обеспечивает информирование проектной группы, спонсоров и других заинтересованных сторон о состоянии рисков проекта и планов по управлению ими.

Корректирование ситуации (risk control) представляет собой процесс исполнения принятых в отношении рисков планов и контроля за ходом их исполнения. Этот процесс также включает в себя инициирование изменений всего проекта (project change control requests), если изменения в состоянии рисков либо в соответствующих планах влияют на прогнозируемый объем работы, требуемые ресурсы или сроки.

Извлечение уроков (risk learning) формализует процесс усвоения накопленного за время работы над проектом опыта в форме, доступной для использования как внутри проектной группы, так и на уровне всего предприятия.

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

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

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

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

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

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

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

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

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

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

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

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

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

Мероприятия по предотвращению рисков

1. Не успеем сдать проект во время
   • Создание максимально детализированного плана-графика проекта;
   • Стимулирование каждого члена команды выполнять свои действия в срок;
   • Тестирование: на каждом этапе разработки проекта должно производиться тестирования, для уменьшения вероятностей возникновения ошибок.
2. Не хватит квалификации персонала
   • Предварительное введение в курс дела;
   • Предоставление списка тематических материалов разработчикам до начала проекта;
3. Один из членов команды заболеет
   • Является форс-мажорным обстоятельством и его предотвращение невозможно.
4. Отключение электричества
   • Предусмотрена система резервного копирования на случай потери данных.

Мероприятия смягчению последствий рисков

1. Не успеем сдать вовремя проект
   • Доработка проекта произведется на следующей итерации;
   • Устранение выявленных замечаний и недоработок в следующей версии продукта.
2. Не хватит квалификации персонала
   • Формирование тематического пакета документов по работе с новым технологиям разработки и освоение его разработчиками.
3. Один из членов команды заболеет
   • Распределение его обязанностей на время его отсутствия между остальными членами команды согласно рекомендациям по совмещению ролей MSF.
4. Отключение электричества
   • Перенесение пропавшего рабочего дня/дней на другие или увеличения рабочего времени в день.

Использованные источники

Microsoft Solutions Framework White Papers. [Электронный ресурс]. – http://www.microsoft.com/technet/solutionaccelerators/msf/default.mspx/, свободный.