Nõuanded ja parimad tavad nõuete paremaks haldamiseks

Mida tähendab nõuete haldamise „parimad tavad“?

See on minu jaoks nii huvitav, et kõik räägivad koolituse soovistparimaid tavasid”. Seda terminit kasutatakse sageli ka sellise nõustamise kirjeldamiseks, mida me ka pakume. Mida see tegelikult tähendab? Usun, et me kõik oleme sisse elanud müüdi, et parimad tavad võivad olla üksikute koolitamise aluseks. Parimaid tavasid ei koolitata, vaid kogetakse.

Kui võrrelda looduse parimaid tavasid käsitlevat lähenemist, teame, et ellu jäävad mitte ainult tugevaimad, vaid ka kõige viljakamad liigid. See on üks põhjus, miks organisatsiooni protsesse on nii raske muuta. Mõelge korraks sellele. Kõige tugevam ja viljakam kirjeldab tõenäoliselt enamikku inimesi, kes teil on teie organisatsiooni peaaegu igas rühmas. Olen seda süsteemitehnika valdkonnas ikka ja jälle näinud. Tugevamad ja viljakamad insenerid on sageli aastaid oma tööd teinud ja neil on selle töö jaoks kindel viis. Palumine neil uusi tehnikaid ja tööriistu proovida on sageli kasutu, sest nad ei tea, kuidas see parandab niigi imelist tööd, mida nad teevad. Nende praktika jääb püsima, kui jätkame neile parimate tavade lähenemist.

Mida me siis teeme? Parimad tavad saavad alguse meie enda isiklikust kogemusest. Kõik raamatud, mille te kätte saate ja parimate tavade kohta loete, käsitlevad autori isiklikke kogemusi mõnes valdkonnas, olgu selleks siis kasutamisjuhud, nõuete esilekutsumine, süsteemitehnika, testimine jne. Ühel hetkel otsustab organisatsioon, et vajab järjepidevat protsessi kogu organisatsioonis. Selle tegemiseks on palju häid põhjuseid. Niisiis moodustatakse rühm, et tulla välja protsessiga, mis kajastaks neid parimaid tavasid. Kuna rühmas on palju parimaid tavasid, siis arvake ära, kes tavaliselt võidab? Tugevamad ja viljakamad. Ja sellest tulenev parim tava annab tavaliselt kompromissi parimate tavade rühma ja organisatsiooni nende vahel, kes seda rolli täidavad. Uuringud näitavad, et selle protsessi tegelikuks mängimiseks kogu organisatsioonis kulub umbes viis aastat. Siis tulevad konsultandid, kes neid tavasid märkavad. Nad võivad näha võimalust ettevõtluseks ja nii jäävad nad nende tavade taha, mis toovad neile rohkem äri. Nad hakkavad ilmuma konverentsidel ja messidel, reklaamides neid tavasid ja kirjutades raamatuid. (Mõelge sellele Agile lähenemine.) Kuna nad otsivad äri, on nad keskendunud tavadele, mis pakuvad neile kõige rohkem äri. Otsime alati parimaid tavasid, nii et me ei pea teadma, kui tihti see töötab, lihtsalt seda CAN töö. Ja nii jätkame seda praktikat kogu organisatsioonis, lootes mõista kõiki eeliseid, millest on aastate jooksul räägitud.

Peame meeles pidama, et parimad tavad põhinevad tagantjärele. Teie töö parimad tavad töötatakse välja selle töö kohta õppides. Kindlasti saame üksteiselt õppida. See pole selle arutelu mõte. Asi on selles, et peame tuginema oma parimatele tavadele eelkõige oma praktilistele kogemustele. Peame olema tähelepanelik, kuidas rakendada parimaid tavasid oma töökohtadele ja organisatsioonidele. Lihtsalt ärge aktsepteerige parimaid tavasid, sest keegi kirjutas sellest raamatu või rääkis sellest konverentsil. Uurige praktikat ja määrake keskkond, kus neid soodustati. Kas see keskkond on võrreldav praegusega? Sageli on vähe ühist. Valige parimate tavade hulgast, mis kehtivad teile ja teie tööle ning pakuvad teile tõelist kasu. Alustage väikeste muudatustega ja lähtuge tavadest, nagu neid teie organisatsioonis rakendatakse. Teadke, kus see on õnnestunud ja kus ebaõnnestunud, ja õppige sellest. Pidage meeles, et kui teil on praktikale tugevaid ja viljakaid vastuväiteid, vajate kedagi, kes praktikast praktiliselt aru saab, et aidata esinejatel mõista, kuidas see praktika neid aitab. Kuulake neid ja lahendage nende mured. Ärge lihtsalt ignoreerige neid ja loodke, et nad kaovad. Nad ei tee seda.

Teisisõnu, lihtsalt sõnade „parim tava” ütlemine ei tähenda, et see oleks teie jaoks parim tava.

Kuidas oma nõuete definitsiooni parandada?

Iga kord, kui muudetakse kas protsessi või tööriistu mida kasutatakse protsessi toetamiseks, on olemas õppimiskõver, mis mõjutab selle protsessi läbiviimiseks vajalikku aega. Kui hakkate oma nõuete määratlemise protsessi täiustamise üle mõtlema, pidage meeles, et selle muudatusega on seotud pingutused. Enamikul juhtudel on tootlikkuse langus töö edenedes. Seda langust nimetatakse sageli J-kõveraks. Kui kasutajad üritavad muuta konkreetse ülesande täitmise viisi, jõuavad nad punkti, kus nad tunnevad, et muudatuse tegemine on lihtsalt liiga raske. Siin on kiusatus pöörduda tagasi vana teguviisi juurde, et ainult ülesanne lõpule viia. Ilma selle takistuse ületamise plaanita ei täida paljud organisatsioonid eesmärki seda muudatust teha. See väljakutse kehtib nii protsesside kui ka tööriistade puhul. Oskuste või tööriistade kasutuselevõttu saab kiirendada kahe strateegia abil.

Esiteks on olemas sügavus lähenemine. Põhjalikus lähenemises valitakse välja põhirühm inimesi, keda koolitatakse uue protsessi või tööriista osas, ning nad saavad ka edaspidi mentorlust, mis ületab koolituse ja tegeliku projekti vahelise lõhe. Mentorid on sageli väljaspool konsultante, kellel on kogemusi konkreetse oskuste valdkonnas. On oluline, et eksperdid oleksid kättesaadavad, et aidata praktikutel oma uusi oskusi otseprojektis kasutada. See põhirühm on üsna väike ja kavatsetakse kasutada neid uute projektide konsultantidena, kes uusi oskusi kasutavad. Neist saavad eksperdid, kes liiguvad projektist teise, et aidata neil inimestel oma uusi oskusi kasutada.

. laius lähenemine keskendub heade tavade oskuste kindlale alusele, mida aja jooksul täpsustatakse. Selle lähenemisviisi raames pakutakse mentoreid, kes pakuvad seda heade tavade oskuste aluseid, sageli konkreetse oskuste valdkonna standardkoolituse kaudu. Tavaliselt on standardprotsessid ja mallid määratletud ja dokumenteeritud erinevate projektimeeskondade jaoks kasutamiseks. Esmane koolitus viiakse läbi suurele rühmale üksikisikutele võrreldes väiksema, keskendunud rühmaga, mida on nimetatud sügavuskäsitluses. Kui projektid hakkavad uusi oskusi kasutama ja saavad rohkem teada nende konkreetsete ülesannete mõjust, antakse need tulemused parimate tavade sihtasutusse, nii et neid saab aja jooksul täpsustada.

Ükskõik, millise meetodi selle jõupingutuste haldamiseks valite, on vajalike muudatuste edukaks tegemiseks ülitähtis. Ilma plaanita langevad need muudatused sageli kõrvale, kui ajakava ja eelarve krõbe on tunda. Selliste muudatuste tegemine nõuab distsipliini, tuge ja sihikindlust. Iga projekti tuleb pidevalt hinnata, et veenduda uute oskuste kasutamises.

Mõelge oma nõuete määratlemise protsessi lihtsale muutmisele. Kes on eksperdid, kellele saate sisemiselt tugineda? Kas vajate koolituseks ja / või juhendamiseks välist abi? Kuhu te lähete sellele koolitusele ja mentorlusele? Kas teie protsess on täna hästi dokumenteeritud või alustate nullist? Mis on teie plaan oma edukuse tagamiseks (sügavus, laius, mõlemad)? Milline on muudatuse ajakava?

"Hullumeelsus teeb ikka ja jälle sama asja ja ootab teistsugust tulemust". (Albert Einstein) Kui teil on selline tunne, alustage muudatuste tegemist, mis annavad teile soovitud tulemused.

Nõuandeid nõuete paremaks kogumiseks

Kui küsitlete kasutajaid ja ütlete põhimõtteliselt "Trick or Treat - anna mulle mõned head nõuded", arvan, mida sa saad? Te saate hulgaliselt asju, mida kasutajad sooviksid näha. Mõni on teile oluline ja mõni mitte. Peate kõik need vajadused sortima ja kategooriatesse sorteerima. Me nimetame neid kategooriaid tavaliselt funktsioonideks. Mõned neist funktsioonidest on projekti jaoks asjakohased ja mõned mitte. Nii et kui hakkate nõudmisi koguma, siis miks mitte keskenduda rohkem küsimustele, mida esitate? Uurige veidi ja vaadake kogu olemasolevat teavet, mis on süsteemi jaoks asjakohane. Tehke kindlaks lõppkasutajad (te ei pea kogu alajaotuses petma ega kohtlema, keskenduge paarile tänavale, kus antakse tõeliselt häid maiuseid) ja seadistage nendega kohtumised. 

Tehke kindlaks protsessid, mida projekt mõjutab - millised muutuvad, millised on uued, kas neid pole enam vaja? Küsige kasutajatelt, millised protsessid nende jaoks hästi töötavad? Tehke tööd, et mõista, kuidas nad täna oma tööd teevad.

Teiseks, kui olete nõuded funktsioonideks sorteerinud, peate tähtsuse järjekorda seadma neid funktsioone. Millised on kliendi lemmikud, et kõigepealt ära teha?Mõnikord ei suuda me tõepoolest prioriteete seada ja jõuame kõigepealt süsteemi hõlpsamatele osadele, selle asemel, et keskenduda kõrge riskiga või mitte hästi mõistetud süsteemi osadele.

Projekti lõpus, vaadake juhtunu uuesti läbi. Me võime küsida kui me läheksime õigetel tänavatel, kui me järgiksime protsessi või mingil põhjusel kõrvale kalduksime, kas saime nii palju komme, kui ootasime? Mis toimis hästi? Milliseid muudatusi saaks protsessi parandamiseks teha? Kas saime oodatud lõpptulemused? Kas kasutajad olid tootega rahul?

3 näpunäidet oma meeskonna koolitamiseks nõuete haldamisel

Kui paluda, et keegi, kes pole kunagi nõudeid kirjutanud ega haldanud, järgiks tugevat ja keerukat nõuete protsessi, on sama, kui paluda viieaastasel mängida Beethoveni Kuuvalgusonaati. Ja kuna me ei paku sageli koolitust ega juhendamist, palume neil õppida seda tükki ise mängima. Seda me teeme, kui viskame oma analüütikud keeruliste nõuete protsessi.

Soovitan kaaluda oma meeskonna koolitamist. Lõpetame mõtlemise, et me kõik lihtsalt "oskame oma tööd teha". See pole tõsi. Saame õppida seda pala iseseisvalt mängima. Ma soovitaksin selle asemel, et võtta viis aastat, oleks mul läinud üksi kümme aastat. Nii on ka meie nõudmistega inseneride ja analüütikutega. Saame lasta neil iseseisvalt õppida. Või võime anda neile koolituse, juhendamise ja aega harjutamiseks.

Muidugi on selle töö tegemiseks võtmetähtsusega (pole mõeldud sõnamängu) mingisuguse protsessi määratlemine, mida me kasutame oma analüütikute koolitamiseks. Ma vihkasin seda “protsessi” sõna, kuid see on oluline. Siin on mõned näpunäited uute nõueanalüütikute kiireks muutmiseks nõuete analüütikuteks.

1. Pakkuge analüütikutele koolitust teie konkreetse protsessi kohta, kasutades teie nõudeid ja tulemusi, nii et koolitus on reaalsem. Nõuete määratlemise ja haldamise üldklassid on suurepärased, kuid need peavad olema kooskõlas protsessidega, mida oma organisatsioonis jälgite. Kui töötate koos väliskonsultandiga, siis eeldage, et koolituse kohandamiseks teie jaoks on vaja teha mõningaid jõupingutusi, kuid see on investeeringut väärt.
2. Määrake oma uutele analüütikutele mentor. Las keegi, kes on seal käinud, seda teeb ja kellel on selle tõestamiseks haavad ja armid, aitab uut analüütikut ja näitab neile köisi. See aitab kõrvaldada selle „hõimutundmise“ mõtlemise. Las nad abistavad seanssidel, vaatavad koos analüütikuga läbi nõudedokumendid ja on neile ressurss. 
3. Las analüütik harjutab. See ei pruugi tunduda liiga praktiline, kuid ärge alustage projekti jaoks uut analüütikut, mis on ettevõtte jaoks kriitiline või mille ümber on nii palju ajalugu ja poleemikat, et edasiliikumine on keeruline. Las nad "harjutavad" lihtsal ja hästi mõistetaval projektil, et jalad märjaks saada.

7 nõuannet paremate nõuete kirjutamiseks

Kirjutamisnõuded on olnud meie jaoks väljakutse juba mitu aastakümmet. Miks see nii keeruline on? Noh, üks põhjus on nõudekeele väljakutse. Me teame, et peame nõuded kirjutama viisil, mis on lugejale loetav ja arusaadav. Kui kirjutame kasutajate nõuded, on lugeja ettevõtte omanik, lõppkasutaja või sidusrühm ja keskendub kirjutamisele „loomulikus” keeles. Loomuliku keele probleem seisneb aga selles, et see on väga ebatäpne ja tõenäoliselt tõlgendatakse seda valesti või valesti. Kuidas seda lõhet ületada?

Mind hämmastab nende analüütikute arv, kellega ma räägin, kes seisavad oma nõuete kirjutamisel vastu igasugusele struktuurile. Tundub, et nad on üsna rahul oma struktureerimata lähenemisviisiga, mis koosneb tavaliselt kirjeldavatest lõikudest ja lausetest, mis eeldavad paljusid lisanõudeid. Nende lugejatele meeldib see meetod, mida nad väidavad. Probleem on selles, et kui need nõuded on arendajatele või süsteemianalüütikutele üle antud, on tavaliselt palju edasi-tagasi arutlusi, et selgitada, mida need nõuded tegelikult tähendavad.

Usun, et siin tuleb teha kompromiss. 

Siin on mõned näpunäited selle lõhe ületamiseks.

1. Kirjutage aktiivse häälega, veendudes, et iga näitleja on iga lause teema.
2. Veenduge, et iga lause on terviklik ja grammatiliselt õige lause koos subjekti, verbi ja predikaadiga.
3. Täpsustage selgelt, millist teavet osalejate vahel edastatakse.
4. Säilitage detailide ühtlane tase. Näiteks peaks kasutaja nõuete täitmiseks olema iga lause teema lõppkasutaja. Süsteeminõuete täitmiseks peaks süsteem olema iga lause teema.
5. Iga nõue peaks kirjeldama selgeid edukriteeriume. Näiteks: "Kasutajal peab olema võimalik auditilogi aruannet vaadata".
6. Igas nõudes peaks olema kirjas üks tegevus ja eesmärk. Jälgige liigset „ja” ja „või” kasutamist. Näiteks: "Kui kuu viimane reede ja makse tuleb tasuda 31. kuupäeval ja kui 31. kuupäev on kuu viimane reede, siis toob makse esitamine sellel päeval pärast kella 6 Ida aja järgi hiljaks makse" . Ma kutsun teid üles sellest aru saama!
7. Nõudel ei tohiks olla pääsuklauslit. Näiteks: "Süsteem määrab sisselogimiskatsete arvu, välja arvatud juhul, kui kasutaja on selgelt vale kasutajanime sisestanud".

4 näpunäidet keeruliste kliendinõuete haldamiseks

Kuidas te selle stsenaariumiga hakkama saaksite? Klient on öelnud, et soovib, et süsteem oleks kasutajasõbralik. Nimetan seda keeruliseks nõudeks, kuna see on tegelikult paljude ainulaadsete nõuete kogum. Esitatud nõuded peaksid olema aatomi tasemel. Teisisõnu peaks iga nõue olema ainulaadne ja täielik mõte. Kuid mis on parim viis kliendiga sellisele tasemele jõudmiseks? Reaalsus (ja kogemused) ütleb meile, et paljud nõuded on tegelikult märksa keerulisemad, kui öeldud.  

Pidage meeles, et me ei tohiks eeldada, et klient esitab meile häid nõudeid. Nad peaksid pakkuma meile probleemi, mida nad tahavad lahendada. Kui see pole selge, peame neilt küsima! Nad on probleemi eksperdid. Kui jätkame seda väidet veel veidi, võime leida, et nõue on, et klient peab uue süsteemi kasutamiseks kolme kuu jooksul koolitama 500 inimest. Muidugi peab see olema kasutajasõbralik. Kuid klient vajab tegelikult viisi, kuidas tagada uute kasutajate kiire koolitamine. See võib muuta lahenduse fookust - kasutusjuhendid, veebikoolitused, õpetused jne.  

Võtame selle lihtsa taotluse kasutajasõbraliku süsteemi jaoks. Siin on mõned probleemid.

• Klient ei soovi töökoja teha kindlaks, mida kasutajasõbralik tähendab. Klient soovib, et mõtleksime tema eest. Lõppude lõpuks oleme me nende "konsultandid".
• Klient ei tea täielikult, mida ta tahab. Nad pole täpselt läbi mõelnud, mida nende jaoks kasutajasõbralik tähendab. Nad võisid selle lisada, sest see on hea mõte ja kõik teised teevad seda. 
• Klient on liiga hõivatud, et meile kvaliteetset sisendit pakkuda. Paluge neil veeta pool tundi, rääkides sellest, mida kasutajasõbralik nende jaoks tähendab, ja nad võivad lihtsalt aega veeta.
• Võib-olla pole klient määranud kõiki kasutajaid, kes otsivad kasutajasõbralikku süsteemi. Teisisõnu, ta ei pruugi tuvastada kõiki, kes võiksid soovida kindlaks teha, kas süsteem on kasutajasõbralik (nt ärikliendid, mitteärilised, kogenud kasutajad vs kogenematud kasutajad, väliskliendid jne).

Seda tüüpi nõuetega seotud riski maandamiseks saab teha mõningaid asju.  

1.  Tehke mõned ekraanide prototüüpide loomist ja neid kasutajale näidata. Küsige neilt konkreetselt, kas nende arvates on need kasutajasõbralikud. Seejärel haarake ekraanide aspektid kasutajaliidese nõuete hulka.
2. Looge oma kasutajasõbralikkuse määratlus. Määratlege kriteeriumid ja kasutage neid oma kasutajate aktsepteerimistestide määratlemiseks. Esitage need kliendile ülevaatamiseks.
3. Jätkake probleemi mõistmist.  Ärge kartke küsimusi jätkata ja süüvida kliendi nõudmise tegelikku põhjust.
4. Veenduge, et teil oleks nõude mõõtmiseks selged kriteeriumid. Ilma selleta ei läbita te seda nõuet kunagi kliendi silmis. Ja ilma selleta pole nõudest üldse kasu.

Kasutab nõuete haldamisel juhtumeid

Kasutusjuhud on tõhus vahend dokumenteerimaks, kuidas kasutaja oma tööd teeb. Sageli kutsutakse "nagu on" ja "olema", aitavad need jutustused tagada, et me mõistaksime, kuidas kasutaja täna oma tööd teeb (nagu on), samuti seda, kuidas ta võib ette kujutada oma homset tööd (olla). Kasutusjuhud muutuvad üha populaarsemaks, kuna analüütikud võitlevad jätkuvalt nõuete seose probleemidega.

Kuid mõnikord kasutatakse kasutusjuhtumeid ajal tõhusalt nõuete esilekutsumine ja määratlus, kuid eksige siis, kui ülemineku nõuetele haldusele. Kui mõelda kasutusjuhtumi toimingutele, kirjeldab iga samm kas kasutaja või süsteemi toimingut. Sõltuvalt täpsusest, mida soovite oma nõuetes ja jälgitavuses, kaaluge iga juhtumi sammu seadmist nõuete avalduseks. Võtke näiteks järgmine lihtne kasutusjuht.

Süsteem kuvab kliendile kontoteabe.

Klient vaatab kontoteabe üle.

Klient valib makseviisi.

Süsteem kuvab kliendile maksevõimalused.

Sellest kasutusjuhtumist on üsna selge, et on kaks süsteemi sammu ja kaks kliendi (st kasutaja) sammu. Kui eraldame kaks süsteemi lauset ja lisame neile vajaduse korral „peab“, saame kaks järgmist süsteemi nõuet:

Süsteem kuvab kliendile kontoteabe.

Süsteem kuvab kliendile maksevõimalused.

Need kaks nõuet hakkavad olema süsteeminõuete aluseks. Need süsteeminõuded jaotatakse tõenäoliselt paljudeks süsteeminõueteks, kuid saame neid jälgida otse kasutuse puhul süsteemi sammudeni.

Pidage meeles, et kasutusjuhtumid sisaldavad süsteemide analüüsimiseks ja arendamiseks väga väärtuslikku teavet. Kasutamisjuhud pole kunagi lõpule viidud, kuna neid tuleb kogu arenduse vältel pidevalt üle vaadata, et need kajastaksid toote tarnimisel täpselt, kuidas see käitub. Veenduge, et kasutusjuhtumeid ei asetataks riiulile, vaid et need oleksid seotud nii testide kui ka süsteeminõuetega.