ИТ-проектите избегнуваат грешки во техничкото прифаќање
содржина
- Одговорности и состав на тимот за прифаќање
- Техничко прифаќање во процесот на развој на софтвер
- Неформални расправии и дамки на неволја
- Како програмерите и корисниците го гледаат намалувањето?
- Слабејте ефикасно и ретко
- Се појавуваат проблеми - што да правам?
предмети
содржина
- Одговорности и состав на тимот за прифаќање
- Техничко прифаќање во процесот на развој на софтвер
- Неформални расправии и дамки на неволја
- Како програмерите и корисниците го гледаат намалувањето?
- Слабејте ефикасно и ретко
- Се појавуваат проблеми - што да правам?
Техничкото прифаќање е моментот на вистината за проектните тимови. Со него, одговорноста се пренесува од инвеститорот до идниот корисник - но само доколку корисникот го одобри резултатот од проектот. Често со прифаќањето доаѓа грубо будење за менаџерот на проектот.
Пример од ИТ компанија:
Датумот за завршување на проектот е фиксен и им е соопштен на партнерите и јавноста. Сепак, самиот менаџер на проектот не верува дека софтверот што неговиот тим го развил е прифатлив. Затоа, бурната гужва започнува непосредно пред круцијалниот состанок. Веќе нема доволно време да се отстранат сите дефекти - толку е сигурно. Менаџментот сè уште инсистира на намалување. Затоа, потребни се мерки за да се одржи штетата што е можно помала. Проектниот тим работи дење и ноќе, но за жал со сомнителен успех: За една грешка што е елиминирана, се создаваат три нови. Објавувањето се испорачува во надеж дека најлошите грешки нема да бидат забележани толку брзо.
Дали ваквите сценарија се навистина неизбежни? Дали успеваат подобри резултати од прифаќање ако компаниите го усогласат управувањето со нивниот проект со ова? Едно е јасно: дури и ако тимот користел прототипови и го развивал производот постепено, тој не е имун на непријатни изненадувања. Сериозни грешки во текот на проектот не можат да се отстранат за време на прифаќањето. Сепак, раководството на проектот треба да го извести раководството за сите преостанати ризици многу однапред на датумот на прифаќање, за да може навремено да донесе соодветни одлуки за неопходните чекори.
Оваа статија се фокусира на проблеми и можни решенија за проблеми во управувањето со проектот на тим за прифаќање. Тие се прикажани со примерот на софтверски проект. Написот е наменет првенствено на проектните менаџери, квалитетни менаџери и оние одговорни за техничко прифаќање.
Одговорности и состав на тимот за прифаќање
Кој е одговорен за одобрување во софтверски проект? Кој ја донесува конечната одлука? Во пракса, постојат неколку модели на одговорност за прифаќање:
- Одговорноста за прифаќањето е на корисникот, бидејќи тој дејствува како клиент за проектот.
- Одговорноста е на ИТ одделот на компанијата, бидејќи корисникот е премногу слаб во однос на надворешните партнери.
- Одговорноста е на корисниците и ИТ одделот (мешана одговорност).
- Одговорноста е на независен тим за инспекција, нарачан од раководството на компанијата (евентуално надворешно).
Мешаната одговорност не ја докажа својата вредност. Доколку идните корисници сакаат да го прифатат резултатот од прифаќањето, важно е да имаат професионална одговорност во процесот на прифаќање. Раздвојување на договорната одговорност (оддел за ИТ) и професионална одговорност (корисници) е можно и сосема практично.
Потребно е мешано знаење како во тимот за прифаќање (техничка, методологија на тест, ИТ). Оваа мешавина на know-how не мора да биде достапна само во самиот тим. Секој член на тимот треба да знае за трите области. Повеќето членови на тимот треба да се фокусираат на специјалистичко знаење во комбинација со знаење како да се справат со тестовите.
Техничко прифаќање во процесот на развој на софтвер
Техничкото прифаќање зазема хибридна позиција во процесот на развој на софтвер. Во него има трансфер на одговорност од развивачите кон идните корисници. Секоја компанија се справува со нив различно. Како избирате варијанта која е соодветна за ваш сопствен проект? Следните белешки се однесуваат на проекти со тим од повеќе од пет вработени.
Цел и целни критериуми за техничко прифаќање
Главната цел е јасна: да се донесе одлука дали клиентот ќе го прифати системот и ќе го користи во производството. Како ја донесувате оваа одлука?