„E doar o clipă”
Oricine lucrează la crearea sau întreținerea unui site web, aplicații sau sisteme cunoaște acest mesaj.
„Puteți doar schimba acest buton?”
„E cu adevărat o modificare mică.”
„Vă rog doar să mutați acest element.”
„Se poate face repede?”
„Cred că sunt 5 minute de muncă?”
Și uneori chiar așa este.
Uneori schimbarea culorii unui buton durează câteva minute. Uneori corectarea unei greșeli de scriere necesită un singur click. Uneori dezvoltatorul deschide codul, se uită, modifică o linie și gata.
Problema este că nu orice modificare care pare mică din perspectiva utilizatorului e mică din perspectiva sistemului.
Și apare o problemă și mai mare când astfel de „modificări mici” sunt câteva zeci sau sute pe lună. Atunci începe să se întâmple ceva interesant.
Compania poate avea impresia că nu comandă mare lucru. Iar echipa IT petrece o parte semnificativă din timp făcând tocmai aceste sarcini mici.
Și aici apare întrebarea: Cât costă cu adevărat un buton „Remediați asta rapid”?
Să începem cu un exemplu simplu
Să ne imaginăm că departamentul de marketing trimite către software house un mesaj:
„Hei, trebuie doar să schimbăm textul de pe buton. În loc de „Verifică oferta” ar trebui să fie „Cunoaște oferta”. E ceva mic, vă rog, faceți rapid.”
Sună banal. Dar din perspectiva echipei tehnice poate arăta complet diferit.
Dezvoltatorul trebuie să:
1. Analizeze solicitarea
Unde se află acel buton?
Este doar într-un singur loc?
Apare în mai multe versiuni ale paginii?
Textul este scris direct în cod?
E gestionat prin CMS?
Schimbarea se referă la versiunea desktop și mobil?
Butonul face parte dintr-un component folosit și în alte locuri?
2. Introducă modificarea
Schimbă textul.
Refactorizează componentul.
Actualizează conținutul în CMS.
Sau modifică codul.
3. Verifice efectul
Arată butonul în continuare corect?
Textul nu iese din aria lui?
Pe telefon totul funcționează?
Nu a afectat alte locuri?
4. Testeze
Se poate da click?
Linkul duce unde trebuie?
Nu a apărut vreo eroare?
5. Deploy-eze modificarea
Dacă schimbarea necesită deploy, trebuie pusă în mediul de producție.
Și dintr-o dată se dovedește că: „Doar schimbare de text”
nu înseamnă neapărat: „Doar 5 minute de muncă”.
Cât poate costa o modificare mică?
Să presupunem un scenariu foarte conservator.
Dezvoltatorul alocă:
- 15 minute pentru analiză,
- 20 minute pentru implementare,
- 15 minute pentru teste,
- 10 minute pentru pregătire și deploy.
În total: 60 de minute de muncă.
Și aici ajungem la un punct important. Dacă tariful orar al echipei este, să zicem, 200 lei net pe oră, o modificare aparent mică costă aproximativ: 200 lei net.
Dar asta nu e tot. În procesul real pot apărea:
- transferul sarcinii,
- precizări asupra cerinței,
- întrebări către client,
- așteptarea unui răspuns,
- verificarea rezultatului de către cel care a solicitat,
- corecții după feedback,
- deploy-uri repetate.
O oră se poate transforma foarte ușor în două. Iar o schimbare mică în câteva ore de muncă ale întregii echipe.
Cel mai scump nu este executarea schimbării
Poate părea paradoxal. Uneori execuția în sine durează 10 minute. Dar pregătirea ia încă 20. Apoi vin testele, deploy-ul, comunicarea și schimbarea contextului.
Și tocmai acest ultim element este adesea cel mai subestimat.
Context switching - costul ascuns al sarcinilor mici
Dezvoltatorul lucrează la o funcționalitate mare. Are codul deschis. Analizează problema. E concentrat.
Dintr-odată apare un mesaj: „Hei, doar o chestie mică. Poți corecta butonul?”
Dezvoltatorul întrerupe munca. Deschide tichetul. Verifică pagina. Caută locul în cod. Face modificarea. Testează. Deploy-ează. Se întoarce la taskul anterior...
Și atunci trebuie să își amintească: „Pe ce lucram, de fapt?”
Asta este context switching, adică schimbarea contextului. Și poate fi foarte costisitoare. Nu pentru că fiecare schimbare ar necesita multă muncă, ci pentru că fiecare întrerupere rupe procesul mental.
Cu cât taskul inițial e mai complex, cu atât costul revenirii e mai mare. De aceea 10 micro-sarcini nu înseamnă întotdeauna 10 × 10 minute. Practic pot însemna mult mai mult.
Un buton e nimic. O sută de butoane e deja un proces.
Să presupunem că o companie trimite echipei tehnice:
- 20 de modificări mici pe lună,
- fiecare durează în medie 45 de minute.
Asta înseamnă: 15 ore de muncă pe lună.
La tariful de 200 lei net: 3000 lei net pe lună.
Pe an: 36.000 lei net.
Și vorbim doar despre 20 de sarcini mici pe lună. Fără funcționalități mari. Fără dezvoltare de produs. Fără noi module. Fără integrări. Fără design.
Doar: „schimbați”, „corectați”, „mutați”, „adăugați”, „ștergeți”.
Acum imaginați-vă o organizație unde astfel de sarcini sunt 50 sau 100 pe lună. Scara arată complet altfel...
Micro-sarcinile au încă un cost - blochează dezvoltarea
Acesta e unul dintre cele mai importante aspecte ale întregii situații.
Dacă echipa de dezvoltare petrece 20% din timp pe corecții mici, nu poate aloca acei 20% pentru dezvoltarea produsului. Pare evident. Dar în practică deseori nu se observă.
Compania întreabă: „De ce o funcție nouă nu e gata încă?”
Dezvoltatorul răspunde: „Am avut multe taskuri curente.”
„Care?”
„Corecții, modificări mici, actualizări, sarcini mărunte.”
Fiecare în parte a fost mică. Dar împreună au creat un blocaj semnificativ. E puțin ca notificările de pe telefon: una nu deranjează. Zece deja deranjează. O sută?... Deodată se dovedește că am petrecut toată ziua reacționând.
Cu micro-sarcinile e la fel.
„Sarcina mică” nu e întotdeauna o sarcină mică
Trebuie înțeles și că nu toate modificările sunt la fel. Schimbarea unui text în CMS poate dura într-adevăr câteva minute.
Dar schimbarea textului în aplicație poate necesita:
- găsirea componentului,
- modificarea codului,
- actualizarea traducerilor,
- teste,
- rebuild-ul aplicației,
- deploy.
Modificarea unui câmp poate necesita schimbări în:
- front-end,
- back-end,
- baza de date,
- API.
O schimbare a unui element din sistem poate afecta alte elemente.
De aceea întrebarea: „Cât va dura schimbarea acestui buton?”
fără cunoașterea arhitecturii sistemului deseori nu are un răspuns rezonabil.
Mai întâi trebuie verificat. Abia apoi se poate estima.
De ce dezvoltatorul spune uneori: „Trebuie să verific”?
Nu e evitare. De multe ori e semn de profesionalism.
Un dezvoltator bun nu ar trebui să promită: „Sigur, cinci minute.”
dacă nu știe ce se ascunde dedesubt.
Ar trebui să spună: „Verific unde e folosit elementul ăsta și revin cu răspuns.”
Aceasta poate dura 10 minute. Dar acele 10 minute pot salva câteva ore de probleme. Pentru că cea mai scumpă schimbare nu e aceea care ia o oră.
Cea mai scumpă este cea care:
- strică o altă funcție,
- produce o eroare în producție,
- impune rollback urgent,
- generează multiple ticket-e,
- necesită intervenția mai multor persoane.
De aceea analiza înainte de schimbare e parte a muncii, nu o pierdere de timp.
Cum poate clientul reduce costurile micro-sarcinilor?
Nu e vorba să nu se mai raporteze modificări mici. Modificările mici sunt parte normală din evoluția unui produs. E vorba de a le gestiona bine.
1. Grupați modificările mici
În loc să trimiteți:
„Schimbați butonul.”
„Mai corectați titlul.”
„Și, apropo, adăugați acest link.”
„Și mutați acest element.”
Mai bine adunați-le într-un singur pachet.
Echipa poate astfel face mai multe schimbări într-un singur ciclu de lucru.
Mai puțin context switching.
Mai puțină comunicare.
Mai puține deploy-uri.
Cost mai mic.
2. Stabiliți priorități
Nu totul e urgent.
Dacă fiecare cerere are statutul:
URGENT
atunci niciuna nu e cu adevărat urgentă.
Merită să împărțiți task-urile în:
- critice,
- importante,
- planificate,
- cosmetice.
Astfel echipa poate lucra mai eficient.
3. Gândiți-vă dacă e nevoie de modificare în cod
Dacă firma schimbă frecvent:
- texte,
- imagini,
- banner-e,
- link-uri,
- mesaje,
poate problema nu e viteza dezvoltatorului.
Poate problema este arhitectura.
Dacă fiecare schimbare de conținut necesită programator, merită luat în considerare un CMS sau un panou administrativ.
Un sistem bine proiectat ar trebui să permită oamenilor din business să gestioneze singuri ceea ce nu necesită intervenție tehnică.
Un sistem bun ar trebui să răspundă la întrebarea: cine ar trebui să facă această schimbare?
E o regulă de design foarte importantă. Nu orice modificare ar trebui să ajungă la dezvoltator.
Dacă marketingul poate singur:
- schimba textul,
- înlocui o imagine,
- adăuga un articol,
- schimba ordinea secțiunilor,
atunci nu are sens să implici un programator.
Dezvoltatorul ar trebui să se ocupe de ce cere competențele lui:
- construcția de funcții noi,
- dezvoltarea sistemului,
- integrări,
- optimizare,
- sigureanță,
- arhitectură,
- rezolvarea problemelor tehnice.
Altfel compania plătește un programator pentru muncă pe care utilizatorul sistemului ar fi putut s-o facă.
E cam ca și cum ai angaja un mecanic auto pentru a alimenta mașina. Sigur, poate să o facă. Dar chiar ai nevoie de asta?
Când merită să spui: „Hai să facem altfel”?
Dacă aceeași solicitare apare regulat, merită să te oprești și să întrebi:
De ce trebuie să facem asta manual de fiecare dată?
Dacă în fiecare săptămână cerem schimbarea aceluiași element, poate ar trebui să creăm:
- o setare în CMS,
- o configurare,
- un panou administrativ,
- automatizare,
- un mecanism self-service.
Costul inițial pentru construirea unei astfel de soluții poate fi mai mare. Dar ulterior fiecare schimbare ar putea costa câteva secunde în loc de o oră.
Asta e diferența între: a plăti pentru fiecare schimbare și a investi într-un sistem care permite schimbările self-service.
Micro-sarcinile și modelul de colaborare cu software house-ul
E un subiect important și pentru clienți.
Dacă colaborarea cu software house-ul se bazează exclusiv pe modelul: „raportăm - estimați - aprobăm - executați”, fiecare modificare mică poate genera un overhead organizațional suplimentar.
De aceea, pentru colaborări recurente, de multe ori se potrivește mai bine:
- pachete de ore,
- abonament de mentenanță,
- echipă dedicată,
- backlog,
- sprinturi regulate,
- ferestre de deploy stabilite.
Nu înseamnă că toți clienții trebuie să aleagă același model. E vorba de potrivirea modului de lucru cu natura proiectului.
Dacă o companie are o singură schimbare pe lună, un proces complex poate fi inutil. Dacă are 50 de cereri pe lună, lipsa unui proces poate fi foarte costisitoare.
Merită să contăm fiecare schimbare?
Depinde.
În unele proiecte, factura minut-cu-minut are sens. În altele generează mai multă administrație decât economii.
De aceea e bine să privim colaborarea în ansamblu.
Întrebarea importantă nu e: „Cât a costat această schimbare?”
Ci: „Cât ne costă felul în care gestionăm toate schimbările?”
Dacă compania plătește 200 lei pentru o schimbare dar astfel evită erori și are certitudinea că totul funcționează corect, poate fi un cost rezonabil.
Dacă însă în fiecare lună plătește câteva mii de lei pentru zeci de micro-sarcini similare, poate merită rezolvat sistemic.
Cele mai scumpe cuvinte în IT?
Poate sună: „E doar o schimbare mică.”
Nu pentru că schimbările mici ar fi rele. Sunt necesare.
Un produs digital trăiește. Nevoile clienților se schimbă. Piața se schimbă. Marketingul se schimbă. Tehnologia se schimbă. Modificările sunt naturale.
Problema începe când organizația nu vede costul cumulat al acestor schimbări.
O schimbare mică? — Nimic mare.
Zece? — Tot puțin.
O sută? — E deja un proces.
Și dacă avem mai multe astfel de procese? Deodată se dovedește că firma nu cheltuie bani pe dezvoltare; îi cheltuie pe corectarea constantă a detaliilor.
În loc să numărăm butoane, să numărăm timpul
Un development gestionat bine nu înseamnă a interzice clienților să raporteze modificări mici.
Înseamnă să știi:
- care schimbări necesită cu adevărat programator,
- care pot fi făcute de sine stătător,
- care merită automatizate,
- care trebuie grupate,
- care sunt cu adevărat urgente,
- care pot fi planificate,
- care merită rezolvate sistemic.
Pentru că uneori cel mai bun răspuns la: „Remediați asta rapid.”
nu e: „Bine, facem.”
ci: „Să ne întrebăm de ce peste o lună iar va trebui să corectăm același lucru.”
Aici software house-ul încetează să fie doar executor. Devine partener tehnologic. Pentru că un partener bun nu doar livrează cereri.
Ajută și să vezi că uneori cea mai ieftină schimbare nu e aceea pe care o facem mai repede. Cea mai ieftină e aceea pe care nu va trebui s-o repetăm pentru a suta oară.
Și de aceea un buton „Remediați asta rapid” poate costa o oră.
Dar un sistem bine proiectat poate face ca următoarele o sută de astfel de schimbări să le faci singur în câteva minute.
Nu e economisire pe seama programatorilor. E investiție într-un proces mai bun, o arhitectură mai bună și o utilizare mai inteligentă a timpului întregii echipe.
