Sāciet ar lēmumu, nevis funkciju sarakstu
Funkciju saraksts ir inventārs, nevis produkta hipotēze. Jautājiet, kādu lēmumu pirmajam posmam jāpadara iespējamu. Varbūt pircējam jāsalīdzina divi piedāvājumi vai operatoram jāpabeidz pieprasījums, nepārnesot datus starp rīkiem. Aprakstiet cilvēku, situāciju, darbību un redzamu pabeigšanas stāvokli. Ja parādās vairāki nesaistīti scenāriji, pirmajam posmam izvēlieties vienu, bet pārējos skaidri atlieciet.
Aprakstiet robežas saprotamā valodā
Nosakiet, kas sistēmā ienāk, ko tā maina un ko rada. “Vadības panelis” ir pārāk neskaidrs. “Operators var filtrēt sintētisku sūtījumu rindu, apskatīt ierakstu un atzīmēt to kā pārskatītu” ir pārbaudāms. Norādiet, vai iekļauta autentifikācija, reālas integrācijas, maksājumi un migrācija. Prototips un produkcijas sistēma var izskatīties līdzīgi, bet tiem ir atšķirīga atbildība. Šo atšķirību skaidri parādiet piedāvājumā un saskarnē.
Vienojieties, ko nozīmē pabeigšana
Pieņemšanas kritēriji apraksta darbību, nevis gaumi. Iekļaujiet veiksmīgo ceļu, nederīgu ievadi, tukšu stāvokli un novēršamu kļūdu. Nosakiet, kurš pārbauda rezultātu un ar kādiem datiem. Nesoliet biznesa rezultātus, kurus neliels programmatūras posms nevar kontrolēt. Noderīgs rezultāts ir pārbaudāms scenārijs, dokumentēti tehniskie pieņēmumi un neatrisināto risku saraksts. Pārdošanas pieaugumam un lietotāju piesaistei nepieciešami papildu pierādījumi.
Nākamo soli izcenojiet atsevišķi
Pirmais posms nav lēts nosaukums neierobežotam produktam. Pēc pārbaudes salīdziniet atlikušās idejas ar iegūtajām zināšanām. Daži pieņēmumi var pazust, citiem vajadzēs padziļinātu darbu. Nākamajam posmam rakstiet jaunu apjomu un budžetu, ieskaitot infrastruktūru un pakalpojumu izmaksas. Ieguldījums kļūst saprotams, neslēpjot nākotnes izmaksas. Sākuma cenai jāapraksta konkrēts rezultāts, nevis jārada iespaids par pilnu daudzlomu platformu.