Журнал проблем

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Issue log" – news · newspapers · books · scholar · JSTOR (September 2017) (Learn how and when to remove this message)

Журнал проблем — это элемент документации управления программными проектами , который содержит список текущих и закрытых проблем проекта. ^[1] Хотя журналы проблем можно рассматривать как способ отслеживания ошибок в проекте, его роль часто выходит за рамки этого. Журналы проблем можно использовать для упорядочивания и организации текущих проблем по типу и серьезности, чтобы расставить приоритеты проблем, связанных с текущей вехой или итерацией . Журналы проблем также могут содержать запросы клиентов и замечания о различных проблемах, которые можно найти в текущем коде.

CAIR - Ограничения, Предположения/Действия, Проблемы, Риски - журнал для отслеживания таких элементов и управления ими.

Журнал проблем обычно пуст в начале проекта, ^[2], но это не всегда верно для последующих релизов. В некоторых проектах журнал проблем фактически используется в качестве руководства для графика релизов; в этом случае журнал проблем может быть заполнен проблемами, которые специально помечены для завершения в предстоящем релизе. В результате проекты, управляемые журналом проблем, могут быть проще в управлении с точки зрения времени завершения и оценки прогресса .
В крупных проектах проблемы обычно управляются программным обеспечением для отслеживания проблем , которое может предоставлять различные способы и инструменты, чтобы помочь менеджеру проекта и команде разработчиков обрабатывать тысячи проблем для одного или нескольких их проектов. Некоторые системы отслеживания проблем также предоставляют возможность сообществу вносить новые идеи и/или код в проект; этот тип сотрудничества широко используется в программировании с открытым исходным кодом .

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

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

• Номер проблемы (ID) : типичный номер для идентификации различных проблем.
• Название проблемы : Название проблемы.
• Описание : Кратко опишите суть проблемы.
• Автор вопроса : Лицо, поднявшее этот вопрос.
• Стороны : все люди, участвующие в решении проблемы.

• Тип проблемы : к какой области знаний относится проблема. (Например, ИТ-инфраструктура, ИТ-приложение и т. д.)
• Приоритет проблемы : определяет, какая проблема является наиболее срочной и должна быть решена в первую очередь. (Например, приоритеты могут включать «Немедленно», «Скоро», «Позже» и т. д.)
• Серьезность проблемы : насколько серьезными будут последствия, если проблема останется нерешенной. (Например, серьезность может включать «Жизненно важный», «Серьезный», «Средний», «Незначительный» и т. д.)

• Дата поднятия : когда был поднят вопрос.
• Дата назначения : когда вопрос был назначен.
• Крайний срок : когда наступает окончательная дата урегулирования вопроса.
• Дата решения : когда проблема фактически решена.

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

• Примечания : некоторые идеи и вещи, которые следует запомнить.

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

• Система отслеживания проблем
• Реестр рисков

• ePMbook Саймона Уоллеса: Проблемы
• Управление программными проектами на практике, Панкадж Джалоте ISBN  0201737213

• Роберт Баттрик (2009). Проект Workout: 4-е издание . Financial Times/Prentice Hall. ISBN 978-0-273-72389-9.