Подготовка к совещанию

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

Инженер процесса готовит презентацию подхода, с помощью которого будет реализован процесс. Такая презентация должна занять 1-3 часа, в зависимости от уровня подготовленности аудитории.

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

Примечание: рабочее совещание - это лишь один из многих способов собрать информацию об организации. Его необходимо дополнять другими методами сбора информации.

Кто должен участвовать

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

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

• Руководители проекта
• Архитекторы программного обеспечения
• Опытные аналитики
• Опытные разработчики
• Опытные специалисты по тестированию
• Руководитель отдела разработки

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

Перед совещанием

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

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

Проведение совещания

Председатель проводит совещание, что означает следующие обязанности:

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

Примером типичной повестки дня рабочего совещания может служить следующая:

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

Налаживание контактов

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

Примером другой модели процесса разработки может служить стандарт ISO/IEC 12207, описанный через виды деятельности и организованный в виде следующих разделов:

• Реализация процесса
• Анализ требований к системе
• Архитектурное проектирование системы
• Анализ требований к программному обеспечению
• Архитектурное проектирование программного обеспечения
• Подробное проектирование программного обеспечения
• Написание кода и тестирование программного обеспечения
• Интеграция программного обеспечения
• Уточненное тестирование программного обеспечения
• Интеграция системы
• Уточненное тестирование системы
• Установка программного обеспечения
• Поддержка приемлемости программного обеспечения

Подведение итогов

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

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