ІТ-проекти уникають помилок у технічному прийнятті
зміст
- Обов'язки та склад приймально-здавальної групи
- Технічне прийняття в процесі розробки програмного забезпечення
- Неформальні розриви та проблемні місця
- Як розробники та користувачі бачать зменшення?
- Ефективно та економно худніть
- Виникають проблеми - що робити?
предметів
зміст
- Обов'язки та склад приймально-здавальної групи
- Технічне прийняття в процесі розробки програмного забезпечення
- Неформальні розриви та проблемні місця
- Як розробники та користувачі бачать зменшення?
- Ефективно та економно худніть
- Виникають проблеми - що робити?
Технічне прийняття - момент істини для проектних команд. З ним відповідальність передається від розробника майбутньому користувачеві, але лише за умови, що користувач схвалить результат проекту. Часто з прийняттям приходить грубе пробудження для керівника проекту.
Приклад від ІТ-компанії:
Дата закінчення проекту визначена і була повідомлена партнерам та громадськості. Але сам керівник проекту не вважає, що програмне забезпечення, розроблене його командою, є прийнятним. Ось чому суєтна суєта починається незадовго до вирішальної зустрічі. Більше не вистачає часу на усунення всіх дефектів - це точно. Керівництво все ще наполягає на зменшенні. Тому необхідні заходи, щоб збиток був якомога меншим. Команда проекту працює день і ніч, але, на жаль, із сумнівним успіхом: Для однієї помилки, яку було усунуто, створюється три нових. Випуск подається з надією, що найгірші помилки не будуть помічені так швидко.
Чи справді подібні сценарії дійсно неминучі? Чи вдаються результати кращого прийняття, якщо компанії узгоджують управління проектами з цим? Зрозуміло одне: навіть якщо команда використовувала прототипи та розробляла продукт поступово, вона не застрахована від неприємних сюрпризів. Серйозні помилки в ході проекту не можна скасувати під час прийняття. Однак керівництво проектом повинно повідомити керівництво про всі залишені ризики задовго до дати прийняття, щоб воно могло вчасно прийняти відповідні рішення щодо необхідних кроків.
Ця стаття зосереджена на проблемах та можливих рішеннях проблем в управлінні проектами приймально-здавальної групи. Вони показані на прикладі програмного проекту. Стаття орієнтована насамперед на керівників проектів, менеджерів з якості та відповідальних за технічне прийняття.
Обов'язки та склад приймально-здавальної групи
Хто відповідає за затвердження в проекті програмного забезпечення? Хто приймає остаточне рішення? На практиці існує кілька моделей відповідальності за прийняття:
- Відповідальність за прийняття покладається на користувача, оскільки він виступає клієнтом проекту.
- Відповідальність лежить на ІТ-відділі компанії, оскільки користувач занадто слабкий по відношенню до зовнішніх партнерів.
- Відповідальність покладається на користувачів та ІТ-відділ (змішана відповідальність).
- Відповідальність лежить на незалежній інспекційній групі, яка була доручена керівництвом компанії (можливо, зовні).
Змішана відповідальність не підтвердила свою цінність. Якщо майбутні користувачі повинні прийняти результат прийняття, важливо, щоб вони несли професійну відповідальність у процесі прийняття. Поділ договірної відповідальності (ІТ-відділ) та професійної відповідальності (користувачів) можливий і цілком здійсненний.
Змішані ноу-хау потрібні команді з приймання (технічні, методологія випробувань, ІТ). Ця суміш ноу-хау не тільки повинна бути доступна в самій команді. Кожен член команди повинен знати про три напрямки. Більшість членів команди повинні зосередитись на спеціальних знаннях, поєднаних із знаннями про те, як проводити тести.
Технічне прийняття в процесі розробки програмного забезпечення
Технічне прийняття займає гібридну позицію в процесі розробки програмного забезпечення. У ньому відбувається передача відповідальності від розробників майбутнім користувачам. Кожна компанія поводиться з ними по-різному. Як ви вибираєте варіант, який підходить для вашого власного проекту? Наступні примітки стосуються проектів із командою, що складається з більше ніж п’яти працівників.
Об'єктивні та цільові критерії технічного прийняття
Головна мета зрозуміла: прийняти рішення про те, чи прийме замовник систему та використовуватиме її у виробництві. Як ви приймаєте це рішення?