Luați o ceașcă de cafea, dragi pasionați de software, pentru că suntem pe cale să ne îmbarcăm într-o călătorie în lumea adesea plină de umor, uneori tragică, dar întotdeauna edificatoare a eșecurilor de proiect. Prima noastră oprire: Stația Așteptărilor. Aici, managerii plutesc într-un ocean de optimism, conduși de curenții subțiri ai așteptărilor, în timp ce acei din proiecte, care fac munca, se simt de parcă ar fi în niște tranșee, în plin război. În condițiile în care comunicarea dintre aceștia este la fel de rară ca o zi însorită în decembrie, dezamăgirea este singurul lucru care se poate obține în mod natural. Din păcate, lucrurile nu se opresc aici. Conduși de idei și intenții bune, cum ar fi decizii și retrospective bazate pe date și fapte, avem de cele mai multe ori nefericita onoare de a fi înșelați de propriile metrici.
Cine ar fi crezut că o excursie în munții din Utah ar duce la așa o schimbare în privința modului în care privim munca? În februarie 2001, un grup de șaptesprezece oameni s-au întâlnit cu scopul de a petrece timp în aer liber și de a se bucura de natură, retrăgându-se într-o cabană la munte. Ei au făcut însă mai mult decât atât, pentru că - imediat după călătorie - întreaga lume urma să citească Manifestul Agile (Agile Software Development Manifesto).
Intenția cu care scriu acest articol este de a împărtăși din experiența de a organiza o conferință internațională în cadrul unei companii de IT cu peste 10.000 de angajați, pe patru continente. Sper să fie utilă celor care fac acest lucru pentru prima dată sau care doresc să vadă și alte abordări.
Avem o tendință naturală să ne avântam în a găsi soluții fără a înțelege pe deplin problema ce se cere a fi rezolvată. O astfel de gândire, axată „pe soluții”, poate conduce la o abordare ineficientă în rezolvarea problemelor. Doar prin înțelegerea profundă a problemei putem atinge potențialul pentru soluții remarcabile, altfel riscăm să generăm soluții pentru probleme inexistente, irosind resurse.
M&A planificate strategic pot ajuta companiile să construiască reziliență, doar că acestea presupun mult mai mult decât executarea unui șir lung de oferte. Achizitorii trebuie să articuleze exact de ce și unde au nevoie de fuziuni și achiziții pentru a aborda probleme și obiective specifice care stau la baza strategiilor lor corporative. În plus, ei trebuie să acorde o gândire atentă cu privire la modul în care intenționează să urmărească aceste procese de M&A programatice și să conceapă inclusiv un plan de afaceri ca atare. Tipurile și metodele fuziunilor și achizițiilor se împart în patru categorii mari. Cea orizontală, verticală, conglomerată și congenerică. În general, indiferent de tip, o companie va achiziționa o altă companie, deoarece factorii săi de decizie cred că va îmbunătăți mersul afacerii fie prin creșterea vânzărilor, scăderea costurilor, fie prin alte moduri.
Mereu am fost atrasă de Artă, Estetic, Frumos. La prima vedere, ce fac acum - Consultanță și Coaching în Agile, în mediul de Software - pare să fie contrar plăcerilor, pare să fie că mi-am antrenat latura de pragmatism, rigiditate, formule și metrici. Astăzi, mi-am propus să scot la iveală, latura creativă din acest proces și să observăm cum Arta, Leadershipul și Programarea se intersectează armonios, iar cu instrumentele potrivite, din produsul tău poți forma o întreagă operă de artă!
Companiile de software locale par să folosească în cea mai mare parte Agile. A vedea ca agile coach că pășim cu toții în aceeași direcție a agilității este încurajator. Dar e destul de evidentă legătura dintre excelența tehnică și agilitate?
Acum mulți ani, un coleg consultant olandez m-a recomandat unui business olandez ce avea un centru de dezvoltare în Cluj pentru a face un audit. Nu am avut mare succes în această organizație. Cu totul surprinzător pentru mine, m-au rugat să revin pentru a verifica progresul și a face niște recomandări. Au înțeles că în calitate de auditor le pot oferi doar răspunsuri teoretice. Nu le puteam spune ce să facă sau cum să facă, dar clientul a fost mulțumit cu acest lucru.
Câți dintre voi vă mai amintiți, din perioada în care erați copii, ce vă doreați să deveniți când veți fi mari? Când mamele noastre sau profesorii noștri ne întrebau: “Ce vrei să te faci când vei fi mare?” Poate unii dintre noi și-au dorit să devină piloți și să zboare peste tot în lume. Alții visam să fim bucătari și să pregătim mâncare pentru cei dragi. Sau poate ne doream să fim ca Neil Armstrong și să ajungem pe Lună. Cu siguranță, fetele și-au dorit să devină balerine, dansatoare, actrițe, exploratoare, visând să devină celebre. Ce vremuri, nu-i așa? Câți dintre voi ați dorit să deveniți QA, programatori, arhitecți software, BA sau PO?
Termenul „over-engineering” este utilizat frecvent pentru a desemna procesul de a complica inutil un sistem sau un produs. Acest lucru se poate întâmpla din mai multe motive, inclusiv din incapacitatea de a înțelege corect o problemă, dorința de a-i impresiona pe ceilalți cu complexitatea răspunsului nostru sau credința că este calea „corectă” de acțiune. În acest articol, vom analiza atât cauzele acestui fenomen, cât și modalități de a-l evita pe cât posibil în munca noastră zilnică.