Top 7 minciuni de la tehnic
"The most common lie is that which one lies to himself; lying to others is relatively an exception."
Ieri, la Netcamp 2009, am avut o prezentare despre echipa tehnica. Slideurile pot fi downloadate, insa reprezinta 5% din informatia expusa. Reactiile au fost pozitive – nu am fost agresat de nimeni, in mod suprinzator. Pentru ca si oameni tehnici si oameni de business mi-au cerut mai multe detalii, m-am hotarat sa dau din casa si sa public topul minciunilor intalnite de la oameni tehnici, in ordinea pericolului.
*** Top 7 minciuni de la tehnic ***
7. Dureaza 3-6-12 luni.
Durerea: Estimarile sunt in 99% din cazuri punctul slab al echipelor IT. Niciodata nu ai o estimare de timp clara, pe care sa te poti baza. Totul pare sa dureze prea mult de la bun inceput si ajunga sa dureze mereu si mai mult.
Pastila: Orice estimare exprimata in luni/ani trebuie tratata ca fiind falsa. Munca este mereu facuta stundenteste, in ultimele zile inainte de deadline. Se defineste un termen de realizare a proiectului. Se comunica o perioada mai scurta la tehnic si mai lunga la client. Proiectule ste impartit in bucati digerabile. Se stabilesc deadlineuri la maxim 1-2 saptamani. Deadlineurile se comunica clientului. Nimic nu se lasa la mila auto-organizarii timpului de catre executantul tehnic.
6. Lucram la backend.
Durerea: Se munceste de mult timp, se plateste deja, nu se poate utiliza nimic. Proiectele IT sunt ca un iceberg, mare parte nu e la vedere. Totusi, daca un client neavizat nu poate vedea rezultatele, sansele sunt ca acestea sa nu existe. Uneori se fac eforturi, nu este doar o minciuna sfruntata. Eforturile sunt irelevante cata vreme nu se vede ce s-a realizat. Afirmatia de mai sus este clasica in proiecte scapate de sub control pentru ca ascunde mizeria sub presul nestiintei tehnice a managerilor.
Pastila: Se definesc si urmaresc rezultatele implementarii unor bucati din proiect. Se trece rapid la partea de frontend pentru a se balansa munca. Ti se va spune ca nu se poate pana nu este terminat backendul. Daca pozitia este ireconciliabila inseamna ca proiectul este complet deraiat si trebuie rupta pisca (schimbati responsabili, delegat etc).
5. Trebuie sa cumparam echipamentul X, softul Y si solutia Z.
Durere: Costurile sar prin tavan datorita unor achizitii costisitoare. Mereu se prezinta solutii scumpe sau echipamente scumpe. Ai nevoie de investitii mari pentru rezultate mici. Stii ca e bine sa investesti in informatizare, insa ti-e greu sa gasesti justificarea economica.
Pastila: Avem 2 vinovati: indragostitul de tehnologie si incompetentul. Indragostitul vrea sa cumpere orice gadget de sute/mii/zeci de mii de euro pentru a se juca. Incompetentul cauta solutii complexe pentru a rezolva probleme simple. Solutiile complexe au costuri complexe, mai ales cand sunt in grija incompetentilor. Orice achizitie este refuzata cata vreme nu e insotita de o argumentatie puternica. Se cer pareri din exterior. Consultanta specializata este optinea cea mai ieftina. E acceptabila cumpararea unor maruntisuri, chiar daca exista solutii alternative mai ieftine. Partea de cercetare ar costa prea mult. Achizitiile IT nu trebuie sa fie niciodata lasate total in mana unei singure persoane tehnice.
4. Trebuie (re)-scris/facut de la zero.
Durere: In urma unei analize rapide se constata ca solutia curenta este inutilizabila si trebuie schimbata sau ca nu exista nicio alternativa buna, deci trebuie dezvoltata una proprie de la zero. Asa se nasc CMS-uri proprii, frameworkuriproprii, infrastructura hardware proprie samd. – cu costuri foarte mari si cu existenta scurta si chinuita.
Pastila: Oricand ti se spune ca trebuie luat ceva de la zero tragi aer in piept si te relaxezi 10 minute. Urmeaza o cercetare de piata. Identifici toate solutiile posibile deja existente, chiar daca par imperfecte sau improprii. Acestea trebuie testate atent. Poti trece la munca de la zero doar daca ai inteles solutiile alternative, stii cum sunt structurate si nu au nicio necunoscuta tehnica. Solutia usoara este adaptarea rapida a unei solutii existente. Lucrurile care trebuie refacute sunt deseori inventii prostesti facute la randul lor de la zero. Cand este necesar, reinventeaza folosind prefabricate, bucati gata existente. Inovatia tehnologica facuta de oameni incapabili sa intelega tehnolgia din jurul lor este cel mai mare dusman in IT.
3. Totul este sub control. Proiectul e 95% gata.
Durere: Termenele se depasesc si sfarsitul proiectului e un miraj. Tehnicul e multumit si spune ca e aproape gata, dar proiectul e inutilizabil. Alternativ, proiectul pare utilizabil dar inca nu e folosit de nimeni si mai trebuie facute mici modificari.
Pastila: Livrarea trebuie setata cu mult inainte de darea in functiune oficiala. Proiectul trebuie utilizat/testat in stadiu alfa/beta cat mai serios (cu testeri sau utilizatori finali reali). Trebuie cunoscute deja partile care chiar functioneaza. Un proiect IT nu este o masina de serie care mai are nevoie de vopsea si scaune, ci un avion experimental. E gata doar atunci cand se poate folosi comod. 95% gata = 15% gata = neterminat/inutilizabil.
2. Am testat, functioneaza.
Durere: Prima versiune este un esec total. Ce parea functional este respins de utilizatori. In afara oamenilor tehnici oricine eticheteaza proiectul ca munca neterminata si aleg sa-l ignore pana chiar functioneaza. Ti s-a spus ca totul este testat si functional.
Pastila: E absolut normal si previzibil ca avionul experimental sa nu poata transporta pasageri cand se lanseaza oficial. Solutia este ca proiectul sa fie deja dat in functiune pe bucati, testat atent de utilizatori reali. Se va considera final atunci cand utilizatorii spun ca functioneaza, nu tehnicii, nu testerii.
1. Ne intereseaza proiectul!
Durerea: Tehnicul pare nemotivat sau neinteresat de proiect. Importanta proiectului este cruciala ca business, insa dintr-un motiv necunoscut nu poti transmite asta mai departe astfel incat sa fie receptionata si aplicata de tehnic.
Pastila: Echipa tehnica e mereu de parere ca are in fata un idiot iremediabil (clientul, omul de business). Singurul lucru care trezeste interesul unui om foarte tehnic este o provocare tehnica, data de tehnologie sau de un coordonator foarte capabil. Altfel, proiectele sunt plictisitoare, clientii imbecili, iar banii nu au vreo relevanta cata vreme iti acoperi nevoile de baza (casa, masa, computer cu internet). Asdar, singurele proiecte de care chiar le pasa oamenilor tehnici sunt cele extrem de tehnice, care foarte rar au o valoare comerciala concreta intr-o companie obisnuita. Solutia este gasirea tehnicilor motivati si de altceva, lucru greu de facut. Alternativ, poti accepta ca nu ii intereseaza si ca vor trata proiectul ca niste mercenari. E perfect cata vreme ai de a face cu mercenari profesionisti ;-)
Definitii: Tehnicul – omul tehnic, echipa tehnica, departamentul tehnic. Proiect – orice sarcina ce trebuie indeplinita, fie aplicatie software, hardware, infrastructura sau serviciu.
Nu toti oamenii tehnici mint (in permanenta ;-) ! S-ar putea sa para jignitoare cele spuse de mine, insa oricine are un strop de experienta stie ca sunt foarte adevarate. Exista (rareori) echipte tehnice cu experinta indelungata, cu un management foarte bun, care nu cad in capcanele miniciunilor de mai sus. Exista (rareori) cand formularile de mai sus sunt adevarate. Rareori!
Minciunile de mai sus ne sunt servite de la tehnic. Noua ne plac, pentru ca o minciuna este o justificare, iar o scuza solida este cel mai facil inlocuitor al unui rezultat. Problema cu scuzele si minciunile este ca nu pot inlocui adevarul sau rezultatele necesare pe termen lung.
Blamarea tehnicului este o … justificare ;-) deci nu rezolva nimic. E necesar sa cunoastem cum suna o minciuna credibila pentru a o identifica rapid. In cele din urma problema interna este una de management, nu una tehnica. Asadar, responsabilul final pentru rezultatele proiectelor si digererea minciunilor este persoana din management. Iti poti asuma costul acestor minciuni?
P.S. Daca ai injurat in gand citind acest articol ai gastigat 20 RON! sub forma unui voucher de la libraria online Okian.ro, valid pentru cumparaturi de peste 100 RON. Le multumesc celor de la Okian.ro pentru ca imi alimenteaza colectia de carti tehnice si de business. Comanda repede doarece sunt doar 20 de vouchere -> MANAC-OKIAN-052J5TE
Posted in Afaceri, Banii tai, Evolutie Personala, Hotnews, Oameni si locuri, Recomandari, Tehnica
December 10th, 2009 at 9:48 pm
Foarte bun articolul, asa cum ne-ai obisnuit :) .
Eu am fost in ultimii 13 de ambele parti ale baricadei si pot sa confirm problemele descrise mai sus dar cauzele nu sunt chiar asa simple cum le-ai descris. Si nici solutiile nu sunt doar cele descrise mai sus.
Problemele de genul acesta apar de cele mai multe ori din cauza oamenilor care conduc proiectul, care nu stiu ce si cum sa ceara si care, din lipsa de experienta, prefera sa lase anumite decizii la latitudinea programatorului.
Mitul programatorului creativ, super calificat, multi lateral dezvoltat, care le face pe toate proactiv este, in cele mai multe din cazuri, doar un mit.
Daca ai un sistem de management al proiectelor eficient, proceduri clare care se respecta si reusesti sa iti castigi programatorii ca fani ai proiectului atunci succesul e asigurat.
December 10th, 2009 at 10:03 pm
:)) foarte tare. Pe toate le-am servit pana acum, de obicei nu am fost crezut (crezuti) dar nu avea nimeni ce sa faca. Cu toate astea, pe final toate par ca se aseaza daca exista un management serios.
December 10th, 2009 at 11:14 pm
Cel mai tare articol despre tehnicieni!!! M-am luptat si eu cu vreo 4-5 dintre ele. Crezi ca se pot schimba oamnii astia vreodata? Hai sa facem brainstorming! Ar fi o solutie care ar cumpara-o multe firme! :)
December 11th, 2009 at 12:33 am
TRĂDĂTORULE!!!! :)
December 11th, 2009 at 1:10 am
Mi se pare mie sau Dragos a trecut in echipa managerilor care nu dau 2 bani pe “tehnici” .. ceea ce ar fi regretabil.
To Dragos :
Cand produsul tau depinde 90% de efortul tehnicilor iar cheltuielile tale se reduc la salarii,internet si calculatoare + free drinks/cofee ultimul lucru pe care vrei sa il faci este sa iti jignesti oamenii care iti aduc profitul .. dar sunt in domeniul asta de ceva timp asa ca nu ma mai mira.
Cat despre mercenari .. o gramada mare in jurul meu sunt dar asta si pentru ca nicio firma nu investeste in oameni mai ales acum asa ca timpul trece leafa merge si lipsa de incredere angajator-angajat nu duce la nimic bun.
Presupun ca de asta ai si postat asa ceva ca un adevarat “manager”.Ceva investitii in training si motivare ar suplini problemele tale dar daca preferi sa pierzi timp e alegerea ta.
PS: Evident postez subiectiv pentru ca sunt de partea cealalta a baricadei.
December 11th, 2009 at 1:19 am
Ceea ce spui tu se aplica in situatia in care oamenii de tehnic si cei de afaceri (marketing) sunt ciudati. Normalul este ca tehnicul sa faca eforturi pentru salariul lor si afacerile pentru proiect ca pana la urma tot salariu lor e.
Cand cele doua echipe nu ajung la puncte de vedere comune mai bine se duc acasa, ca oricum firma aia se duce de rapa.
In alta ordine de idei vii sambata la blug*os*con, in Rectoratul Politehnici Bucuresti incepand cu ora 10.00
Mai multe informatii la http://blugoscon.blug.ro
December 11th, 2009 at 4:19 am
Sunt jumate manager, jumate IT-st. Ca IT-st sunt bun dar in .ro sunt mediu, ca manager sunt slab da in .ro cred ca ash fi super. Concluzie? Din experienta proprie in .ro IT-stii sunt buni ca raport pretz,investitie/calitate. Managerii==nuli==0. Si asta pt ca avem scoli de IT si pasiune pt IT. Dar la managemet avem cel mult un ASE in care te invatza cum sa ai gura mare si aere. Ori gura mare != comunicare && aere != (planning, management competent,relatie profesionala cu clientii si cu angajatii). Per total sunt de acord cu ce zici, insa se pare ca descrii niste echipe formate din oameni saltati de la cursurile de anul 1 de la automatica. Am lucrat si eu cu ei si stiu ca e ceva mai greu, dar mi-au placut ca evolueaza. Ca manageri n-am vazut decat bufnite care stau enshpe ore la servici si cam asta e sg lor calitate si practic plafonul lor superior. Adevarul e nici mediu din .ro nu e asha pro-business si nu au de unde sa apara manageri buni. Spor!
December 11th, 2009 at 8:41 am
Iti inteleg durerea dar cui foloseste ceea ce expui aici? Ai vreo solutie?
Cred ca acest post arata o oarecare ignoranta in ceea ce priveste proiectele software care in general sunt greu de estimat, greu de urmarit si se fac dupa ureche.
Generalizarile nu ajuta..
Ramane de vazut cat esti de dispus sa platesti pentru un proiect implementat de o echipa profesionista si care urmeaza o metodologie.
De asemenea mai ramane de vazut in ce masura esti capabil sa iti structurezi ideile astfel incat proiectul sa fie coerent de la inceput pana la sfarsit. In multe cazuri IT-ul primeste ca input niste vise si trebuie sa scoata ceva utilizabil.
Asadar esti dispus sa platesti? Ai merge la frizer sa iti scoata maselele?
Niste cifre: http://www.it-cortex.com/Stat_Failure_Rate.htm
December 11th, 2009 at 9:11 am
Ok, părerea mea ca şi “tehnic” e asta:
7. Dureaza 3-6-12 luni.
Motiv: De cele mai multe ori specificaţiile iniţiale sunt incomplete. În calitate de tehnic, de multe ori am fost nevoit să dau o estimare mai mare a timpului pentru a acoperi o parte din adăugările/modificările ce puteau apărea pe parcurs. Şi tot de multe ori, acestea au fost în număr mai mare decât am estimat.
6. Lucram la backend.
Motiv: Probabil chiar se lucrează la backend. :)
5. Trebuie sa cumparam echipamentul X, softul Y si solutia Z.
Motiv: Ai dreptate, de cele mai multe ori această afirmaţie vine de la entuziaşti sau de la necunoscători care, pentru a construi un monopost pentru carting, au nevoie de un motor V8.
Uneori însă, chiar e nevoie de o soluţie scumpă, în lipsa căreia… (vezi punctul următor :P )
4. Trebuie (re)-scris/facut de la zero.
Motiv: Probabil nu au fost alocate fondurile pentru soluţia scumpă X de mai sus. :)
Alteori, pentru că ceea ce există deja este o mizerie făcută de amatori, care ar putea afecta dezvoltarea proiectului în viitor. Şi, în cele din urmă, da, probabil e nejustificată propunerea.
3. Totul este sub control. Proiectul e 95% gata.
Motiv: Probabil că, în conformitate cu specificaţiile iniţiale, proiectul chiar este 95% gata. Totuşi, cum am mai spus, acele specificaţii iniţiale nu sunt întotdeauna complete şi mai apar modificări neprevăzute pe final. Ce-i mai dureros este că, destul de des, managerii/persoanele atehnice vin pe final cu chestii de genul: “ar mai fi o chestiuţă pe care vreau s-o faceţi, dar care n-o să vă ia mult”… De unde ştii că n-o să ia mult? Ştii ce implică asta din punct de vedere tehnic?
2. Am testat, functioneaza.
Motiv: Probabil ai lăsat un tehnician să proiecteze interfaţa cu utilizatorul. Să-ţi fie învăţătură de minte! :) Aplicaţia probabil chiar funcţionează, dar într-un mod nu foarte intuitiv, pe care o persoană normală nu-l înţelege cu uşurinţă, de aceea ajunge să fie respinsă.
1. Ne intereseaza proiectul!
Motiv: Lipsa specificaţiilor, lipsa fondurilor pentru resursele necesare, constrângerea de a lucra pe cod deja existent şi de proastă calitate, presiunile şi impunerea unui “workflow” anormal, de genul “mai lăsaţi backend-ul şi faceţi ceva şi la frontend să putem arăta ceva clientului”, chestiile “mici” care apar când ţi-era lumea mai dragă şi credeai că începi să întrezăreşti luminiţa de la capătul tunelului, reproşurile şi lipsa recunoştinţei pentru faptul că ai tras ca un bou şi ai făcut tot posibilul să mulţumeşti o echipă de marketing care mai mult te-a încurcat decât să te ajute… Ei bine, toate astea pot duce în unele cazuri la un oarecare dezinteres în ceea ce priveşte un proiect! :)
December 11th, 2009 at 2:57 pm
Acest post foloseste managerilor si oamenilor tehnici. Daca era o problema cu o solutie care sa intre intr-un post de blog nu m-as fi obosit sa o aduc in discutie. Nu e vorba despre cum se fierbe un ou, ci de cum se lucreaza intr-o industrie noua, imatura. Vad ca solutia ta este “specificatia” perfecta. O sa scriu un articol despre cat de aberant este acest concept, deoarece atinge rapid aproape tot ce e gresit cu modul in care ne gandim la IT.
December 11th, 2009 at 4:06 pm
cu aia cu “trebuie refacut de la 0″ nu prea sunt de acord, sunt multe proiecte la care ai scapa muuult mai usor daca l-ai reface from scratch decat daca ai tot carpi pe ce au lucrat niste “meseriasi”
December 11th, 2009 at 4:07 pm
also, la 3 sferturi din problemele puse de tine raspunsul e “Agile”.
December 11th, 2009 at 4:28 pm
Nu specificaţia perfectă ci completă… Nu prea ai cum să faci estimări pentru o chestie despre care nu ştii destule. Mai dureros este că ţie ţi se pare că un tehnician ar trebui să ştie cum să rezolve probleme despre care tu nici măcar nu ştii că există, atâta vreme cât consideri că ar trebui să prevadă toate viitoarele cerinţe care nu apar în specificaţii… Cum am mai spus, eu încercam să includ şi o parte (pe care puteam cât de cât s-o deduc) din eventualele provocări, însă, de multe ori, asta nu este de ajuns.
December 11th, 2009 at 4:35 pm
Nu exista specificatii perfecte / complete.
Din experienta pot spune urmatoarele:
- specificatiile se impart in “long term goals” si “small steps” unde fiecare long term goal e compus din mai multi small steps
- la inceput trebuie sa defineste unde vrei sa ajungi, in cat timp si la ce bani
- cand ai obiectul general definesti long term goals, faci o lista si apoi incepi sa tai tot ce este irelevant, irealist, nu se poate incadra in termen si in bani
- cand ai trecut si de etapa asta iei primul long term goal si definesti small steps
- definirea de small steps se face doar inaintea inceperii lucrului la un long term goal
Cateva lucruri generale:
- toti cei implicati in proiect, indiferent de competente, trebuie sa lucreze impreuna, nu unul impotriva altuia
- in online, specificatiile unui proiect se pot schimba de la o zi la alta in functie de cum evolueaza piata (se poate scrie un articol si despre asta, e poveste lunga despre cum te poti proteja in astfel de situatii)
In incheiere trebuie sa spun: acest textarea e mult prea mic (latime) si imi este greu sa scriu mai mult :)
December 11th, 2009 at 4:36 pm
tare clasamentul:) eu fac parte din management si subscriu la cele spuse de tine. La toate.
Prima, cea cu 3-6-12luni, mi se pare cea mai grea de “tratat” intrucat chiar daca la majoritatea proiectelor adaug circa 30% la timpul comunicat de echipa tehnica, mi s-a intamplat si mi-o iau peste ochi de cateva ori ca nu am livrat la timp. Inca mai am de invatat cum sa tratez mai bine deadlineurile date de tehnic.
Partea cu “lucram la backend” cred totusi ca sta in atributiile account managerului, sau echivalentului acestuia, sa-i explice clientului valoarea adaugata chiar daca ea va fi undeva in “backend” si nu va putea fi testata direct de catre client.
December 11th, 2009 at 4:44 pm
Eh… Cât despre încheierea “tot ce e gresit cu modul in care ne gandim la IT” eu cred că ar trebui să fie mai degrabă “tot ce e gresit cu modul in care oamenii de marketing se gândesc la IT”, ceea ce este complet diferit. De exemplu, un vânzător de la alimentară se gândeşte la oamenii din IT ca la ăia care le instalează lor Windows-u’. Greşeli de genul ăsta există şi în modul în care marketing-ul percepe IT-ul.
P.S.: Scuze, dar a expirat timpul în care-mi puteam edita comentariul anterior!
December 11th, 2009 at 6:34 pm
Salut Dragos,
In lumea IT de cativa ani exista solutii (si abordari) verificate pentru probleme si proiecte de acest gen.
Vezi concepte de dezvoltare (si livrare de functionalitate) iterativa gen Agile, Scrum, Extreme Programming si modurile de lucru gen Feature Driven Development, Test Driven Development – solutiile intuite de tine se apropie pe undeva de aceste concepte. In principal modul de lucru Agile propune lucrul in iteratii (ex: 2 saptamani), livrare continua de functionalitate (ex: vezi Google care poate livra functionalitati noi la fiecare cateva ore fara sa strice functionalitatea existenta), flexibilitate mare ce permite adaptarea la cerintele clientului/pietei chiar daca ele vin tarziu in decursul proiectului. Vezi si: http://agilemanifesto.org/principles.html
Alocari gen “lucrul la backend 3-6 luni” sunt incompatibile cu Agile si sunt considerate o greseala din start.
Exista si in Romania o miscare firava in aceasta directie. Un exemplu: http://www.agileworks.ro/agile-scrum-more/
Hai ca ma intind la povesti si am pierdut un Pomodoro pentru acest comentariu (vezi http://www.pomodorotechnique.com/).
December 11th, 2009 at 6:45 pm
Mihai,
Sunt perfect de acord cu tine si un mare fan al metodelor de dezvoltare agile. Teoria se aplica si proiectelor IT non-software, insa si acolo exista solutii. Existenta acestor metode, din nefericire, nu inseamna automat ca sunt folosite la nivelul la sunt necesare.
December 11th, 2009 at 7:20 pm
As redenumi articolul: Top 7 caracteristici care definesc IT-istii incompetenti
December 11th, 2009 at 8:26 pm
@Mihai
Nu era vorba niciunde de “lucrul la backend 3-6 luni”. Era vorba de estimarea pentru un întreg proiect, care să dureze în totalitate 3-6 luni. Lucrul la backend era altă poveste, nu le amesteca.
În iteraţii de 1 săptămână (nu 2, cum ai propus tu), la o aplicaţie complexă ce cuprinde 6 secţiuni principale cu câte 4 subsecţiuni fiecare, unde fiecare iteraţie presupune lansarea unei versiuni finale pentru câte o subsecţiune, dacă facem calculul ai să vezi că se ajunge cu uşurinţă la un termen de 6 luni. Asta fără a mai lua în calcul perioada de cercetare/documentare şi cea pentru design (nu numai design-ul grafic, ci design-ul produsului, cu caracteristicile şi modul său de funcţionare).
Încă un lucru: nu compara Google cu boutique-urile din .ro! Pentru a lansa acel feature de care vorbeai în numai câteva ore au fost nevoie de săptămâni (dacă nu luni) de cercetare şi testare. De exemplu, caută şi vezi cam de cât timp este în teste unul din ultimele feature-uri Google: fade-in şi fade-out pentru toate elementele din homepage-ul Google, cu excepţia logo-ului şi a formularului de căutare.
-
Nu neg faptul că şi la noi se pot face lucruri de calitate şi într-un interval relativ mic de timp, ci vreau doar să subliniez că vina (acolo unde e cazul) este împărţită între cele 2 grupuri de oameni. IT-iştii sunt uneori incompetenţi, dar asta nu înseamnă că oamenii de vânzări/marketing/creativii/etc. au întotdeauna dreptate. Cercetarea şi documentarea sunt la fel de importante ca dezvoltarea.
Un exemplu recent este proiectul de la Launch48, http://sevinde.ro . Nişte oameni au venit cu ideea, a părut ok şi s-au grăbit s-o implementeze doar pentru a arăta că, vezi doamne, se poate!
Aiurea! Dacă ar fi cercetat cineva un pic, ar fi aflat că în multe dintre oraşele mari din ţară (Timişoara, Constanţa, etc.), consiliile locale au interzis afişele gen “Mă vinde” din geamurile autoturismelor, aplicând amenzi celor care nu respectă hotărârea. Astfel, ideea care făcea proiectul să fie diferit de alte site-uri de anunţuri, s-a cam dus naibii… Asta nu i-a oprit s-o implementeze. Asta până când vor descoperi lipsurile şi îşi vor da seama că-s doar un alt site de anunţuri, dar căruia îi lipsesc o parte din beneficiile oferite de restul site-urilor de acelaşi gen. Deci, deşi s-a lucrat mai puţin, rezultatul este unul slab, fapt ce ar fi putut fi evitat dacă se investea mai mult timp în studierea problemei, găsirea soluţiei şi implementarea ei. Să nu mai vorbim de faptul că ideea se presupunea a fi implementată în 48 de ore… Care ore au cam trecut!
Ideea e că, dacă vrei ceva de calitate, trebuie să investeşti timp şi resurse, nu se poate face orice doar bătând din palme!
December 12th, 2009 at 12:18 pm
inca o contra-partida: http://www.euareblog.ro/catalin-nicolescu/top-7-minciuni-de-la-tehnic/
December 12th, 2009 at 9:58 pm
Dragos Manac: “Nu e vorba despre cum se fierbe un ou, ci de cum se lucreaza intr-o industrie noua, imatura.”
Acum vreo 20 de ani, cind am primit primul PC si ceva carti/reviste, auzeam acelasi lucru.
Cred ca e timpul sa ne consideram o industrie matura, si sa ne comportam ca o industrie matura.
December 13th, 2009 at 4:26 am
Scrum e cool pentru manageri pentru ca ignora toata partea aia tehnica nesuferita si obtii grafice colorate si iluzia ca treaba merge.
Are si parti bune. E bine sa impui revizii periodice a ceea ce s-a facut, ce trebuie facut, sa impui un stil de lucru care produce imbunatatiri mici si constante. Programatorii sunt ca studentii, daca-i lasi de capul lor vor toci in noaptea de dinaintea examenului.
Altfel Scrum e o mare prostie. Cel mai grav: nu se aloca timp elaborarii de specificatii si estimarilor tehnice. Task-urile sunt alese exclusiv pe baza meritelor business si executantii sunt fortati sa scoata estimari din burta ad-hoc. Rezulta eforturi de dezvoltare care nu au decit intimplator legatura cu realitatea. Se rateaza in mod constant obiectivele sau sunt atinse prin eforturi anormale care taxeaza programatorii.
Alta prostie: culpabilizarea si stresarea executantilor. Termenele nerealiste incep sa se resimta iar pentru cei care protesteaza Scrum recomanda luarea in vizor si eliminarea pentru ca “nu se pot adapta”. Incepe sa semene a cult religios? Stati s-o vedeti pe urmatoarea:
Se transforma comunicarea in interiorul echipei in scop in sine si se iroseste timp cu ritualuri imbecile. Exemplu: daily meetings. Teorie: promoveaza comunicarea in echipa si transmiterea informatiei privind mersul proiectului. Practic: comunicarea oricum are loc, vorbim de membrii aceleiasi echipe care lucreaza permanent impreuna. Acele 15 minute se transforma in minim 30 de productivitate zero datorita plimbarii pina la locul obligatoriu de intalnire, toata treaba devine o mini-vacanta. Daca mai ai si un manager de geniu care decide sa se faca daily meeting dimineata poti sa arunci la cos o ora intreaga. Toate astea ar putea fi inlocuite cu un simplu email de la fiecare membru catre team leader la sfarsitul zilei.
Metodele Agile sunt in general extremisme. Contin elemente bune dar din pacate e nevoie de manageri priceputi pentru a le extrage. Ceilalti le aplica orbeste si obtin doar moduri noi si interesante de fail.
December 13th, 2009 at 11:16 am
Foarte bun articolul. Si eu m-am intalnit cu diverse probleme la niste persoane amatoare care lucrau in domeniul IT. Puteau sa faca orice pana sa se apuce de el.
December 13th, 2009 at 5:07 pm
Permiteti-mi sa dau replica la cele sapte puncte.
7. Corectitudinea estimarilor depinde de claritatea si completitudinea specificatiilor si de cat de mult sunt schimbate pe parcurs. Nu sunt posibile specificatii perfecte si uneori se impun schimbari pe parcurs; dar atunci acceptati faptul ca automat proiectarea initiala trebuie ajustata si ca va exista un impact.
6. Este un caz particular al problemei 7. Un backend de calitate este mult mai flexibil si permite mai multe features pe frontend. Dar trebuie sa se aloce initial timp suficient pentru a fi proiectat si creat, iar specificatiile trebuie sa fie robuste. Daca se lucreaza exagerat de mult la backend inseamna ca (a) specificatiile de baza variaza anormal de des; si/sau (b) nu s-a investit suficient timp in faza de proiectare a backend-ului, s-a facut o carpeala care trebuie peticita si ajustata permanent.
5. Cateodata trebuie sa cumperi anumite solutii. Nu toti oamenii din IT produc snake-oil. Unii produc lucruri valoroase, stiu ca sunt valoroase si le vand la un pret corespunzator. Exemplu: cand graficianul cere Photoshop, i-l cumperi.
4. Mirajul refacerii de la zero este un viciu al oamenilor tehnici. Este atractiv pentru ca le permite sa proiecteze o solutie completa, un exercitiu care angreneaza toate cunostintele si creaza experienta valoroasa. Cei care doresc sa se maturizeze trebuie sa si-l recunoasca si controleze. Maturizare insemnand sa livreze.
3+2. Uneori este o problema de usability; interactiunea cu end-user este neadecvata. Din pacate se acorda foarte rar suficienta atentie interfetei utilizator. Este creata fie de oameni tehnici, care nu sunt utilizatori tipici, fie de management, client, graficieni etc. care nu au neaparat competentele necesare.
Apoi, orice proiect IT are anumite faze peste care nu se poate trece. Din pacate deseori se taie din testing si bug-fixing pentru a oferi mai multe features pe hartie. Asumati-va consecintele.
1. Nu sunt de acord cu explicatia data. Inginerii sunt artizani care creaza lucruri estetice si functionale. Uneori opere de arta. Isi iubesc meseria pentru ca lasa ceva in urma lor si le pasa de fiecare surub montat. Au implicit o reactie viscerala impotriva celor a caror meserie jongleaza cu lucruri intangibile si/sau care le trivializeaza munca.
Daca doriti ca oamenii din IT sa fie realmente interesati: tratati-i cu respect; platiti-i corect; incercati sa le intelegeti munca. Acest ultim aspect este mai important decat se crede. Nu poti face management IT aplicand precepte generice de management sau teorii din carti. Trebuie sa stii ce presupune procesul specific si sa cunosti caracteristici, idiosincrazii, cutume etc. ale oamenilor din bransa.
Abia cand aceste conditii nu sunt indeplinite oamenii din tehnic devin cinici si dezinteresati. Este o greseala enorma sa porniti de la ideea ca sunt fie geeks complet rupti de realitate fie mercenari. Acestea sunt cazuri extreme. Omul tehnic tipic isi doreste (a) sa produca lucruri utile (b) sa-si sporeasca cunostintele facand asta si (c) sa fie apreciat pentru munca facuta.
December 13th, 2009 at 6:29 pm
[...] Manac publica propriul top al minciunilor “de la tehnic”. Totusi, imi pare ca arunca prea usor vina in gradina [...]
December 15th, 2009 at 12:45 pm
f adevarat
December 20th, 2009 at 11:39 pm
Minciuna!
December 21st, 2009 at 2:38 am
Bun postul asta Antreprenor 2010. Ai facut o treaba buna Dragos Manac. La cat mai multe..
February 16th, 2010 at 12:11 pm
uau… ce de comentarii :))
imi plac cele care au raspuns punct cu punct la cele expuse, NOT! (desi le-am citit printre randuri)
ai atins un punct sensibil, pentru ca partea tehnica are contra-argumente si mai dureroase. da, proiectele ies de cacat atunci cand cel care le cere / coordoneaza este un idiot sau nu stie sa ce sa ceara si asta este cruda realitate de care ei se lovesc mai des.
considerand tonul in care au fost scrise as zice ca te-ai lovit de curand de proiecte ce tine de web / online… soft-ul corporate e uneori intr-o situati mai buna, alteori intr-o situatie chiar mult mai proasta :).
2 chestii pe care tot managerii ar trebui sa le stie:
– trebuie investit intr-un arhitect de solutii competent cu experienta in spate in domeniul respectiv. tehnicul va face o aplicatie pe care sa o inteleaga doar ei, nu oamenii obisnuiti, iar testarea primeste ceva care nu mai poate fi schimbat decat cu eforturi masive si este pusa intr-o situatie de a se multumi cu ce exista ca altfel “nu mai vine banul”
– in romania nu se investeste si in calitate, se pune accent pe dezvoltare – solutie care se doveste “distractiva” mai putin pentru investitor si client. aplicatia nu e testata din primele etape si ok-ul se da cu jumatate de gura, ii cunosc doar pe programatori, merg la bere impreuna…
February 18th, 2010 at 12:14 am
Industria asta nu e nici nouă nici imatură. Am lipsit noi din peisaj şi improvizăm. Vrem să facem e.g. cloud computing cu mentalitate de studenţi şmecheri (it/management).