Alkampfer's Place

Il blog di Gian Maria Ricci
posts - 659, comments - 871, trackbacks - 80

My Links

News

Gian Maria Ricci Mvp Logo CCSVI in Multiple Sclerosis

English Blog

Tag Cloud

Article Categories

Archives

Post Categories

Image Galleries

I miei siti

Siti utili

Requisiti e processo

Stamane nel mio TweetDeck appare questo tweet di RobyMes

image

Più passano gli anni, più sono sempre più convinto che spesso l’errore comune di chi sviluppa è mettere troppa enfasi sulle tecnologie, o su aspetti tecnici, che, sebbene abbiano la loro importanza, non sono sicuramente determinanti alla fine della riuscita di un buon progetto. Per questo concordo al 100% con Roberto.

Come sempre riporto due delle frasi che più amo nel Mytical Man Month

I believe the hard part of building software to be the specification, design, and testing of conceptual construct, not the labor of representing it and testing the fidelity of the representation.

The hardest single part of building a software system is deciding precisely what to build

Per non citare poi i report dello Standish Group che evidenziano come i maggiori problemi nei progetti software siano da ricondursi ad una errata o assente gestione dei requisiti.

Gian Maria.

Print | posted on giovedì 18 agosto 2011 15:51 |

Feedback

Gravatar

# re: Requisiti e processo

Stesso identico problema qui. I devs creano work items e features legate a come adottare un tool diverso nel progetto in corso al posto di focalizzarsi sui requirements e i bugs
Ma la colpa e' sempre legata al fatto che manca un PM che mantenga dritta la rotta.
18/08/2011 21:01 | raffaeu
Gravatar

# re: Requisiti e processo

Sicuro, affidiamoci ai PM: con la frusta si risolvono tutti i problemi, persino quelli concettuali.

-LV
19/08/2011 02:24 | LudovicoVan
Gravatar

# re: Requisiti e processo

Il problema vero è che i PM, in quanto Project Manager, dovrebbero gestire il progetto, non fare gli analisti con il cliente, e lo schiavista con la frusta dalla parte del team.

Un buon PM dovrebbe essere in grado di gestire al meglio le risorse che ha (Tempo, Team di sviluppo, qualità, etc) per soddisfare i requisiti del cliente. Troppo spesso non è però cosi. :(
19/08/2011 20:13 | alkampfer@nablasoft.com
Gravatar

# re: Requisiti e processo

> Un buon PM dovrebbe essere in grado di gestire al meglio le risorse che ha [...] per soddisfare i requisiti del cliente.

Avevi appena detto, giustamente, che un PM non deve fare l'analista. Project management non ha niente a che fare con i requisiti, e' una funzione cosiddeta' ausiliaria, cioe' trasversale ai progetti, il cui obiettivo e' massiizzare l'efficacia nell'uso delle risorse di processo/aziendali.

L'officina la dovrebbe condurre il capo officina, detto direttore di produzione in una qualunque azienda appunto di produzione. E non puo' che essere uno che, oltre a saper condurre uomini, sa anche come le sue tasche cosa significa e come si fa a produrre software.

-LV
20/08/2011 04:36 | LudovicoVan
Gravatar

# re: Requisiti e processo

No, in SCRUM ci vuole lo ScrumMaster, in Agile generale ci vuole il PM.
Certo, il suo ruolo non e' quello di avere il frustino e di fare l' analista o l' architetto. Il suo ruolo e' quello di gestire i progetti, ed a mio modico parere, non deve avere conoscenze informatiche. Per un buon PM non sono necessarie.
Io, nella ditta corrente, non ho un PM ma un CTO che vuol fare tutto lui, ed in fatti i risultati si vedono (fallimentari ...)
Prima avevo un PM e tutto filava liscio come l' olio.
21/08/2011 23:38 | raffaeu
Gravatar

# re: Requisiti e processo

> No, in SCRUM ci vuole lo ScrumMaster, in Agile generale ci vuole il PM.

Non potrei essere meno d'accordo. Fra l'altro agilita' e' ortogonale ai modelli di processo.

-LV
22/08/2011 00:13 | LudovicoVan
Gravatar

# re: Requisiti e processo

Commento dopo molto tempo sorry @raffaeu.

Le persone in Italia sono ostili al PM a mio avviso perchè lo identificano nella persona che dice "tra un mese l'analista ti dara le specifiche, e secondo questo gantt tra 5 mesi facciamo il deploy al cliente. Period!". Ovvero la persona che vende fumo/da date irrealistiche/inserisce feature dannose/inserisce feature inutili, etc etc

Nella realtà la figura del PM è importante, ma deve fare il suo lavoro, ovvero gestire il progetto, non imporre, valutare i rischi, capire come gestire l'ALM etc.

Ti faccio un esempio, se io tra 2 mesi ho una fiera, e quindi ho una data che è inamovibile, il PM dovrebbe essere in grado di gestire il tutto per far si che a data della fiera io abbia un demo funzionante, stabile e che sia in grado di dare competitive advantage rispetto ai concorrenti. Quando il pm 2 gg prima dice che avendo visto l'interfaccia di un concorrente dobbiamo anche noi inserire XYZ allora qualche cosa non va.

Confrontandomi con gli altri, anche questo fine settimana al csddd, viene sempre fuori che spesso i PM portano solamente problemi nel progetto, invece di risolverli.

Per il resto sono daccordo con te, ci vuole "un bel PM", ma se non è "bel" poi sono dolori ;)
06/09/2011 13:39 | alkampfer@nablasoft.com
Comments have been closed on this topic.

Powered by:
Powered By Subtext Powered By ASP.NET