Back
Diario del CEO

La mia prima esperienza come project manager: cosa ho imparato dai miei primi clienti?

Tra il 2014 e il 2016, PrestaRock era composta da tre sviluppatori, me compreso. La mia giornata lavorativa era ora strutturata in modo diverso: circa il 30% del mio tempo era dedicato alla gestione del progetto e alla comunicazione con il cliente, un altro 30% alla coordinazione dei compiti, alle descrizioni e alla preparazione delle specifiche, e il tempo rimanente veniva dedicato alla programmazione.

Come erano i miei primi clienti? Cosa ho imparato da loro e quali errori ho commesso? Perché ogni mio email o richiesta migliorava nel tempo?

Come freelance, ho notato che passavo quasi la metà del mio tempo di programmazione al telefono e nelle email. Questo mi ha naturalmente portato a avviare la mia azienda. Sono passato organicamente da sviluppatore a project manager, e la mia conoscenza in questo ruolo è stata principalmente plasmata osservando come altri project manager avevano lavorato con me nel corso della mia carriera.

Ho anche scritto di come, quando ero un programmatore che lavorava in un’agenzia pubblicitaria, fosse fastidioso che il project manager non avesse conoscenze tecniche. Di conseguenza, la gestione del progetto era semplicemente un’attività di trasmissione di messaggi e di agire come intermediario “copia/incolla” tra me e il cliente.

Mi immaginavo come un tipo completamente diverso di project manager che potesse risolvere questo problema. Volevo essere in grado di rispondere a qualsiasi domanda tecnica in tempo reale durante le riunioni, fornire raccomandazioni su come implementare soluzioni in modo più efficiente (interpretando il ruolo di un analista) e stimare i compiti sul posto. Questo approccio ha gettato le basi di ciò che PrestaRock rappresenta oggi—Rock Solid Ecommerce Solutions.

AGILE invece di WaterFall

Abbiamo introdotto il principio del one-stop-shop, garantendo che i project manager non dovessero dire: “Non lo so, devo controllare con lo sviluppatore per vedere se è possibile, quanto costa, ecc.” Avere un unico canale di comunicazione via email è diventata la nostra garanzia di velocità e qualità.

Basandomi su ciò che avevo sentito all’università, ho gestito i progetti nel modo migliore che conoscevo. Ho implementato un metodo di gestione del progetto AGILE SCRUM nell’azienda, introdotto SPRINT settimanali, documentato processi e istruzioni e abbandonato uno stile di lavoro ad hoc in cui i compiti venivano assegnati casualmente. Invece, abbiamo pianificato tutto e strutturato correttamente i compiti.

Questo mi ha permesso di distribuire il lavoro in modo più efficiente. All’inizio di ogni settimana, documentavo e assegnavo i compiti agli sviluppatori, garantendo che non avessero bisogno di interrompermi durante la settimana. Questo mi ha liberato per concentrarmi sulla programmazione o sul lavoro con i clienti.

Ho acquisito conoscenze non solo dalle mie esperienze precedenti, ma anche imparando dai miei clienti. Ogni email migliorava nel tempo—iteravo sul mio stile di scrittura, sulle risposte e sull’approccio comunicativo con ogni interazione. Ho cercato ciò che Brian Tracy chiama “eccellenza.”

Come freelance, ho avuto l’opportunità di lavorare con alcune delle più grandi attività di e-commerce dell’epoca, e ho avuto la fortuna che i miei primi clienti fossero più esperti di me. Alcuni mi hanno inviato richieste ben strutturate, e ho capito che il loro formato sarebbe stato utile per gli altri. Così ho iniziato a utilizzare una struttura simile per gli altri clienti. Attraverso tentativi ed errori, abbiamo sempre avuto più lavoro di quanto potessimo gestire.

Sfide e Primi Errori

Tuttavia, le sfide arrivarono presto. Man mano che crescevamo, abbiamo commesso i nostri primi errori e sperimentato i nostri fallimenti. Durante quegli anni, ci siamo trovati ad affrontare clienti esigenti e, onestamente, proprio come lavorare con dipendenti non talentuosi, era più difficile lavorare con clienti inesperti.

Desiderare di essere un buon fornitore di servizi = Scadenze mancate

Dieci anni fa, uno dei nostri primi fallimenti era che il nostro team era ancora piccolo. A volte calcolavamo male le durate dei compiti, portando a ritardi perché i compiti venivano completati da qualcun altro anziché da me. Inoltre, spesso sorgevano lavori extra inaspettati, che i clienti assumevano sarebbero stati consegnati entro la stessa scadenza, anche quando lo scope si espandeva.

Come project manager, non sapevo gestire le aspettative, rendendo difficile convincere i clienti che alcuni compiti dovevano essere suddivisi in fasi separate o pianificati come una nuova fase.

In definitiva, talvolta promettevo involontariamente scadenze irrealistiche, che non potevamo sempre rispettare. Guardando indietro, però, l’intera industria dell’e-commerce era come il Far West, e nessun progetto IT in Lituania veniva mai completato in tempo durante quegli anni.

Lavoro Aggiuntivo: Sempre Pagato?

Uno dei miei più grandi fallimenti è stato il tentativo di un cliente di costruire un “centro commerciale online.”

Anche allora, sapevo che l’idea sarebbe fallita, ma non sono riuscito a convincere diversamente il cliente. Quindi, abbiamo proseguito. Tutto andava bene fino a quando il cliente ha importato 500.000 prodotti su PrestaShop 1.6. E cosa è successo? Ovviamente, PrestaShop non ce l’ha fatta.

Ancora una volta, è emersa una mancanza di conoscenze sulla gestione del progetto. Il nostro team ha iniziato ad ottimizzare gratuitamente il progetto, anche se era un lavoro aggiuntivo. Non sono riuscito a convincere il cliente che avrebbe dovuto pagare quasi quanto costava il progetto per farlo funzionare.

Ma non eravamo il tipo di azienda che lasciava incompiuto un progetto, quindi abbiamo continuato a lavorare gratuitamente.

I Clienti Inesperti Si Preoccupano Solo del Risultato Finale

Una situazione simile si è verificata con un negozio di gioielli d’ambra ecommerce proveniente dalla costa. Il cliente non sapeva niente di computer, internet o negozi online ma voleva costruirne uno.

Abbiamo aiutato con tutto finché non ci siamo trovati di fronte a un problema—le foto dei prodotti del cliente erano di scarsa qualità e non correttamente scattate. Eppure, siamo stati incolpati perché, dal punto di vista del cliente, il risultato finale avrebbe dovuto funzionare senza problemi.

Non capivano, anche dopo tre o quattro riunioni, quando spiegavamo che la piattaforma di e-commerce generava miniature da ciò che il cliente caricava; abbiamo cercato di risolvere la scarsa qualità delle foto in modo programmato.

La situazione è peggiorata quando abbiamo dovuto integrare un nuovo modulo di carta di credito PayPal appena rilasciato. Il cliente ha chiesto: “Fallo funzionare come eBay!” Tuttavia, PrestaShop non aveva un modulo di terze parti per questo, e la tecnologia di PayPal non lo permetteva. Il cliente non lo accettava ancora.

I Clienti Che Dichiarano di “Non Avere Soldi”

Ricordo di aver visitato una delle più grandi aziende di Kaunas per discutere lo sviluppo di un negozio di elettronica ecommerce.

Il CEO continuava a lamentarsi che i nostri prezzi erano troppo alti e insisteva sul fatto che tutto dovesse essere più economico. Poiché si trattava di un cliente importante e prestigioso, ho offerto sconti.

In seguito, ho scoperto che questa azienda aveva un fatturato annuo di 30 milioni di euro e milioni di profitti.

All’epoca ero giovane e inesperto, quindi offrivo sconti a quasi tutti. Questo mi ha reso un contraente ideale: economico, veloce e di alta qualità.

Gli Errori dello Sviluppatore Danneggiano le Relazioni con i Clienti

Infine, una delle nostre sfide più grandi erano gli errori degli sviluppatori.

Non avevamo tester all’epoca. Dopo i miei primi progetti, ho capito che dovevo rivedere tutti i compiti, così sono diventato sia un project manager che un tester.

Era scioccante che se commettevo 10 errori mentre programmo per clienti statunitensi, i miei sviluppatori ne facevano altrettanti in ogni compito di 5 ore.

Per i clienti orientati ai risultati, gli errori all’inizio del progetto distruggevano la fiducia. Diventava impossibile addebitare il lavoro aggiuntivo perché i clienti incolpavano i nostri errori e richiedevano correzioni gratuite. E poiché volevamo essere i migliori, “rimborsavamo i nostri errori”—spesso a nostre spese.

Sommario

I primi anni lavorando con i clienti sono stati principalmente di successo—fino a quando abbiamo iniziato a crescere rapidamente. La crescita rapida significava che siamo passati solo da me a tre sviluppatori. È sembrato un grande salto, considerando che inizialmente condividevamo un ufficio con un designer, e ora gli sviluppatori occupavano completamente il nostro spazio.

Man mano che crescevamo, abbiamo accettato ogni possibile cliente e progetto, il che ha portato ai nostri primi fallimenti—alcuni clienti dovevano essere lasciati andare, e alcuni progetti non avrebbero mai dovuto essere avviati. Gli errori, la correzione gratuita e la nostra incapacità di difenderci contro il lavoro aggiuntivo non retribuito ci hanno impedito di raggiungere una redditività adeguata—stavamo lavorando per coprire i nostri stipendi.

Tuttavia, queste lezioni hanno gettato le basi per i nostri progetti più significativi, che verranno descritti nei prossimi post. E soprattutto, non abbiamo ripetuto i nostri errori—e entro il 2015-2016, eravamo già diventati l’agenzia leader nelle soluzioni PrestaShop. I clienti riconoscevano PrestaRock come una delle poche aziende in grado di codificare correttamente e offrire servizi di alta qualità.