despre online, Romania, politica si despre mine

Traim o perioada in care cuvantul eficientizare este din ce in ce mai des auzit.
Cand cutitul ajunge la os ne gandim la solutii. In unele cazuri este prea tarziu, in alte cazuri solutiile gasite nu combat decat efectele unor probleme, nu si cauzele.

Desi nu pot vorbi despre eficientizare in general, pot insa oferi o solutie pentru eficientizarea unui departament de dezvoltare software.
Atunci cand vorbesti despre eficientizare intr-un departament de dezvoltare software trebuie sa te gandesti la urmatoarele aspect: individ, echipa, arhitectura, mod de lucru si masurarea rezultatelor. Relatiile dintre ele sunt asa cum am incercat sa le reprezint in imaginea de mai sus.

A. Individul

Cel mai greu este sa modelezi fiecare individ in asa fel incat sa functioneze bine atat in echipa cat si in companie.
Fiecare individ este diferit si, in consecinta, trebuie dezvoltata o strategie de eficientizare pentru fiecare individ in parte.

Fiecare individ trebuie sa fie canalizat spre zonele in care el este eficient si, in consecinta, alocarea lui pe proiecte trebuie sa fie facuta in functie de competentele si afinitatile lui.

Nu trebuie uitat ca omul este, in general, usor influentabil de cei din jurul lui. Asta se cheama puterea exemplului. Folosindu-te de acest lucru poti rezolva probleme aparent minore cum ar fi: intarzieri, defocusare, lipsa de interes fata de proiecte, etc.

B. Echipa

Modul in care construiesti echipa unui proiect este un factor esential in succesul acelui proiect.
Nu exista o reteta universal valabila pentru orice tip de proiect dar putem mentiona cateva reguli generale de urmat.

Echipe mici: o echipa mica este intotdeauna mai eficienta. De ce? Pentru ca in echipele mici se creaza acele relatii personale intre membrii echipei, relatii personale ce duc, in parte, la responsabilizarea fiecarui individ. Echipele mici si datorita faptului ca fiecare membru al echipei va avea ocazia sa inteleaga proiectul la care lucreaza in intregime.

Echipele sa aiba la dispozitie resursele umane de care au nevoie, nu mai mult: componenta unei echipe trebuie sa fie variata, sa contina oameni cu competente variate care sa acopere toate aspectele proiectului. In felul asta elimini un stres ce poate aparea in cursul executiei proiectului. Deasemenea, trebuie sa fii atent sa nu implici oameni cu competente similare pe aceleasi taskuri; in situatia asta pot aparea dispute personale si eficienta scade atata timp cat focusul individului nu mai este pe proiect.

Nivel de competente echilibrat: nu poti avea intr-o echipa 2 programatori foarte buni si 2 programatori foarte slabi. Aceasta diferenta mare de competente va duce la conflicte personale si vom vedea iarasi cum scade eficienta.

C. Arhitectura

Orice departament de software este bine sa aiba la dispozitie o arhitectura pe care sa lucreze. Fie aceasta arhitectura este adoptate, fie este dezvoltata in-house, asta mai putin conteaza. Ce conteaza este modul in care interactioneaza individul si echipa cu aceasta arhitectura.

Orice arhitectura folosita trebuie sa fie un prieten al individului si sa-l ajute sa-si faca treaba mai bine, mai usor si intr-un timp mai scurt.
Arhitectura trebuie sa fie si un prieten al echipei si trebuie sa faciliteze lucrul in echipa.

D. Modul de lucru

Modul de lucru este, intr-o oarecare masura, dependent de arhitectura folosita.

Scriam aici despre best practices in development, este o sursa buna de inspiratie cand vrei sa te gandesti cum vei normaliza modul de lucru in echipa.

Atata timp cat este impusa o disciplina de lucru si se lucreaza standardizat sunt putine tipuri de probleme ce pot aparea.

E. Masurarea rezultatelor

Rezultatele fiecarei echipe si ale fiecarui individ trebuie masurate.
Masurarea trebuie facuta atat periodic (perioade predefinite) cat si spontant.

Rezultatele nu se pot incadra decat in 3 categorii:
- sub asteptari
- conform asteptarilor
- peste asteptari

In general este bine ca rezultatele sub asteptari sa fie urmate de penalizari iar cele peste asteptari sa fie urmate de premiere.
Din experienta pot spune ca un astfel de sistem se echilibreaza singur in timp iar marea majoritate se vor afla in segmentul “conform asteptarilor”.
Trebuie mentionat, deasemenea, ca un sistem de penalizari nu poate exista fara unul de premiere asa cum nici unul de premiere nu poate exista fara unul de penalizari.

Un ultim lucru care trebuie mentionat este acela ca masurarea rezultatelor trebuie sa se faca transparent.

———

Cam acesta este modelul pe care vi-l propun pentru eficientizarea  unui departament de dezvoltare software.

Observatie: oricare patru puncte din cele de mai sus nu poate functiona corect fara al cincilea.