Managerul trânteşte uşa şi ne zice că suntem în belea. Clienţii noştri vechi se plâng de multe bug-uri şi performanţe proaste, clienţii noi se plâng pe întârzieri şi lipsă de dedicaţie. Și, colac peste pupăză, top managementul consideră departamentul nostru financiar nejustificat şi vrea să reducă serios cheltuielile. Managerul ne mai zice că suntem programatori geniali, că lucrăm asiduu şi creăm soluţii software cool. Dar există ceva greşit şi nu mai putem continua sa lucrăm aşa.

Anxietatea a început sa ne penetreze sufletele. Ştim unde e greșeala: nu ne ajung oameni în echipă, ne-am asumat prea multe angajamente, codul se transformă într-o mizerie mare, tehnologia nouă şi versiunea nouă de software fac ceva rău cu serverele. Un bulgăre de zăpadă compus din diferite probleme ne face să fim stresaţi, distraţi şi incapabili de lucru productiv.

Cum ar putea proceda managerul după aceasta?

  • Neîncredere. Devine dictator, ia decizii de sine stătător, inclusiv angajează consultanţi din afară ca să recomande ce e de făcut sau poate chiar să ne înlocuiască. Totuşi,

    • suntem programatori buni şi ne cunoaştem treaba bine – nu lipsa de abilităţi şi cunoştinţe este problema.

    • cuiva din afară i-ar lua mult timp ca să înţeleagă sistemul şi ei vor avea o altă motivaţie şi nu le va păsa de succesul pe termen lung.

    • oamenii vor fi descurajați și managerul nu poate lua decizii eficiente fără implicarea activă a echipei.

  • Încredere. Va învesti echipa cu putere deplină de a rezolva problemele şi de a lua decizii proprii în speranţa că oamenii deştepţi, motivaţia bună şi expertiza tehnică pot face minuni. Oricum,

    • este greu de adoptat o viziunea proaspătă și gândire nestandardă atunci când echipa e scufundată într-o situație dificilă de mai mult timp.

    • s-ar putea ca o echipă să nu aibă înțelegere și control asupra forțelor externe : management, clienți, finanțe.

    • schimbarea realității este un proces dur (mai ales în mințile oamenilor) și necesită mai mult decât doar experiență tehnică.

Există o a treia cale. Plasați practicile de îmbunătățire în centrul procesului de dezvoltare. Faceți din auto-îmbunătățire un lucru inevitabil și necesar oricărei activități. Faceți-o în fiecare zi.

Îmbunătățirea proceselor - Calea Toyota

Dintre cele mai sigure procese ample de auto-îmbunătățire Calea Toyota reprezintă cel mai bun exemplu. Aceasta se concentrează pe eliminarea risipei, rezolvarea problemelor de la origine și luarea deciziilor corecte. Calea Toyota reduce problemele, crește eficiența internă și face compania una de succes. Acesta este cel mai bun remediu de ieșire din criză.

Obiective:

  • Probleme – situații de urgență, focare care necesită soluționare imediată: bug-uri, căderea serverului, expirarea datei limite.

  • Risipe – activități ineficiente și fără valoare adăugată: așteptarea, dezinformarea, stresul.

  • Provocări – adaptarea la forţele externe (piaţa, concurenţii, clienţii, societatea): noi tendinţe şi tehnologii, modificări în așteptările utilizatorilor referitor la interfață și funcționalitate.

Practicile de depistare a risipei și stoparea rezolvării problemelor

Depistarea risipei

Echipa și managerii ar trebui să învețe să identifice sarcinile: problemele adevărate și risipile. În caz contrar, îmbunătățirile vor fi împușcături în întuneric.

Există mai multe obiective în dezvoltarea software-ului:

  • oameni stresați – energie redusă, productivitate scăzută, un număr mai mare de greșeli

  • așteptări – întârzieri, instrumente/probleme de sistem și nefuncționare, pană de capacitate (așteptarea rezultatelor muncii altor oameni)

  • supra-inginerie – producând caracteristici și design complicat fără necesitate reală

  • lucru nefinisat – funcționalitate neutilizată în sistemul viu, aflată, probabil, încă în construcție sau în curs de elaborare sau pur și simplu abandonată (dar nu eliminată)

  • defecte – irosire completă de timp și bani

  • creativitate neutilizată – pierdere de timp, idei, abilități, îmbunătățiri și învățare din cauza faptului că nu implicați sau ascultați angajații dumneavoastră

  • informații neadecvate – neclare, care induc în eroare sau pur și simplu informație eronată care cauzează activitate inutilă și conduce într-un sfârșit la refacere

  • supra-procesare – luarea de măsuri inutile pentru construirea software-ului din cauza insuficienței proceselor și a design-ului sistemului, suspendării, birocrației, conformării, instrumentelor greoaie

  • mișcare – efortul necesar pentru a obține informația, sisteme de acces sau instrumente de utilizare

  • multi-tasking – pierdere de timp pentru a comuta între proiecte, sarcini sau diferite activități

Jidoka – încetați de a rezolva problema pentru a obține calitate din prima

Nu este îndeajuns să cunoașteți sarcinile dvs. Echipa ar trebui să execute ordinul de a trage în țintă imediat. În caz contrar, cele mai bune intenții vor fi îngropate sub avalanșa crescândă a problemelor.

Cum să încetezi:

  • calitatea pentru clienți conduce toate procesele – previne patch-urile temporare și deciziile proaste vis-a-vis de calitate

  • toleranța scăzută față de problemele calității și imediata lor detectare reprezintă principiul de bază al muncii

  • utilizarea Andon – un sistem care semnalizează pentru ajutor,

  • înștiințează despre o problemă și stopează procesul de producție

  • axarea pe capacitățile instrumentelor și a procesului de detectare a problemelor și de stopare a acestuia

  • utilizarea tututor metodelor moderne de QA disponibile

  • managerii încurajează oprirea procesului de soluționare a problemelor și sprijină implimentarea măsurilor de contra-atac

Luarea deciziilor

Calea Toyota- ”Luați deciziile încet, prin consens și temeinic, luând în considerație toate opțiunile, implementați rapid.”

Chiar cunoscând problemele și fiind dedicată soluționării lor, Echipa ar trebui să ia decizii corecte întru soluționare.

Ia deciziile lent

  • Du-te și vezi (Genchi Genbutsu)

  • Înțelege cauzele fundamentale (Kaizen)

  • Consideră în linii mari toate soluțiile alternative și dezvoltă pentru soluțiile alese o argumentare detaliată, amânând anumite decizii maximum posibil (Set-Based concurrent engineering)

  • Realizarea unui consens în cadrul echipei și a partenerilor în cazul în care decizia de grup e preferată (în timp ce managementul poate interveni dacă consensul nu este atins)

  • Utilizează dispozitive eficiente de comunicare – de preferință o singură parte a foii

Implementează rapid

  • Implimentează soluții și contra-măsuri

  • Evaluează rezultatele

  • Standardizează în cazul când soluțiile sunt efective

Practici pentru eliminarea risipei și soluționarea problemelor

Genchi Genbutsu – du-te și vezi tu însuți pentru a înțelege complet situația

Cât de des facem concluzii bazate pe informație parțială, ipoteze vagi sau spusele altora? Informația creează realitate în mintea ta, aceasta realitate servind drept bază pentru deciziile tale. Deci, tu și echipa ta ar trebui să obțineți informații juste pentru a lua decizii corecte:

  • du observații cu mintea limpede

  • evită ipoteze și idei preconcepute

  • utilizează informația verificată personal

Într-un cuvânt, întemeiază deciziile pe ceea ce se întâmplă cu adevărat.

Kaizen (5 de ce-uri) – învățare și îmbunătățire continuă

”Noi privim erorile ca oportunități de învățare” – Calea Toyota

Echipa ar trebui să găsească originea problemelor. Kaizen ajută la găsirea acestora prin întrebarea repetată “de ce apare problema?“

Exemplu de Kaizen Problemă: există erori JavaScript persistente pe un site din producție

  • De ce? Developer-ul nu a construit corect logica interactiunii componentelor UI pentru complexul web

  • De ce? Un developer a implimentat propria soluție fără orientare și suficientă experiență în acest domeniu

  • De ce? Un expert din echipă nu a comunicat despre existența soluțiilor demonstrate, nu a ajutat și împărtășit cunoștințele

  • De ce? Echipa este supusă stresului, supra-angajată și nu are suficient timp pentru a comunica

  • De ce? Managerii acceptă prea mult lucru fără a se consulta cu echipa de dezvoltare

  • De ce? Puteți continua…

Kaizen ne obligă să depășim dorința de a găsi o primă explicație convenabilă și de a aplana problemele fără rezolvarea cauzelor care stau la baza lor. Prin aplicarea neînduratoare a acestei practici, ajungem să înțelegem mai profund realitatea și să învățăm mai bine despre produsele, procesele, oamenii, mediul și instrumentele noastre. Kaizen este o practică de bază pentru depistarea risipei, soluționarea problemelor și îmbunătățirea procesului. Pentru a evita uitarea învățării din Kaizen, este important de a standardiza procesul de îmbunătățire și de a-l situa la baza ulterioarelor îmbunătățiri.

Practici de susținerea proceselor

Standarde – astăzi știți cel mai bine ce trebuie să îmbunătățiți mâine

Lucrul standardizat este mai ușor, mai ieftin și mai rapid - metodele stabile repetabile pot menține predictabilitatea, productibilitatea înaltă și suportă calitatea.

Standardele efective nu provin din teorie, ci din:

  • cele mai bune practici

  • cunoștințele acumulate și experiența individuală

  • lecții din aplicarea standardelor existente

Echipa ar trebui să utilizeze standarde în diverse domenii: faze de proiect și activități, practici de dezvoltare, abordări de arhitectură și design, codul de convenții, tehnici de programare, biblioteci și coduri ale terțelor părți, reutilizarea componentelor și a soluțiilor, testare și așa mai departe. Standardizarea în dezvoltarea sofware-ului este un subiect controversat: unii teoreticieni doresc să aducă programarea mai aproape de ingineria supusă standardelor, practicienii însă sunt dornici de a reduce standardizarea la minimum, promavând creativitatea și auto-organizarea. În interpretarea rigidă, standardele sunt reguli care ”trebuie urmate” în orice situație; în altă interpretare standardele sunt pași bine definiți și linii directoare recomandate în context specific. Eu sunt adeptul ultimei definiții. O echipă productivă ar trebui să dispună de standarde pentru a se axa pe nevoile clienților în locul luptei continue cu aceleași puzzle-uri și probleme. Sistemul de standarde nu ar trebui să fie a un cod greoi de conduită birocratică, dar o carte fluidă și luminoasă de cunoștințe, o carte care conține cele mai utile și importante norme și liste de verificare. Standardele vor fi eficiente dacă acestea sunt minime, revăzute de multe ori (Kaizen) și urmate de fiecare membru al echipei.

Tehnologii sigure foarte bine testate

Echipa ar trebui să fie conservatoare față de tehnologiile noi. Dezvoltarea software-ului și IT prosperă datorită schimbării și inovației. Cu toate acestea, calea Toyota sugerează să fii conservator în adaptarea tehnologiei și consideră stabilitatea și fiabilitatea operațiunilor obiective mult mai importante decât menținerea în rând cu tehnologia de ultimă oră.

Considerații pentru utilizarea tehnologiei

  • scopul principal este de a îmbunătăți fluxul și de a susține oamenii, procesele și valorile

  • procesul este condus de afaceri, nu se referă la tehnologii; software-ul și instrumentele nu elimină risipile desinestătător

  • tehnologia este vizuală și intuitivă – oamenii o pot folosi corect și eficient

  • procesează manual înainte de a adapta tehnolgia în sprijinul procesului – întelege ce probleme soluționează ea și cum te poate tehnologia ajuta

  • important: la Kaizen oamenii/procesele sunt simple, mașinile sunt complicate

Adaptarea la noile tehnologii:

  • tehnologia nouă este nesigură și este dicifil de a o standardiza, prin urmare ea pune în pericol fluxul

  • procesul dovedit are prioritate față de tehnologiile noi și netestate

  • efectuează teste adevărate înainte de a adapta o tehnologie nouă

  • respinge tehnologia în cazul în care ea intră în conflict cu cultura sau ar putea perturba stabilitatea, fiabilitatea și previzibilitatea

În același timp, în căutare de noi abordări, oamenii trebuie încurajați să ia în considerație tehnologiile noi. Dacă tehnologia ameliorează procesele și fluxul, după testarea ei minuțioasă, ea trebuie imediat implementată.

Controalele vizuale

Echipa ar trebui să aibă un statut clar al informației. Controalele vizuale pot transmite creierului nostru informație complexă într-o manieră foarte rapidă și eficientă. Putem folosi controalele ca pe o istorie narativă pentru utilizator; statutul proiectelor, serverelor sau construrii codului; diagramele burndown şi alte lucruri.

Simpli indicatori vizuali ajută oamenii să depisteze imediat dacă au deviat de la standarde, să arate esența situației și direcția de soluționare a problemei.

  • utilizează cei mai importanți și simpli indicatori

  • apoi oferă o imagine clară pentru decizii și ce e de făcut în continuare

  • reduce rapoartele la un ecran / o foaie de hîrtie chiar și pentru cele mai importante decizii

Oamenii, conducătorii și echipa

Oamenii

Oamenii care elaborează software-ul sunt oamenii care ar trebui să îmbunătățească procesul. Ei sunt direct implicați și au o experiență de prima mână a problemelor și a risipei. Calea Toyota pretinde că fiecare membru al echipei poate soluționa problema și că experiența de lucru valorează mai mult decât cunoștințele teoretice. Echipa va depăși oricare consultanți exteriori și va găsi o mai bună modalitate de lucru, dacă membrii ei sunt deschiși pe probleme și dornici de a găsi soluții bune.

Conducători

Echipa are mare nevoie de lideri puternici pentru a crea produse tari, pentru a depăși problemele. Toyota crește lideri care înteleg complet lucrul, trăiesc această psihologie și trebuie să înțeleagă detaliat activitatea de zi cu zi.

Inginerul Șef este persoana-cheie în proiectele Toyota:

  • binecuvântat de managementul de sus

  • deține controlul asupra proiectului

  • inginer de excepție

  • punte critică între ingineri și satisfacția clienților

  • antrenor pentru alți ingineri

  • centrat în primul rând pe concepte și mai apoi pe tehnicitate

Conceptul de Inginer Șef reprezintă un excelent exemplu pentru conducerea tehnică a software-ului. Deseori, liderul echipei software este lipsit de autoritate sau ia decizii prea tehnice, fără o bună înțelegere a nevoilor clienților.

Echipe

Echipa ar trebui să fie variată și capabilă să rezolve o gamă largă de probleme. Toyota crează echipe de produs cu funcționalitate hibridă, care:

  • să utilizeze luarea integrativă a deciziilor

  • să implimenteze rapid și precis

  • să sporească procesul și fluxul prin rezolvarea de probleme tehnologice dificile

Dezvoltatorii de software și liderii lor sunt fundamentul succesului în orice proiect. Managementul, procesul și tehnologia nu pot decât să-i susțină. Dar oricum, procesul este la fel de bun pentru ca oamenii să-l urmeze. Prin urmare, este important de a face echipele de software jucătorul cheie în procesul de îmbunătățire, dat fiind faptul că ele cunosc problemele, înțeleg lucrul și sunt capabile să găsească soluții bune.

Utilizând Calea Toyota

Poate echipa să inverseze o situație și să câștige? Poate ea oare să elaboreze un proces optim și experiență competență de dezvoltare rapidă a soluțiilor de calitate înaltă și costuri reduse?

Aceast articol ilustrează opțiunea cea mai efectivă – elaborarea continuă a procesului de îmbunătățire în centrul dezvoltării. Procesul care se axează pe calitate, elimină risipele și rezolvă problemele de la rădăcină(origine). Cred că această abordare reprezintă fundamentul unui succes de durată. Managerii și compania dvs. o vor îndrăgi!