Размер групп и масштаб проекта

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

Логистик

Инструктор

Прочие обязанности

Некоторые важные обязанности тестеров часто упускают из вид. К ним относятся:

уведомление об ошибках и их отслеживание, сборка продукта, выявление и контроль рисков 0

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

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

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

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

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

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

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

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

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

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

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

Достоинства тематических групп — эффективность, сбалансированность и ответственность.

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

Приведем еще один пример. Иногда группу разработчиков требуется разделить на три подгруппы, каждая из которых занимается одним уровнем архитектуры (пользовательским, прикладным или уровнем данных). Довольно часто в крупных отделах разработки группу программистов подразделяют на группу решений и компонентную группу. Первые создают собственно приложение, «склеивая* вместе его компоненты, разработанные вторыми. Кстати, это разделение часто оказывается и разделением по языкам программирования: разработчики решений, как правило, работают с языками, позволяющими быстро собирать приложения из готовых компонентов, тогда как выбор языка для разработки повторно используемых компонентов, пригодных для многих проектов, определяется прежде всего соображениями эффективности.

Небольшие проекты

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

каждую из шести задач решал один из членов группы. Однако не во всех проектах это возможно.

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

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

• Конфликт интересов — нельзя совмещать роли, интересы которых

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

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

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

мер, знания и опыт менеджера продукта и логистика сильно отличаются. Сочетания ролей, помеченные буквой «Д» — Допустимо — возможны, так как их интересы совпадают. Например, как тестеры, так и инструкторы отвечают за выполнение требований пользователей.

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

Дата добавления: 2014-01-05