Проблема

Хоча проблеми ніхто не хоче, вони є невід'ємною частиною будь-якого великого твору, а отже, і будь-якої методології, яка намагається допомогти справам вийти добре. Ідея створення проблеми полягає в тому, щоб усунути проблеми.

Проблемою ми позначаємо ширшу групу подій, які часто мають окремі назви в термінології фірми. У AyMINE окремі типи можна відрізнити за допомогою циферблата, визначеного відповідно до корпоративної методології:

• Невідповідність – Відхилення від стандарту, як правило, визначається внутрішнім аудитом. Невідповідність може не призвести до збою.
• Проблема – Неясність щодо рішення, наприклад, під час розробки, а також, наприклад, проблеми на виробництві (наявні дефекти)
• Дефект – Неправильний вихід, який не відповідає жодній з вимог входу.
• Стимулювання – Пропозиція, зауваження або застереження від будь-кого з групи розслідувань. При подальшому аналізі, як правило, визначають, як класифікувати її більш детально – наприклад, як проблему, але, наприклад, пропозиції щодо покращення.

Життєвий цикл проблеми

Кожна проблема повинна бути помічена якомога швидше, коли вона з'являється. Звичайно, тільки в тому випадку, якщо воно не вирішується відразу (то, напевно, це не проблема).

Коли проблема реєструється, вона залишається "активною", тобто вирішеною до її завершення. У AyMINE проблема має, по суті, той же життєвий цикл, що і завдання або вимога. Передбачається, що усунення проблеми хтось візьме на себе, до того часу він може залишитися відкритим без розв'язувача.

Запис проблеми

Більшість процесуальних методологій вимагають, щоб були записані всі або більшість зазначених нижче даних. Перевірте, можливо, власну методологію вашої організації, що саме вона вимагає.

Виникнення проблеми

Документація при створенні журналу проблеми повинна включати:

• Опис, як проявляється проблема
• Ідентифікація того, хто і коли його повідомив (не обов'язково той, хто його записав)
• Коли він почав проявлятися, виник або вперше з'явився на нього
  **Кому дістанеться проблема управління?

Вирішення проблеми

В рамках подальшого аналізу повинні створюватися записи:

• Причина проблеми – Її висновки можуть вимагати більш детального аналізу, наприклад, Root-cause, Fishbone, 8D report та ін. Ці аналізи повинні бути додані, оскільки вони є важливою документацією процедури. Причина задокументована на власній вкладці в деталях.
• Процедура вирішення – Які події та висновки були зроблені при вирішенні проблеми:
• Події: Документовані у формі події (вкладка діяльності)
• Висновки: Записано в процедуру розв'язання (під сам опис проблеми). Що стосується припущень, речей для обговорення або пропозицій, то ми рекомендуємо задокументувати дискусію на тему проблеми. Примітка: дискусія архівується так само, як і сам об'єкт, і тому є документацією рішення, яке можна переглянути, а потім провести аудит.

Стани вирішення проблеми

• Новий – після створення, проблемою досі ніхто не займається
• Вільний до вирішення – Проблему "куратор" назвав такою, що чекає на когось, хто візьметься за неї
• У вирішенні – хтось відповідає за проблему
• Вирішений – Проблема була вирішена і чекає підтвердження адміністратором. Якщо проблему безпосередньо вирішує адміністратор, то проблема взагалі не потрапляє в цей стан.
• Завершено – Проблема повністю вирішена. У стан він потрапляє або шляхом його вирішення контролером, або шляхом підтвердження того, що проблема вирішена (контролером, коли її вирішив хтось інший).
• Вирішений – Проблема перестала мати сенс вирішувати. У цей стан розв'язувач може перенести його вручну за допомогою команди. Проблема знята, наприклад, у тому випадку, якщо вона стосувалася контракту, який був скасований.

Документація проблеми

Проблеми можуть залишатися відкритими взагалі як би довго. Система не має інструменту, щоб оцінити актуальність проблеми, а тому не організує її вирішення в цілому. Однак для проблеми слід зазначити, до якого часу її слід усунути, а проблеми, які перевищать цю дату, виділені на робочому столі.

Документація проблеми має й інші переваги:

• Збільшення представництва членів команди, які таким чином легше передають порядок денний, який необхідно вирішити
• Передача досвіду в інших і пізніших проектах, які можуть отримати досвід, на що звернути увагу і на що розраховувати, що може статися
• При якісній документації вирішення проблеми можна отримати в інших проектах або заходах взагалі досвід вирішення проблеми.
• Виконання вимог методологій, таких як PMBOK, ISO9000, ASPICE, ISO26262 та ряду інших, які сприймають документацію проблем як основний інструмент для того, щоб проблеми не зникали і не залишилися невирішеними.

Проблема проти завдання

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

Правильний опис проблеми

Щоб розв'язати задачу, вона повинна бути задокументована з самого початку. Особливо, якщо проблему має вирішувати хтось інший, ніж хто знайшов проблему і записав, або якщо відомо, що рішення відкладається і не буде безпосереднім. Зміст опису проблеми здебільшого визначають і методології якос ті роботи, і внутрішня система якості. Методики сходяться на тому, що опис повинен містити як мінімум:

• Точна ідентифікація середовища, в якому виникла проблема (наприклад, чи є проблема на внутрішньому пристрої, чи у клієнта і у якого)
  ** За яких обставин виникла проблема?
• Що викликає або може викликати проблему
  ** Наскільки серйозні наслідки?
• Які кроки до нього дійшли (особливо, якщо це можна зробити тими ж кроками знову)
  **Якою має бути правильна поведінка?

Крім того, доцільно зазначити (якщо відомо і актуально):

• Посилання на документацію, що описує правильний стан (наприклад, керівництво погано працюючого пристрою)
• Протоколи або інші записи з неправильної поведінки

При багатьох проблемах, звичайно, деякі з вищезазначених значень не мають значення, або мають його лише в переносному значенні (зразком для документації проблеми) іноді є помилкове пристрій. У цьому випадку документація має повний сенс. В іншому прикладі – недостатнє знання у члена проектної команди, зрозуміло, що більшість пунктів опису будуть непридатними. Обидва приклади при цьому є проблемою, яку слід зазначити при створенні).

Документація рішення

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

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