<< Comunicazione & dialogo | Home | Due definizioni equivalenti di buon disegno >>

Situazioni da team: disaccordo sulla architettura

Per lo sviluppo di una funzionalità gli altri membri del team concordano su una soluzione architetturale che detesti, cosa fai ?

 Update 17/06/2008: idee dai commenti

  • cercherei di capire perchè il team stia facendo quella scelta e perchè la trovino più adatta a quella che farei io

  • Dopodiche calcolo a spanne il guadagno che la mia soluzione avrebbe rispetto a quella proposta e valuto di conseguenza se vale la pena portare altri argomenti alla discussione o se non convenga lasciare perdere

  • mettere in piedi un esempio cercando di dimostrare che la mia soluzione abbia più possibilità di sopravvivere alle evoluzioni. il tutto valutando costi e benefici

  • Ognuno di noi pone pro/cons della propria soluzione e alla fine si valuta per bene

 

Tags :   |  |  |  |  |  |

Print | posted @ lunedì 16 giugno 2008 23.57

Comments on this entry:

Gravatar # re: Situazioni da team: disaccordo sulla architettura
by Mauro Servienti at 17/06/2008 6.00
Ciao Luka,

se sono convinto delle mie idee cerco di mettere in piedi un esempio che "smonti", nel senso buono del termine, le teorie altrui cercando di dimostrare che la mia soluzione abbia più possibilità di sopravvivere alle evoluzioni. il tutto valutando costi e benefici.... che male non fa.

... comunque in tutti i casi cerco di intavolare una discussione.

.m
  
Gravatar # re: Situazioni da team: disaccordo sulla architettura
by Alessandro at 17/06/2008 8.42
Fondamentalmente sarei d'accordo con Mauro.
Dove mi trovo adesso però, la parte architetturale e delle evoluzioni future ha peso veramente scarso... Molto più importante è la parte dei costi, anzi direi che è l'unica che conta.
Ecco perchè mi trovo a "predicare" nel deserto. Sono l'unico che conosce .NET, mentre tutti gli altri sono rimasti ad ASP classico e VB6. E' chiaro però che proporre una qualsiasi soluzione che usi le nuove tecnologie abbia un costo molto elevato dato che va fatta da nuovo, mentre una qualsiasi pezza al software esistente è molto più economica. Motivazioni tecniche, motivazioni archietturali, non sembrano aver nessuna importanza. Anche far capire che l'investimento fatto adesso porterà sicuramente ad una produttività più elevata nel medio-lungo termine, non ha importanza perchè l'unica cosa che viene vista è che il costo X immediato è superiore al costo Y delle pezze.
Alla luce di tutto questo inizio a pensare che o sono io ad avere idee sbagliate sullo sviluppo del software oppure ho sbagliato posto...
  
Gravatar # re: Situazioni da team: disaccordo sulla architettura
by Tommaso Caldarola at 17/06/2008 9.14
Nel mio team nulla si impone o si accetta come ordine. Ognuno di noi pone pro/cons della propria soluzione e alla fine si valuta per bene.
  
Gravatar # re: Situazioni da team: disaccordo sulla architettura
by Alessandro Scardova at 17/06/2008 10.20
Non ci sono soluzoni architetturali "detestabili" ce ne sono alcune adatte o meno alla situazione che si sta affrontando, quindi cercherei di capire i motivi addotti dagli gli altri membri del team, augurandomi che non siano l'equivalente opposto di detestabile, ma che siano legati a problematiche che mi siano sfuggite. Dopodiche calcolo a spanne il guadagno che la mia soluzione avrebbe rispetto a quella proposta e valuto di conseguenza se vale la pena portare altri argomenti alla discussione o se non convenga lasciare perdere. A volte tirare i remi in barca aiuta a non affondare.
  
Gravatar # re: Situazioni da team: disaccordo sulla architettura
by Antonio Ganci at 17/06/2008 16.55
Cambio team :-)
A parte gli scherzi per prima cosa cercherei di capire perchè il team stia facendo quella scelta e perchè la trovino più adatta a quella che farei io.
Se non sono d'accordo sulla motivazione ma non riesco a fornire elementi sufficienti a convincerli mi metto l'anima in pace e accetto la decisione.
  
Gravatar # re: Situazioni da team: disaccordo sulla architettura
by Luca Minudel at 17/06/2008 19.41
@Alessandro

una possibilità che hai è quella di aspettare una piccola feature per la quale usare la nuova tecnologia da un vantaggio grosso ed evidente.
a feature finita e risparmio avvenuto avrai un bonus di credibilità per riproporre la nuova tecnologia per la prox feature a cui sarebbe utile.

di successo in successo potresti pian piano procedere nella direzione che desideri. sempre se vale la pena aspettare e pazientare, e questo lo sai solo tu


  
Gravatar # re: Situazioni da team: disaccordo sulla architettura
by Alessandro Sorcinelli at 18/06/2008 15.20
@Luca
E' esattamente quello che sto facendo. Su ogni nuovo progetto o su ogni feature nuova in cui intravedo dei benefici, propongo la nuova tecnologia ed effettivamente sono tutti contenti del risultato finale.
Ma nulla sembra cambiare... Staremo un po' a vedere...
  

Your comment:

Title:
Name:
Email:
Website:
 
Italic Underline Blockquote Hyperlink
 
 
Please add 5 and 6 and type the answer here: