1 Process patterns для географически распределенных команд Владимир Л Павлов Андрей A Терехов

2 Process patterns для географически распределенных команд Введение Организационные шаблоны (паттерны) Шаблоны (паттерны) процессов Шаблоны (паттерны) организационных изменений

3 Об авторах Владимир Л Павлов (Intel, Россия) Директор по аутсорсингу и поддержке процессов разработки ПО Директор по аутсорсингу и поддержке процессов разработки ПО Microsoft Endorsed MSF Practitioner, MCSD for.NET, MCSD, MCDBA, MCT, CompTIA Certified IT Project+ Microsoft Endorsed MSF Practitioner, MCSD for.NET, MCSD, MCDBA, MCT, CompTIA Certified IT Project+ Член PMI, ACM, IEEE и IEEE Computer Society Член PMI, ACM, IEEE и IEEE Computer Society Андрей A Терехов (Microsoft, Россия) Менеджер академических программ Менеджер академических программ К.ф.-м.н. К.ф.-м.н. Microsoft Endorsed MSF Practitioner, MCSD, (ex-)MCT, IEEE Certified Software Development Professional Microsoft Endorsed MSF Practitioner, MCSD, (ex-)MCT, IEEE Certified Software Development Professional Член ACM, IEEE и IEEE Computer Society Член ACM, IEEE и IEEE Computer Society Данный доклад базируется на опыте, приобретенном авторами до их присоединения к Intel/Microsoft, в период, когда авторы являлись руководителями крупных российских/украинских аутсорсинговых компаний

4 Intel в 2003 году 35 лет (основан в 1968) 78,000 сотрудников, 294 офисов в 48 странах Более 450 продуктов и услуг Оборот $30.1 млрд. Чистый доход $5.6 млрд. Инвестиции в исследования и разработку $4.4 млрд. Центры исследований и разработки расположены по всему миру

5 Microsoft в 2003 году 29 лет (основан в 1975) 55,000 сотрудников, 89 дочерних компаний Оборот $32.2 млрд. Чистый доход $10 млрд. Инвестиции в исследования: $5.2 млрд. Как правило, вся разработка осуществляется в главном кампусе в Редмонде, США

6 Что такое Шаблон процесса? Шаблон (pattern) – описание обобщенного решения, применимого к некоторому классу проблем, на основе которого может быть сформулировано конкретное решение частной задачи Шаблон процесса (process pattern) – специфический шаблон, созданный, применяемый или определенный в терминах инженерии процессов разработки программного обеспечения (ПО) Инженерия процессов разработки ПО (process engineering) – область знаний, связанная с определением, осуществлением, оценкой, нормированием, управлением, изменением и совершенствованием процессов разработки программного обеспечения

7 В качестве иллюстрации мы будем использовать MSF В данном докладе рассказ будет вестись на примере MSF. Мы предполагаем, что слушатели знакомы хотя бы с одной из распространенных методологий (MSF, RUP, CDM и т.д.), но не обязательно владеют именно MSF Microsoft Solutions Framework - используемый внутри Microsoft подход к управлению IT-проектами Сегодня Microsoft практически никак не рекламирует MSF, являющийся основой ее успеха. Софтверный гигант зарабатывает деньги не продавая этот продукт, а ИСПОЛЬЗУЯ его Первоначальная версия MSF увидела свет в 1994 г.; в 2002 г. была опубликована последняя версия MSF (v3.0). MSF взрослеет подобно другим продуктам Microsoft. Windows XP намного более зрелый продукт, чем Windows 95, аналогичная тенденция наблюдается и для MSF Все материалы по MSF открыты для широкого доступа. Кроме того, желающие внедрить MSF на своем предприятии могут бесплатно получить комплект шаблонов для всех документов, используемых в MSF-проектах.

8 СНГЕвропа / США Компания – разработчик Офис разработки Компания – посредник Главный офис Клиент Для различных аутсорсинговых моделей могут требоваться различные схемы адаптации методологий разработки ПО компанией-разработчиком предоставляется УСЛУГА клиент получает ПРОДУКТ либо услугу Типичные модели аутсорсинга

9 Сколько между нами границ? СНГЕвропа / США Компания в СНГ Компания в США/Европе Клиент языковый барьер различные часовые пояса культурные отличия

10 Сосредоточенная разработка Стратегия Организационная структура Бизнес процессы

11 Распределенная разработка СНГ США/Европа Как распределить/переделать стратегию, организационную структуру и бизнес процессы?

12 Process patterns для географически распределенных команд Введение Организационные шаблоны (паттерны) Шаблоны (паттерны) процессов Шаблоны (паттерны) организационных изменений

13 Типичные модели аутсорсинга СНГЕвропа / США Компания – разработчик Офис разработки Компания – посредник Главный офис Клиент Для различных аутсорсинговых моделей могут требоваться различные схемы адаптации методологий разработки ПО компанией-разработчиком предоставляется УСЛУГА клиент получает ПРОДУКТ либо услугу

14 Software outsourcing: игра в испорченный телефон СНГЕвропа / США Технические специалисты Специалисты в предметной области Клиент Когда программист разговаривает с менеджером или специалистом в предметной области, нередко происходит потеря или искажение важной информации Когда два человека из разных стран (разных культур) ведут разговор по телефону через океан, нередко происходит потеря или искажение важной информации Что случается, когда программист общается по телефону со специалистом-предметником из другой страны?

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

16 Модель проектной группы MSF для аутсорсинговых проектов Европа / США Разработка Тестирование Управление программой Управление выпуском Удовлетворение потребителя Управление продуктом СНГ

17 Наше решение: в распределенных командах основные проектные роли должны быть представлены во всех подгруппах СНГ США / Европа Управление программой Разработка Тестирование Удовлетворение пользователя Управление продуктом Управление программой Разработка Тестирование Управление выпуском Удовлетворение пользователя Управление продуктом Управление выпуском

18 Проектная группа MSF как матричная организация Проектная группа MSF организованна как команда равных (команда соратников). В этой модели роль Управление программой является не столько руководящей, скольконаправляющей. По существу, проектная группа MSF структурирована подобно тому, что называется в PMBOK Матричной организацией. Это кросс-функциональные группы, которые объединяют в себе профессионалов из различных областей (из различных подразделений организации), собранных в одну проектную команду Проектная группа MSF, будучи командой равных, наиболее близка к слабой матричной организации в ее чистой форме, описанной в PMBOK. Здесь слабый означает уровень влияния менеджера проекта на принятие решений, а не качество или способности группы Из Microsoft whitepaper MSF and the Project Management Body of Knowledge

19 Организационный тип Характеристики проекта Полномочия менеджера проекта % сотрудников, работающих на полную ставку Роль менеджера проекта Общие названия для полномочий роли МП Функциональный Матричный Сильно матричный Проектный Административный штат проекта Низкие или отсутствуют нет Part-time Координатор проекта/ Лидер проекта Part-time Ограниченные 0-25% Part-time Координатор проекта/ Лидер проекта Менеджер проекта/ Сотрудник проекта Слабо матричный Сбалансированно матричный Умеренно низкие Умеренно высокие Высокие, тотальные 15-60%50-95%85-100% Full-time Менеджер проекта/ Менеджер программы Менеджер проекта/ Менеджер программы Part-timeFull-time PMI PMBOK Матричные организации

20 Функциональная организация Исполнительный директор Функциональный менеджер Функциональный менеджер Функциональный менеджер Штат Координация проекта

21 Проектная организация Исполнительный директор Менеджер проекта Менеджер проекта Менеджер проекта Штат Координация проекта

22 Слабая матричная организация Исполнительный директор Функциональный менеджер Функциональный менеджер Функциональный менеджер Штат Координация проекта

23 Сбалансированная матричная организация Исполнительный директор Функциональный менеджер Функциональный менеджер Функциональный менеджер Штат Менеджер проекта Координация проекта

24 Сильная матричная организация Исполнительный директор Главный менеджер проекта Функциональный менеджер Функциональный менеджер Менеджер проекта Штат Менеджер проекта Штат Менеджер проекта Штат Координация проекта

25 Наше решение: МиниМаксный подход к управлению географически распределенными матричными организациями Если матричная организация географически расположена во множестве офисов/стран/часовых поясов То она становится трехмерной матрицей То она становится трехмерной матрицей Каждая функция должна быть представлена в максимально возможном числе офисов В случае оффшорной разработки некоторые из функции не имеют смысла для некоторых из офисов В случае оффшорной разработки некоторые из функции не имеют смысла для некоторых из офисов Каждый проект должен быть размещен в наименьшем возможном числе офисов Это обобщение известного метода, называемого коллокация (collocation) проектной команды Это обобщение известного метода, называемого коллокация (collocation) проектной команды В случае оффшорной разработки каждый проект будет осуществляться как минимум в двух офисах В случае оффшорной разработки каждый проект будет осуществляться как минимум в двух офисах

26 Process patterns для географически распределенных команд Введение Организационные шаблоны (паттерны) Шаблоны (паттерны) процессов Шаблоны (паттерны) организационных изменений

27 Дисциплина управления рисками MSF Формулировка риска База знаний о рисках Список рисков Главные риски Анализ и приоритезация Планирование Мониторинг Коррекция Извлечение уроков Выявление

28 Управление рисками аутсорсинговых проектов СНГ Европа / США Формулиро вка риска База знаний о рисках Список рисков Главн ые риски Анализ и приорит езация Планиро вание Монит оринг Коррекция Извле чение уроко в Выявление Формулиро вка риска База знаний о рисках Список рисков Главн ые риски Анализ и приорит езация Планиро вание Монит оринг Коррекция Извле чение уроко в Выявление

29 Наше решение: один сквозной процесс управления рисками для всех подгрупп / офисов СНГ Европа / США Формулировка риска База знаний о рисках Список рисков Главные риски Анализ и приоритезация Планирование Мониторинг Коррекция Извлечение уроков Выявление

30 IBM Rational Unified Process Общий менеджмент Окружение Бизнес-моделирование Реализация Тестирование Анализ и проектирование Подготовит. итерации Шаг. #1 Стадии Дисциплины Итерации Шаг. #2 Шаг. #n Шаг. #n+1 Шаг. #n+2 Шаг. #m Шаг. #m+1 Развертывание Управление конфигурациями Требования РазработкаВнедрениеНачалоКонструирование

31 Дисциплины IBM RUP для аутсорсинговых проектов СНГ Европа / США

32 Наше решение: все дисциплины важны для каждой подгруппы СНГ США / Европа РазработкаВнедрениеНачалоКонструирование

33 Постмортем проекта СНГ Европа / США Постмортем Постомортем – это процедура, посредством которой команда проекта подводит итоги проекта и анализурует все его позитивные и негативные аспекты. Целью постмортема является извлечение уроков из предыдущего опыта для повышения эффективности при выполнении последующих проектов Постмортем

34 Наше решение: сквозной постмортем для всех заинтересованных сторон СНГ Европа / США П О С Т М О Р Т Е М К сожалению, это не является общепринятой практикой в оффшорных аутсорсинговых проектах Постмортем

35 Один из шаблонов проектирования GRASP: Полиморфизм Проблема: Как организовать зависящее от типа альтернативное поведение? Как обеспечить расширяемость компонент? Как организовать зависящее от типа альтернативное поведение? Как обеспечить расширяемость компонент? Решение: Если поведение объектов должно зависеть от их типа, необходимо задействовать механизм полиморфизма Если поведение объектов должно зависеть от их типа, необходимо задействовать механизм полиморфизма Плюсы: Легко обеспечивается расширяемость Легко обеспечивается расширяемость Новые реализации могут внедряться без ущерба для клиентов Новые реализации могут внедряться без ущерба для клиентов Минусы: Не всегда легко правильно оценить спектр будущих вариаций (расширений) Не всегда легко правильно оценить спектр будущих вариаций (расширений) Дополнительные усилия на проектирование Дополнительные усилия на проектирование

36 Наше решение: наследование уменьшает бюрократизацию Традиционный подход Наш подход Итого: 64 страницы Итого: 34 страницы Стандарт кодирования на Java Стандарт кодирования на C++ Стандарт кодирования на С Общий стандарт кодирования Стандарт кодирования на Java Стандарт кодирования на C++ Стандарт кодирования на С

37 Офис в США/Европе Открытые источники Офис в СНГ Наше решение: используйте наследование при построении своей архитектуры процессов СНГСША / Европа Норматив Регламент Инструкция Стандарт Норматив Регламент Норматив Инструкция СтандартНорматив

38 Process patterns для географически распределенных команд Введение Организационные шаблоны (паттерны) Шаблоны (паттерны) процессов Шаблоны (паттерны) организационных изменений

39 Больший объем работы, больше ресурсов… Объем работы, выполняемой компанией Размер компании / ресурсы Большинство компаний в этой области

40 Несколько слов о продуктивности… Продуктивность сотрудников Количество сотрудников Большинство компаний в этой области

41 Шаблоны (паттерны) организационных изменений Шаблоны организационных изменений описывают процессы, характерные для периода быстрого роста/расширения компании Например: Если размер компании превышает 3-5 человек, то появляется формальная иерархия команды Если размер компании превышает 3-5 человек, то появляется формальная иерархия команды Если размер компании превышает человек, то становится необходимой делегация полномочий от исполнительного директора к менеджерам среднего звена Если размер компании превышает человек, то становится необходимой делегация полномочий от исполнительного директора к менеджерам среднего звена Если размер компании превышает человек, то возникает потребность в формализации бизнес-процессов и построении системы управления качеством Если размер компании превышает человек, то возникает потребность в формализации бизнес-процессов и построении системы управления качеством Напоминаем, что в данном докладе мы рассматриваем компании, занимающиеся созданием программного обеспечения ;-))

42 Дисциплина управления подготовкой MSF Определение Знания, умения, способности Корректировк а Оценивание Осмыслени е

43 Наше решение: интегрированный процесс управления подготовкой, эффективностью и развитием Определение Корпоратив ная база данных Корректировк а Оценивание Осмысление Планировани е

44 Заключение МиниМаксный подход позволяет эффективнее организовать работу географически распределенных матричных организаций Все функции должны быть представлены в каждом офисе Все функции должны быть представлены в каждом офисе Каждая дисциплина (группа процессов) должна быть распространена на все офисы/подгруппы один сквозной процесс управления рисками для всех подгрупп один сквозной процесс управления рисками для всех подгрупп Крайне важен сквозной постмортем с вовлечением всех заинтересованных сторон Использование наследования при построении архитектуры процессов позволяет уменьшить бюрократизацию Управление подготовкой, эффективностью, развитием должно быть интегрированным

45 См. также Шаблоны процессов (English) (English) (English) (English) Microsoft Solutions Framework (English) (English) (Russian) (Russian) IBM Rational Unified Process (English) (English) PMI PMBOK – Свод знаний по управлению проектами (Project Management Body Of Knowledge) ?itemID=110&varID=1 (English) ?itemID=110&varID=1 (English) ?itemID=110&varID=1 ?itemID=110&varID=1 (English) (English)

46 См. также В. Павлов, А.Терехов Особенности использования современных методологий управления ИТ-проектами в работе географически распределенных команд (English) (English) (русский) (русский) Д.Маленко, В.Павлов Process Patterns, основанные на MSF (English) (English) В.Павлов, А.Терехов Как готовить ИТ-менеджеров ? (русский) В. Кияев, А.Терехов "О сертификации российской компании, производящей программное обеспечение (English) (English) (русский) (русский) В. Кияев, И. Соболев, А.А. Терехов, Б. Федотов Формализация и автоматизация распределенного процесса разработки программного обеспечения В. Кияев, И. Соболев, А.А. Терехов, Б. Федотов Формализация и автоматизация распределенного процесса разработки программного обеспечения (English) (English) (русский) (русский)

47 Благодарности: Александр Зверинцев (NOKIA, Польша) Александр Жуйков (ISD, Украина) Андрей Филев (Murano Software, США/Россия) Андрей Низовский (Waveaccess, Россия) Анна Тиунова (Lanit-Tercom, Россия) Ирина Мозговая (ДНУ, Украина) Никита Бойко (ISD, Украина) Сергей Алпаев (ISD, Украина) Сергей Горяинов (Berest, Украина) Сергей Трошин (Lanit-Tercom, Россия) Симон Молдавский (UkrSoftPro, Украина) Виктор Чурилов (ISD, Украина) Владимир Уфнаровский (Lanit-Tercom, Россия) Юрий Губанов (Lanit-Tercom, Россия) Юрий Ус (SCC, США)

48 Данную презентацию можно загрузить с сайтов Вопросы?

49 Доклад был сделан на Четвертом международном форумеВозможности России по экспорту продуктов и услуг в области разработки программного обеспечения (ROSS 2004) Санкт-Петербург 10 Июня 2004