Добавлен: 15.06.2023
Просмотров: 311
Скачиваний: 4
Введение
Не зависимо от того, какого предприятие по величине, будь то малая фирма или крупная компания, коммуникация в ней является важной составляющей успешной деятельности. Так же коммуникация- это одно из самых сложных явлений в менеджменте и управлении. Ни одна организация не может полноценно функционировать без коммуникации. Велико значение коммуникаций не только в деятельности предприятия, но так же в жизни людей, которые трудятся на этом предприятии. Хорошо организованная, она позволяет людям комфортно чувствовать себя на работе, быть уверенными в завтрашнем дне и осознавать свою значимость. При рассмотрении роли коммуникации в глобальных масштабах, можно сказать, что от эффективности коммуникации зависит и жизнедеятельность всего общества.
Изучение специфики использования технологий деловой коммуникации является актуальной на сегодняшний день темой. Эффективная работа по связям с общественностью создает благоприятные условия для достижения успеха в деловой сфере.
Главным определяющим моментом, влияющим на эффективность деловой коммуникации является психологический настрой группы. Поэтому создание благоприятного настроя в своем коллективе - это важная задача любого руководителя. На предприятии, где руководитель не может (или не хочет) грамотно управлять коммуникациями, как правило, наблюдается безынициативность работников, низкая производительность труда и высокая текучесть кадров. Рано или поздно эти факторы приводят предприятие к упадку, а подчас и к банкротству.
Именно эти обстоятельства побудили осуществить данное исследование, цель которого - обоснование выбора и разработка эффективной деловой коммуникации (Целью данной работы является изучение и разработка умелого и правильного делового общения).
Для достижения цели необходимо решить ряд задач.
1. Проанализировать основные теоретические положения;
2. Разработать рекомендации по деловому общению.
Объектом исследования моей курсовой работы является деловое общение. Предметом исследования - тактика общения в бизнесе.
Методологической основой данной курсовой работы была использована литература по основам теории коммуникации таких авторов как Аткинсон В. В., Абчук В.А., Алешина И.В., Айви А.Е., Берг В., Беркли-Ален М., Беттеджер Ф., Биркенбил В., Борисов А., Бороздина Г. В., Зверинцев А.Б., Курбатов В. И., Кузин Ф.А.
В данном списке хотелось бы выделить работы Курбатова В. И. Его работы является принципиально важными для понимания теории деловой коммуникации.
Были изучены такие источники как Журнал «Маркетинговые коммуникации», а также некоторые интернет источники. Исследование источников помогает по-новому взглянуть на деловую коммуникацию.
Практическая значимость. Данная тема активно изучается исследователями примерно с конца двадцатого века по причине появления и развития бизнес - отношений.
Сформулированные выше задачи предопределили структуру настоящей работы, которая состоит из введения, двух глав, заключения, списка использованной литературы.
В первой главе теоретически рассмотрена сама деловая коммуникация. Во второй главе рассмотрены методы разговора с сослуживцами, деловой беседы, переговоров и т. п, особенности поведения начальников и подчиненных.
По завершению исследования сделаны выводы, освещены проблемы и даны рекомендации практического характера.
Глава 1. Теоретические аспекты изучения деловой коммуникации
1.1. Понятие проектной среды
Среда проекта имеет три дискретных состояния. Это среда для создания прототипов, среда разработки и среда сопровождения.
1. Среда для создания прототипов включает в себя «испытательный стенд» для тестирования, использующийся для создания прототипа архитектуры проекта, который является основой для принятия технических решений в течение двух стадий жизненного цикла — начальной стадии и уточнения. Такая конфигурация должна поддерживать следующие виды деятельности:.
• Оценка производительности и анализ технических рисков;
• Оценка альтернатив создания/покупки и изучение применимости коммерческих продуктов.
• Выбор решений, касающихся устойчивости к ошибкам и динамического изменения конфигурации.
• Анализ рисков, связанных с переходом к полномасштабной реализации.
• Разработка сценариев тестирования и инструментов анализа требований.
2. Среда разработки должна включать в себя полный набор инструментов разработки, которые требуются для поддержки различных рабочих процессов, а также для поддержки «круговой» разработки в максимально возможной степени.
3. Среда сопровождения обычно должна совпадать с окончательной версией среды разработки. В некоторых случаях среда сопровождения может являться подмножеством среды разработки, поставляемой в качестве одного из конечных продуктов проекта.
Переход к совершенному процессу разработки ПО создает новые проблемы и возможности для контроля за согласованностью действий и для оценки реального прогресса и качества. Как показывает опыт, полученный при осуществлении проектов в реальной жизни, сильно интегрированная среда оказывается необходимой как для упрощения, так и для усиления контроля над процессом. Так же существуют четыре важные дисциплины, которые критичны для управления и достижения успеха в современном процессе итерационной разработки:.
1. Инструменты должны быть интегрированы для поддержки непротиворечивости и трассируемости. «Круговая» разработка — это термин, который используется для описания ключевого требования к различным видам среды, которые поддерживают итерационную разработку.
2. Управление изменениями должно быть автоматизировано и построено для успешного управления сразу несколькими итерациями и обеспечивания простоты внесения изменений. Изменение — это фундаментальная составляющая итерационной разработки.
3. Различные виды организационной инфраструктуры позволяют строить разные среды проекта на основе одних и тех же процессов и инструментов. Общая инфраструктура проектов способствует их согласованности, постоянному обучению персонала, использованию извлеченных уроков и получению иных стратегических выгод.
4. Распространение поддержки автоматизации на среду других заинтересованных сторон обеспечивает дальнейшее развитие безбумажного обмена информацией и более эффективное рассмотрение рабочих продуктов проекта.
По мере того как индустрия ПО движется в направлении автоматизированной поддержки различных рабочих продуктов, все более и более возрастает необходимость в гарантии эффективности и безошибочности переноса данных из одних рабочих продуктов в другие. «Круговая» разработка — это поддержка среды, необходимая для обеспечения непротиворечивости различных рабочих продуктов.
Автоматизированная трансляция проектных моделей в исходный код {как при прямом, так и при обратном проектировании) определяется довольно четко. Автоматизированная трансляция проектных моделей в модели процесса (распределенной среды) также постепенно упрощается за счет использования таких технологий, как ActiveX и Common Object Request Broker Architecture (CORBA).
Компиляторы и загрузчики уже давно обеспечивают преобразование исходного кода в исполняемый код. По мере того как различные архитектуры начинают использовать разнородные компоненты, платформы и языки, сложность создания, управления и поддержания широкомасштабных сетей компонентов предъявляет новые требования к контролю за конфигурацией и к автоматизации управления сборкой приложений из компонентов. Однако современные среды не поддерживают автоматизацию в максимально возможной степени. Например, автоматизированное создание вариантов тестирования из описаний варианта использования и сценария до сих пор не в состоянии поддерживать что-либо, кроме наиболее тривиальных случаев, таких как сценарии тестирования отдельных модулей.
Главная причина применения «круговой» разработки — это необходимость упростить внесение изменений в источники данных для разработки ПО. Такой контроль за конфигурацией всех технических рабочих продуктов важен для поддержания непротиворечивого и свободного от ошибок представления изменяющегося продукта. Однако нет никакой необходимости иметь переходы в двух направлениях во всех случаях. Например, хорошо было бы строить варианты тестирования для сценариев, описанных для заданного логического множества объектов, но мы не можем получать объекты исключительно на основании вариантов тестирования. Похожим образом, обратное превращение плохо написанного исходного кода в объектно-ориентированную проектную модель может оказаться непродуктивным.
Трансляция данных из одного источника в другой не всегда может быть выполнена на 100%. Например, перевод проектных моделей в исходный текст на C++ может касаться только структурного и декларативного аспектов представления исходного кода. Компоненты кода по-прежнему должны быть наполнены спецификой атрибутов или методов конкретного объекта.
Управление изменениями так же важно для итерационного процесса, как и планирование. Отслеживание изменений в технических рабочих продуктах является решающим для понимания реальных тенденций прогресса разработки и тенденций качества, направленных на получение приемлемого конечного продукта или промежуточной версии. В рамках традиционных процессов создания ПО способы управления конфигурацией технических рабочих продуктов использовались преимущественно на поздних этапах жизненного цикла. В современном процессе, где комплекты рабочих продуктов требований, проекта и реализации представляются посредством строгих нотаций уже на ранних стадиях жизненного цикла и претерпевают множество изменений, управление изменениями оказывается фундаментальным для всех стадий и практически для всех видов деятельности.
Запросы на внесение изменений.
Наименьшая неделимая единица программистской работы, в результате которой производится создание, изменение или отказ от устаревших компонентов в рамках базовой конфигурации, называется запросом на внесение изменений в ПО (SCO, Software Change Order). Запросы на внесение изменений — один из главных механизмов распределения и.
планирования работы по созданию ПО. Пример запроса, приведенный на рис. 12.3, является хорошей отправной точкой для описания набора примитивов, требуемых для внесения изменений. Здесь показан уровень детализации, необходимый для управления изменениями в современном процессе создания ПО. За счет автоматизации ввода данных и поддержки записей с изменениями в онлайновом режиме может быть автоматизирована и бюрократическая составляющая управления изменениями, связанная с различными отчетами о состоянии проекта.
Определение уровня, на котором следует писать SCO, всегда является проблемой. Для большинства проектов неделимая единица измерения SCO принимается без особого труда. SCO должен быть написан для отдельного компонента, чтобы его выполнение можно было возложить на одного человека. Если исправления требуют труда двух человек из двух разных команд, необходимо писать два отдельных.
Главными полями SCO являются: название, описание, параметры, исправления, оценка и диспозиция.
■ Название предлагается автором и окончательно утверждается советом по контролю за конфигурацией (ССВ, Configuration Control Board). В этом же поле должна содержаться ссылка на внешний отчет о проблеме, если это изменение было инициировано извне (например, пользователем).
■ Описание проблемы включает в себя имя автора, дату возникновения, присвоенный ССВ идентификатор и идентификаторы соответствующих версий вспомогательного ПО. Описание проблемы в текстовом виде содержит как можно больше деталей, к нему должны прилагаться участки программы, копии экрана, сообщения об ошибках и любые другие данные, которые могут помочь локализовать проблему или описать необходимые изменения.
■ Параметры, собираемые по каждому запросу, важны для планирования, составления графика и оценки качества. Категория вносимых изменений может иметь следующий тип: 0 (критичная ошибка), 1 (ошибка), 2 (усовершенствование), 3 (новая возможность) и 4 (другое). При принятии запроса выполняются предварительные оценки дефектов в ПО и объема работ, необходимого для решения проблемы. Графа «Дефект» является количественным выражением объема требуемых изменений, «Переделка» дает количественное определение сложности вносимых изменений. По мере внесения исправлений фиксируется реальный объем дефектного ПО и уточняются реальные объемы работ, необходимые для переделок. В графе «Анализ» указывается число человеко-часов, затраченных на понимание требуемых изменений (воспроизведение проблемы, ее локализация и устранение, если тип изменений 0 или 1; анализ и создание прототипов альтернативных решений, если тип равен 2 или 3). Графа «Реализация» определяет количество человеко-часов, затраченных на проектирование и реализацию исправления. В графе «Тестирование» указывается количество часов, затраченных на тестирование исправлений, графа «Документация» определяет общий объем работ по обновлению других рабочих продуктов, таких как руководство пользователя или описание версии. Количество дефектного ПО задает глубину вносимых изменений и может выражаться в SLOC, функциональных точках, файлах, компонентах или классах. В случае выбора SLOC программа сравнения исходных файлов, которая выявляет количественные различия, может предоставить простую оценку объема дефектного ПО. Точное значение числа дефектных строк не слишком важно. При изменении от 0 до 100 строк их количество следует округлять до ближайшего десятка, при изменении от 100 до 1000 строк — до ближайшей сотни и т.д.