4.Размер групп и масштаб проекта
В проектной группе за каждое направление должен отвечать как минимум один человек. При реализации крупного проекта возникает затруднение, связанное с эффективным обменом информацией. В небольших организациях или при работе над мелкими проектами роли можно совмещать.
Крупные проекты: чтобы справиться с крупным проектом, приходится делить проектную группу на тематические и функциональные подгруппы.
Тематические группы Это небольшие подгруппы из одного или нескольких человек, роли которых различны. Каждой из таких групп выделяется некий набор функциональных возможностей приложения, за все стороны проектирования и разработки которого она и отвечает (включая составление проекта и графика реализации).
Достоинства тематических групп — эффективность, сбалансированность и ответственность.
Функциональные группы ---формируются в рамках одной роли. Они нужны в очень крупных проектных группах или при работе над крупномасштабными проектами, когда отдельные роли нуждаются в дополнительном подразделении. Например, в Microsoft отдел менеджмента продукта обычно состоит из групп планирования и маркетинга. Обе они занимаются менеджментом продукта, но первая отвечает за определение действительно необходимых заказчику функций приложения, а вторая — за информирование потенциальных клиентов о достоинствах продукта.
Приведем еще один пример. Иногда группу разработчиков требуется разделить на три подгруппы, каждая из которых занимается одним уровнем архитектуры (пользовательским, прикладным или уровнем данных). Довольно часто в крупных отделах разработки группу программистов подразделяют на группу решений и компонентную группу. Первые создают собственно приложение, «склеивая* вместе его компоненты, разработанные вторыми. Кстати, это разделение часто оказывается и разделением по языкам программирования: разработчики решений, как правило, работают с языками, позволяющими быстро собирать приложения из готовых компонентов, тогда как выбор языка для разработки повторно используемых компонентов, пригодных для многих проектов, определяется прежде всего соображениями эффективности.
Небольшие проекты
Хотя в модели группы разработчиков предусмотрено шесть направлений деятельности, необязательно включать в проектную группу шесть человек. Другими словами, некоторые должности можно совмещать. Конечно, основной смысл такого разделения в том, чтобы
каждую из шести задач решал один из членов группы. Однако не во всех проектах это возможно.
В небольших группах один человек может играть несколько ролей. При этом мы рекомендуем соблюдать следующие принципы разделения должностей.
• Нельзя совмещать разработку с другими видами деятельности — создателей приложения не стоит отвлекать от основной задачи.
• Конфликт интересов — нельзя совмещать роли, интересы которых
противоположны. Пример — менеджер продукта и менеджер программы. Первый хочет выполнить все требования заказчика, второму же надо уложиться в график и бюджет.
назначение на эти роли разных людей позволяет соблюсти интересы всех участников проекта.
На рис.показаны комбинации ролей, оказывающие позитивное и негативное влияние на проект. Роли, отмеченные буквой «3»— Запрещено— нельзя совмещать из-за конфликтов интересов. Вероятность совмещения ролей, отмеченных буквой «Н» — Нежелательно —мала из-за сильного различия в необходимой квалификации. Напри-
мер, знания и опыт менеджера продукта и логистика сильно отличаются. Сочетания ролей, помеченные буквой «Д» — Допустимо — возможны, так как их интересы совпадают. Например, как тестеры, так и инструкторы отвечают за выполнение требований пользователей.
В некоторых проектных группах возможно успешное совмещение ролей, комбинация которых согласно нашей таблице опасна. Главное — помнить цели каждого направления и контролировать совмещение должностей в соответствии с ними, предотвращая конфликты. В противном случае некоторые обязанности какой-то роли будут не выполнены, что увеличивает число неконтролируемых рисков.
- 2. Модель па
- 2.1.Бизнес - перспектива
- 2.2.Прикладная перспектива
- 2.3.Информационная перспектива
- 2.4.Технологическая перспектива
- 2.5 Основные опасности при разработке производственной архитектуры
- 2.6 Задачи модели производственной архитектуры msf
- 3. Создание производственной архитектуры
- 1. Общая характеристика модели приложения
- 1.1.Повторное использование компонентов
- 1.2.Размер приложения
- 1.3. Производительность приложения
- 1.4.Масштабируемость приложений
- 1.5.Виды архитектуры
- 2. Модель приложений
- 2.1. Бизнес-модель
- 2.2 Пользовательская модель
- 2.3 Логическая модель
- 2.4 Технологическая модель
- 2.5 Модель разработки
- 2.6 Физическая модель
- 1. Общие характеристики модели проектных групп
- 2. Обязанности членов группы
- 3. Модель проектой группы
- 3.1. Менеджер продукта
- 3.2Менеджер программы
- 3.3.Разработчик
- 3.4 Тестер
- 3.5.Инструктор
- 3.6 .Логистик
- 4.Размер групп и масштаб проекта
- 5. Создание группы
- 5.1.Поиск руководителей
- 5.2.Повышение эффективности коллективной работы
- 5.3. Координация работы с внешними группами
- 1. Модель разработки приложений
- 2.Модель процесса разработки msf
- Основные этапы
- Промежуточные этапы
- Итеративность
- 3. Фазы разработки и их основные этапы.
- 3.1 Фаза Анализ
- 3.3.Фаза «Планирование»
- 3.3.Фаза «Разработка»
- 3.4. Фаза «Стабилизация»
- 4. Принципы модели процесса разработки
- 5.Роли членов группы в модели процесса разработки
- Динамика фазы Анализ модели процесса разработки msf
- 1.Процесс исследования
- 1.1.Распределение обязанностей ролей
- 2. Модель управление рисками
- 2.1.Источники риска
- 2.2.Способы управления рисками
- 3.Этап «Одобрение концепции» и его результаты
- 3.1Концепция
- 3.2.Прототип
- 3.3. Структура проекта
- 3.4. Сводный документ оценки рисков
- 3.5. Согласование концепции
- Динамика фазы планирования
- 1.Общая характеристика фазы планирования
- Фаза «Планирование» и процесс проектирования
- Распределение ролей при планировании
- Обязанности ролей при планировании
- 12.Процесс проектирования
- 2.1. Стадии концептуального проектирования
- 2.2.Стадия логического проектирования
- 2.3.Стадия физического проектирования
- 2.1. Управление рисками на фазе планирования
- 4.Этап «Одобрение плана проекта» и его результаты
- 4.1.Функциональные спецификации
- 4.2.Основной план проекта
- 4.2.Основной график проекта
- 4.3.Пересмотренный документ оценки рисков
- Динамика фазы разработки и ее основные результаты.
- 1. Общая характеристика фазы разработки
- 2. Основные этапы разработки
- 2.1.Распределение обязанностей на стадии разработки
- 2.3.Первый этап: анализ и рационализация
- 2.4.Второй этап: реализация
- 2.5.Третий этап: аттестация
- 2.6.Управление рисками
- 3.Этап «Завершение разработки» и его результаты
- 3.1. Код и исполняемые модули
- 3.2.Средства повышения эффективности работы пользователей и сопроводительные материалы
- 3.3. Тестовые материалы
- Динамика фазы стабилизации
- Распределение обязанностей в группе
- Промежуточные этапы
- Управление рисками на фазе Стабилизации
- 1)Организованные риски;
- Этап «Выпуск продукта» и его результаты