Gestire progetti con php

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.

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.

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 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.

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.