Те казват: "Няма значение как ще се направи на проекта. Важно е, че те предаде него. "
В действителност, ако доставката на проекта, за да се отрази в самото начало, шансовете за успешното му изпълнение се увеличиха значително. И там са най-малко три важни етапа, когато е важно да се повдигне въпроса, когато се занимават с клиента - в началото на проекта, в средата или към междинните етапи на проекта, както и завършване на проекта.
В началото на проекта, всички, и на отбора, и клиента са в щастлив еуфория. Проектът се разглежда в по-розова светлина. И често с клиента blurts всичко, което трябва да се преместим по проекта, но времето и формата на датата се пренебрегва. В същото време, и клиентът също не бърза да повдигне този въпрос, защото ако не са посочени критериите за приемане - това му дава свободата да се правят безкрайно искове за извършената работа. "Тъй като системата не работи във всички известни браузъри? Или защо плувах подреждане на елементи на XXX на страница? И тук е грешката е намерена - ако обичате да го оправи ... "И така нататък до безкрайност. Уви, в момента, за съжаление, софтуерът не работи без грешки, така че ако просто не се споразумеят за критериите за приемане - то може да се превърне в процес на безкраен.
Какво да направите в самото начало на проекта:
- Ние съгласува с клиента сумата на задачи. какво трябва да се направи и да разрешим тези проблеми. Веднага изяснява правилата, които важат за приемане не е фразата:
- "Очевидно е" - ако нещо не е важно, то трябва да бъде изразена и се записва (например, може да бъде самостоятелно, предоставена на клиента, че "системата трябва да работи във всички браузъри", но това изискване води до значително увеличаване на времето тестване, и, съответно, трябва да бъдат включени в бюджета, ако клиентът наистина нужда от нея).
- "Ние говорихме за това" - отново, това се случва, че изискванията за потока на клиента е толкова голяма, че дори и да записва всички нямат време. Ето защо, разработен на спецификациите и изпратени за потвърждение на клиента, за да се гарантира, че нищо не е забравено. Ако нещо липсва - това не може да се изисква за приемане.
Важно! Необходимо е да се прави разлика между проверка при приемане на тестване на пълната система. Целта на проверка при приемане - да се гарантира, че системата функционира на най-очакваните сценарии за използването. За средните системи, такъв план ще съдържа около 30-100 скрипт, който развитие обикновено отнема не повече от 1-2 дни, а самото приемане на прохода - около 2-8 часа.
Следващата важна отправна точка се появява по време на изпълнението на проекта.
От опит - колкото по-тясно на клиента, участващи в проекта, и сте наясно с, толкова по-добре разбира ситуацията и е по-склонен да направи компромис в случай на непреодолима сила. В допълнение, можете да получите оценка на междинното работата и ако има някаква коментар веднага ги отстраним и да вземе предвид в бъдещото развитие и не се коригира след снежна топка от проблеми в края на проекта.
Какво да се прави по време на проекта:
- Ние предоставяме доклади за състоянието на клиента по проекта - какво е направено, какво е останало, това, което срещнати проблеми, които изискват намесата на клиента и това може да бъде решен самостоятелно.
Важно! Задължително формат: 1 страница + тренировка резултати. Разбира се, клиентите достатъчно време да се рови във всички детайли, така че основната информация ще бъде консолидиран отчет за него, и част, тя ще изглежда по-дълго, колкото е необходимо. Също така е удобно "модел на светофара", когато в началото на доклада се изпраща на състоянието: GREEN - всичко е наред, оранжево - така, така, ЧЕРВЕН - всичко лошо. - Ние провеждаме временно демо - например, на всеки 2 седмици (или по-вероятно / по-малко в зависимост от продължителността на проекта) демонстрира резултати, питат становището на клиента и да получат потвърждение, че или всичко върви по план, или са необходими корекции, но тук ние виждаме, независимо дали е правилно приети всички на изискванията на клиентите.
Важно! Новият "списък с желания" по време на демонстрацията на клиента може да се случи. Това е абсолютно нормално. Точно тогава веднага и да реши какво да прави с тях - да включат в проекта и да се премести на графика или привличане dop.resursy да ги прилагат или се оставя за бъдещето - това е възможно и необходимо, за да се съгласи веднага. И ако имате някакви коментари - това със сигурност е вярно, че в момента на приемане не беше неприятни изненади.
Накрая, когато проектът е към края си, че е важно правилно да държат си доклад завършване и приемане, с акцент върху критериите, разработени в началото на проекта.
Най-често срещаната грешка - клиентът просто изпраща версия на системата, тъй като, ако отборът вярва, че тази дейност се извършва, или клиентът не определя датите, на които трябва да получат потвърждение на работа може да доведе до факта, че приемането е била забавена продължение на много месеци.
Какво да се прави до края на проекта:
- Ние държим крайното вътрешно "приемане" тестване. в които ние виждаме, че всички скриптове работят.
- Датата, договорени с клиента и да извърши окончателната демо система. докаже, където крайният резултат от развитието на клиента. Ако всичко е направено правилно, демонстрацията не трябва да се откриване на критични или важни въпроси, както и всички глобата е фиксирана и ще трябва да бъдат коригирани, като част от поддръжката.
- Съгласен съм за определен период от време е пълно приемане. когато тя се съгласи, че клиентът има времето, през което тя може още по-нататъшно самостоятелно тест система. Това е много важно, че този път е, разбира се. Т.е. да бъде ясно договорени датата, на която са направени забележки.
Тук, може би, тези 8 прости правила, е основата, която ще ви позволи да вземе успешно вашите проекти!
Свързани статии