Che ci piaccia o no, se facciamo un progetto per hobby, solo per il nostro divertimento personale, ma anche per il più tecnico si diventa, in realtà, un project manager e ha un ruolo nella gestione operativa come responsabile unico della valutazione, pianificazione, realizzazione e controllo di un progetto. E, come Project Manager, possiamo sperimentare il crepacuore del fallimento di un nostro progetto.
Ci sono molti modi in cui un progetto può fallire. Si può non riuscire perché le scadenze non vengono rispettate, i bilanci si sono superati, i risultati non sono ciò che è stato richiesto, ecc. Ma può anche fallire emotivamente: il progetto può avere successo, ma le aspettative della gente non riflettono l’attesa e non c’è alcuna gratificazione per un lavoro ben fatto.
Il Project Manager può essere un rappresentante del committente incaricato di realizzare il progetto. Il suo obiettivo essenziale è quello di assicurare il rispetto dei costi, dei tempi e della qualità concordati e soprattutto il raggiungimento della soddisfazione del committente.
Cosa può fare il tecnico Project Manager per ridurre al minimo le possibilità di essere aggiunto nella lista di “progettisti falliti” al curriculum? La risposta è: fare più o meno quello che fanno i non tecnici responsabili del progetto.

Gestire le aspettative
Va benissimo pensare che la realtà sia importante ma, nel mondo degli affari, si sa che tutto quello che la gente pensa o crede che sia successo sia sempre più importante di ciò ch’è realmente accaduto; e lo stesso vale per i progetti. Anche alcuni dei progetti di maggior successo può soffrire di una mancanza di aspettative che eclissa per sempre il buon lavoro che è stato fatto ed i benefici ricevuti. E se il fallimento delle aspettative è abbastanza grave, può anche minare e far deragliare altri progetti che si stavano facendo bene. Quindi, come si fa a gestire le aspettative?
Per prima cosa, assicurarsi che tutto sia molto chiaro su ciò che nel progetto si deve fare, quali saranno i benefici, quali dati devono essere richiesti agli utenti, quali sono le necessarie risorse per sostenerlo, da quali altri progetti potrebbe dipendere e quello che dovrebbe fare. Si è elencato l’ultimo punto due volte, ma è davvero importante! Molte volte gli utenti sentono solo quello che vogliono sentire; magari si può fare un promemoria o una breve conversazione per impostarlo bene.
Prestare particolare attenzione a ciò che il responsabile dice a proposito del progetto, sia fuori dal lavoro sia in seguito quando il progetto avanza, e muoversi rapidamente per correggere eventuali false dichiarazioni che si fanno, prima che possano diventare saggezza accettata, come parte integrante dell’ambito del progetto, fin dall’inizio.
Allo stesso tempo, muoversi altrettanto rapidamente e educatamente per affrontare qualsiasi tipo di discorso negativo che si sente parlare del progetto. L’idea non è quella di silenziare il discorso ribelle -anche se si prende l’elenco dei nomi non è una cattiva idea, caso mai per dopo-, ma piuttosto di scoprire se si tratta di un malinteso o di una cattiva esposizione dei fatti, o s’è qualcosa che potrebbe trasformarsi più tardi in un problema per affrontali tempestivamente, o per modificare le specifiche del progetto, dando ancora un altro sguardo a quegli assunti di base.
Non essere tradizionale, ma iterativo
In un tradizionale progetto di tipo a cascata, si sviluppa un piano di un progetto che parte dall’inizio e va avanti fino alla fine; quando termina si tiene conto del tempo globale e la sua stima in euro. Non farlo! Utilizzare un metodo iterativo, una metodologia agile (o leggera) o metodo agile per il progetto -si intende un particolare metodo per lo sviluppo del software che coinvolge quanto più possibile il committente, ottenendo in tal modo una elevata reattività alle sue richieste- in cui ogni passo si conclude con un risultato o prodotto facilmente verificabile e altamente visibile per facilitare alle persone di misurare le loro aspettative nei confronti.
Nonostante le similitudini, i progetti tecnici non sono come la costruzione di un ponte. Le incognite principali per la costruzione dei ponti sono le caratteristiche del suolo dove si sta mettendo le sue fondamenta. Una volta che viene valutata, gran parte dell’incertezza viene tolta. I progetti tecnici potranno non avere più variabili, ma sono sparsi lungo il progetto e non si sa mai se veramente si arriva al punto, finché non si è fatto (forse), in cui tutte queste variabili siano note. I progetti a cascata si basano sul fatto che le incognite saranno valutati e compensati andando avanti. Per vari motivi, i progetti tecnologici non sembrano funzionare in quel modo e così i progetti a cascata si rivela un modello povero.
Il problema principale con i progetti a cascata, tuttavia, è che si lavora mettendo alle persone sul palco dei ‘test’ allo stadio quasi finale. Non è progettato per supportare situazioni in cui i testing sono fatti dal primo giorno. Come risultato, i problemi, anche i problemi maggiori, non saranno identificati finché il progetto sarà praticamente completato.
L’agilità, d’altra parte, è tutto iterazione: lavoro per due settimane, produrre qualcosa di reale e farlo provare agli utenti, quindi ripetere o ripartire. Non ci sono presentazioni in Power Point o riunioni di team, solo qualcosa di cui le persone possono accedere e provarlo. Quello che si ottiene è la loro attenzione.
Mentre si lavora con metodologia agile (o leggera) usando Agile alliance, si consiglia di usare anche lo Scrum ch’è un framework che all’interno del quale è possibile utilizzare vari processi e tecniche. Non dovrebbero essere usate insieme, ma forse è una buona idea. Uno sa quello che piace alla gente? Loro pensano che le cose siano corte: inizia, accade e finisce. Questa è l’essenza dello Scrum: molto breve, non c’è tempo per arrivare comodi o per tirarsi indietro nelle riunioni del team del progetto in cui si parla di tacchino e si parla veloce. S’impedisce a chiunque di dimenticare il progetto e quello che sta facendo, e non occupa neanche una ridicola quantità di tempo dalla giornata.
E che cosa significa tutto questo per noi? Agile e Scrum consente una visibilità molto più ampia sul modo in cui si fa la stima complessiva del progetto. Con i test utente, in corso regolarmente, si ottiene il tracciato delle cose che potrebbero essere aggiunte all’applicazione e le cose che possono essere estratte o tolte. Se ci sono grossi problemi, è possibile iniziare la riprogettazione molto presto nel processo. Questo ci fa proattivi, che è un po’ come avere dei bei capelli, ma paga sempre dividendi e mette il progetto in una luce positiva.
I mali dello Scope Creep
Altri progetti sono condannati da scope creep -La sindrome di lavandaio o scope creep nella gestione dei progetti si riferisce a quei cambiamenti incontrollati nel l’ambito di un progetto. Questo fenomeno può verificarsi quando l’ambito di un progetto non è definito, documentato, o adeguatamente controllato.- più di ogni altra cosa. Lo scope creep provoca ritardi nei progetti, oltre il budget, e non riesce a rispondere alle aspettative soggettive del pubblico ospite. Quindi, non lasciare che accada. È come godere del tempo con i vostri suoceri, però, si sa che è più facile a dirsi che a farsi.
Nella sua forma più comune, lo scope creep si verifica quando qualcuno porta il progetto a un punto e fa l’introduzione con le parole “questo era il modo in cui abbiamo voluto fin dall’inizio”. E probabilmente sono onesti, possono avere davvero pensato che la funzione X stava per eseguire una funzione Y e che in realtà è stata la principale ragione per l’esistenza del progetto. E così, perché si suppone che l’applicazione parta, quando si aggiunge la funzione a volte l’impatto di questa modifica è irrilevante, ma la maggior parte delle volte non lo è. E questo può accadere non solo una volta nel ciclo di vita di un progetto, ma può succedere più e più volte. Quindi, che cosa fare?
In primo luogo, prima di qualsiasi altra cosa, bisogna essere diplomatici. Può venire voglia di saltare sul tavolo e afferrare la gola a qualcuno, ma è necessario mantenere la calma e mantenere l’equilibrio del potere dalla nostra parte. Tornare al nostro progetto iniziale e mostrare che la richiesta non è mai stata discussa, tanto meno identificata come parte integrante della domanda -lì dove sono le chiare e dettagliate dichiarazioni del progetto-.
In secondo luogo, per limitare il numero di volte che lo scope creep venga fuori, è necessario assicurarsi che gli utenti stiano facendo un buon lavoro nei loro test iterativi. Lo scope creep è più dannoso quando si verifica in seguito ad uno sviluppo dove ci sono un sacco di ammodernamentio aggiornamenti, più o meno visibile dall’utente. Nei test iterativi, piuttosto che parlare di come sta andando il progetto, è meglio mettere in condizione all’utente su cosa fa esattamente il sistema.
In definitiva, il problema è duplice. In primo luogo, può non essere stato dettagliato o abbastanza specifico in termini di ciò che l’applicazione farà e non farà: entrambe le parti devono essere precisate. In secondo luogo, è necessario tenere a mente che probabilmente gli utenti non sono pagati al 100% per l’attenzione quando si parla o quando leggono qualcosa che si è scritto -anche quando si è in una riunione con lo scopo specifico di martellare su ciò che l’applicazione dovrebbe fare-. Non aspettare che le cose che si ha esplicitamente scritto, la gente lo conosca come dovrebbe. Una buona tecnica è quella di definire un piano e poi potranno dire quello che pensano su quello che il sistema farà e cosa possono aspettarsi da esso. Registrare la sessione – si può utilizzare al processo.
Purtroppo, non esiste una cura per prevenire lo scope creep. Il meglio che si può fare è cercare di prevenirla, e quando alza la sua brutta testa, tentare di testarlo nel miglior modo possibile. Alla fine, c’è una buona probabilità che si sta andando bene e che fa ciò che l’utente vuole, che da soli non lo fanno, fanno solo un addendum al progetto. Specificare i passi necessari per farlo, il tempo che ci vorrà, l’impatto che avrà su tutto il resto, e quindi ottenere l’approvazione dal proprio bacino di utenza che vuole veramente questo fatto.
Attenzione alle Stranezze
Attenzione per le cose strane. Non vuole dire esigenze strane, ma le cose che possono essere nuove per la squadra o per l’ambiente. Ad esempio, se si crea un’applicazione che accetta i dati della carta di credito, siamo sicuri che si è realmente capito il PCI? -In elettronica e informatica la peripheral component interconnect (PCI), (interconnessione di componente periferica), è un’interfaccia a bus per collegare la CPU con le più svariate periferiche interne al computer attraverso la scheda madre.- O, forse si sta per passare da CodeIgniter a Lavarel, si potrebbe avere bisogno di un po’ più di tempo in più (anche al di là della curva normale)?. Tenerte d’occhio le cose che potrebbero inciampare.
Riassunto
La linea di fondo è questa: la gestione di un progetto è un gioco che non si può vincere. Se avete il budget, il tempo e se ognuno pensasse che siamo dei sandbagger -chi fa barricate con sacchi di sabbia- non crederanno più alle nostre stime di nuovo. Tenete gli occhi su ciò che è importante. Siate specifici, sarebbe bello, essere agili, e sperare per il meglio.
Similari
Fondamentali di jQuery
87% JQuery
[nextpage title=”Benvenuti”] jQuery stà diventando rapidamente uno strumento che ogni sviluppatore web di interfacce dovrebbe conoscere. Lo scopo di questo libro è di fornire una panoramica della biblioteca, in modo che qu…
Python per tutti
65% Python
[nextpage title=”Copertina”] Python para todos è un libro sulla programmazione in Python. Questo è un tutoriale su Python adatto a tutti i livelli e si può scaricare in pdf gratuitamente in spagnolo. Il tutoriale di Python…
Miti interessanti sul SEO
17% Seo
Come in diversi altri settori di questo mondo, il mondo SEO è composto da centinaia di miti che lo hanno reso piuttosto confuso. Quando i SEO erano partiti tutto era semplice e diretto. Le tecniche non erano complesse e no…
Modello di spazi dei nomi in JavaScript
11% JScript
In questo post, si discuteranno dei modelli intermedi, avanzati e gli approcci per il namespacing in JavaScript. Si comincia con l’ultimo come credo che molti dei lettori abbia qualche precedente esperienza in questo setto…
Guida allo Zend Framework
9% Zend
Zend Framework è un framework open source per PHP. Zend Framework separa la logica e le azioni usando il pattern MVC (Model View Controller). Cosa è lo Zend Framework? Framework per la costruzione di siti web più veloci e …