Che cosa fare se il capo rinvia sempre le decisioni importanti in merito ai requisiti e alla progettazione generale?

Costruisci prototipi

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

Dovresti essere in grado di renderlo parzialmente funzionante lentamente e, eventualmente, di ridefinire parte del codice errato quando diventa più chiaro ciò che stai cercando di fare.

È un problema comune che non sanno quello che vogliono finché non vedono qualcosa e capiscono che non è quello che vogliono. Ho scoperto che quando qualcuno vuole che tu abbia appena iniziato a costruire 'un quadro' o qualcosa di 'generico' come quello che ti sta dicendo, ti metteresti nei guai se ci provassi. I framework sono già stati scritti, non è necessario farlo.

Ci sono diversi problemi che ho raccolto dal tuo messaggio: 0-Non è compito tuo gestire il progetto e non è compito tuo raccogliere i requisiti degli utenti finali. 1-Il capo non conosce i requisiti esatti 2-Il capo non parla con gli utenti finali dei requisiti 3-Il capo sta lanciando una terminologia che non capisce veramente agile 4-Stai elaborando una soluzione che viene riscritta più volte e non ne sei felice

Per quanto riguarda l'1,2 e il 3, non si può fare molto su questo se non si è una persona anziana. Tuttavia, è possibile eseguire quanto segue:

A - Chiedigli di condividere con te il piano del 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. Se non lo suggerisci.

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

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

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

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

F - Guarda come altri sviluppatori hanno coopedato con questo tizio.

Per quanto riguarda il n. 4, puoi suggerirgli di utilizzare un approccio di prototipazione o un generatore di codice che possa aiutarlo, tu e l'utente a prendere in considerazione gli 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'email per sapere quale input hai ricevuto, cosa hai fatto (in dettaglio) e qual è il risultato. Assicurati di attribuire i risultati alla giusta causa come (mancanza di requisiti, ecc.).

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

Questo non sta andando bene!

Buona fortuna.

Avevo un capo come quello - in effetti scherzavo dicendo che il suo motto era "l'indecisione è la chiave della flessibilità".

Qualunque sia il lavoro di sviluppo che fai, probabilmente sei in una posizione migliore per risolvere il problema del cliente del tuo capo. Se non sai qual è il problema che il client sta cercando di risolvere (che non è la stessa cosa di una specifica), allora qualcuno non sta facendo in modo che i loro requisiti vengano raccolti correttamente.

Disegna alcuni layout di pagina o crea un prototipo non / semi-funzionale. Ma fai qualcosa. Non è chiaro dal tuo post se stai costruendo software full-client o web-app, ma la bellezza di quest'ultimo è che puoi rilasciare presto, rilasciare spesso. Inizia con le ossa nude e lavora da lì. Una falsa partenza non fa male se ottiene un po 'di dialogo che scorre e alcune decisioni prese.

Abbiamo un detto circa $ WORK (web-app interne) per i nostri clienti: "Ti darò qualcosa in modo che tu possa dirmi quello che vuoi." Siate pronti a buttare via la prima bozza, ma potreste essere sorpresi di quanto raramente sia necessario.

Indica a lui che i libri Agile suggeriscono di posticipare le decisioni finché puoi ma non più di . Ogni decisione ha un punto in cui deve essere fatta, e forse sei lì adesso.

D'altra parte, anche te stesso. Hai davvero bisogno di decidere quale strato di persistenza utilizzerai per questa app? Oppure puoi iniziare a scriverlo su un CSV e tenerlo abbastanza astratto per prendere quella decisione più tardi?

Scrivi il tuo documento spec e tieni una recensione dove lo spieghi e lui firma su di esso. Allora diventerai capo e il tuo capo passerà a più problemi di gestione interpersonale piuttosto che a problemi tecnici.

Impegnati in una "gestione verso l'alto" parla al tuo capo e ai clienti, individua alcune soluzioni, scegli il migliore per il tuo team da implementare, trova difetti negli altri e "gestisci" il tuo manager nel rendere il "giusto" decisione.

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

Devi progettare e realizzare qualcosa. Dal momento che il tuo capo non prenderà decisioni, allora fallo da solo. Prenditi un po 'di tempo in più per documentare le tue decisioni e le tue ipotesi prima di implementarle. Mandalo a chiunque possa riguardare incluso il tuo capo. Si spera che questa lista includa più del tuo capo, in quanto eserciterà un po 'di pressione su di lui per prendere alcune decisioni poiché sa che gli altri sono consapevoli di essere pronti a procedere. Rimarrai sorpreso dalla rapidità con cui ricevi feedback quando prendi decisioni per iscritto, specialmente se prendi decisioni che non sono d'accordo con altre persone. Nel frattempo, vorrei procedere con le decisioni che hai preso fino a quando non ho detto diversamente.

Se hai perso 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 avresti intrapreso.

Inoltre, alcune persone hanno un momento difficile per iniziare, ma una volta che vedono qualcosa di tangibile la loro mente inizia a giocare. Forse il tuo capo è così e il tuo dirgli quello che hai intenzione di scrivere lo farà andare avanti.

Prendi le tue decisioni e inizia a programmare. Naturalmente, lo sviluppo in modo flessibile aiuterà (leggi Agile Patterns, Principles and Practices di Robert C Martin, se non lo hai già fatto), ma tutta la flessibilità del mondo non sarà di aiuto se non verranno mai prese decisioni. Potresti scoprire che devi solo sviluppare ciò che pensi che sia necessario, e quindi modificarlo come richiesto. Spesso i clienti / i capi non sanno quello che vogliono finché non lo vedono, o finché non vedono qualcosa che non vogliono. Questo probabilmente ti porterà al di fuori dello scopo di essere uno sviluppatore, ma questa è la vita. Trovo spesso che io e i miei colleghi stiano effettivamente facendo delle scelte di business. A volte queste non vengono messe in discussione, e le decisioni che ho preso iniziano a guidare l'azienda, semplicemente perché nessun altro farebbe la decussione. Assicurati di elencare TUTTE le ipotesi e le decisioni (senza eccezioni) e presentarle al tuo capo.