Si të shkruani kërkesat e projektitSi të shkruani kërkesat e projektit

Para se një agjenci t'ju japë ofertë për një webfaqe ose një softuer, duhet ta dijë çfarë ju duhet. Zakonisht ky informacion vjen në një email me tri fjali dhe një link te webfaqja e konkurrentit. Ofertat që vijnë pas tij vështirë se krahasohen, sepse secila agjenci i plotëson boshllëqet në mënyrën e vet.

Dokumenti i kërkesave i mbyll këto boshllëqe. Ai përshkruan me fjalët tuaja çfarë duhet të arrijë projekti, për kë dhe si do ta vlerësoni rezultatin. Ky udhëzues u drejtohet pronarëve, menaxherëve dhe udhëheqësve të projekteve në kompani të vogla dhe të mesme që së shpejti do të porosisin një webfaqe, një web aplikacion ose një aplikacion mobil. Në fund do të keni një dokument me tetë pjesë, që një ekip mund ta shqyrtojë dhe t'ju japë ofertë për të, e sipas të cilit ju më vonë e pranoni punën. Nëse doni të filloni menjëherë, shkarkoni shabllonin falas në Word dhe plotësojeni ndërsa lexoni.

Dokumenti i kërkesave apo specifikimi: kush shkruan çfarë

Këto dy dokumente shpesh ngatërrohen, por ndarja është e thjeshtë. Dokumentin e kërkesave e shkruani ju, si klient. Ai përmbledh çfarë ju duhet dhe pse. Në vendet gjermanishtfolëse quhet Lastenheft, dhe standardi DIN 69901-5 e përshkruan si tërësinë e kërkesave që klienti i vendos për punën që do t'i dorëzohet. Specifikimin e shkruan furnitori si përgjigje, në gjermanisht Pflichtenheft. Ai përcakton si do të plotësohen kërkesat, sa kushton dhe kur do të jetë gati.

Shkurt: dokumenti i kërkesave tregon çfarë dhe pse, specifikimi tregon si. Nëse që në dokumentin tuaj caktoni me cilën bazë të dhënash apo me cilin framework do të ndërtohet, e merrni përsipër punën për të cilën e paguani agjencinë, e bashkë me të edhe rrezikun e atij vendimi.

Në Zvicër përdorimi është më i lirshëm. Edhe dokumenti i klientit shpesh quhet Pflichtenheft, për shembull në projekte që udhëhiqen sipas HERMES, metodës së administratës federale zvicerane për menaxhimin e projekteve. Mos u hutoni nga emri: rëndësi ka kush e shkruan dokumentin dhe çfarë përmban. Kush do të thellohet, gjen në udhëzimin gjerman VDI 2519 një përshkrim të hollësishëm se si ndërtohen të dy dokumentet. Për një projekt webfaqeje ose softueri të një kompanie të vogël ose të mesme, mjafton struktura që tregojmë këtu.

Çfarë përmban dokumenti i kërkesave

Një dokument i mirë kërkesash për një webfaqe ose softuer ka tetë pjesë. Secila mbështetet te e mëparshmja: nga qëllimi dalin përdoruesit, nga përdoruesit rrjedhat e punës, nga rrjedhat funksionet. Pjesët e fundit vendosin kornizën: cilësinë, pranimin, buxhetin dhe afatet.

Që pjesët të mos mbeten abstrakte, një shembull na shoqëron në gjithë udhëzuesin. Është i trilluar, por tipik: një kompani hidraulike me 25 punonjës në kantonin e Fribourgut, në Zvicër. Klientët e saj flasin gjermanisht ose frëngjisht. Sot punët menaxhohen në letër, kurse faturat kompania i bën tashmë me Bexio, një program kontabiliteti zviceran. Tani do që një softuer ta zëvendësojë letrën. Kompaninë nuk e emërtojmë dhe nuk japim shuma.

Qëllimi dhe sfondi

Filloni me arsyen e projektit. Çfarë nuk shkon mirë sot, çfarë duhet të jetë më mirë pas tij dhe si do ta kuptoni që ia arriti qëllimit? Përshkruani edhe çfarë ekziston tashmë: sisteme, dokumente, zakone. Një qëllim si „digjitalizimi“ nuk i ndihmon askujt. Një qëllim si „asnjë raport nuk rishkruhet më“ mund të kontrollohet.

Shembull: Sot teknikët i shkruajnë raportet me dorë. Në mbrëmje zyra i rishkruan dhe vetëm atëherë mund të krijohet fatura në Bexio. Rrugës humbin orë pune dhe materiale, dhe faturat shpesh dalin disa ditë pas punës. Qëllimi: çdo punë regjistrohet në mënyrë digjitale, nga telefonata e klientit deri te fatura. Suksesi shihet kur zyra nuk rishkruan më asnjë raport dhe fatura është gati një ditë pas vizitës.

Përdoruesit dhe rolet

Shkruani kush do ta përdorë sistemin, sa veta janë dhe çfarë mund të shohë e të bëjë secili rol. Rolet përcaktojnë të drejtat e qasjes, dhe të drejtat e qasjes zënë një pjesë të madhe të punës. Mendoni edhe për ata që e përdorin sistemin vetëm herë pas here, si drejtuesit ose një kontabilist i jashtëm.

Shembull: Tre veta në zyrë krijojnë punët dhe planifikojnë caktimet. Rreth 20 teknikë shohin vetëm punët e veta dhe plotësojnë raportet në telefon. Pronari sheh gjithçka dhe miraton faturat. Klientët nuk punojnë në sistem; ata marrin vetëm një SMS dhe faturën.

Rrjedhat e punës

Përshkruani hap pas hapi si shkon puna sot dhe si duhet të shkojë në sistemin e ri. Kush bën çfarë, me çfarë radhe dhe ku kalon përgjegjësia nga njëri te tjetri? Te këto kalime ndodhin shumica e gabimeve, dhe aty softueri ndihmon më së shumti.

Shembull: Klienti telefonon. Zyra krijon punën dhe cakton një teknik. Tekniku e merr punën në telefon. Në vend regjistron foto, materiale, orë pune dhe nënshkrimin e klientit. Zyra kontrollon raportin, fatura shkon në Bexio dhe klienti e merr. Sot, mes hapit të katërt dhe të pestë, ka një raport në letër që rishkruhet në mbrëmje. Pikërisht këtë hap duhet ta zëvendësojë projekti.

Funksionet sipas përparësisë

Renditni funksionet që dalin nga rrjedhat e punës dhe secilit i jepni një përparësi: e domosdoshme, e dëshirueshme, opsionale ose jo tani. Të domosdoshmet përbëjnë versionin e parë; pa to projekti nuk e arrin qëllimin. Të dëshirueshmet shtohen nëse lejojnë buxheti dhe koha. Opsionalet janë ide për më vonë, kurse „jo tani“ shënon çfarë lihet jashtë me vetëdije. Kjo kolonë e fundit ka më shumë rëndësi se sa duket, sepse e pengon një dëshirë që të rritet pa u vënë re brenda projektit.

Shembull: Të domosdoshme: krijimi i punëve, planifikimi i caktimeve, raporti i punës në telefon me foto dhe nënshkrim, dhe fatura në Bexio. Të dëshirueshme: një SMS për klientin para vizitës dhe punët periodike të mirëmbajtjes. Opsionale: rezervimi online për klientët dhe raportet për secilin teknik. Jo tani: një portal për klientët dhe menaxhimi i stokut. Versioni i parë përfshin të katër të domosdoshmet dhe SMS-në para vizitës.

Të dhënat dhe lidhjet

Shkruani cilat të dhëna mbani, nga vijnë ato dhe me cilat sisteme duhet të lidhet sistemi i ri. Përmendini programet ekzistuese me emër dhe tregoni në cilin drejtim lëvizin të dhënat. Nëse të dhënat e vjetra duhet të barten, shënojeni edhe këtë këtu, me një sasi të përafërt.

Shembull: Të dhënat e klientëve sot janë në Bexio dhe mbeten aty. Sistemi i ri lexon klientët dhe adresat nga Bexio dhe dërgon atje faturat e miratuara, me rreshta për orët e punës dhe materialet. Fotot dhe nënshkrimet ruhen bashkë me punën. Raportet e vjetra në letër nuk barten.

Cilësia

Këtu hyjnë kërkesat që nuk janë funksione, por që vendosin nëse projekti ka sukses: shpejtësia, siguria, gjuhët, pajisjet dhe qasshmëria. Shkruajeni secilën ashtu që të mund të kontrollohet, me një numër ose një kusht të qartë. Për Zvicrën këtu hyn edhe mbrojtja e të dhënave: të dhënat personale bien nën ligjin zviceran për mbrojtjen e të dhënave (DSG), dhe nëse keni klientë në BE, mund të vlejë edhe GDPR-ja. Shënoni ku lejohet të ruhen të dhënat.

Shembull: Ekranet e teknikëve janë në gjermanisht dhe frëngjisht, dhe SMS-ja dërgohet në gjuhën e klientit. Aplikacioni punon në telefonat e zakonshëm Android dhe iOS, edhe në bodrum pa sinjal: raporti ruhet dhe dërgohet më vonë. Çdo faqe ngarkohet për më pak se 2,5 sekonda në një telefon të zakonshëm me internet mobil. Të dhënat ruhen në Zvicër ose në BE.

Pranimi

Përshkruani si do ta kontrolloni punën e përfunduar para se ta pranoni. Kush teston, me cilat të dhëna dhe çfarë duhet të dalë si rezultat? Kur pranimin e caktoni që në dokumentin e kërkesave, i shkruani kërkesat më qartë, sepse çdo kërkesë ka nevojë për një kontroll. Shënoni edhe çfarë merrni në dorëzim: qasjet, dokumentimin dhe një prezantim për ekipin tuaj.

Shembull: Zyra dhe dy teknikë kalojnë 20 punë testuese nga telefonata deri te fatura. Pranimi kalon kur të gjitha faturat e miratuara arrijnë në Bexio pa u rishkruar, dhe kur një teknik i ri e plotëson raportin e parë për më pak se tri minuta pa trajnim. Në dorëzim kompania merr të gjitha qasjet dhe një udhëzim të shkurtër për zyrën dhe teknikët.

Buxheti, afatet dhe pronësia e kodit

Jepni një buxhet nga–deri, qoftë edhe të përafërt. Një kufi i tillë nuk jua dobëson pozitën. Ai i lejon agjencisë të propozojë një zgjidhje që përshtatet, në vend që të hamendësojë. Përmendni datat që janë vërtet të caktuara dhe tregoni pse. Dhe sqaroni kujt i përket kodi më pas. Te ne kodi i përket klientit, por kjo nuk ndodh kudo, dhe ia vlen ta shkruani.

Shembull: Buxheti për versionin e parë: nga ___ CHF deri në ___ CHF. Versioni i parë duhet të punojë para sezonit të ngrohjes në vjeshtë, kur vijnë më shumë punë. Kompania merr gjithë kodin burimor dhe të gjitha qasjet, dhe më vonë mund ta zhvillojë sistemin edhe me një ekip tjetër.

Kërkesa që një ekip mund t'i testojë

Shumica e dokumenteve të kërkesave nuk dështojnë sepse mungojnë funksionet, por për shkak të formulimeve të paqarta. „Aplikacioni duhet të jetë i shpejtë“ tingëllon e arsyeshme, por askush nuk mund ta kontrollojë nëse është plotësuar. Agjencia e kupton ndryshe nga ju, dhe diskutimi fillon gjatë pranimit.

Një kërkesë që testohet ka tri pjesë: çfarë matet, kufiri dhe si kontrollohet. Standardi ndërkombëtar ISO/IEC/IEEE 29148 kërkon të njëjtën gjë nga kërkesat e mira: ndër të tjera, ato duhet të jenë të qarta dhe të verifikueshme. Nuk keni nevojë ta lexoni standardin. Mjafton ta kontrolloni çdo kërkesë me një pyetje: gjatë pranimit, si do ta kuptoja nëse kjo është plotësuar?

Në shembull duket kështu:

• Aplikacioni duhet të jetë i shpejtë. E testueshme: çdo faqe ngarkohet për më pak se 2,5 sekonda, e matur në një telefon të zakonshëm me internet mobil. Vlera është shembull. Ajo përputhet me pragun e Google për një Largest Contentful Paint të mirë, çastin kur shfaqet elementi më i madh i faqes.
• Aplikacioni duhet të jetë i lehtë. E testueshme: një teknik i ri e plotëson raportin e parë për më pak se tri minuta, pa trajnim.
• Aplikacioni duhet të lidhet me Bexio. E testueshme: të gjitha faturat e miratuara arrijnë në Bexio pa u rishkruar, të kontrolluara me 20 punë testuese gjatë pranimit.

Kufijtë nuk duhet të jenë të përsosur. E rëndësishme është që të ekzistojnë. Nëse një agjenci mendon se një vlerë është joreale, jua thotë në pyetjet e saj dhe mund ta ndryshoni bashkë. Kjo është më mirë sesa të zbuloni gjatë pranimit se të dyja palët kishin parasysh diçka tjetër.

Çfarë të mos shkruani

Dokumenti i kërkesave nuk bëhet më i mirë sa më shumë që të përmbajë. Tri gjëra e bëjnë më të keq:

• Të caktoni një teknologji pa arsye. „Duhet të ndërtohet me React“ është vendim për mënyrën se si ndërtohet. Nëse ka një arsye të vërtetë, për shembull sepse ekipi juaj do ta mirëmbajë kodin pikërisht me atë teknologji, shkruajeni arsyen. Përndryshe ia lini zgjedhjen ekipit që mban përgjegjësinë për të.
• Dizajnet e ekraneve si kërkesa. Skicat ndihmojnë për të shpjeguar, por nuk janë kërkesa. Një dizajn përcakton si duket diçka, jo çfarë duhet të bëjë. Përshkruani qëllimin dhe bashkëngjitni skicën si ide.
• Listën e funksioneve të konkurrentit. Konkurrenti i ka ndërtuar funksionet për klientët dhe rrjedhat e veta të punës. Kush i kopjon, paguan për funksione që askush nuk i përdor dhe i harron rrjedhat e veta.

Çfarë ndodh pasi ta dërgoni

Kur na e dërgoni dokumentin e kërkesave, e lexojmë dhe ju kthehemi me pyetje. Pothuajse çdo dokument lë diçka të hapur, dhe kjo është normale: pyetjet tregojnë ku fshihen supozimet. Pastaj merrni një ofertë me shtrirjen e punës, çmimin dhe planin kohor, që u referohet tetë pjesëve tuaja. Në thelb, ky është specifikimi nga pjesa e parë.

Pasi ta pranoni ofertën, vijnë dizajni, ndërtimi, pranimi dhe dorëzimi. Pranimi kontrollon pikërisht atë që keni përshkruar në pjesën 7 të dokumentit. Sa zgjat ndërtimi varet nga shtrirja e punës. Udhëzuesi ynë për kostot jep kohëzgjatjet me të cilat punojmë: një webfaqe prezantuese për 1–2 javë, një web aplikacion për 2 muaj e më shumë, dhe versioni i parë i një aplikacioni mobil për 1–2 muaj. Aty gjeni edhe çmimet përkatëse. Një projekt si shembulli, me zyrë, teknikë dhe lidhje me Bexio, është web aplikacion. Faqja jonë për web aplikacionet shpjegon si i ndërtojmë.

Dokumenti i kërkesave në projektet agile

Shpesh thuhet se projektet agile nuk kanë nevojë për dokument kërkesash, sepse kërkesat ndryshojnë gjithsesi. Kjo është vetëm gjysma e së vërtetës. Detajet ndryshojnë, qëllimi jo. Edhe një ekip agil duhet ta dijë çfarë ndërton, për kë, brenda cilëve kufij dhe si do të pranohet rezultati.

Prandaj në një projekt agil dokumenti i kërkesave cakton qëllimin, kufijtë, përparësitë dhe mënyrën e pranimit. Funksionet e veçanta nuk përshkruhen deri në detajin e fundit. Ato kalojnë në një backlog, një listë e renditur që ekipi e punon hap pas hapi dhe që ju mund ta riorganizoni sipas përparësive gjatë rrugës. Përparësitë nga pjesa 4 janë pika e nisjes. Në shembull qëllimi mbetet i njëjtë: asnjë raport nuk rishkruhet më. Nëse SMS-ja para vizitës hyn në versionin e parë apo në të dytin, kjo mund të ndryshojë gjatë rrugës.

Gabimet më të shpeshta

Këto janë gabimet që i shohim më shpesh në dokumentet e kërkesave:

• Pa qëllim, vetëm funksione. Pa qëllim askush nuk mund të vendosë cili funksion ka më shumë rëndësi.
• Gjithçka është e domosdoshme. Kur çdo funksion ka përparësi, asnjë nuk ka. Versioni i parë bëhet shumë i madh dhe shumë i shtrenjtë.
• Kërkesa të paqarta për cilësinë. „I shpejtë“, „i sigurt“ dhe „i lehtë për t'u përdorur“ pa kufi nuk mund të pranohen.
• Harrohen sistemet ekzistuese. Një lidhje me kontabilitetin, CRM-në ose stokun që del vetëm gjatë ndërtimit i zhvendos buxhetin dhe afatet.
• Pa buxhet nga–deri. Pa kufi, tri agjenci japin ofertë për tri projekte të ndryshme.
• Mungon pranimi. Kush nuk e cakton si kontrollohet puna, në fund diskuton për të.
• Pronësia e kodit mbetet e hapur. Kujt i përket kodi duhet të sqarohet para fillimit, jo kur ndërroni furnitorin për herë të parë.

Shablloni falas

Shablloni ynë përmban tetë pjesët e këtij udhëzuesi, secilën me një shpjegim të shkurtër dhe hapësirë për përgjigjet tuaja. Është skedar Word që mund ta ndryshoni lirisht dhe ta ndani me të tjerët. Nuk ju kërkojmë email.

• Shablloni në shqip
• Shablloni në anglisht
• Shablloni në gjermanisht (Lastenheft-Vorlage)

Plotësoni së pari qëllimin, përdoruesit dhe rrjedhat e punës. Funksionet dalin prej tyre pothuajse vetvetiu. Lëreni bosh atë që nuk e dini dhe shënoni që është ende e hapur. Një boshllëk i sinqertë është më i mirë se një përgjigje e hamendësuar.

Pyetje të shpeshta

Si quhet Lastenheft në anglisht?

Në anglisht dokumenti i klientit zakonisht quhet project brief ose requirements document, kurse në ekipet e produkteve edhe PRD (product requirements document). Homologu i Pflichtenheft është specification; në softuer shpesh quhet software requirements specification (SRS), sipas ISO/IEC/IEEE 29148. Përkthim fjalë për fjalë nuk ka, prandaj me partnerët anglishtfolës ndihmon të thoni kush e ka shkruar dokumentin.

Lastenheft apo Pflichtenheft: cili më duhet?

Si klient ju duhet Lastenheft, pra dokumenti i kërkesave. Pflichtenheft e shkruan agjencia si përgjigje, zakonisht si pjesë të ofertës ose pasi ta pranoni atë. Në Zvicër edhe dokumenti i klientit shpesh quhet Pflichtenheft; atëherë nënkuptohet prapëseprapë dokumenti juaj, ai që përshkruan ky udhëzues.

Sa i hollësishëm duhet të jetë dokumenti?

Aq sa një agjenci të mund t'ju japë ofertë pa hamendësuar, dhe jo më shumë. Për një web aplikacion si në shembull, shpesh mjaftojnë pak faqe. Më e rëndësishme se gjatësia është që të jenë të tetë pjesët dhe që çdo kërkesë për cilësinë të ketë një kufi. Detajet që sqarohen vetëm gjatë ndërtimit i takojnë backlog-ut.

A më duhet dokument kërkesash për një webfaqe të vogël?

Nuk ju duhet një dokument i gjatë, por përgjigjet që qëndrojnë pas tij po. Edhe për një webfaqe të vogël duhet ta dini për çfarë shërben, kush e viziton, cilat faqe dhe gjuhë i duhen, kush e siguron përmbajtjen dhe cili është buxheti nga–deri. Shpesh mjafton një faqe me tetë titujt e shabllonit.

Na e dërgoni dokumentin tuaj

Kur dokumenti juaj të jetë gati, edhe nëse ka ende boshllëqe, na e dërgoni përmes faqes së kontaktit. E lexojmë, ju kthehemi me pyetjet tona dhe pastaj përgatisim një ofertë. Nëse doni të dini çfarë të keni parasysh kur zgjidhni një ekip, ju ndihmon udhëzuesi ynë për angazhimin e një kompanie softueri në Kosovë.

Burimet

• Wikipedia (gjermanisht), Lastenheft, me përkufizimin sipas DIN 69901-5 dhe referencën për VDI 2519
• HERMES, metoda zvicerane federale për menaxhimin e projekteve
• web.dev, Largest Contentful Paint: një vlerë e mirë është 2,5 sekonda ose më pak
• ISO/IEC/IEEE 29148, inxhinieria e kërkesave për sisteme dhe softuer