Как се пише изисквания

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

В идеалния случай, бих искал да получа ПМУ - документ, в който клиентът е описано всичко, което той знае, че властта, как проектът трябва да бъде използван от потребителя, тъй като, ако клиентът иска да управлява проект, аз показа дизайн, помисли за бъдещото развитие. Сън, както се казва, не е вредно. Защото това никога не се случва.

Както получили обичайните изисквания

Изисквания могат да дойдат чрез система за управление на задачите с по пощата, Skype, по време на среща в разговор. Описанията на качество и детайлност обикновено са оскъдни и трябва да бъдат изяснени. Няма нищо специално, изясняване изисквания - това е един нормален работен процес. Често тези, които са изправени пред изискванията за писане за първи път, можете да чуете следното изречение: "Аз пиша TK не може, така че не ме питай за изисквания." Тук е необходимо да се разделят на заданието и изисквания.

Клиент - не е програмист, TK запис не може от него не е задължително условие. Какво се изисква от клиента, който е дошъл с тази работа - да се знае и да е областта и да отговори на въпроси, за да се изяснят изискванията. Това се случва, че отговорът е много трудно да се постигне.

Какво да включите

Клиентът не е наясно или не напълно наясно с това, което той иска от работодателя / старши мениджър, и, съответно, не може да формулира искания за изпълнение на задачата. В този случай, разработчиците, чиято задача е по-добре да не идват, не добра воля в такъв проект. По-добре да отиде в обратната посока и да получава информация от източника. Клиентът не компетентен в областта на развитието и срамежлива, за да изразят своите мисли в прост език. Тези трудности се решават бързо, тъй като МРа задача - да се говори с събеседник, да зададете въпроси сондиране и извличане на информация. Между другото, на описанието на изискванията по прост, "гражданско" език - е добре дошъл. Много по-лошо, когато технически термини, които не са приложени по делото.

Защо не можем да "направи по някакъв начин"

Ако клиентът има по-горе включите него се предлага да се направи "по някакъв начин", "по ваша преценка." Бели петна в исканията и предложенията от типа "направи като нещо" - е зло. Алгоритъмът е "някак си" не пишете в него всички трябва да бъдат стриктно. Младата дизайнерка, гледайки към такова описание, се удивиха очи и опитен разработчик ще програма по свой собствен начин. В първия случай, задачата няма да бъде извършена във втория - ще се извършва не по начина, който искате бизнеса.

Как да се гарантира, че всичко е наред

Имате нужда от бърза обратна връзка за изясняване на изискванията и да се вземат решения. В реалния живот не винаги получавате бърз обратна връзка, например, когато клиент - отгоре и е трудно да се достигне.

Изисквания към детайла до такава степен, че няма да има въпроси от разработчиците. Разбира се, те ще се появят в процеса на кодиране, но изискванията ние ще го фиксират в състояние, където предприемачът за първи път го стана ясно за него. Detailing изисквания - е резултат от сътрудничеството между клиента и PMA. Животът пример: първоначалните молби, получени от клиента на същата страница (с две снимки на нея все още), след обновяване се превърнали в 19 страници. Това е 18 страници с информация се съставят от клиента в процеса на одобрение на изискванията, които са били доведени до степен на детайлност, което е необходимо да се започне строителство.

Не е необходимо да се изработи изискванията за архитектура. Има 80 нива изпомпва клиенти. който се рови в темата, така че изискванията, започват да се изработи дадено приложение или да се изгради схема на база данни. Това е твърде много. От страна на екипа за развитие винаги има човек, който е изобретил архитектурата и ще бъде отговорен за това. Но отговорността за което им е наложено от тези хора не ми харесва тази част от архитектурата.

Не забравяйте да запишете на споразумението. Потвърден срок информация живот в претоварените различни глави проекта - две седмици. След това, нефиксирана задача е забравени или изгубени части, нови фантазии, задачата започва да звучи различно. Един добър инструмент, за да се определи изисквания - Google Docs, винаги има видима актуална версия, можете да конфигурирате правото, да видите историята на промените.

Доведете вашите изисквания, ние ще се изясни с тях :)