Introducere

În episodul 4 am observat că activele care nu au fost transpuse în cod sunt cele mai predispuse să devină moșteniri negative în viitor. Acum vrem să ne întrebăm din nou: este dezvoltarea cetățenească o modalitate de a construi sisteme de producție?

Răspunsul este clar: dezvoltarea cetățenească nu este destinată producției. În esență, ea reprezintă o „dezvoltare-schiță” ce transformă cerințele din perspectiva utilizatorului într-o formă funcțională.

Dacă ignorăm această perspectivă și credem că „dezvoltarea cetățenească = un instrument magic cu care oricine poate construi instant un sistem”, vom repeta istoria și vom produce din nou moșteniri negative. Să clarificăm ce înseamnă această „dezvoltare-schiță” și cum ar trebui folosită.

Întreaga serie

  • Intuirea viitorului dezvoltării cetățenești — istorie, prezent, IA generativă și ce urmează 0/7 (indisponibil încă în română)
  • Este dezvoltarea cetățenească revenirea EUC? — Lecțiile istorice ale lui Kami Excel 1/7 (indisponibil încă în română)
  • Kami Excel a fost cu adevărat „negativul”? — De la salvator la moștenire nocivă 2/7 (indisponibil încă în română)
  • Lumina și umbra platformelor moderne de dezvoltare cetățenească 3/7
  • Moștenirile pe care IA generativă le salvează și cele pe care le abandonează 4/7
  • Dezvoltarea cetățenească nu este atotputernică, este o „dezvoltare-schiță” 5/7 (această parte)
  • Perspectivele decalate produc pe bandă moșteniri negative 6/7 (indisponibil încă în română)
  • Legacy-ul continuă să se nască, dar poate fi îmblânzit — Viziunea viitorului dezvoltării cetățenești 7/7 (indisponibil încă în română)

Care este valoarea dezvoltării-schiță?

Aplicațiile și instrumentele create în dezvoltarea cetățenească sunt adesea privite drept „nefinisate” sau „brute”. Însă tocmai această „brutalitate” reprezintă valoarea lor.

Cerințele din perspectiva utilizatorului devin clare

Imaginează-ți o aplicație de management al clienților construită în low-code de către departamentul de vânzări. În ea se reflectă instinctele zilnice ale utilizatorilor: „dacă nu este așa, este incomod”.

  • Granularitatea câmpurilor de intrare
  • Ce informații vor să vadă pe lista principală
  • Cât de naturală este plasarea butoanelor și fluxul acțiunilor

Aceste detalii nu se transmit printr-o simplă „fișă de cerințe”. Chiar dacă descrii specificațiile în text, nuanțele și „senzația de pe teren” se pierd aproape complet. Doar un prototip funcțional scoate la suprafață reacții reale: „asta chiar e utilizabil” sau „în practică tot ar fi incomod”.

Identificarea rapidă a neînțelegerilor și lipsurilor

Mai mult, o schiță funcțională scoate la iveală din timp: „Avem nevoie de o căutare aici.” „Fluxul de aprobare trebuie să aibă două etape, nu trei.”

În dezvoltarea tradițională, specialiștii citeau documentația și proiectau pe baza imaginației. Rezultatul? După livrare, terenul spunea „nu e cum ne așteptam”, iar reparațiile deveneau rutină. Dezvoltarea cetățenească poate reduce drastic această risipă.

Capcanele transformării în producție

Totuși, nu trebuie să transformăm schița în producție ca atare. Acolo se ascund capcane majore.

  • Scalabilitate: funcționează într-un departament mic, dar la nivelul întregii companii performanța se prăbușește.
  • Securitate: controlul accesului sau gestionarea logurilor sunt superficiale și nu rezistă auditului sau cerințelor legale.
  • Mentenabilitate: dacă autorul pleacă sau este transferat, soluția devine o cutie neagră.

A afirma „schița are valoare” nu înseamnă că „poți lansa schița în producție”. Altfel repetăm povestea lui Kami Excel: salvator temporar, apoi povară moștenită.

Împărțirea responsabilităților cu specialiștii

Cum tratăm atunci rezultatele dezvoltării cetățenești? Răspunsul este limpede.

  • Cetățenii = construiesc schița: concretizează perspectiva utilizatorului și prezintă un prototip.
  • Specialiștii = realizează versiunea curată: reconstruiesc soluția astfel încât să respecte cerințele non-funcționale (scalabilitate, securitate, mentenabilitate).

Prin această împărțire, ambele părți își maximizează punctele forte. Cetățenii transpun „experiența directă din teren” într-un instrument. Specialiștii garantează „calitatea și sustenabilitatea” versiunii de producție.

Față de metodele tradiționale, unde specialiștii proiectau bazându-se doar pe documente, existența unei schițe permite discuții mult mai precise încă de la început. Rezultatul: dezvoltare mai eficientă și produse finale de calitate mai bună.

Ce trebuie protejat prin guvernanță

Pentru ca dezvoltarea cetățenească să rămână sănătoasă, sunt necesare reguli organizaționale.

  • Clarificare: stabiliți că rezultatele dezvoltării cetățenești sunt prototipuri cu domeniu de utilizare limitat.
  • Inventariere: introduceți procese periodice de curățare și eliminare a aplicațiilor sau roboților RPA abandonați.
  • Proces de transfer: instituționalizați predarea schițelor utile către departamentul IT, urmată de o versiune curată pentru producție.

Cu această guvernanță, riscul de a recrea moșteniri negative precum Kami Excel scade dramatic. În lipsa ei, dezvoltarea cetățenească devine doar un „generator de aplicații sălbatice” care amplifică datoria tehnică a organizației.

Concluzii

Dezvoltarea cetățenească nu este „un mecanism universal care permite oricui să creeze sisteme de producție”. Dar folosită ca „schiță”, reduce neînțelegerile și lipsurile în definirea cerințelor și permite proiectarea sistemelor ancorată în perspectiva utilizatorului.

Producția este responsabilitatea specialiștilor, schița este treaba cetățenilor. Respectând această împărțire, dezvoltarea cetățenească devine un punct de pornire pentru productivitate, nu o moștenire negativă.

Adevărata ei semnificație stă în „democratizarea procesului de definire a cerințelor”. Doar cu această înțelegere dezvoltarea cetățenească devine o forță sustenabilă pentru organizație.

Partea următoare: Perspectivele decalate produc pe bandă moșteniri negative 6/7