Uno sviluppatore dovrebbe accettare una stima del carico di lavoro effettuata da una macro di Excel?

12

In un nuovo progetto, un amico doveva scrivere dei test in cui il tempo necessario per scriverli era calcolato da una macro di Excel scritta dal suo manager non sviluppatore.

In tali circostanze, uno sviluppatore dovrebbe assumersi la responsabilità di scrivere ed eseguire i test nel tempo calcolato? I risultati di questi test sono affidabili?

Per informazione, il mio amico ha rifiutato di essere responsabile per le stime che non ha fatto, ha chiesto di riuscire a lavorare su un altro progetto e sono stati sostituiti da un sì-ragazzo fuori dalla scuola inesperto.

project-management productivity testing

— Nelstaar
fonte

7

Cosa significa "accettare" una "stima"? Se stimate, ci vorranno 30 giorni per fare qualcosa, cosa succede se "accetto"? Cosa me ne importa di quanto tempo mi ci vorrà per fare qualcosa? È possibile stimare lo faccio in un minuto per tutte le cure che, si sarà sbagliato, non io.

— David Schwartz,

2

@David Accettare una stima si riferisce generalmente alla revisione delle stime e alla garanzia del consenso. Ad esempio, se viene utilizzato uno strumento di stima parametrica, facendo in modo che gli ingegneri del progetto riesaminino tali dati per garantire coerenza, magari utilizzando una seconda metodologia come Wideband Delphi.

— Thomas Owens

12

Sembra qualcosa che dovrebbe essere inviato a Scott Adams per un cartone animato Dilbert.

— MetalMikester

1

Finché c'è una recensione. In questo esempio particolare non ce n'erano.

— Nelstaar,

5

Ricorda: una stima, un impegno, un obiettivo e un piano per raggiungere un obiettivo sono quattro cose diverse. Assicurati che tutti siano chiari su quali siano queste cose e su quale di queste quattro cose sia l'output di Excel.

— nlawalker,

14

Dipende da quanto siano sensibili allo sviluppatore e da quali dati / logica si basano. ( potrebbero essere basati su dati statistici raccolti nel corso di diversi anni su quanto tempo è stato richiesto - da questo stesso sviluppatore e / o da altri - per risolvere compiti simili in passato ... o potrebbero essere interamente basati su quelli del suo manager - corretto o errato - ipotesi.)

Idealmente, dovrebbe discutere con il suo manager che non ci si può ragionevolmente aspettare di impegnarsi e assumersi la responsabilità per un compito stimato da qualcun altro.

Rifiutare chiaramente di impegnarsi nelle stime può effettivamente comportare una sua rapida sostituzione, quindi è meglio avere un approccio più morbido ed evitare il confronto diretto, se possibile.

— Péter Török
fonte

7

Presumibilmente la macro funziona su una sorta di dati di input, non è solo un generatore di numeri casuali? Quindi, per rispondere alla tua domanda, dobbiamo sapere quali sono i dati di input e cosa fa la macro. Senza questo, ogni risposta è piuttosto insignificante.

Oppure, la tua domanda è davvero sull'accettazione delle stime prodotte da un manager a cui manca l'esperienza pertinente? In questo caso la risposta è no, tu (o il tuo amico) dovreste produrre le proprie stime e inviarle al gestore. Se le 2 cifre non corrispondono, devono lavorare insieme per trovare il modo migliore di procedere, magari accettando di scrivere meno test o impiegando più tempo a scriverli tutti.

Il rifiuto del punto in bianco non aiuterà nessuno, e nemmeno lavorare a una scala temporale che non puoi rispettare non è divertente, la soluzione sta nel prendere un approccio professionale e giungere a un compromesso che consenta al lavoro di procedere.

— Steve
fonte

I test sono suddivisi in sotto-parti (quasi atomiche) e si ottiene una piccola stima.

— Nelstaar,

Penso che usando questo metodo il tester finale non veda / testi il quadro generale.

— Nelstaar,

1

"Presumibilmente la macro funziona su una sorta di dati di input, non è solo un generatore di numeri casuali" Potrebbe anche essere casuale perché il loro non è un modo per catturare OGNI variabile che renderebbe accurato un tale algoritmo.

— maple_shaft

1

@maple_shaft: ecco perché lo chiamano un preventivo - non è (o non dovrebbe essere) previsto che sia accurato. Che tu stia stimando utilizzando alcuni calcoli in Excel o con carta e matita, non fa alcuna differenza. L'uso di Excel per le stime ha molto più senso di alcune altre "tecniche" che ho visto in uso ...

— Treb

Le stime di @Treb dovrebbero essere accurate quanto i dati forniti e lo stato attuale del progetto lo consentono, dato il Cono di incertezza.

— Thomas Owens

5

Sicuramente NO.

Un programma di piccole dimensioni, anche un programma di grandi dimensioni e complicato, non può stimare quanto tempo impiegherà un lavoro di programmazione. Vedi Limiti matematici alla stima del software per i motivi. È disponibile anche un documento più lungo, sottoposto a revisione paritaria, grandi limiti alla stima del software .

Vorrei anche riconsiderare la mia opinione del gestore in questione: perché crede che una macro di foglio di calcolo non sia stata provata in passato, dato che tutto il resto è stato provato a stimare la durata dell'attività del software in passato.

— Bruce Ediger
fonte

1

Non ho ancora letto per intero questi articoli, ma i metodi parametrici sono stati ampiamente utilizzati per stimare i progetti software entro il 15% per oltre 20 anni, supponendo che i dati di input siano validi. Inoltre, metodi collaborativi come Wideband Delphi possono (e sono stati utilizzati) per confermare l'accuratezza dei modelli parametrici. Vedi Software Engineering Economics (Boehm) per una discussione sui metodi parametrici e l'applicazione di Wideband Delphi su progetti software (sia con che senza modelli paremetric).

— Thomas Owens

Sono d'accordo con Thomas. Sebbene non sia possibile prevedere con precisione ogni singola attività per un intero progetto, nel corso di un progetto e utilizzando i dati storici per un'organizzazione specifica è possibile accedere al ballpark. Alcune attività richiederanno più tempo e altre più brevi, ma alla fine avranno una media. Soprattutto se il progetto è simile a quelli già realizzati dall'organizzazione. Detto questo, le stime non possono tenere conto di cose davvero inaspettate, come l'hardware / software non funziona come pubblicizzato, le nuove tecnologie sono molto più difficili del previsto, carenze di sviluppatori, scarsa leadership e gestione.

— Dunk,

1

Dovete leggere e comprendere il documento. Una semplice macro di foglio di calcolo non ha la possibilità di stimare correttamente. Il software è matematica e talvolta i sistemi matematici sono soggetti a un piccolo problema noto come incompletezza. Ti garantisco che il manager in questione si sta prendendo in giro da solo e che i risultati della macro non sono correlati alla realtà.

— Bruce Ediger,

1

@Bruce: avendo usato le formule (compresi i fogli di calcolo Excel) per la stima del progetto con successo, posso sicuramente affermare che né Thomas, il Manager né io stessi ci stiamo necessariamente prendendo in giro. Come ho affermato, ogni singolo compito varierà, ma nel corso di un progetto tendono a pareggiare. Ho scoperto che l'utilizzo della formula (sviluppata e modificata nel tempo) è stato molto più accurato delle stime dei singoli sviluppatori. In generale, gli sviluppatori sono eccessivamente ottimisti o eccessivamente pessimisti. Naturalmente, le formule funzionano solo quando vengono dati dati ragionevoli, l'abilità è sicuramente un fattore.

— Dunk

Ho letto quei giornali ieri sera. Sono contrari a oltre 40 anni di prove nella gestione dei progetti e oltre 30 anni di prove nella gestione dei progetti software. Vedi iiasa.ac.at/Admin/PUB/Documents/RM-75-071.pdf e sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html

— Thomas Owens

4

Ugh!

Questo è un "odore di lavoro" gigantesco. Questa è un'incredibile micro-gestione.

Se non possono fidarsi dei loro dipendenti per fornire un preventivo, cos'altro non si fidano di te?

— OZZ
fonte

1

Il 99% degli sviluppatori non può nemmeno elaborare stime errate basate su qualcosa di oggettivo e tanto meno stime accurate. Quindi non vedo nulla che indichi "odore di lavoro" perché qualcun altro ha elaborato un preventivo. Soprattutto se hanno usato dati reali per giustificare il loro numero. Se le persone sono ritenute responsabili di soddisfare il preventivo di ogni attività, allora si tratta di un problema di odore di lavoro. Tuttavia, se lo strumento sottovalutasse ampiamente tutte le attività, a tutti gli sviluppatori mancherebbero le stime. OTOH, se tutti gli altri sembrano soddisfare la maggior parte di tutte le stime e un altro sviluppatore non lo fa mai, questo è un problema di odore dello sviluppatore.

— Dunk,

@Dunk - il mio punto è, la micro gestione fino a questo punto nello sviluppo di software è un "odore di lavoro" e non vorrei lavorare lì.

— ozz,

1

quello che chiami microgestione è l'unico modo per fare affari in molti settori. Se non riesci a elaborare stime ragionevoli di costi e programmi per grandi progetti, la tua azienda avrà un lavoro molto difficile per ottenere contratti. Contrariamente all'ideale agile, i clienti in molti settori non si impegneranno in contratti di decine di milioni di dollari se non sanno cosa otterranno alla fine. Non sarebbero contenti dell'idea che i loro soldi se ne siano andati, hanno un prodotto funzionante, ma fa solo il 50% di ciò di cui hanno bisogno o desiderato.

— Dunk,

@ Dunker - Se sei soddisfatto della gestione che ha prodotto stime per te, vai avanti. Preferirei che il team di sviluppo producesse stime. Stime di gestione ridicole (insieme a richieste in costante evoluzione, un'intera altra discussione) sono il motivo per cui molti progetti software non riescono a consegnare in tempo e nel budget programmato. Preferirei fidarmi delle persone che svolgono il lavoro.

— ozz,

Non è una questione di gestione fare stime o le persone che fanno il lavoro elaborando le stime. Si tratta di estrarre le stime dal culo o di tentare di basare le stime su alcuni dati oggettivi. È stata la mia esperienza che nel confrontare le stime di gestione con le stime degli sviluppatori scopriresti che le stime di gestione tendono a tradursi in tempi più lunghi per il completamento. Gli sviluppatori tendono ad essere ottimisti .....

— Dunk,

3

Assolutamente no.

Ti prometto che il manager non è così illuso da pensare che la sua macro di Excel sia in grado di prevedere con precisione le stime. Non sto nemmeno discutendo di ciò che dovrebbe essere un fatto ben noto che ci sono troppe variabili coinvolte per prevedere con precisione qualcosa di simile in un algoritmo. Se ha inventato un tale algoritmo, dovrebbe brevettarlo e fare milioni secondo me.

Quello che sta realmente accadendo qui è che il manager sta usando questa presunta macro di Excel come un travestimento leggermente velato per nascondere il fatto che sta forzando aspettative non realistiche e una pressione indebita sui suoi sviluppatori.

Sa che è BS e non gliene importa, è una scusa per prenotare in eccesso le risorse e provare a fare le cose più velocemente rendendo tutti i suoi "inutili" sviluppatori "LATE".

Questo manager sembra un cretino sfruttatore.

— albero_acero
fonte

1

Eh, solo perché il gestore sta generando stime per gli sviluppatori non significa che siano imprecise e non possiamo davvero trarre tale conclusione senza ulteriori informazioni. Se il manager è competente, dovrebbe riconoscere le cose in modo realistico e non irrealistico, adattando abbastanza facilmente le cose di conseguenza.

— rjzii,

1

@Rob, stai dimenticando il punto chiave che l'OP ha fatto, che sono stati tenuti a queste stime (presupposto rigorosamente perché il precedente sviluppatore del team menzionato "non voleva essere tenuto alle stime" ed è stato riassegnato). Non c'è nulla di sbagliato nei modelli di stima, ma dovrebbero essere una linea guida approssimativa e nulla a cui "aggrappare gli sviluppatori", che purtroppo ho visto il management fare a MOLTE persone.

— maple_shaft

2

Qui il problema era che queste stime si spostavano direttamente nella fattura del cliente. Perché alcuni manager continuano a chiamarlo stime?

— Nelstaar,

@maple_shaft - Senza sapere quali sono le stime, è difficile dire se fossero irragionevoli e quindi valide le obiezioni da sostenere. Se fossero stime oneste (ad es. "Otto ore per scrivere Hello World"), non vi sarebbe alcun problema a trattenerle al di là della filosofia.

— rjzii,

3

In un nuovo progetto, un amico doveva scrivere dei test in cui il tempo necessario per scriverli era calcolato da una macro di Excel scritta dal suo manager non sviluppatore.

Esistono modelli di stima parametrica per stimare i tempi di completamento dei progetti, inclusi i progetti software. Di solito, la stima si riferisce al codice di produzione, ma non vedo perché non possa essere estrapolato per stimare il tempo necessario per scrivere il codice di prova. Queste stime sono valide solo quanto i dati che vengono inseriti in esse, tuttavia.

Supponendo che il metodo utilizzato sia un modello di stima valido e che i dati siano accurati e validi, non c'è motivo per cui una buona stima non possa provenire da una macro Excel scritta da un gestore non sviluppatore.

In tali circostanze, uno sviluppatore dovrebbe assumersi la responsabilità di scrivere ed eseguire i test nel tempo calcolato?

Nessuna stima dovrebbe mai essere accettata alla cieca, in nessun caso. Nessuna stima è mai perfetta, indipendentemente da come viene generata. Spetta all'ingegnere rivedere eventuali stime, identificare potenziali problemi, valutarne l'impatto, discutere e perfezionare la stima secondo necessità.

I risultati di questi test sono affidabili?

I test sono validi tanto quanto lo sforzo impiegato nella progettazione e attuazione. Se un tester esegue test di bassa qualità, i difetti passeranno attraverso i test e passeranno a una fase successiva del progetto. È ovvio che la pressione programmata porterà a test di bassa qualità, quindi se il tempo è insufficiente per progettare i casi di test appropriati e quindi implementare tali casi, i test non sarebbero altrettanto utili.

— Thomas Owens
fonte

3

Sembra che tu stia facendo due domande diverse:

I risultati di questi test sono affidabili?

Excel è uno strumento come qualsiasi altro con cui lavoriamo e ciò in cui sono stati scritti i calcoli non dovrebbe davvero avere un impatto sui risultati dell'algoritmo stesso. Il fatto che la stima provenga da una macro di Excel non è rilevante per la validità dei risultati del calcolo (vale a dire la validità della stima). Se si hanno ipotesi errate nel modello sottostante, non importa cosa si utilizza per fare il calcolo poiché le ipotesi sottostanti sono errate.

In tali circostanze, uno sviluppatore dovrebbe assumersi la responsabilità di scrivere ed eseguire i test nel tempo calcolato?

Se il requisito per cui lo sviluppatore fa il lavoro nel tempo indicato è nel suo contatto, allora non c'è molto che possano fare per discuterne fintanto che le stime sono ragionevoli. Il che porta al punto successivo: se i calcoli stanno dando un ragionevole lasso di tempo e sono simili alle stime che lo sviluppatore si darebbe, allora non c'è motivo di non opporsi alle scadenze indicate. In effetti, potrebbe funzionare a vantaggio degli sviluppatori in quanto potrebbero essere in grado di influenzare le assunzioni utilizzate nel modulo al contrario se ricevessero una sequenza temporale arbitraria.

Se le tempistiche sembrano impossibili per la quantità di lavoro richiesto, allora ovviamente dovrebbero sollevare questa preoccupazione e provare a lavorare con il manager per ottenere tempistiche più realistiche, ma se le tempistiche sono fattibili, avranno difficoltà a obiettare contro di loro.

In termini di gestione del progetto e tempistiche di stima, sì, può essere fatto ma dipende fortemente dalla natura del lavoro svolto. Probabilmente vedrai stime più precise fornite per il tempo richiesto per scrivere il codice di test unitario (supponendo che lo sviluppatore capisca il framework e li abbia scritti in precedenza) di quanto lo farai per scrivere un nuovo codice rispetto ai casi d'uso in cui il codice di test è stato scritto per.

— rjzii
fonte

Sono d'accordo che questo metodo può / potrebbe essere utilizzato fintanto che esiste un dialogo tra gli attori del progetto.

— Nelstaar,

1

@Nelstaar - Praticamente tutto ciò che ho letto sulla gestione e sulla stima dei progetti implica un dialogo continuo e la messa a punto delle cose col passare del tempo. Di solito le stime più affidabili hanno una probabilità associata ad esse per quanto riguarda le probabilità di colpire l'obiettivo indicato (cioè il 90% di probabilità che l'attività richieda 8 ore).

— rjzii,

2

Non voglio minimizzare i test di scrittura, ma probabilmente il progetto ha già fatto scrivere a molti sviluppatori. Se le stime si basano su questi dati, potrebbero essere più precisi di quanto ipotizzato dal tuo amico. Poiché il tuo amico ha lasciato il progetto, non ha fatto alcun tentativo di creare stime opposte o vedere se potevano essere completate come previsto, non lo sapremo mai.

Tutto quello che doveva fare era completare uno o due test per vedere quanto fosse accurata la stima e tornare al manager con una discussione legittima. Potrebbero esserci altri membri del team che potrebbero aver fornito un feedback sull'affidabilità delle stime o sulle conseguenze del rimanere indietro. A volte un manager deve dare "qualcosa" al suo capo per rendere tutti felici. Gli sviluppatori vedono questo come un falso senso di sicurezza. Forse se ci fosse un movimento per gli sviluppatori di fornire stime e mostrare la volontà di fare le cose, il management potrebbe sviluppare più fiducia.

Immagino che, se fosse in grado di completare i test in meno tempo, non direbbe nulla al riguardo. Inoltre, scusandosi da una pratica in cui non crede, può indicare un alto livello di integrità.

— Jeffo
fonte

+1 per fornire feedback durante l'esecuzione delle attività relative alle stime.

— rjzii,

1

Risposta semplice e breve:

Non ti interessa da dove viene la stima.

Quello che ti interessa davvero è la stima stessa. Concordi con esso o non sei d' accordo e spiega perché e quanto vorresti stimare. Questo è il più importante.

— Clemente Herreman
fonte

1

Dovresti preoccuparti della provenienza del preventivo. Un modello parametrico con input validi e ragionevoli, un generatore di numeri casuali, uno studente di informatica del primo anno, un ingegnere del software con 5 anni di esperienza con meno di 6 mesi nel dominio e un ingegnere del software trasformato project manager con 25 anni di esperienza nel dominio tutti hanno una diversa capacità di produrre una stima efficace. Ciò ritorna anche a un commento che ho fatto su una precedente risposta sulla responsabilità etica / professionale di un ingegnere del software di rappresentare, difendere e contestare le stime in modo appropriato.

— Thomas Owens

Esatto: il più importante è discutere la stima. Approverei volentieri l'uso delle macro di Excel se le stime fatte fossero più spesso corrette di un ingegnere di 25 anni di esperienza. Ciò che è importante è la stima e la spiegazione che lo portano (carico di lavoro, risorse disponibili, difficoltà), non da chi o cosa è stato annunciato.

— Clemente Herreman,

Sei d'accordo con me dicendo che la tua risposta è sbagliata? Dati gli stessi input (come carico di lavoro, risorse, difficoltà, ecc.), Chi è importante quanto il cosa e perché. Si riduce a un fattore di fiducia. Mi fido di COCOMO (creato e gestito da alcune menti leader nella stima dei costi del software) più di una macro di Excel (realizzata da qualcuno con esperienza e conoscenza limitate nella stima dei costi, tanto meno il dominio dell'applicazione). Tutto dipende dal quadro generale per stabilire quanto sia affidabile questa stima.

— Thomas Owens

No no, immagino di non essere abbastanza chiaro. Non è davvero importante chi ha fatto la stima. Ciò che è importante è l'accuratezza della stima. Ogni volta che ottengo una stima, la confronto con quella che farei, quindi la discuto con il mio project manager se sono d'accordo o no. Se il loro argomento è abbastanza buono, allora sono d'accordo con loro e accetto la stima. Vedere? Non ho mai parlato né pensato a chi avesse stimato.

— Clemente Herreman,

Come si determina l'accuratezza se non si conosce chi ha stimato e quali metodi hanno usato? Potrei fornire gli stessi dati a due persone: uno è uno studente di ingegneria del software del primo anno che sta frequentando il suo primo corso di informatica e l'altro è un ingegnere del software senior con 15 anni di esperienza e 5 nel dominio. Entrambi usano gli stessi metodi di stima (non dimenticare: spesso anche gli input sono stime). Lo studente può dire che ci vorranno 6 mesi con una sicurezza del 95%. L'ingegnere senior può dire che ci vorranno 15 mesi con l'80% di fiducia. Mi fiderei di più dell'ingegnere senior.

— Thomas Owens

1

In teoria, uno sviluppatore non dovrebbe mai accettare una stima fatta da qualsiasi altra persona, non importa come sia stata raggiunta. Uno dei motivi è che dare una stima più lunga di quella a cui il proprio manager si sente a proprio agio espone immediatamente un potenziale problema di pianificazione o forse un malinteso sulla portata del lavoro da svolgere.

Le persone generalmente trovano la stima del tempo di programmazione ancora più difficile della programmazione stessa, quindi se il tuo manager può scrivere una macro di Excel in grado di risolvere quel problema, probabilmente può costruire una macro per scrivere il codice (improbabile).

Ora, in pratica , se capisci il lavoro e le stime sembrano ragionevoli, ha senso semplicemente esprimere un po 'di preoccupazione sulla metodologia di passaggio ma poi acconsenti provvisoriamente a vedere se riesci a soddisfarle. Più tardi, se il lavoro ti sta portando più tempo rispetto alle stime, dovresti portarlo all'attenzione dei tuoi manager il prima possibile. Preparati a discutere i motivi esatti in base alla tua effettiva esperienza di implementazione. Spero che a quel punto il tuo manager non sia irragionevole e continui a insistere sul fatto che lavori su stime generate meccanicamente.

— PeterAllenWebb
fonte

-1

Una delle più recenti metodologie di sviluppo software è agile e uno dei framework agili noti è la mischia . Ma in questa metodologia, gli sviluppatori (scrum team) sono responsabili del calcolo del tempo richiesto per svolgere un'attività o implementare una user story.

Dico sicuramente NO . Perché:

Un gestore non sviluppatore non può stimare il tempo richiesto per svolgere un lavoro
Stimare il tempo richiesto per fare qualsiasi lavoro richiede un po 'di intelligenza umana, che Excel non ha
Accettando tali pratiche di lavoro, il manager si abitua progressivamente a sostituire gli sviluppatori nei tempi di stima. Ciò può provocare catastrofe. Considera questo scenario in cui il tuo manager dice:

Voglio iniziare un nuovo progetto per la vendita di biciclette online e so che ci vogliono 3 settimane per realizzarlo.

— Saeed Neamati
fonte

5

L'OP non ha menzionato la squadra del suo amico usando metodi agili. Non penso che le regole agili abbiano rilevanza per i team che usano altri metodi (o nessun metodo). Il buon senso dovrebbe, tuttavia :-) Inoltre, è ovvio che non è stato Excel a decidere delle stime, ha eseguito solo alcuni calcoli basati su alcuni presupposti e dati (a noi sconosciuti) (ognuno dei quali può essere corretto o errato) . Se inserisco le stime per una determinata attività da ciascuno dei membri del nostro team, quindi imposto Excel per calcolare la media di questi, Excel sta effettuando la stima?

— Péter Török,

3

1 e 2 sono palesemente falsi. I modelli di stima parametrica sono ampiamente accettati nella gestione di progetti software e sono stati per oltre 20 anni e chiunque abbia una formazione di gestione dei progetti (ingegnere del software o meno) può essere addestrato per utilizzare questi strumenti, supponendo che essi (o, preferibilmente, gli ingegneri del progetto ) sono in grado di fornire stime accurate degli input.

— Thomas Owens

3

-1 - Questo non risponde alla domanda, presenta errori evidenti ("... le più recenti metodologie di sviluppo software sono agili") e non sembra aggiungere nulla di rilevante. Non sono sicuro a cosa servissero i voti positivi o la risposta accettata.

— Morgan Herlocker,

1

certamente non sappiamo dalla domanda se la stima parametrica sia la norma in questa società e / o se sia basata su una buona storia per il loro business; se questo è il caso di quanto odio dirlo, il rifiuto di fare il proprio lavoro secondo le procedure operative accettate dall'organizzazione (senza seguire un ragionevole percorso di interrogatorio) è imprudente.

— StevenV

2

Thomas, sono d'accordo, penso solo che ci sia troppo che non sappiamo sulla situazione per rispondere categoricamente Sì o No. In ogni caso, il rifiuto totale senza una buona discussione per assicurarsi che la situazione e il ragionamento siano capiti raramente è un buona mossa di carriera.

— StevenV,