Citizen Development sau Dezvoltarea Civilă a fost poziționată de mulți ca o soluție aproape magică la o multitudine de probleme, în special de către furnizorii de platforme și consultanții care le înconjoară.
Concluzia noastră este că soluția de Citizen Development, așa cum este concepută popular, în mare parte nu a funcționat.
Au existat excepții de la această regulă, și au fost minunate. Dar au fost implicate circumstanțe unice pentru majoritatea dintre ele, iar rezultatele au fost mai mult accidente fericite decât rezultate planificate.
O persoană cu titlul de Citizen Developer este un utilizator ale cărui responsabilități nu constau în dezvoltarea de aplicații, dar care alege totuși să creeze aplicații, de obicei cu utilizare locală și folosind instrumente low-code/no-code.
Ce este Citizen Development?
Avem nevoie de o înțelegere comună a problemei înainte de a merge mai departe. Termenul "Citizen Development" a fost aplicat unei varietăți largi de lucruri, în așa măsură încât termenul estepe punctul de a-și pierde sensul.
Următoarea definiție ar trebui să fie acceptată de majoritatea oamenilor care au examinat fenomenul în ultimul deceniu:
Un Citizen Developer este un utilizator ale cărui responsabilități nu constau în dezvoltarea de aplicații, dar care alege totuși să creeze aplicații, de obicei pentru utilizare locală și de obicei folosind instrumente low-code/no-code.
Cu toate acestea, termenul este într-adevăr suprautilizat. A fost folosit pentru a se referi la orice dezvoltare low-code/no-code, chiar și atunci când este realizată de profesioniști. A fost folosit pentru a se referi la orice dezvoltare ad-hoc a prototipurilor, chiar și dacă este scrisă cu cod personalizat.
Nu ne concentrăm asupra acestor cazuri marginale; dacă ceva, ele sugerează că cineva care folosește termenul "dezvoltare civilă" în aceste moduri nu înțelege foarte bine fenomenul. Având aceste aspecte stabilite, să continuăm.
Cum a luat naștere Citizen Development?
Ce ar motiva un non-dezvoltator să dezvolte aplicații? O combinație a două probleme care există de mult timp:
Problema 1: Backlog-ul de aplicații
Rareori se întâmplă ca nevoile organizației pentru aplicații noi sau actualizate să fie satisfăcute cu ușurință, într-un interval de timp acceptabil și cu resurse disponibile. Pentru majoritatea dintre noi, cererea depășește oferta. Au fost propuse mai multe metode pentru abordarea backlog-ului de aplicații de-a lungul anilor. Acestea variază de la limbaje diferite, metodologii diferite, instrumente diferite etc., până la construirea de centre interne de excelență IT, la externalizarea agresivă și frecventă a proiectelor. Toate au întâmpinat, să spunem frumos, un succes mixt.
Problema 2: Decalajul dintre părțile interesate și dezvoltator
În multe cazuri, persoana care dezvoltă o soluție nu are o înțelegere nativă a problemei de afaceri care trebuie rezolvată. Aceasta înseamnă că, într-un fel sau altul, dezvoltatorul trebuie să fie învățat de către utilizator ce este necesar. Înseamnă și că utilizatorul trebuie să fie învățat ce este posibil din punct de vedere tehnic. Aceasta nu funcționează întotdeauna. Unele abordări angajează oameni special pentru a acționa ca intermediari și interpreți, oferindu-le titluri precum analist de sisteme sau (în unele cazuri) manager de produs. Alte abordări implică cicluri scurte de dezvoltare pentru a permite verificări frecvente cu părțile interesate și utilizatorii.
Ambele abordări, și majoritatea celorlalte, încă văd problema ca pe o evaluare a cerințelor, elaborarea a ceea ce reprezintă un contract și lucrul spre îndeplinirea contractului.
Problema cu aceasta este că, cel mai adesea, rezultă în faptul că părțile interesate și utilizatorii spun ceva de genul "este exact ceea ce am cerut, dar nu este ceea ce vreau."
Soluții propuse
Backlog-ul a fost o preocupare care precede introducerea tehnologiei informației în lumea afacerilor. Oameni deștepți și-au dedicat multă atenție problemei; cele mai multe, dacă nu toate soluțiile propuse implică una din cele trei abordări:
- Schimbarea instrumentelor.
- Schimbarea procesului.
- Schimbarea oamenilor.
Schimbarea instrumentelor constă în găsirea unui set de instrumente și/sau platforme care să facă dezvoltatorii mai productivi. Cadre de lucru, servicii, limbaje, medii low-code, instrumente de dezvoltare rapidă a aplicațiilor (RAD) - lista nu este fără sfârșit, dar este lungă.
Este admirabil, dar chiar și când funcționează cel mai bine, se ocupă în mare parte de problema backlog-ului, nu a problemei deconectării. Dezvoltatorii încă nu înțeleg ceea ce au nevoie și/sau doresc utilizatorii și stakeholderii.
Schimbarea procesului implică introducerea de noi metodologii; acestea sunt răspândite peste tot și unele dintre ele se referă la același lucru cu diferențe subtile.
Este posibil să fi auzit de prototiparea rapidă, programarea extremă, dezvoltarea agilă, dezvoltarea aplicațiilor comune, dezvoltarea Lean, dezvoltarea scrum și așa mai departe.
Aceste abordări au valoare - în multe cazuri, o valoare mare. Cu siguranță pot reduce backlog-ul, cu condiția ca cerințele să nu se extindă pentru a se potrivi cu timpul și resursele disponibile. Unele dintre ele pot reduce deconectarea dintre stakeholderi și dezvoltatori, dar depinde mult de cine sunt stakeholderii și ce rol li se permite (și doresc să) joace.
Schimbarea oamenilor, spre deosebire de cele două opțiuni anterioare, este o dezvoltare comparativ recentă. Este conceptul central tăcut din spatele Citizen Development. Ne vom concentra pe aceasta pentru restul acestui whitepaper.
O privire în amănunt asupra Citizen Development
Nu ar trebui să ne surprindă faptul că definiția Citizen Development e cel puțin lacunară.
Termenul este derivat din conceptul clasic al soldatului civil, un membru nonprofesionist al populației unei națiuni care poate, atunci când este necesar, să ia armele și să ajute la apărarea regatului.
Uneori, o populație formată din soldați civili operează în locul unei armate profesioniste. Uneori, soldații civili extind capacitatea unei armate profesioniste. Conceptul nu este nou și nu este izolat; nu este dificil să vedem termenul aplicat în Roma antică, Franța napoleoniană și Elveția de astăzi, de exemplu. Extrapolând din aceasta, am putea (și probabil ar trebui să) concluzionăm că: Citizen Development reprezintă construirea de aplicații realizată de dezvoltatori non-profesioniști.
Prin "non-profesionist", ne referim la faptul că dezvoltarea care se face nu face parte din munca obișnuită.
- Citizen Development poate și uneori chiar implică scrierea unui cod. Aceasta poate varia de la interogări SQL la formule Excel până la scripturi PowerShell sau JavaScript/Python/C#.
- Citizen Development este mai frecvent asociat cu instrumente low-code/no-code și pentru ca non-profesioniștii să fie implicați, renunțarea la cod ajută.
- Procesul de Citizen Development ar putea să fi avut o anumită pregătire formală, dar cei mai mulți dintre dezvoltatori sunt susceptibili să fi fost autodidacți prin experimentare sau studiu independent. Șansele să fi urmate vreo metodă formală de dezvoltare sunt mici.
- Proiectele dezvoltatorilor tind să fie (dar nu trebuie să fie) de mică amploare, adesea pentru baze de utilizatori de o singură persoană - dezvoltatorii individuali înșiși.
Unde a fost Citizen Development utilizat cel mai activ?
Unii analiști au sugerat că Citizen Development ar trebui tratat ca inevitabil și tolerat, dacă nu încurajat. Susținătorii practicii cred că dezvoltarea civilă este locul unde are loc inovația și IT ca locul unde are loc curatarea (sau mai degrabă, „sisteme de inovare” vs. „sisteme de înregistrare”).
Citizen Development tinde să fie de natură foarte personală, conceput pentru a calma un fel de mâncărime. Mâncărimea în cauză ar putea fi percepută timp pierdut, bani cheltuiți în afara grupului dacă nu a companiei etc.
Citizen Development ar putea implica, de asemenea, automatizarea sarcinilor care sunt fie obositoare, fie predispuse la erori. De fapt, automatizarea acestora duce la scăderea costurilor de formare.
Ar putea implica, de asemenea, îmbunătățirea calității și/sau cantității rezultatelor personale.
Este posibil, totuși, ca Citizen Development să fie încercat, deoarece o nevoie cu un public mai larg nu va fi abordată de IT pentru o perioadă inacceptabil de lungă.
Speranțele din spatele Citizen Development
Cele mai optimiste aspirații ale Citizen Development se rezumă la două beneficii cheie:
- Dacă fiecare cetățean (angajat) poate construi aplicații, numărul disponibil de generatori de aplicații se extinde, iar numărul de solicitări în așteptare scade la aproape zero.
- Dacă cetățenii sunt utilizatorii și dezvoltatorii, nu va exista nicio deconectare între părți interesate și dezvoltatori și nu vor exista probleme de comunicare, deoarece nu va fi nevoie de comunicare.
Ipotezele din spatele dezvoltării cetățenilor
Pentru ca dezvoltarea civilă să aibă un avantaj, trebuie realizate câteva ipoteze, fie implicit, fie explicit:
- Abilitățile necesare pentru a dezvolta aplicații nu sunt la îndemâna non-dezvoltatorilor. Acest lucru se datorează faptului că angajații sunt acum mai pricepuți la dezvoltare, fie pentru că instrumentele sunt acum mai ușoare.
- Angajații doresc să creeze aplicații pentru ei înșiși.
- Singura problemă reală de rezolvat este construirea unei soluții, moment în care cetățenii se pot reorienta asupra îndatoririlor lor principale. Lucruri precum instruirea, depanarea, crearea de profiluri, monitorizarea, auditarea, continuitatea serviciului sunt fie non-probleme, fie sunt tratate „în alt mod”.
Unele dintre aceste presupuneri sunt mai realiste decât altele.
Citizen Development și dezvoltarea low-code/no-code
Trebuie să ne oprim o clipă și să subliniem între paranteze că, prea des, oamenii cu o perspectivă îngustă asupra acestui subiect tind să echivaleze dezvoltarea civilă cu dezvoltarea low-code (sau chiar fără cod).
Ar fi o greșeală.
În primul rând, cel mai mare număr de utilizatori ai instrumentelor de dezvoltare low-code/no-code sunt dezvoltatori profesioniști. Astfel de instrumente ajută la accelerarea proiectelor și la obținerea unor rezultate mai consistente și mai ușor de înțeles.
Desigur, atunci când dezvoltarea civilă este finalizată, aproape întotdeauna se face cu un set de instrumente low-code/fără cod. Aproape. Există cazul hibrid al scripturilor, care este, fără îndoială, cod, în ciuda protestelor autorilor săi.
În cea mai mare parte, totuși, este sigur să ne gândim la Citizen Development ca fiind un subset al dezvoltării low-code/fără cod.
Care a fost rezultatul?
Un număr destul de mare de companii și organizații au încercat Citizen Development. Când a trecut de testele inițiale, au existat două teme consecvente pentru rezultatele observate:
Au fost construite mai multe aplicații
Această așteptare a fost cu siguranță îndeplinită. Dacă utilizatorii ar fi dispuși să devină dezvoltatori cetățeni și au creat aplicații, numărul de aplicații care au intrat în testare pilot, dacă nu producția completă, a crescut într-un grad vizibil. Acesta a fost exact prin proiect.
A fost consumat mai mult timp
Acest rezultat este unul care ar putea fi înregistrat sub „consecințe nedorite”. Este imposibil să obțineți ceva pentru nimic și, în acest caz, efectul a fost cel mai vizibil în ceea ce privește modul în care a fost petrecut timpul. Specific:
- Dezvoltatorii civili nu vor face această muncă în timpul lor liber. Timpul petrecut pentru construirea unei aplicații este timpul fără a face lucrări de design grafic, sau pregătirea bugetelor, sau supravegherea liniilor de producție și așa mai departe.
- Au existat distrageri. În multe cazuri, IT-ul a trebuit să distragă timpul pentru a sprijini eforturile de dezvoltare a cetățenilor, fie pentru a oferi instruire, pentru a rezolva probleme etc. Este asemănător cu a face singur o reparație la casă și, în cele din urmă, a trebui să cheme un antreprenor pentru a termina (și adesea repara) lucrarea.
În unele cazuri extreme, dacă totul a mers bine și o aplicație dezvoltată de cetățeni devenea populară, timpul a fost consumat atât de dezvoltator, cât și de IT, lucrând la modalități de extindere a soluției pentru a se adapta la sarcina mai mare, bazele multiple de utilizatori, cerințele noilor utilizatori, etc.
Aceasta a fost uneori o fază temporară prin care au trecut organizațiile și uneori a devenit un set constant de circumstanțe.
Au fost organizațiile fericite?
CIMI Corporation, o companie de consultanță în management și tehnologie cu sediul în New Jersey, SUA, a efectuat un sondaj în 2018 asupra organizațiilor din Statele Unite. Întrebat despre proiectele de Citizen Development:
- 54% au fost considerați un eșec în primul lor an
- 28% au avut rezultate marginale
- < 20% au fost un succes clar
Faptul că unul din cinci proiecte au fost un succes nu este o statistică rea, dar cu siguranță nu este o îmbunătățire. Esti surprins? Descoperă cum abordarea alternativă - Citizen Assisted Development te poate ajuta să îți creșteți afacerea. Cu adevărat.
