Cred că o mare parte dintre problemele cu care se confrunta un proiect, în ceea ce privește implementarea, ar putea fi prevăzute și evitate înainte de a scrie vreo linie de cod, dacă s-ar parcurge, cu calm și poate o doză de detașament următorii pași:
Clarifică scopul proiectului
E un pas mare și important, însă tot pe atât de ignorat și ”pus la colț” când vine vorba de detalii tehnice. Eu vin din câmpul dezvoltării și programării de sait-uri web, și uneori se întâmplă ca clientul să fie foarte încântat de design-ul prezentat și să semneze contractul pe loc. Însă peste câteva săptămâni, aproape de lansare să realizeze că design-ul saitului e total ”afon” de scopul acelui sait. Da da, putem discuta zile în șir și să ajungem la concluzia că scopul unui sait e ”să vândă”, dar chiar ai nevoie de un design plin de briz-briz-uri pentru asta? – vezi Amazon
Așadar, ca programator e esențial să înțelegi scopul proiectului la care lucrezi. Asta te va ajuta să împarți cerințele clientului în versiuni să-ți programezi milestone-urile și desigur data când o versiune stabilă va ieși pe poarta ”laboratorului”.
Eh, da o să fie și proiecte al căror scop va suna așa: ”Sait nou pentru compania X”, ”re-branding pentru agenția Y” – dar dacă proiectul nu are un scop bine definit, poate că nici nu merită investiția de timp. Deci un pont pentru managerii de proiecte: faceți tot posibilul să vă convingeți programatorii că lucrează la ceva important.
Vezi ce au făcut și alții
De multe ori poți avea impresia că ești pus în fața unei probleme unice. Și în 1% din cazuri așa e. Deci pentru o mare parte din cazuri există posibilitatea ca cineva să fi abordat deja aceeași problemă și chiar să o fi rezolvat. Poate cu mici nuanțe dar în definitiv, a găsit o soluție. Acuma nu mă refer aici la chestii ca trimiterea unui newsletter sau crearea unui slideshow. Acesta nu sunt probleme, ci sunt task-uri. Dacă ai înțeles bine scopul proiectului, atunci înseamnă că ai o imagine a formei lui finale, deci de ce să nu vezi cum au abordat alții acest tip de proiecte?
Citește documentația
O mare parte dintre bug-urile cu care se confruntă programatorii, sunt un rezultat al faptului că nu au citit toată documentația. Sau uneori chiar nu au citit-o deloc. De fapt uneori ajung să re-implementeze o funcție care era deja într-o librărie standard. Deci revizuirea documentației, chiar dacă plicticoasă e vitală, înainte de a scrie cod.
Supune design-ul la use-cases
Acest task ar trebui executat de un tester, sau o personană responsabilă de QA, dar dacă nu e nici un ins cu asemenea etichetă prin preajmă, tu ca programator ar trebui să o faci, înainte de a scrie cod. Sfatul meu ar e să o faci oricum.
Când programezi pentru web, un buton în plus sau în minus nu e așa de greu de adăugat, dar ce te faci dacă butonul respectiv trebuie să aibă text în 4 limbi, și cuvântul corespondent din estoniană are 24 de litere :P . Da, se întâmplă așa des ca design-ul să ignore complet utilizatorul și să se axeze exclusiv pe a ”arăta bine”.
În consecință dacă nu-ți place să re-modelezi HTML și CSS (și mie îmi place tetrisul, dar uneori devine enervant :P ), supune design-ul la use-cases și dacă ceva ”dă cu virgulă” un project manager ar trebui să știe, înainte să începi să scrii cod.
