Плохое управление проектом

Дизайн и разработка
29 августа 2013

Название анти-паттерна: Плохое управление проектом
Также известен как: Шалтай-Болтай
Уровень, на котором чаще всего встречается: Предприятие
Название решения, направленного на улучшение: Система предупреждения рисков
Тип решения, направленного на улучшение: Роль и процесс
Основные причины: Ответственность (первопричина)
Неуравновешенные силы: Управление рисками (всеобъемлющая сила)

Пример из жизни:
"Что пошло не так? Всё было отлично, и вдруг... БАБАХ!"

Вводная информация

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

Общая форма

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

Сюда входит техническое планирование (архитектура) и действия по контролю качества (проверка и тестирование). В частности, вот основные ошибки: неправильное определение архитектуры, недостаточный анализ кода (проверка ПО) и недостаточное тестовое покрытие.

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

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

Симптомы и последствия

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

Типичные причины

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

Существующие исключения

Не существует исключений для анти-паттерна «Плохое управление проектом».

Решение, направленное на улучшение

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

Административные риски

Эти риски возникают из-за руководства и им же решаются:

  • Процессы. Комплексное определение разработки продукта.
  • Роли. Чёткая ответственность за внедрение процессов.

Общие риски проекта

Эти риски возникают благодаря следующим факторам:

  • Перерасход средств.
  • Досрочное прекращение проекта.
  • Разработка несоответствующего продукта.
  • Техническая неисправность.

 

Качественные риски

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

Одинаковое понимание

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

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

  • Потерянный функционал. Какие-то компоненты служб так и не были созданы, потому что не было общего представления о том, как все эти компоненты будут взаимодействовать на базовой инструментальной платформе.
  • Неполный функционал. Какой-то компонент не будет демонстрировать весь необходимый функционал, потому что разработчики не расскажут об этом пользователям (другим разработчикам).
  • Чрезмерный функционал. Требования так и не были полностью поняты. Это приводит к разработке ПО без учёта каких-либо требований или потребностей.
  • Модули кода будут настроены, но не будут полностью взаимодействовать между собой. Нет определения потоков управления в системе и границах модулей.

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

Вариации

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

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

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

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

Пример

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

  • Стандартам кодирования (в том числе предъявляемым к проекту)
  • Анализу кода
  • Планированию тестирования
  • Модульному тестированию
  • Тестированию API
  • Интеграционному тестированию
  • Объектному тестированию
  • Программной документации

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

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

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

  • Дизайн
  • Кодирование
  • Тестирование
  • Документальное оформление

Каждый член группы отвечает за:

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

В течение шести месяцев каждый процесс был несколько раз усовершенствован, и каждая команда реализовала каждый процесс хотя бы один раз. Улучшения были выражены в уменьшении (более 50%):

  • Дефектов кода
  • Ошибок в документальном оформлении
  • Нетестированного кода

Схожие решения

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

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

РћСигинал статьи: Source Making (sourcemaking.com)
Похожие статьи
КомментаСРёРё (0)