Cosa fare se il capo posticipa sempre le principali decisioni in merito ai requisiti e alla progettazione generale?

Quando inizia un nuovo progetto, il mio capo evita sempre di prendere decisioni fisse. Di solito dice: ok, inizia a scrivere qualcosa e sii il più generico possibile. Quando hai finito guardiamo come continuiamo. Il suo argomento è fondamentalmente che non si conosce e "sviluppo agile".

Per mantenere la domanda il più generica possibile: cosa fai se al tuo capo non piace prendere decisioni?

Basta attenersi ad esso e scrivere codice che potrebbe subire un pesante refactoring e una riscrittura parziale poche settimane dopo? O continuare a discutere fino a quando il capo non prende almeno alcune decisioni? Questa è più o meno la mia strategia attuale. Perché è come una legge della fisica, a un certo punto qualcosa deve essere consegnato. O perché il capo del capo vuole vedere i risultati o perché le cose stanno diventando ridicole ad un certo punto.

Osservo anche che il mio capo critica quasi tutto. Anche i suggerimenti che si basano sul suo ...

Costruisci prototipi

Inizia a disegnare schermate che all'inizio non fanno nulla (presumibilmente hai abbastanza per farlo?)

Dovresti essere in grado di renderlo parzialmente funzionante lentamente e alla fine refactoring del codice errato quando diventa più chiaro cosa stai cercando di fare.

È un problema comune che non sanno cosa vogliono fino a quando non vedono qualcosa e si rendono conto che non è quello che vogliono. Ho scoperto che quando qualcuno vuole che tu inizi a costruire "un framework" o qualcosa di "generico" come quello che ti sta dicendo, ti metterai nei guai solo se ci provi. I framework sono già scritti, non è necessario farlo.

Ci sono diversi problemi che ho raccolto dal tuo messaggio: 0-Non è il tuo compito gestire il progetto e non è il tuo compito raccogliere i requisiti dell'utente finale. 1-Il capo non conosce i requisiti esatti 2-Il capo non parla con gli utenti finali dei requisiti 3-Il capo sta gettando una terminologia che non capisce davvero agile 4-Stai elaborando una soluzione che viene ri scritto più volte e non ne sei contento

Per quanto riguarda 1,2 e 3 c'è poco da fare al riguardo se non sei una persona anziana. Tuttavia, è possibile eseguire le seguenti operazioni:

A - Chiedigli di condividere con te il piano di progetto. Potrebbe averne uno o ne costruirà uno mostrando i compiti e le scadenze. Uno di questi dovrebbe riguardare l'analisi e la raccolta dei requisiti. In caso contrario, suggeriscilo.

B - Preparare alcuni riferimenti sull'importanza dei requisiti per il successo del progetto software

C - Preparagli una pagina di ciò che Agile è e non è.

D - Preparagli un elenco di input tipici per la fase di progettazione e convincilo del valore di ciascuno.

E - Suggerire l'aggiunta di un analista aziendale e / o modellatore di dati al team. Tali ruoli dovranno spettare all'utente finale e ottenere le informazioni richieste o almeno buona parte di esso.

F - Guarda come altri sviluppatori hanno collaborato con questo ragazzo.

Per quanto riguarda il n. 4, puoi suggerirgli di utilizzare un approccio di prototipazione o un generatore di codice che aiuterebbe lui, l'utente e l'utente a prendere una decisione sugli aspetti funzionali dell'applicazione. La maggior parte degli strumenti non genera una GUI perfetta, ma almeno è possibile acquisire la funzionalità richiesta.

In tutti i casi, assicurati di documentare chiaramente ciascuna iterazione e di inviargli un'e-mail su quale input hai ricevuto, cosa hai fatto (in dettaglio) e quale sia il risultato. Assicurati di attribuire i risultati alla causa corretta come (mancanza di requisiti, ecc.).

Purtroppo alcune persone non accettano consigli. Quindi fai attenzione a come comunichi con lui.

Questo non sta andando bene!

In bocca al lupo.

Avevo un capo del genere, infatti scherzavo dicendo che il suo motto era "l'indecisione è la chiave della flessibilità".

Qualunque sia il lavoro di sviluppo che svolgi, probabilmente sei in una posizione migliore per risolvere il problema del cliente rispetto al tuo capo. Se non sai quale sia il problema che il cliente sta cercando di risolvere (che non è la stessa cosa di una specifica), qualcuno non sta eseguendo correttamente le proprie esigenze.

Disegna alcuni layout di pagina o crea un prototipo non / semi-funzionale. Ma fai qualcosa. Dal tuo post non è chiaro se stai creando software per client completo o app Web, ma la bellezza di quest'ultimo è che puoi rilasciare presto, rilasciare spesso. Inizia con le ossa nude e lavoraci da lì. Un falso inizio non fa male se riesce a far fluire qualche dialogo e prendere alcune decisioni.

Abbiamo un modo di dire circa $ WORK (app Web interne) per i nostri clienti: "Ti darò qualcosa in modo che tu possa dirmi quello che vuoi." Preparati a buttare via la prima bozza, ma potresti essere sorpreso da quanto raramente devi farlo.

Fai notare che i libri di Agile suggeriscono di rimandare le decisioni il più a lungo possibile, ma non di più . Ogni decisione ha un punto in cui deve essere presa e forse sei lì adesso.

D'altra parte, interrogati anche tu. Devi davvero decidere quale livello di persistenza utilizzerai per questa app? Oppure puoi iniziare a scriverlo su un CSV e tenerlo abbastanza astratto per prendere quella decisione in seguito?

Scrivi il tuo documento di specifiche e mantieni una recensione in cui lo spieghi e si firma su di esso. Quindi diventerai capo e il tuo capo passerà a problemi di gestione più interpersonali piuttosto che a problemi tecnici.

Impegnati a parlare di "gestione verso l'alto" con il tuo capo e i tuoi clienti, trova alcune soluzioni, scegli la migliore da implementare per il tuo team, trova difetti negli altri e "gestisci" il tuo manager nel prendere la decisione "giusta".

E ovviamente assicurati che pensi che sia stata tutta una sua idea. (specialmente quando tutto va storto!)

Devi progettare e implementare qualcosa. Dal momento che il tuo capo non prenderà decisioni, prendile tu stesso. Prenditi un po 'di tempo extra per documentare le tue decisioni e le tue ipotesi prima di metterle in atto. Invialo a chiunque possa interessare, incluso il tuo capo. Spero che questa lista includa più del tuo capo, perché gli farà una leggera pressione nel prendere alcune decisioni poiché sa che altri sono consapevoli che sei pronto a procedere. Sarai sorpreso dalla rapidità con cui ricevi feedback quando prendi decisioni per iscritto, specialmente se prendi decisioni con cui altre persone non sono d'accordo. Nel frattempo, procederei con le decisioni che hai preso fino a quando non è stato detto diversamente.

Se hai finito di perdere tempo a implementare ciò che il tuo capo non voleva, allora è su di lui e non su di te poiché era consapevole del percorso che stavi per intraprendere.

Inoltre, alcune persone hanno difficoltà a iniziare, ma una volta che vedono qualcosa di tangibile, la loro mente entra in gioco. Forse il tuo capo è così e il tuo dirgli che cosa pensi di fare per iscritto gli farà andare avanti la mente.

Prendi le decisioni da solo e inizia a scrivere codice. Naturalmente, lo sviluppo in modo flessibile aiuterà (leggi Agile Patterns, Principles and Practices di Robert C Martin se non l'hai già fatto), ma tutta la flessibilità del mondo non aiuterà se non vengono mai prese decisioni. Potresti scoprire che devi solo sviluppare ciò che pensiè necessario e quindi modificarlo come richiesto. Spesso i clienti / i capi non sanno cosa vogliono finché non lo vedono o finché non vedono qualcosa che non vogliono. Questo probabilmente ti porterà fuori dallo scopo di essere uno sviluppatore, ma questa è la vita. Trovo spesso che io e i miei colleghi stiamo effettivamente facendo descrizioni aziendali. A volte questi non sono messi in discussione e le decisioni che ho preso iniziano a guidare il business, semplicemente perché nessun altro prenderebbe la decisione. Assicurati di elencare TUTTI i tuoi presupposti e decisioni (senza eccezioni) e presentarli al tuo capo.