Файл: Деловые коммуникации в проектной среде..pdf

■ Исправление. Это поле включает в себя имя ответственного за реализацию вносимых изменений, изменяемые компоненты, реальные показатели и описание изменений. Уровень детализации компонентов, допускающий их передачу для внесения изменений, может варьироваться, но, вообще говоря, самый низкий уровень передаваемых компонентов должен быть приблизительно таким, чтобы работу мог выполнить один человек. Например, просто «компонент» является недостаточной детализацией для передачи команде.

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

■ Диспозиция. ССВ присваивает запросу одно из следующих значений статуса:

• Предложен: запрос написан и ожидает рассмотрения ССВ.

• Принят: ССВ утвердил запрос.

• Отклонен: запрос закрыт с указанием причин — например, не является

проблемой, повтор, устаревшие изменения, выполнено по другому запросу.

• На хранение: запрос принят, но отложен до более поздней версии.

• В работе: запрос передан, и по нему ведется активная работа в организации-

разработчике.

• На оценке: выполнен организацией-разработчиком; находится на оценке в

организации, выполняющей тестирование.

• Закрыт: полностью выполнен, с чем согласны все члены ССВ.

ССВ может также присвоить приоритет и идентификатор версии для определения приоритетов и организации параллельной разработки.

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

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

В общем случае для большинства систем требуются три уровня базовых версий: основные, второстепенные и промежуточные. Каждому уровню соответствует число в идентификаторе вида N.M.X, где N — номер основной версии, М — номер второстепенной версии, а X — идентификатор промежуточной версии. Основная версия представляет собой новое поколение продукта или проекта, в то время как второстепенная версия — это тот же основной продукт, но с улучшенными возможностями, производительностью или качеством. Основные и второстепенные версии обычно являются внешними версиями продукта, которые остаются неизменными и поддерживаются в течение некоторого периода рремени. Промежуточная версия соответствует рабочей конфигурации, которую намереваются использовать как временную. Чем короче ее жизненный цикл, тем лучше. На рис. 12.4 показаны примеры историй некоторых версий для двух различных ситуаций.

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

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

■ Тип 1: ошибка или дефект, который либо не ухудшает полезность системы, либо его можно обойти. Такие ошибки обычно связаны с некоторыми неудобствами в критичных вариантах использования или с серьезными дефектами во второстепенных вариантах использования, вероятность столкнуться с которыми сравнительно низка.

я Тип 2: изменение, которое можно рассматривать скорее как усовершенствование, нежели как реакцию на ошибку. Его целью, как правило, является повышение производительности, улучшение тестируемости, применимости или какого-либо другого аспекта качества, что является свидетельством высокого класса разработки.

■ Тип 3: изменение, необходимость которого вызвана обновлением требований. Это могут быть новые свойства или функциональные возможности, находящиеся вне рамок текущей общей концепции и бизнес-плана.

■ Тип 4: изменения, которые не подходят ни под одну из других категорий. Примеры подобных изменений включают в себя изменения только в документации или обновление версии под коммерческие компоненты.

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

■ Стандартизированный выбор инструментов (посредством инвестирования конкретной лицензии либо посредством переговоров с поставщиками о предоставлении выгодных скидок с тем, чтобы у команд, работающих над проектом, появлялась экономическая мотивация использовать именно этот инструмент), который способствует развитию основных рабочих процессов и повышает ROI при обучении.

■ Стандартные нотации для рабочих продуктов, такие как UML для всех проектных моделей или Ada 95 для всех разрабатываемых на заказ критичных по надежности рабочих продуктов.

■ Дополнения к инструментам, например заранее разработанные или выполненные на заказ шаблоны (описание архитектуры, критерий оценки, описания версий, оценки состояния).

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

■ Другие компоненты организационной инфраструктуры, польза от которых является косвенной:.

• Библиотека ссылок на предшествующий опыт планирования, оценки и улучшения параметров процесса; ответы на вопросы «Насколькохорошо?», «Как много?», «Почему?».

• Существующие практические примеры, включая объективные точки отсчета для оценки успешно завершившихся проектов, которые следовали принципам организационного процесса.

• Библиотека примеров рабочих продуктов проекта, таких как планы разработки ПО, описания архитектуры и истории оценок состояния.

• Модели проведения аудита и способы сопоставления с внешними схемами оценки, такими как Software Engineering Institute’s Capability Maturity Model (SEI CMM).

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

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

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

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

■ Получать и использовать работающие продукты для выполнения оценок вручную.

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

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

На рис. 12.6 показаны новые возможности для производительной деятельности третьих заинтересованных сторон при выполнении больших контрактов. Существует несколько важных причин для распространения ресурсов среды разработки на некоторые заинтересованные стороны.

■ Технические рабочие продукты — это не только бумага. Материалы в электронном виде в строгой нотации, например визуальные модели или исходный код, могут рассматриваться более эффективно при использовании инструментов вместе с подходящими браузерами.

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

■ Даже бумажные документы должны доставляться электронным способом для снижения стоимости продукции и времени оборота.

Рис. 12.6. Распространение среды на другие заинтересованные стороны.

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

1.2 Содержание делового общения

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

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

Деловая коммуникация в проектной среде полноценна только тогда, когда в ней гармонично соединены взаимосвязанные, но различающиеся стороны:

 внешняя, поведенческая, операционально-техническая;

 внутренняя, затрагивающая ценностные особенности личности.

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

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

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

 особенности коммуникативных возможностей партнеров (особенности интеллектуальной деятельности, эрудиция и профессиональная компетентность, лексикон и тезаурус, речевая культура и умение слушать);

 сложившийся характер отношений с деловыми партнерами (уважение, зависимость, пренебрежение, сотрудничество);

 психотип и деловой статус партнеров - коммуникативные намерения в конкретной ситуации.

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

- творчески-продуктивный;

- подавляющий;

- дистанционный;

- прагматически-деловой;

- популистский и заигрывающий, превентивный, а также дружеский.

Выбор стиля зависит от некоторых факторов:

 статуса человека;

 целей, задач и коммуникативных намерений;

 особенностей складывающейся во время общения ситуации;