În cadrul unui proiect un programator i se cere să pună patru imagini într-o pagină de site. Programatorul realizează că are ceva timp la dispoziție, așa că decide să pună un slider cu galerie pentru cele patru imagini. Doar că, atunci când prezintă feature-ul, pe o anumită rezoluție sliderul nu funcționează corect. Clientul din departamentul de business, evident nemulțumit, îl întreabă de ce a pierdut timpul făcând acest extra feature “fancy” în loc să facă corect ce i s-a cerut în specificații. Evident, proiectul trebuie adus la forma cerută inițial.

În termeni de Project Management, ce a făcut programatorul respectiv se numește “gold-plating“. E o problemă contra-intuitivă ce apare des la programatorii lipsiți de experiență. Deși limitele specificațiilor sunt clare, ei fac ceva în plus în ideea de a se face remarcați. Din punctul lor de vedere asta dovedește proactivitate, putere de muncă, dorință de creștere, cunoștințe tehnice etc. Sau, uneori, iau decizia, fără a se consulta cu nimeni, că acel produs are neaparată nevoie de acel feature în plus. În cazuri mai rare, gold-plating-ul presupune crearea unui extra feature sexy/shinny pentru a ascunde problemele unui alt feature ce nu funcționează corect. Dar, de cele mai multe ori, gold-plating-ul este facut cu cele mai bune intenții.

Doar că orice feature ce nu a fost cerut poate aduce următoarele probleme:

Crește riscul Orice feature nou poate avea bug-uri. Sau probleme de integrare. Sau probleme de licențiere. Toate aceste riscuri nu au fost luate în calcul de Project Manager și pot afecta proiectul.

Devine sursa problemelor Ca în exemplul de mai sus, în ochii clientului extra feature-ul va fi de vină pentru orice problemă pe care o va avea proiectul. Chiar dacă nu are o legătură directă cu problema respectivă.

Creează probleme de business Programatorul nu cunoaște de cele mai multe ori care este logica de business din spatele unui feature ce i-a fost cerut. Așa că orice modificare necerută a acestui feature poate crea probleme viitorilor utilizatori ai produsului.

Crește costul Orele ce au fost alocate de programator acelui extra feature, puteau fi folosite altfel. Practic programatorul a lucrat la ceva ce nu a fost plătit. Not a good business. În plus, dacă extra feature-ul nu este dorit, vor trebui alocate alte ore pentru a aduce produsul la forma dorită inițial.

Crește așteptările Chiar dacă extra feature-ul a fost văzut ca un succes de către client, la toate proiectele viitoare acesta se va aștepta să primească iar mai mult decât a cerut. Iar dacă nu va primi în plus de fiecare dată, va fi dezamăgit. E o strategie sigură spre eșec.

Creează neîncredere La vederea unui extra feature  shinny creat de un freelancer, clientul își va pune diverse probleme: ce probleme încearcă să ascundă ? am plătit prea mult dacă a avut timp și disponibilitate să facă muncă în plus? pot profita de faptul că mă consideră un client important și să plătesc mai puțin?

 

Rolul programatorului nu este de a inventa valoare, ci de a executa cât de bine se poate ce i-a fost cerut.
Odată ce cerințele pentru proiectul respectiv au fost definite și totul planificat, orice mică modificare presupune niște riscuri. De aceea programatorul trebuie să colaboreze strâns cu Project Managerul, astfel încât să reducă la minim riscul apariției acestor riscuri.

Dacă ești programator și te gândești să faci ceva în plus pentru proiect, oprește-te. Vorbește cu PM-ul și analizați împreună dacă e o idee bună sau nu.
Dacă ți se pare că ai timp liber și că poți face un feature mai mișto decât ce ți s-a cerut, cere aprobarea PM-ului. Până primești răspunsul, ieși la o cafea, stai pe Facebook sau orice altceva. Doar nu lucra la ceea ce te gândești. Poate fi mai rău.

 

Ce este gold-plating-ul in dezvoltarea software

9 thoughts on “Ce este gold-plating-ul in dezvoltarea software

  • September 21, 2017 at 12:39
    Permalink

    Problema are două fețe, iar pe cealaltă nu prea ai pomenit-o. Intuitia și experiența unui programator s-ar putea să-i spună că un feature, chiar dacă nu e menționat, va fi util.

    În exemplul cu slider-ul tău: chiar dacă nu e trecut la cerințe, cel mai probabil va fi nevoie de cel puțin două formate de imagini (wide/portrait).

    Ca programator poți gândi în waypoint-uri trasate de client/project manager sau poți gândi proactiv, corectând/ajustând/completând specificațiile eronate. Mai ales în cazul în care se lucrează remote și pe fusuri orare diferite.

    Secretul, de fapt, este să găsești un echilibru între a fi proactiv și a introduce features inutile.

    Reply
    • September 21, 2017 at 12:50
      Permalink

      Intuiția și experiența sunt super apreciate, exact pentru că găsesc potențiale probleme.
      Extra feature-ul poate trebuie făcut, dar nu independent de către un programator de tip “lup singuratic”.
      Înainte să se facă trebuie să se analizeze (de PM sau clientul final) care sunt implicațiile.

      Reply
    • September 21, 2017 at 18:38
      Permalink

      Și totuși sunt puțini programatori care chiar cunosc bine și domeniul de business. “Corectând/ajustând/completând specificațiile eronate” este ca și cum ai spune că clientul nu știe ce vrea sau business analistul nu înțelege nevoia clientului. Totuși sunt de acord că în anumite situații trebuie să fim proactivi în anumite limite.

      Reply
  • September 21, 2017 at 18:44
    Permalink

    Chestiile mentionate in articol, sunt intr-adevar, relevante si posibile, la un programator foarte, foarte incepator. Dar hai sa va zic o alta chestie. Voi ati intalnit multi clienti care stie exact ce vor ? Ca eu… nu prea. Si-am lucrat cu destui in aproape 30 de ani de IT.
    Deci poate… si programatorul ala incepator, stie mai bine de ce are nevoie clientul, decat clientul. Clientul de cele mai multe ori are aere in cap, preconceptii, chestii de genul eu vreau slider pentru wordpress da’ sa fie facut in python, sau vreau ceva simplist pentru a urmari telefoanele din firma, da’ sa fie facut in corel draw. Ca… nah, au auzit si ei expresii “complexe” si se dar mari cu expresiile respective.

    La fel si 99% din “donsoarele” sau feciorii lu’ mama care intocmesc acele “specificatii”
    Cei mai in varsta.. tineti minte “instructiunile ” lu nea’ Ceasca, RIP ?
    Lasati domne’ arhitectii sa faca arhitectura, designerii sa faca design, si programatorii sa faca programare. Nu ma intereseaza in nici o forma cum afiseaza un site rezultatele, pe care le genereaza un cod facut de mine, in backend, daca designul e treaba altuia.
    Da’ nici nu poti lucra pornind cu mentalitati ca “asta e specificatia, trebuie respectata”. Chestii de genul ala se fac cu roboti, nu cu oameni care gandesc.
    Omul care gandeste, mai pune intrebari, mai contreaza, mai modifica, si eventual cade de acord. Pt ca… vorba colegului de la devforum, daca esti robotel bun si nu gandesti proactiv, o sa-ti para rau mai tarziu

    Reply
  • September 22, 2017 at 00:19
    Permalink

    In mod amuzant, nu stiam ca are un nume dar am facut si eu asta. Dar nu ca programator fara experienta. Ca junior si dupa, nu m-am legat la cap fara sa ma doara. Mai tarziu… alta viata. Am facut-o pentru ca am vrut, am stiut perfect ce fac si ce implicatii are (inclusiv cea de marirea asteptarilor clientului, nu m-a deranjat ptc taskurile erau si simple si supraestimate de project manager si imi permiteam si stiam ca pot sustine in continuare trendul fara sa ma deranjeze). Cred ca cel mai bine spus, am facut-o din mandrie. Dar nu o fac des si cand o fac, il fac pe client sa inteleaga intr-un mod diplomat si dragalas ca a fost un ‘cado’ si nu e ceva obisnuit si mereu a fost multumit chiar si de atat. Eu in general am avut (din fericire si ma bucur) feedback pozitiv la gold-plating fara probleme in viitor. poate e un caz neobisnuit. Si da, precum a spus cineva, de multe ori se intampla ca gold-platingul sa fie de fapt intuitia programatorului cu privire la un fapt ce i-a scapat clientului, si l-ar fi dorit si a uitat sa zica si se bucura sa vada ca a fost implementat, fara a se gandi ca e ceva special deci win-win

    Reply
  • September 26, 2017 at 12:36
    Permalink

    Expresii precum “ei fac ceva în plus în ideea de a se face remarcați.” ma fac sa cred ca articolul fie este o gluma sau un marketing stunt fie a fost scris de “un junior” devenit peste noapte ” un senior”.
    Nu cred ca sunt programatori, sau chiar oameni punct, carora sa le placa ceea ce fac si sa coloreze doar intre linii pentru ca asa li s-a spus sau mai exact: “limitele specificațiilor sunt clare”.

    Din punctul meu de vedere nu asta ar arata, in special un junior: “Din punctul lor de vedere asta dovedește proactivitate, putere de muncă, dorință de creștere, cunoștințe tehnice etc.”. In loc sa tragem astfel de concluzii poate ar fi mai bine sa stam de vorba putin cu acea persoana si sa vedem ce l-a impins cu adevarat sa ia aceasta decizie. PArerea mea e ca ar ajuta cu mult mai mult si ar face si “juniorul” sa se simta apreciat si nu ridiculizat cum reiese din acest articol.

    “În cazuri mai rare, gold-plating-ul presupune crearea unui extra feature sexy/shinny pentru a ascunde problemele unui alt feature ce nu funcționează corect.” – aceasta este iarasi o idee preconceputa si care da dovada de lipsa de maturitate a “sefului” echipei. Da, am zis sefului si nu liderului, pentru ca un team leader nu ar pune astfel problema. Si totusi, daca acel junior s-a gandit la acest scenariu eu as sugera sa-l incurajati pentru ca e clar ca intai pune interesul firmei la care lucreaza, sa iti asumi raspunderea de a acoperi pe cineva nu e usor, iar in al doilea rand arata maturitate in gandire prin faptul ca se gandeste in avans si nu ca un simplu robotel “blocat” la linia curenta.

    Si acum ajungem la afirmatia mea cum ca acest articol e scris de un “over night made senior”:
    – “Crește riscul Orice feature nou poate avea bug-uri” – mai intai, cred ca pentru asta avem in echipa acele persoane cu titulatura de TESTER, iar mai apoi in ce proiecte ati lucrat in care nu ai avut macar un bug sau cel putin parerea clientului sa fie diferita de implementarea ta?
    – “Devine sursa problemelor … în ochii clientului extra feature-ul va fi de vină pentru orice problemă pe care o va avea proiectul. Chiar dacă nu are o legătură directă cu problema respectivă.” – nici nu stiu de unde sa incep cu ideea asta. Aici cred ca mai bine s-ar face o analiza a modului de comunicare cu clientul decat a modului de lucru a unui “junior”
    – “Programatorul nu cunoaște de cele mai multe ori care este logica de business din spatele unui feature ce i-a fost cerut.” – pentru astfel de scenarii sunt acele concepte si metode de project management, SCRUM, KANBAN fiind doar doua dintre cele mai populare. Ideea de baza a acestor metode este ca TOATA echipa participa la planificarea unui feature si nu doar “seful” pentru ca el trebuie sa stie si sa ia decizia asta.
    – “Crește așteptările Chiar dacă extra feature-ul a fost văzut ca un succes de către client, la toate proiectele viitoare acesta se va aștepta să primească iar mai mult decât a cerut. Iar dacă nu va primi în plus de fiecare dată, va fi dezamăgit. E o strategie sigură spre eșec.” – asta trebuie sa recunosc ca m-a facut sa pic din scaun. Draga, autorule! Tu daca mergi sa-ti cumperi cafea inainte de a ajunge la birou si intr-o dimineata o domnisoara draguta, “junioara” la vandut cafea, iti pune un pic mai mult pentru ca i se pare ca esti ingandurat si ti-ar prinde bine un zambet de dimineata, oare cum ai reactiona? I-ai spune ca de acum o sa vrei ceva in plus in fiecare dimineata altfel isi pierde clientul? Sau poate i-ai zambi si i-ai multumi, poate si un mic bacsis!?
    – “Creează neîncredere La vederea unui extra feature shinny creat de un freelancer, clientul își va pune diverse probleme: ce probleme încearcă să ascundă ?” – oare chiar cu o idee mai inainte nu ziceai ca va face clientul sa vrea mai mult de fiecare data? Cum poate fi si una si alta? Eu nu am avut pana acum clienti carora sa le livrez ceva in plus si sa ma ia la bani marunti. Nici cand am dat-o in bara. Parol!

    “Rolul programatorului nu este de a inventa valoare, ci de a executa cât de bine se poate ce i-a fost cerut.”
    Iar acest paragraf e ceea ce face diferenta intre un “SEF” si un team leader. Un team leader inspira coechiperii sa mearga mai sus in schimb ce un sef stie doar sa-i tranteasca de pamant. Poate sunt eu mai flower power insa sa stii ca programatorii aia carora le pasa si le face placere sa programeze NU SUNT ROBOTI. Poate articoul tau facea referire la un nou tip de AI?!

    Si ca sa nu ma mai lungesc pentru ca deja comentariul meu cred ca e mai lung decat articolul, vreau sa zic ca acest pasaj e singura idee buna, din punctul meu de vedere, din intreg articolul asta: “programatorul trebuie să colaboreze strâns cu Project Managerul”. Asta ar trebui sa fie singura “lege” in cadrul unei echipe.

    Reply
    • September 26, 2017 at 13:03
      Permalink

      Denis, faptul că începi comentariul cu o presupunere/atac la persoană, în mod normal m-ar face să ignor restul. Dar apreciez faptul că ți-ai argumentat opiniile, așa că îți răspund.

      Toate opiniile din articol vin din ideea că cred mult mai mult în programatorul integrat într-o echipă, foarte bun pe domeniul lui, decât în programatorul atotștiutor, de tip “lup singuratic”.

      Unde ai dreptate e punctul legat de Scrum și Kanban. Da, corect, genul ăsta de probleme apar mai rar când se folosește o metodologie agilă, din simplul motiv că ciclul de execuție-control este mult mai scurt. Să nu uităm totuși că metodologiile agile sunt doar derivate ale metodologiei clasice de project management și se folosesc doar în domenii specifice (IT) și doar în anumite cazuri (proiecte mici-medii, specificații inițiale neclare, echipe cu experiență).
      Legat de asta, opinia mea e că pe termen mediu-lung, pe măsură ce programarea devine o meserie în care se intră tot mai ușor, rolurile vor începe din nou să se împartă foarte clar: business și execuție.

      Înțeleg părerea ta de acum – e bazată pe experiența proprie. Însă toate punctele expuse de mine sunt analizate, definite, explicate și bazate pe experiența a zeci/sute de mii de project manageri de-a lungul timpului.
      Legat de experiența mea, am 12 ani de experiență în Java și sunt Project Manager certificat PMP.

      Reply
      • September 26, 2017 at 14:07
        Permalink

        Multumesc pentru feedback si incep prin a spune ca imi pare rau daca ti s-a parut ca fiind un atac la persoana comentariul meu. Nu a fost intentia si voi lua masuri pe viitor.
        Revenind la reply-ul tau: mentionezi ca vorbesti despre programatorul de tip “lup singuratic”. As dori sa-ti spun ca din punctul meu de vedere acest aspect nu se vede in articol. Ba as zice ca e chiar opusul. Fapul ca un programator este freelancer, pentru ca la acest tip inteleg ca te referi, nu inseamna ca este “junior”, “lipsit de experienta” sau mai mult de atat ca este “atotstiutor”. Mediul in care lucram si tehnologia ne permite sa lucram de oriunde. Faptul ca cineva alege sa nu fie constrans de un birou nu sunt de parere ca trebuie clasificat automat ca fiind “junior”.
        Mentionezi mai apoi in raspunsul tau ca Scrum si Kanban sunt metode folosite doar in domenii specifice, precum IT-ul, si doar in proiecte mici si medii. Aici iarasi nu sunt de acord cu tine datorita experientei acumulate. Am lucrat in echipe de 3 oameni dar si in echipe de 50 de oameni raspanditi pe 3 timezone-uri si in toate cazurile metoda SCRUM a fost de foarte mare ajutor. In special in definirea mai clara a task-urilor si chiar si a implementarii – aici ma refer la discutiile pe care echipa le are cand se face analiza task-urilor in vederea estimarii lor si a planificarii sprint-ului.
        Referitor la ideea ca aceste metodologii sunt folosite doar in IT as vrea sa-ti atrag atentia asupra faptului ca cel putin KANBAN vine din domeniul auto, mai exact de la Toyota. Faptul ca noi auzim despre aceste metode doar in cadrul firmelor de IT cred ca se datoreaza mai mult din mediului in care lucram 🙂 si a gandirii inca inradacinate in trecut a multor manageri autointitulati.
        Desi se pare ca avem puncte de vedere diferite, si asta e perfect normal, sunt in totalitate de acord cu tine in faptul ca piata, in special la noi, incepe ca ceara din ce in ce mai multi specialisti. Insa, cred ca deviem din nou si dupa cum ziceam mai devreme aceasta idee nu reiese din nici un paragraf al articolului.

        PS: Poti share-ui un link cu un studiu la care faci referire in penultimul paragraf? Sunt foarte interesat sa studiez astfel de chestii.

        Acum ma intorc la sedinta cu “juniorii” pentru ca avem de planificat urmatorul sprint.

        Reply
  • September 26, 2017 at 14:34
    Permalink

    N-am zis nicăieri că freelancer-ul și programatorul remote trebuie considerați juniori. Dimpotrivă, cred că lucratul cu succes astfel e o dovadă clară de senioritate.
    Legat de Kanban…c’mon, știi la ce mă refer, Kanban de la Toyota și Kanban din software n-am în comun decât niște principii.

    Prin studiu mă refer la “PMBOK Guide”, manualul de Project Management. Despre gold plating se vorbește în capitolul “Project Scope”, dacă nu mă înșel.
    M-ai făcut curios cu Scrum cu echipă de 50 de oameni. Vorbeau 50 la daily scrum? Sau, de fapt, erau mai multe echipe?

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *