Softuer i personalizuar – platforma, integrime, konfiguratorë, middleware – është aty ku projektet janë më unike dhe ku problemet janë më të vështira për t'u parashikuar në detaje. Megjithatë, në përgjithësi, të njëjtat modele vazhdojnë të shfaqen. Ne kemi dorëzuar më pak projekte softuerike të personalizuara sesa faqe interneti, kështu që kjo listë bazohet në përvojën e ekipit tonë dhe jo në statistika.
1. Shtrirja që rritet gjatë zhvillimit
Problemi më i zakonshëm në përvojën tonë. Ideja evoluon ndërsa ndërtohet: një rol i ri përdoruesi, një raport shtesë, një veçori mesazhesh "që përdoruesit do të presin". Çdo shtesë është e arsyeshme. Së bashku ato dyfishojnë projektin.
Si e trajtojmë: çdo projekt ka një shtrirje të qartë të versionit të parë dhe një listë po aq të qartë jashtë shtrirjes. Idetë e reja shkojnë në një listë të versionit të dytë, jo në fazën aktuale. Kur diçka duhet vërtet të shtohet, ne e riplanojmë hapur: çfarë lëviz jashtë, ose si ndryshon afati kohor.
2. Rregullat e biznesit të përcaktuara shumë vonë
Softueri ka nevojë për rregulla: kush mund të shohë çfarë, çfarë ndodh kur një pagesë dështon, si anulohet një rezervim, cili status vjen pas cilit. Shpesh këto rregulla përcaktohen vetëm kur klienti sheh versionin e parë funksional.
Si e trajtojmë: ne i shkruajmë rregullat kryesore gjatë përcaktimit të shtrirjes si skenarë të thjeshtë ("kur një përdorues bën X, atëherë Y ndodh") dhe i konfirmojmë ato para ndërtimit. Pyetjet e hapura të mbetura ndiqen me pronarët.
3. Mungesa e aseteve bllokon përparimin
Disa veçori nuk mund të ndërtohen pa input nga klienti. Në një projekt konfiguratori produkti 3D, skedarët CAD duhej të konvertoheshin në modele 3D të gatshme për web dhe materialet të krijoheshin si tekstura; numri i aseteve rritet me çdo produkt dhe përfundim. Asgjë nuk mund të renderohej derisa të mbërrinin skedarët.
Si e trajtojmë: ne identifikojmë varësitë e aseteve gjatë përcaktimit të shtrirjes, i kërkojmë ato së pari dhe ndërtojmë pjesë të tjera të sistemit ndërsa presim.
4. API-të dështojnë në heshtje
Integrimet me shërbimet e jashtme – burimet e drejtimeve, korrierët, CRM-të, sistemet e listimit – prishen kur një çelës skadon, një shërbim bie ose API ndryshon. Rasti më i keq është një dështim i heshtur: të dhënat thjesht ndalojnë së rrjedhuri dhe askush nuk e vëren.
Si e trajtojmë: trajtimi i gabimeve dhe alarmet janë pjesë e çdo integrimi. Në flukset e automatizimit, hapat e shkaktuar nga gabimet njoftojnë ekipin kur diçka dështon, në vend që të dështojnë në heshtje.
5. Email-et që nuk mbërrijnë kurrë
Platformat dërgojnë shumë email-e: konfirmime, njoftime, rivendosje fjalëkalimesh, faturat. Në një ndërtim platforme, QA gjeti se email-et e konfirmimit të pagesës nuk po mbërrinin. Klientët do të kishin paguar pa marrë konfirmim.
Si e trajtojmë: çdo email i sistemit është pjesë e planit të testimit, dërgohet përmes një shërbimi të vërtetuar të email-eve transaksionale dhe kontrollohet në kutitë reale të postës.
6. API-të e paguara dhe kostot e funksionimit
Veçoritë që thërrasin shërbime të jashtme të paguara – pasurimi i të dhënave, AI, harta, SMS – kanë kosto për përdorim që rriten me përdoruesit. Një prototip që është i lirë për t'u përdorur me dhjetë përdorues mund të jetë i shtrenjtë me një mijë.
Si e trajtojmë: ne vlerësojmë kostot e funksionimit gjatë përcaktimit, minimizojmë thirrjet e paguara të API dhe ruajmë aty ku është e mundur.
7. Ndërtuar në një mjedis, vendosur në një tjetër
Sistemet e zhvilluara në mjedisin tonë më pas kalojnë në serverin e klientit, me versione, leje dhe rregulla rrjeti të ndryshme.
Si e trajtojmë: ne sqarojmë mjedisin e synuar herët, përdorim konfigurime të kontejnerizuara aty ku është e mundur (për shembull Docker me një proxy të kundërt), dhe planifikojmë migrimin si një hap më vete.
8. Pyetje mbi pronësinë dhe IP
Në projekte më të mëdha, ka rëndësi kush zotëron çfarë: kod specifik për projektin, komponentë ekzistues, biblioteka të palëve të treta.
Si e trajtojmë: kontratat përcaktojnë pronësinë për fazë, duke dalluar teknologjinë bazë nga dorëzimet e projektit.
Përmbledhje
| Problemi | Masa jonë standarde |
|---|---|
| Rritja e shtrirjes | Lista jashtë shtrirjes, prapavija e versionit dy |
| Rregullat e biznesit të vonuara | Skenarët e shkruar të konfirmuar para ndërtimit |
| Asetet e munguar | Varësitë e kërkuara së pari |
| Dështime të heshtura të API | Trajtimi i gabimeve dhe alarmet |
| Email-e të sistemit që mungojnë | Email transaksional, plan i plotë testimi për email |
| Kostot e funksionimit | Vlerësimi i kostos, thirrje minimale të paguara |
| Ndryshimet në mjedis | Qartësi e hershme, kontejnerë, migrim i planifikuar |
| Pronësia | Përcaktuar për fazë në kontratë |
Ritmi i komunikimit
Një problem që qëndron nën disa nga ato të mësipërmet është komunikimi i parregullt. Heshtje të gjata të ndjekura nga grupe të mëdha reagimesh çojnë në surpriza nga të dyja palët. Në projektet e personalizuara ne punojmë me një ritëm të caktuar: një përditësim i shkurtër javor me atë që është bërë, çfarë është më pas dhe cilat vendime janë të hapura, plus një demo e softuerit funksional në fund të çdo faze. Klientët shohin progresin herët dhe keqkuptimet dalin në sipërfaqe ndërsa janë ende të lira për t'u rregulluar.
Fija e përbashkët
Pothuajse asnjë nga këto nuk janë thjesht teknike. Ato kanë të bëjnë me qartësinë: çfarë saktësisht duhet të ndërtohet, me çfarë inputesh, nën cilat rregulla, duke funksionuar ku, në pronësi të kujt. Sa më herët të përgjigjen ato pyetje, aq më lehtë ecën një projekt i personalizuar.
Pyetjet e Shpeshta
Si e parandaloni zgjerimin e qëllimit pa qenë të ngurtë?
Duke i bërë ndryshimet të dukshme. Idetë e reja janë të mirëseardhura; ato diskutohen dhe vendosen në një fazë, në vend që të shtohen në heshtje.
Po sikur të mos i dimë të gjitha rregullat ende?
Kjo është normale. Ne fillojmë me udhëtimin kryesor, konfirmojmë rregullat për të dhe ndjekim pyetjet e hapura. Faza të mëvonshme plotësojnë pjesën tjetër.
A testoni me përdorues të vërtetë?
Ne testojmë të gjitha rolet dhe skenarët brenda dhe rekomandojmë një grup të vogël përdoruesish të vërtetë para një lançimi të gjerë.
Pse projektet e softuerit të personalizuar kanë nevojë për një listë jashtë fushës?
Sepse idetë e reja shfaqen sapo njerëzit shohin softuerin që funksionon. Nga përvoja jonë, shkrimi i asaj që nuk është në versionin e parë është ajo që e mban një MVP në orar.
Si e testoni softuerin e personalizuar para lançimit?
Në një mjedis provë me të dhëna reale shembull, pasuar nga një raund testimi me njerëzit që do ta përdorin atë çdo ditë. Rastet e skajshme nga të dhënat reale gjejnë më shumë probleme sesa testet e skriptuara vetëm.
Po planifikoni një projekt softueri të personalizuar?
Nëse dëshironi një plan realist për projektin tuaj, rezervo një takim të shkurtër me ekipin tonë dhe ne do t'ju shpjegojmë fazat, çfarë na nevojitet nga ju dhe ku projektet si i juaji zakonisht humbasin kohë. Ju gjithashtu mund të shfletoni punën e përfunduar në portofolin tonë të softuerit të personalizuar.
Comments