14 motive comune proiecte Software nu reușesc (și cum să le evite)

foto:

Getty

echipele tehnologice se aruncă adesea în noi proiecte software cu speranțe mari, ceea ce face cu atât mai frustrant dacă proiectul este deraiat. Liderii tehnologici trebuie să fie conștienți de potențialele capcane ale proiectului înainte de timp pentru a evita pierderea timpului și a bugetului.

experții Forbes Technology Council au supravegheat multe proiecte în mandatul lor profesional. Mai jos, 14 dintre ei împărtășesc motive comune proiectele software flounder și ce pot face echipele tehnologice pentru a evita căderea într-o capcană.

1. Neînțelegerea nevoilor afacerii

unul dintre motivele pentru care proiectele software eșuează este lipsa de înțelegere a nevoilor afacerii. Afacerea trebuie să articuleze în mod clar cerințele în detaliu. Trebuie să existe o cartografiere precisă a caracteristicilor și funcțiilor la nevoile afacerii. Atribuirea unui lider de afaceri experimentat echipei de proiect este esențială pentru succes. – Wesley Crook, FP complet

2. Incapacitatea de a ajunge la un consens cu privire la prioritățile

există diverse motive pentru care proiectele de dezvoltare software eșuează, dar unul comun care are un impact mare este atunci când sponsorii proiectului și echipele de proiect nu sunt clar aliniate la prioritățile de top pentru proiect. Descompunerea acestor priorități în” must-haves”,” ar trebui-haves „și” ar putea-haves ” poate oferi un cadru solid pentru iterarea și livrarea unor caracteristici particulare. – Jahn Karsybaev, Prosource it

3. Lipsa clarității și a Strategiei de execuție

scopul principal al unui proiect software este de a rezolva problemele unei afaceri. Aceasta necesită nu numai un management de proiect eficient și eficient și un management al așteptărilor părților interesate, ci și un consens clar al întregului grup de părți interesate cu privire la definirea problemei afacerii și o strategie robustă de execuție pentru a furniza software care rezolvă obiectivele afacerii. Eșecul de a aborda oricare dintre aspectele prezentate mai sus duce la un proiect deraiat. – Kartik Agarwal, TechnoSIP Inc.

4. Nu Începând cu clientul final

uneori, proiectele software încep cu o idee grozavă care este implementată (la timp sau târziu) și livrată doar pentru dezvoltatori pentru a descoperi că problema pe care au rezolvat-o nu era de fapt problema pe care clientul lor trebuia să o rezolve. Făcând munca grea de a-ți înțelege profund clienții, ceea ce au nevoie și pentru ce sunt dispuși să plătească stabilește plafonul performanței proiectului și poate ajuta la reorientarea unei echipe atunci când lucrurile deraiază. – Guy Yalif, Intellimize

5. Cerințe neclare

unul dintre cele mai frecvente motive pentru care proiectele software eșuează este cerințele neclare și lipsa unei explicații detaliate. Foarte adesea clienții înșiși nu sunt siguri exact ce vor să vadă și, ca urmare, proiectul nu poate merge mai departe. Comunicarea cu clienții dvs. și solicitarea viziunii lor detaliate asupra viitorului produsului este cheia pentru a vă asigura că proiectul nu va eșua. – Daria Leshchenko, SupportYourApp Inc.

6. Așteptând prea des un „glonț de argint”

, entuziasmul apare din falsa credință că un proverbial „glonț de argint” va rezolva o anumită problemă. Cu toate acestea, soluțiile adecvate sunt rareori atât de simple—sunt un amestec de metodologie, strategie și suport pentru echipă, nu rezultatul unei singure acțiuni, tehnologii sau idei. Liderii tehnologici ar trebui să încurajeze comunicarea deschisă și să impulsioneze procesul decizional al grupului participativ pentru a rezolva provocările. – Christopher Yang, Managementul Călătoriilor Corporative

7. Lucrul într-un siloz

cel mai mare motiv pentru care proiectele software eșuează este că echipele se angajează într-o călătorie pentru a construi ceva care fie nu este o nevoie de afaceri, fie nu abordează problema corectă. Ambele motive sunt rezultatul unei nealinieri între afaceri și tehnologie. Pentru a evita acest lucru, este crucial să identificați problema pe care afacerea încearcă să o rezolve și apoi să lucrați colectiv cu afacerea și nu într-un siloz. – Tanvir Bhangoo, Freshii inc.

8. Considerând că domeniul de aplicare poate fi definit în avans

deși este important să înțelegem problema și să definim cazurile de utilizare în avans, aproape niciun proiect nu poate fi considerat de succes dacă nu se adaptează la cerințele de afaceri în schimbare în timpul dezvoltării. Din păcate, unele Echipe tehnologice încă insistă să atingă obiectivul inițial, făcând astfel efortul lor ineficient sau chiar un eșec. – Song Bac Toh, Tata Communications

9. Lipsa de coordonare și planificare detaliată

multe proiecte software întârzie sau eșuează din cauza lipsei unei bune coordonări și a unei planificări detaliate. Echipele trebuie să implementeze un proces de planificare de jos în sus care identifică dependențele dintre rezultate și include estimări de la inginerii înșiși. După ce planul de lansare este setat, organizez întâlniri zilnice de stand-up de 15 minute în care apar probleme și sunt identificate și gestionate noi riscuri. – Dave Mariani, La Scară

10. Fricțiunea cauzată de roluri nedefinite

rolurile nedefinite creează adesea fricțiuni asupra echipelor de proiect. Încercați să utilizați un cadru DACI de la început pentru a defini în mod clar cine are autoritate asupra a ceea ce. Pentru proiectele blocate, recalibrarea cine este șoferul, aprobatorul, contribuitorul și informat în cadrul proiectului poate acționa ca o resetare hard, inspirând o colaborare și o autonomie reînnoite. – Leore Avidar, Lob.com Inc.

11. Asteptand Supracustomization de Software

deseori, noi credem că software-ul poate fi personalizat la un nivel care va adapta la toate nevoile. Aceasta este o concepție greșită. A fi realist este important. Definiți cerințele privind capacitatea software-ului. Efectuarea cererilor de schimbare pe măsură ce mergeți necesită ajustări, dar aceasta este pălăria care va trebui purtată pentru a evita frustrările. – Bhavna Juneja, Infinity, o companie de tehnologie Stamford

12. Lipsa disciplinei

dacă ar fi să construim o casă și să continuăm să schimbăm planul, bugetul proiectului ar scăpa de sub control și termenul limită după termen ar fi ratat. Creați o viziune despre cum arată succesul proiectului. Blocați – l și executați. Orice altă idee grozavă și ocol pot fi luate în considerare pentru o fază ulterioară a proiectului. – Sam Polakoff, Nexterus, Inc.

13. Prea multe mâini în Pot-ul Dev

stabilesc (și limitează) cine este implicat din prima zi, indiferent dacă construiești sau nu. Acest lucru poate fi dificil pentru companiile mai mari de tehnologie cu procese complexe și canale de comunicare. Dar, în lumea de dezvoltare app, o astfel de complexitate este în detrimentul crafting un produs pe deplin realizat, care se potrivește viziunea unică a tuturor, fără a cădea pradă domeniul de aplicare fluaj și o cronologie proiect fără sfârșit. – Joshua Davidson, ChopDawg.com

14. Nu este suficient accent pe abilitățile Soft

un accent clar și semnificativ pe gestionarea procesului de schimbare este adesea lipsit sau insuficient. Am văzut multe proiecte software în diferite categorii și într-o serie de tipuri și dimensiuni diferite de organizații care se confruntă cu provocări, deoarece sunt super-concentrate pe munca tehnică, dar nu aplică suficientă energie pentru formare, coaching, team building și abilități soft. – Amith Nagarajan, rasa.io