ИТ проектите избягват грешки в техническото приемане
съдържание
- Отговорности и състав на приемащия екип
- Техническо приемане в процеса на разработване на софтуер
- Неформални раздели и проблемни места
- Как разработчиците и потребителите виждат намалението?
- Отслабвайте ефективно и пестеливо
- Възникват проблеми - какво да се прави?
субекти
съдържание
- Отговорности и състав на приемащия екип
- Техническо приемане в процеса на разработване на софтуер
- Неформални раздели и проблемни места
- Как разработчиците и потребителите виждат намалението?
- Отслабвайте ефективно и пестеливо
- Възникват проблеми - какво да се прави?
Техническото приемане е моментът на истината за проектните екипи. С него отговорността се предава от разработчика на бъдещия потребител - но само ако потребителят одобри резултата от проекта. Често с приемането идва грубото събуждане за ръководителя на проекта.
Пример от ИТ компания:
Датата за края на проекта е фиксирана и е съобщена на партньорите и обществеността. Но самият ръководител на проекта не вярва, че софтуерът, разработен от неговия екип, е приемлив. Ето защо забързаната суматоха започва малко преди решаващата среща. Вече няма достатъчно време за отстраняване на всички недостатъци - това е сигурно. Ръководството все още настоява за намаляване. Следователно са необходими мерки, за да се запази възможно най-малко щетите. Екипът на проекта работи денем и нощем, но за съжаление със съмнителен успех: За една грешка, която е отстранена, се създават три нови. Изданието се доставя с надеждата, че най-лошите грешки няма да бъдат забелязани толкова бързо.
Наистина ли са неизбежни такива сценарии? Успеват ли по-добрите резултати от приемането, ако компаниите приведат управлението на своите проекти в съответствие с това? Едно е ясно: дори ако екипът е използвал прототипи и е разработил продукта постепенно, той не е имунизиран срещу неприятни изненади. По време на приемането не могат да бъдат отстранени сериозни грешки в хода на проекта. Ръководството на проекта обаче трябва да информира ръководството за всички останали рискове много преди датата на приемане, за да може своевременно да вземе подходящи решения за необходимите стъпки.
Тази статия се фокусира върху проблемите и възможните решения за проблеми при управлението на проекти на екип по приемане. Те са показани на примера на софтуерен проект. Статията е насочена предимно към ръководители на проекти, мениджъри по качеството и отговорни за техническото приемане.
Отговорности и състав на приемащия екип
Кой е отговорен за одобрението в софтуерен проект? Кой взема окончателното решение? На практика има няколко модела на отговорност за приемане:
- Отговорността за приемането е на потребителя, тъй като той действа като клиент на проекта.
- Отговорността е на ИТ отдела на компанията, тъй като потребителят е твърде слаб към външни партньори.
- Отговорността е на потребителите и ИТ отдела (смесена отговорност).
- Отговорността е на независим инспекционен екип, възложен от ръководството на компанията (вероятно външно).
Смесената отговорност не е доказала своята стойност. Ако бъдещите потребители трябва да приемат резултата от приемането, е важно те да носят професионална отговорност в процеса на приемане. Разделянето на договорната отговорност (ИТ отдел) и професионалната отговорност (потребители) е възможно и съвсем практично.
В екипа по приемане се изисква смесено ноу-хау (технически, методология за изпитване, ИТ). Тази комбинация от ноу-хау не само трябва да бъде на разположение в самия екип. Всеки член на екипа трябва да знае за трите области. Повечето членове на екипа трябва да се съсредоточат върху специализирани знания, съчетани със знания как да се справят с тестовете.
Техническо приемане в процеса на разработване на софтуер
Техническото приемане заема хибридна позиция в процеса на разработване на софтуер. В него има прехвърляне на отговорност от разработчиците към бъдещите потребители. Всяка компания се справя с тях по различен начин. Как избирате вариант, който е подходящ за вашия собствен проект? Следните бележки се отнасят за проекти с екип от повече от петима служители.
Обективни и целеви критерии на техническото приемане
Основната цел е ясна: да се вземе решение дали клиентът ще приеме системата и ще я използва в производството. Как вземате това решение?