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

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

Введение

Актуальность темы.

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

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

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

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

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

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

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

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

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

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

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

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

В данной исследовательской работе оценка роли групповой осознанности в управлении IT-проектом будет рассмотрена на примере выборки специалистов, собранной с помощью анонимного онлайн-опросника. Деятельность отобранных специалистов активно связана с разработкой программного обеспечения в IT-проектах. Среди них есть: разработчики сайтов, Android-разработчики, разработчики дистанционного банковского обслуживания (далее ДБО), front-end разработчики, и другие.

Размер эмпирической выборки: 88 человек.

Цели и задачи исследования.

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

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

Теоретическое исследование существующих разработок по данной тематике.

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

Анализ базовых процессов формирования групповой осознанности в организации.

Разработку и проведение эмпирического исследования среди сотрудников, вовлеченных в разработку программного обеспечения.

Разработать программу исследования.

Сбор тестовых данных сотрудников.

Анализ данных эмпирического исследования.

Определить специфику управления IT-проектом с учетом концепции групповой осознанности.

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

Объект и предмет исследования.

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

Методология исследования.

Исследование будет проводиться в три этапа. В первой части будет проведен анализ уже собранных данных, касающихся тематики влияния групповой осознанности на качество управления IT-проектами. В качестве источников будут использованы такие электронные реферативные базы и источники, как: Web of Science, MIT Sloan Review.

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

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

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

1. Теоретическое исследование проблемы групповой осознанности в управлении проектом по разработке программного обеспечения

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

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

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

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

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

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

Основные модели разработки программного обеспечения:

.        Модель водопада.

2.      V-модель.

.        Инкрементная модель.

4.      RAD модель.

.        Гибкая методология.

.        Итерационная модель.

.        Спиральная модель.

.        Модель прототипирования.

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

Описание основных моделей разработки программного обеспечения:

Модель водопада:

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

Основные преимущества данной модели:

.        Крайне простая модель для освоения и применения

.        Легко управляемая в виду своей жесткости - каждая фаза имеет свое место, и должна соблюдаться строгая последовательность.

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

.        Идеально подходит для маленьких проектов, с четкими и ясными требованиями.

К основным недостаткам данной модели относят:

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

.        Проект не считается законченным, пока не пройдет через все фазы проекта.

.        Высокие уровни риска и неопределенности.

.        Не подходит для сложных или объектно-ориентированных проектов.

.        Не подходит для проектов с долгим сроком обслуживания или с долгим сроком исполнения.

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

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

.        В случае, когда требования поставлены четко, ясно, и они зафиксированы.

.        Определение конечного продукта остается стабильным.

.        Отсутствуют неоднозначные требования.

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

.        Проект исполняется в малые сроки.

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

V-модель.

Данная модель берет свое название исходя из двух английских слов “Verification” и “Validation”, которые означают “Верификация” и “Валидация” соответственно. Так же, как и в модели водопада, V-образная модель подразумевает только последовательный путь выполнения процессов. По своей сути, данная модель является расширением модели водопада. Помимо движения вниз по линейной модели водопада, в модели V, после стадии реализации происходит подъем вверх, данным образом формируя букву V. Основным отличием между V-моделью и моделью водопада - раннее планирование тестирования в соответствии с V-образной моделью.

К основным преимуществам данной модели относят:

.        Простота использования.

.        Каждая фаза нацелена на определенные практические результаты.

.        Более высокая вероятность успеха относительно модели водопада в виду разработки планов тестирования на ранней стадии проекта.

.        Отлично работает, когда требования ясно сформулированы.

.        Верификация и Валидация продукта происходят на ранних стадиях разработки.

К основным недостаткам данной модели относят:

1.      Как и модель водопада, является негибкой моделью разработки.

.        Малая гибкость и настраиваемость в процессе разработки делает проект дорогостоящим.

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

.        Модель не предусматривает плана действий с неучтенными проблемами.

.        Помимо четкого планирования, требует больше временных и материальных затрат.

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

Инкрементная модель.

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

Работая в инкрементной модели, разработчики добавляют нововведения шаг за шагом, подразумевая, что, в конце каждого цикла нововведение разработано до конца и функционирует без проблем.

К основным принципам разработки в инкрементной модели относят:

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

.        Техническое задание формируется непосредственно перед планированием разработки.

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

К основным преимуществам данной модели относят:

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

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

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

.        Помогает смягчить архитектурные и интеграционные риски заранее.

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

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

К основным недостаткам данной модели относят:

.        Так как некоторые модули будут разработаны раньше остальных, необходимо разработать структурированный интерфейс и план сборки.

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

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

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

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

.        Не смотря на то, что основные требования должны оставаться без изменений, некоторые детали могут со временем меняться и расширяться.

.        В случае, когда необходимо в скором времени выпустить продукт на рынок.

.        Когда внедряется новая технология разработки.

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

Модель RAD.

Модель RAD, или Rapid Application Development, или Быстрая Разработка Приложений, являет собой разновидность инкрементной модели. В модели RAD компоненты системы разделяются на несколько составляющих и разрабатываются одновременно, таким образом формируя мини проекты. Итоговые разработки упаковываются, распределяются и собираются в рабочий прототип. Эта модель разработки дает возможность заказчику увидеть и опробовать систему, а так же сформировать отзыв и детализировать требования.

Модель имеет следующие фазы:

.        Бизнес моделирование:

Информационные потоки распределяются между подразделениями.

.        Моделирование данных:

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

.        Моделирование процессов:

Объекты данных конвертируются в моделирование данных с целью достижения поставленных бизнес-целей. Объекты данных обрабатываются по системе CRUD.

4.      Генерирование приложения:

Средства автоматической сборки преобразуют мини проекты в одно приложение.

.        Тестирование и запуск:

Финальное тестирование всех компонентов системы и ее интерфейса, запуск.

К основным преимуществам RAD модели относят:

.        Оптимизированное время разработки.

.        Позволяет повторно использовать некоторые компоненты.

.        Появляется возможность быстрой первоначальной проверки.

.        Появляется возможность обратной связи с клиентами.

.        Оптимизированная интеграция с самого начала производства.

К основным недостаткам RAD модели относят:

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

.        Данная модель применима лишь к тем проектам, которые можно разделить на модули.

.        Требуются профессиональные дизайнеры и разработчики.

.        Модель является зависимой от навыков моделирования. Неправильно спланированная модель разработки может навредить проекту.

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

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

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

.        Данную модель необходимо выбрать в том случае, когда есть доступ к высокому уровню знаний в бизнесе и при необходимости создать систему за короткий промежуток времени (2-3 месяца).

Гибкая методология разработки.

Гибкая методология разработки, как и предыдущая модель, берет свое начало из инкрементной модели. Программное обеспечение разрабатывается в соответствии с инкрементными, ускоренными циклами. В результате разработчик получает маленькие сборки системы, которые накладываются на предыдущую сборку, тем самым повышая функционал. Каждый выпуск проходит тестирование, с целью выявления ошибок и недочетов. Данная методология разработки применяется для разработки стратегически важных приложений. На сегодняшний день, самой популярной моделью Гибкой методологии разработки является Экстремальное Программирование (Extreme Programming, XP).

К основным преимуществам Гибкой методологии относят:

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

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

.        Программное обеспечение часто обновляется.

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

.        Тесное и каждодневное сотрудничество между разработчиками и заказчиком.

.        Постоянное внимание на техническое совершенствование и улучшение дизайна.

.        Постоянная адаптация программного обеспечения в соответствии с обстоятельствами.

.        Даже самые поздние корректировки в техническое задание не наносят существенного ущерба проекту.

К основным недостаткам Гибкой методологии относят:

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

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

.        В случае, если клиент не имеет представления, какой конечный результат он ожидает, проект может “сломаться”.

.        Только высококвалифицированные разработчики способны работать внутри данной модели.

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

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

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

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

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

Итеративная (или итерационная) модель.

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

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

К основным преимуществам Итеративной модели относят:

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

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

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

.        В данной модели больше времени уделяется непосредственному проектированию продукта, а не документированию.

К основным недостаткам Итеративной модели относят:

.        Каждая стадия итерации является жесткой и не имеет перекрытий.

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

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

.        Требования к разрабатываемой системе полностью определены и понятны.

.        Когда проект является большим по своим масштабам.

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

Спиральная модель

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

.        Планирование:

На данном этапе происходит сбор требований к проекту. Собираются требования типа “BRS” (Business Requirement Specifications) и “SRS” (System Requirement specifications), или Технические и системные требования.

2.      Анализ рисков:

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

.        Разработка:

На данном этапе происходит разработка программного обеспечения и его тестирование.

.        Оценка:

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

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

К основным преимуществам Спиральной модели относят:

.        Высокий уровень анализа рисков.

.        Подходит для стратегически важных проектов.

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

.        Дополнительный функционал может быть добавлен позднее.

.        Программное обеспечение создается на ранней стадии разработки.

К основным недостаткам Спиральной модели относят:

.        Высокий уровень анализа рисков требует привлечения специалистов.

.        Может перерасти в крайне дорогой проект.

.        Успешность проекта зависит от качества анализа рисков.

.        Не эффективен для небольших проектов.

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

.        Когда важны затраты и учет риска.

.        Для проектов с средними и высокими рисками.

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

.        Заказчик и пользователи не до конца уверены в своих требованиях.

.        Сложные требования к проекту.

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

.        Ожидаются значительные изменения.

Модель прототипирования.

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

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

.        Пользователи активно вовлечены в процесс разработки.

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

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

.        Пользователи могут быстро и оперативно указать на выявленные ошибки и недочеты.

.        Недостающий функционал может быть быстро выявлен и внедрен.

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

К основным недостаткам прототипирования относят:

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

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

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

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

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

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

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

Следовательно, методологии разработки программного обеспечения подразделяются по следующим категориям: Тяжеловесы и Легкие. Методологии-тяжеловесы подходят тем проектам, внутри которых изменения вряд ли произойдут, а уровень программного обеспечения позволяет детально распланировать разработку. Методологии-тяжеловесы легкие для понимания и применения. Они обеспечивают надежную документацию и являются привлекательными для владельцев проекта, поскольку они хорошо структурированы и демонстрируют ощутимые результаты на каждом этапе проекта, а так же создают иллюзию контроля процесса в виду строгой последовательности исполнения. Действуя внутри методологии-тяжеловеса, руководитель проекта может в любой момент провести проверку отчетности и дать оценку выполненной работе. Таким образом, руководитель проекта вовлечен только в стадии планирования, исследования и проверки проекта на предмет соответствия выполненного задания техническим требованиям.

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

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

Подходы к изучению групповой осознанности.

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

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

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

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

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

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

.        Сосредоточенность на ошибках.

.        Отказ от упрощений.

3.      Чувствительность к операциям.

.        Приверженность к устойчивости.

.        Децентрализация процессов принятия решений.

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

Рассмотрим каждый процесс по отдельности:

Сосредоточенность на ошибках.

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

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

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

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

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

Старбак и Милликен (1988), анализируя причины катастрофы шаттла “Челленджер”, выделили несколько обстоятельств для успешного завершения проекта. “Успех порождает уверенность. Когда организация успешна, то, как правило, менеджеры приписывают это к своим личным заслугам, нежели к удаче. Сотрудники становятся более уверенными в своих силах и способностях, в своих управленческих способностях, в процессах и программах, развернутых внутри организации. Они доверяют проводимым процедурам и считают, что их достаточно для предостережения развивающихся проблем, искренне доверяя им, считая, что данные процессы сфокусированы на самых важных аспектах проекта.” Основываясь на предположении, что успех демонстрирует компетентность, люди впадают в самодовольство, невнимательность и привыкают к установленным процедурам контроля, которые они часто оправдывают тем, что они устраняют ненужные усилия. То, чего им никак не удалось предвидеть, так это то, что данное погружение в рутину порождает ошибки по причине человеческого фактора, и что каждый аспект успешного проекта необходимо рассмотреть и противопоставить тем угрозам и рискам, которые стояли перед проектом. В Высоконадежных организациях подобное отношение к проекту трактуется как отказ от стремления к улучшениям, а подобная невнимательность рассматривается как потеря бдительности, а привыкание к рутине как сбой в непрерывной регулировке процессов. Таким образом, если менеджер проекта допускает наличие даже маловероятного провала, то это равносильно допущению, что, даже если данный проект окажется удачным, то это делает будущий успех все менее вероятным, чего, естественно, в Высоконадежных организациях, нельзя допустить.

Отказ от упрощений.

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

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

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

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

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

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

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

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

Внимание к повседневной деятельности.

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

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

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

Приверженность к устойчивости.

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

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

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

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

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

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

Децентрализация процессов принятия решений.

Как мы поняли из предыдущих процессов, внедрение в Высоконадежных организациях структурированную и слаженную систему выявления ошибок обычно являются самой причиной возникновения ошибок. В исследовании Тернера была описана фармацевтическая компания, производящая стерильные жидкости для больниц, которые распространялись через эффективную систему поставок. В 1971 году компания развернула производство жидкой декстрозы, которая не была должным образом стерилизована, и не выдерживала перепадов температур. Таким образом, партия загрязненных жидкостей была направлена в несколько британских больниц, где сразу же у пациентов наблюдались побочные эффекты. Надежная система поставок гарантировала лишь своевременное появление на полках больниц некачественного товара. Ваухан описывала подобную ситуацию в НАСА (пятиступенчатый процесс обработки отклонений). Упорядоченные процедуры в НАСА позволили продолжиться эрозии уплотнительных колец и никаким образом не регулировали данное допущение, в то время как данная ошибка оставалась незамеченной в рамках упорядоченной системы.

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

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

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

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

Таким образом, одновременное внедрение и расширение данных процессов способствует развитию групповой осознанности в Высокоорганизованных организациях.

Роль групповой осознанности в управлении проектом по разработке программного обеспечения.

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

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

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

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

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

Отсюда вытекает вопрос - каким образом организация может создать подобное пространство, поддерживать и развивать его эффективность?

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

1.      Осознание.

2.      Принятие.

3.      Реализация.

4.      Ассимиляция.

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

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

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

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

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

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

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

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

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

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

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

Так же была рассмотрена модель организации инновационного менеджмента, благодаря которой инициируется инновационная деятельность Высоконадежной организации.

2. Эмпирическое исследование проблемы групповой осознанности в управлении проектом по разработке программного обеспечения

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

.        Разработка онлайн-анкеты для сотрудников IT-проектов.

.        Сбор данных.

.        Анализ собранных данных.

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

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

Для проведения анализа выдвинутых гипотез необходимо сформировать выборку сотрудников, активно вовлеченных в проектную деятельность по разработке программного обеспечения в Высоконадежных организациях. В данной работе объектом исследования выступает выборка на основе сотрудников IT-компаний. В исследование включаются только проектно-ориентированные организации. Стоит заметить, что IT-компании, чьим профилем деятельности не являлись проекты по разработке программного обеспечения, так же исключались из тестирования. Мы можем только догадываться, в каком процентном соотношении количество ответов от той или иной компании, принявшей участие в опросе, так как участие в нем было полностью анонимным, поэтому их перечисление не представляет необходимости. Таким образом, в опросе приняли участие 88 респондентов из разных IT-компаний. Деятельность каждого респондента была напрямую связана с разработкой программного обеспечения в рамках IT-проекта.

В данном разделе выпускной квалификационной работы будет проведено эмпирическое исследование проблемы групповой осознанности в управлении проектом по разработке программного обеспечения.

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

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

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

1.      Организационный коллективизм.

.        Честное лидерство.

.        Отсутствие дискриминации в организации.

.        Возможность влиять на принятия решения в работе.

.        Групповая осознанность.

.        Ясность роли.

.        Социальная поддержка. Поддержка со стороны руководства, коллег и компании.

.        Забота о персонале и мотивация.

.        Индивидуальная осознанность.

.        Шкала давления большинства.

.        Отсутствие aффективного реагирования.

.        Шкала авторитета.

.        Совместное обсуждение проблем.

.        Ориентация на анализ опыта.

.        Оценка соответствия действий долгосрочным целям.

.        Метакогнитивная осведомленность.

.        Инновационность.

.        Рефлексия внутригрупповых отношений.

.        Совместный анализ будущих рисков и возможностей.

.        Ориентация на обмен знаниями.

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

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

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

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

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

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

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

Те коэффициенты, которые являлись статистически значимыми, были отмечены красным цветом, с целью облегчения зрительного восприятия результатов анализа.

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

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

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

.        Ясность роли (X1).

.        Социальная поддержка. Поддержка со стороны руководства, коллег и компании(X2).

.        Рефлексия внутригрупповых отношений (X3).

.        Отсутствие аффективного реагирования (X4).

.        Метакогнитивная осведомленность (X5).

Таким образом, можно сформулировать следующие гипотезы:

Гипотеза 1: Существует положительная корреляция между социальной поддержкой со стороны руководства и групповой осознанностью в IT-проектах.

Гипотеза 2: Существует положительная корреляционная связь между индивидуальной осознанностью и групповой.

Гипотеза 4: Существует положительная корреляционная связь между инновационностью и метакогнитивной осведомленностью.

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

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

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

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

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

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

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

Рефлексия внутригрупповых отношений - умение сотрудника анализировать собственное восприятие на самоанализ внутригруппового взаимодействия.

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

Метакогнитивная осведомленность - умение сотрудником управлять собственными знаниями, накопленным опытом и применять их на практике.

Под инновационностью подразумевается умение сотрудников разрабатывать и внедрять инновационные решения.

Стоит отметить, что принимаются за действительность только те связи, в которых коэффициент детерминации являлся приемлемым (от значения 0,4), а значимость устанавливается на уровне p-value<0,05.

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

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

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

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

Рис. 1

Дальнейшему анализу будет подвержена гипотеза о корреляционной взаимосвязи между инновационностью и следующими двумя факторами: отсутствие аффективного реагирования и метакогнитивная осведомленность.

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

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

Интерпретация результатов эмпирического исследования и рекомендации.

Итак, опишем результаты проверки гипотез.

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

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

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

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

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

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

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

Заключение

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

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

Для выполнения данной цели нами были выполнены следующие шаги:

Было проведено рассмотрение и анализ моделей разработки программного обеспечения, процесса формирования групповой осознанности в Высоконадежной организации и влияние групповой осознанности на IT-проекты с точки зрения инновационного менеджмента. Далее, мы осуществили теоретическое обоснование применимости внедрения концепции групповой осознанности в легкие методологии разработки программного обеспечения.

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

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

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

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

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

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

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

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

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

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

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

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

Литература

1.      Swanson E.B. and N.C. Ramiller (2004), “Innovating mindfully with information technology”, MIS Quarterly, 28, 553-583.

.        Duncan N.B. (1995), “Capturing flexibility of information technology infrastructure: a study of resource characteristics and their measures”, Journal of Management Information Systems, 12, 37-57.

.        Yates J. and J. Van Maanen (2001), “Information Technology and Organizational Transformation: History, Rhetoric, and Practice”, Sage Publications: London.

.        Fichman R.G. (2004), “Going beyond the dominant paradigm for information technology innovation research: emerging concepts and methods”, Journal of the Association of Information Systems, 5, 314-355.

.        Mikko Valorinta. (2009),” Information technology and mindfulness in organizations, Industrial and Corporate Change”, Volume 18, Number 5, pp. 963-997.

.        Dewett T., and Jones G.R. (2001). “The role of information technology in the organization: A review, model, and assessment.” Journal of Management 27, 313-346.

.        Attaran M. (2003). “Information technology and business-process redesign.” Business Process Management Journal 9, 440-458.

.        W.W. Royce, “Managing the development of large software systems: Concepts and techniques”, IEEE WESCON, vol. 26, no. 8, pg. 1-9, 1970.

.        S. Mathur, S. Malik, “Advancements in the V-Model”, International Journal of Computer Applications, vol. 1, no. 12, pg. 29-34, 2010, doi: 10.5120/266-425.

.        K. Beck, “Embracing change with extreme programming”, Computer, vol. 32, no.10, pg. 70- 77, 1999, doi:10.1109/2.796139.

.        C. Larman, V.R. Basili, “Iterative and Incremental Development: A Brief History”, Computer, vol. 36, no. 6, pg. 47-56, 2003, doi:10.1109/MC.2003.1204375.

.        J. Martin, Rapid application development, Publisher: Macmillan Publishing, 1991,pg. 788, ISBN:0-02-376775-8.

.        B.W. Boehm, “A spiral model of software development and enhancement”, Computer, vol. 21, no. 5, pg. 61-72, 1988, doi: 10.1109/2.59.

.        M. Liviu, “Comparative study on software development methodologies”, Database Systems Journal, vol. 5, no. 3/2014, pg. 37-56.

.        D. Riehle, “A comparison of the value systems of Adaptive Software Development and Extreme Programming: How methodologies may learn from each other”, Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering, XP 2000, 21-23 Jun. 2000, Cagliari, Italy, pg. 35-50.

.        J.A. Livermore, “Factors that Impact Implementing an Agile Software Development Methodology”, Proceedings of IEEE SoutheastCon, SECON 2007, 22-25 Mar. 2007, Richmond, USA, Publisher: IEEE, 2007, doi: 10.1109/SECON.2007.342860, pg.82-86.

.        J.E. Cooling, T.S. Hughes, “The emergence of rapid prototyping as a realtime software development tool”, Proceedings of the Second International Conference on Software Engineering for Real Time Systems, 18-20 Sep. 1989, Cirencester, UK, Publisher: IET, 1989, pg. 60-64.

.        Karl E. Weick, Kathleen M. Sutcliffe and David Obstfeld, “Organizing for High Reliability: Processes of Collective Mindfulness”, R.S. Sutton and B.M. Staw (eds), Research in Organizational Behavior, Volume 1 (Stanford: Jai Press, 1999), pp. 81-123.

.        Perrow C. (1984). “Normal accidents: Living with high-risk technologies.”, New York: Basic Books.