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

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. V-модель.

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

4. RAD модель.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Технология производства понятна проектной группе.

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

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

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

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

V-модель.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Модель RAD.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Оценка:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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