Creșterea datoriilor tehnice în micile companii indiene de software care dezvoltă aplicații și site-uri web: cine este responsabil pentru aceasta?

Sunt în industria indiană de servicii software de 10 ani și în tot acest timp, am văzut proiecte bune finalizate și făcând minuni. Am văzut echipe scheletice lucrând neobosit în condiții dureroase pentru a construi produse care au fost iubite de oameni de pe jumătatea planetei. Și, deși au existat amintiri grozave în acest deceniu, lucrând la niște proiecte minunate, am fost, de asemenea, martorul unor proiecte care au mers la vale și produse software s-au distrus din diverse motive. S-a întâmplat de mai multe ori decât mi-aș fi dorit în jurul meu și în jurul oamenilor pe care i-am cunoscut de-a lungul acestor 10 ani.

S-a vorbit mult despre proiecte care merg prost. Memele roiesc pe internet despre modul în care întreaga ierarhie se urmărește una pe alta ca un lanț alimentar în jungle. Unii oameni dau vina pe programatori pentru că au scris coduri cu erori, în timp ce alții blestemă conducerea pentru că au făcut promisiuni nepractice care sunt imposibil de îndeplinit. Unii oameni chiar dau vina pe clienți pentru că nu înțeleg cerințele tehnice și dependențele acestei industrii. Dar aproape că nu am auzit pe nimeni vorbind despre Datoria Tehnică sau Datoria Codului și să se ocupe de această problemă într-un mod civilizat, fără a arăta cu degetul unul spre celălalt. Nu am întâlnit nici o dată acest termen de Tech Debt de la oamenii din jurul meu, sau de la evenimentele la care am participat, sau de la blogurile locale pe care le-am citit.

Am întâlnit acest termen doar când am citit bloguri și reviste din Silicon Valley din Statele Unite. Aceasta înseamnă că majoritatea programatorilor și directorilor de software care lucrează în companiile mici și mijlocii de dezvoltare de software din India nici nu ar fi auzit de acest termen până acum. Deci, permiteți-mi să încep prin a explica termenul în sine. Datoria tehnică sau Datoria de cod este un concept în dezvoltarea de software care reflectă costul implicit al reluării suplimentare cauzat de alegerea unei soluții ușoare (limitate) acum, în loc de a folosi o abordare mai bună care ar dura mai mult.

Lasă-mă să o descompun pentru a o simplifica. Este un concept pentru a calcula costul rezolvării problemelor de programare și proiectare care ar fi putut crește din cauza alegerii unei opțiuni ușoare de construire a unui anumit modul, sau a unui întreg sistem, în loc de a alege cea mai bună și cea mai eficientă metodă de a-l construi. În domeniul dezvoltării software, acest fenomen al lenei și întârzierii tale care se întoarce să te muște în cur se întâmplă mult mai des decât oriunde altundeva. Este aproape ca și cum Karma a primit o reprezentare socială a cărții de către programatori.

Vă rog, nu mă înțelegeți greșit, nu dau vina pe programatori pentru toată datoria de cod. Cu siguranță există mai multe entități care sunt responsabile pentru datoria de cod care apare cu siguranță în peste 90% dintre proiectele companiilor de dezvoltare de software de dimensiuni mici din India. Permiteți-mi să încerc să acopăr câteva dintre ele pe scurt:

1. CLIENȚI NEBRABĂTORI ȘI EXCESIȚI

Da, voi începe prin a mușca chiar mâna care se hrănește și o fac fără milă. Piața proiectelor de dezvoltare software externalizate de dimensiuni mici este uriașă și foarte fragmentată. Există companii cu adevărat bune care justifică perfect această piață globalizată, în timp ce altele sunt doar companii parazitare care se hrănesc cu acest aranjament perfect bun doar pentru că este nereglementat și necontrolat.

Acest lucru îi determină pe clienți să facă o greșeală în alegerea companiei potrivite cu care să se asocieze în funcție de nevoile lor. Deși nu au abilități adecvate de verificare nu este vina lor, dar nu există nimeni de vină pentru că nu au inteligență de bază în identificarea unei companii de gunoi dintr-una autentică. Acum, odată ce sunt de acord să meargă mai departe cu o echipă sub-talentată, își sufocă așteptările nerealiste și cronologia față de ei. Nu numai că, unii dintre ei chiar trec peste bord și arată cât de deștepți sunt aducând propriile sugestii în design și programare. (#notaclientii)

Dacă sunteți vreodată client al unei companii de dezvoltare de software, vă rog cu umilință să le lăsați să fie și să le permiteți să-și facă treaba. Încercați să mergeți la un medic sau un avocat și spuneți-le ce ați căutat pe google și ce a spus despre problema dvs. și vedeți reacția pe fețele lor. Niciun expert în domeniile lor nu îi place să fie sfătuit despre propriul lor domeniu de către un noob. Inginerii software nu fac excepție.

Dacă găsiți o echipă bună de dezvoltare de software și par promițătoare, acordați-le spațiul lor și nu vor simți nevoia de a tăia colțuri, ceea ce ar duce la mai puține datorii de cod în proiectul dvs. Și ghiciți ce, de cele mai multe ori, sunteți voi băieți, clienții care plătesc datoria respectivă. Ați auzit vreodată de cuvintele: „Solicitare de schimbare”? Pun pariu că majoritatea dintre voi au! Într-un scenariu ideal, nu ar trebui să auzi acele cuvinte în viața ta. Dar asta se întâmplă rar. Și de cele mai multe ori auziți aceste cuvinte, cu atât mai mult ați greșit să fiți client al unei companii de software.

2. MANAGERI LENESI ȘI OBSERVAȚI

Când spun manageri aici, este oricine în poziția de management de proiect din partea companiei de dezvoltare de software. Fie că este vorba despre un manager de proiect, sau un lider de echipă, sau un șef de livrare, sau un proprietar de companie, dacă ați încercat vreodată să vă spălați rapid pe mâini de un proiect doar pentru a-l încheia și a încasa plata, sunteți o petrecere de vina, de asemenea, în această sumă Tech Dabt în proiectele dumneavoastră.

Deși partea cea mai tristă aici este că voi nu trebuie să plătiți niciodată pentru datoria tehnologică. Fie clientul plătește pentru el folosind un produs substandard, fie plătește mai mulți bani pentru a-l curăța. Și dacă nu este clientul, sunt săracii programatori care plătesc pentru asta, fiind nevoiți să lucreze ore nesfârșite mult peste ceea ce li se cere să facă. Dar aproape niciodată nu sunt acești băieți de mijloc, așa că, după mine, ar trebui să fie cele mai responsabile entități în acest subiect privind datoria tehnologică.

Dacă angajați vreodată unul dintre ei, cea mai mare calitate pe care ar trebui să o aibă este moralitatea. Dacă busola lor morală îndreaptă în direcția corectă, ei își vor asuma responsabilitatea și vor lua decizia corectă care este în favoarea proiectului, ceea ce ar duce în cele din urmă la mai puțină compilare a datoriilor tehnologice. Acest lucru îmi amintește de acel celebru citat al lui Jack Ma în care vorbea despre alegerea de a lucra pentru liderul potrivit. Foarte potrivit în acest scenariu aici.

3. PROGRAMATORII

Oh, da, nu aș încheia acest subiect dându-vă vina și pe voi! Dar hei, #notallprogrammers nu? Ei bine, da, dar aproape 94% dintre programatori. Cel puțin așa crede CP Gurani, CEO-ul Tech Mahindra, când a făcut dezvăluirea șocantă în urmă cu câțiva ani că 94% dintre absolvenții IT nu sunt apți pentru post. Nu știu exact cum a ajuns la acel număr, dar fiind un produs al colegiilor indiene de inginerie și fiind martor la întregul ecosistem de inginerie IT în ultimii 10 ani, pot spune că tind să fiu de acord cu ceea ce a spus domnul Gurani.

Nu încerc să dezbat dacă este 94%, sau 90%, sau 80%. Dar, ca să vă facem o analogie, este ca și cum aproape toți știm că avem nevoie de făină, apă și un praf de sare pentru a face aluatul și un sucitor pentru a face chapatis. Dar foarte puțini dintre noi pot face de fapt chapatis comestibile. Este un proces foarte simplu, dar necesită totuși un anumit talent și multă practică pentru a excela în el. Același lucru este și cu programarea. Cu toții știm rețeta, dar foarte puțini ne-au suflecat mânecile și ne-au murdărit mâinile și au practicat-o atâta timp cât a fost nevoie pentru a stăpâni acel meșteșug.

Prin urmare, chiar și atunci când un programator obișnuit este comandat pentru un proiect, el ar scrie fără să știe cod cu datorii tehnologice încorporate, pe care nu și-ar da seama decât mai târziu. Și dacă vă întrebați cum funcționează în general industria în mod pozitiv, majoritatea programatorilor fiind nepotriviți pentru acest loc de muncă, este din cauza managerilor lor eficienți și a seniorilor cu experiență care au învățat lucrurile pe cale grea. Ele ajută acele mâini și minți proaspete să navigheze pe căile perfide ale scrierii codului optim și fac livrarea proiectului fezabilă și îl mențin liber de o datorie împovărătoare. Și, în cele din urmă, cu îngrijirea adecvată și formarea acelor începători pentru a deveni buni la locul de muncă, sau ajung să își ia rămas bun de la industria IT.

Deci, în concluzie, cred că toate cele 3 părți majore din această colaborare sunt de vină pentru compilarea datoriilor de cod. Din nou, nu luați această piesă ca pe o piesă de demontare pentru tot ceea ce este în neregulă cu industrie. Este la fel ca orice altă industrie din lume, cu o parte echitabilă de orori, precum și eroi. Chiar și după 10 ani de a face asta, tot nu aș face altceva cu viața mea. Îmi place acest job, îmi place să fiu o companie mică care lucrează la proiecte interesante de la clienți din întreaga lume.

Scopul a fost de a face pe toți cei 3 părți interesate mai responsabili și de a le familiariza cu această pierdere subiacentă care a fost afectată de ei prin colaborare greșită. Dacă o echipă de dezvoltare software dorește să calculeze și să măsoare cu exactitate datoria tehnologică, poate urma un model de proces strict bazat pe metodologia Agile sau chiar pe metodologia Waterfall. Când urmați această abordare disciplinată, veți putea să marcați separat acele sprinturi de revizuire și reparare și, la sfârșitul unei faze, veți putea calcula cu precizie de câte dintre ele aveți nevoie și veți ajunge cu ușurință la motiv pentru asta.

Voi încheia cu acest citat final din Samuel Beckett: