Come mantenere elevato il livello di produttività quando le persone continuano a cambiare i requisiti all'ultimo minuto?

4

Ho iniziato a lavorare come ingegnere informatico con una startup circa un anno e mezzo fa. Tutti qui si preoccupano di questo progetto e lavorano sodo. ma ho avuto un problema qui da un po 'di tempo.

Le persone qui hanno "mancanza di disciplina" quando si tratta di compiti di sviluppo. Chiedono una funzionalità, chiedo mille domande in modo da essere chiaro sui requisiti della funzionalità. Come non mi piace mai perdere un singolo scenario durante la raccolta dei requisiti. e faccio il mio lavoro con tutto il cuore e il cervello in esso.

Più tardi nel giorno della demo, avrebbero detto: cambiamo questo a quello e quello a questo. 5 demo dopo, cercando di adattarmi ai loro requisiti e al loro flusso, finisco con un pasticcio di codice che funziona come vogliono.

Ora, dato che il flusso è totalmente cambiato, non è nemmeno la stessa funzione con cui ho iniziato, c'è ritardo nel lancio, ci sono bug nella produzione e il marketing le sta urlando. Finisco sempre in qualche casino. e sono stanco di farlo.

Non riesco a risolvere il problema con queste persone, posso solo provare a sistemare me stesso, credo che i problemi vengano quando mi fanno lavorare sempre sulla stessa cosa e sono demotivato a lavorare e procrastinare.

Mi piace questo progetto, voglio davvero restare qui un po 'più a lungo e voglio dare il massimo anche se sto lavorando a qualcosa per la quinta volta.

Qualche consiglio su come mantenere alto il livello di produttività in questi scenari? Come faccio a essere sicuro di non perdere nulla mentre cambio le funzioni? e cosa faccio quando mi sento bloccato.

P.S. ATM Sto apportando cambiamenti nel flusso di un portale utente che ho effettivamente completato in modo impeccabile la scorsa settimana. e ora sono bloccato, non ho voglia di farlo. e non riesco nemmeno a pensare a come risolvere questi problemi.

    
posta Saira 30.07.2018 - 15:50
fonte

4 risposte

18

L'idea che i requisiti siano corretti e che il codice che stai scrivendo non debba essere modificato è estremamente problematico. In realtà, i requisiti non sono mai stati corretti. Se è necessario modificarlo prima o dopo la versione iniziale, a un certo punto in futuro, è molto probabile che il codice abbia bisogno di essere modificato. Quando cessa di essere vero, è perché la base di codice viene abbandonata.

Nella tua situazione, hai identificato che 1. i tuoi requisiti iniziali non sono quelli che alla fine consegnerai e 2. che non puoi influenzare alcuna modifica a quella realtà.

Tutto ciò indica una cosa: è necessario ottimizzare la strategia di sviluppo in base alla possibilità di cambiare. Molte delle pratiche software che leggerete qui riguardano la capacità di comprendere il codice in seguito, la facilità di modifica o entrambi.

La prima cosa che ti suggerisco è di smettere di provare a costruire un sistema completo e completo prima di mostrarlo ai proprietari dei tuoi prodotti. Costruisci invece prototipi funzionanti e portali davanti ai responsabili delle decisioni in anticipo. Prendi il loro feedback, implementalo e rendi le cose un po 'più rifinite. Mostralo di nuovo a loro. Risciacqua e ripeti. Alla fine, dovresti arrivare a un punto in cui iniziano a dire che tutto è OK tranne che per i dettagli. Ecco quando inizi a sistemare le cose.

L'altra cosa che spicca è che quando apporti queste modifiche, le stai hackerando. Dovresti seguire gli stessi standard per il tuo codice, sia che si tratti di una modifica dell'ultimo minuto o se il tuo codice non è dovuto per 6 settimane. Sì, è inevitabile che tu possa aver bisogno di modificare qualcosa all'ultimo minuto e ripulirlo ogni tanto, ma farlo come parte della tua versione normale è molto dannoso per il codice base. Il codice scritto in modo scadente, più difficile sarà adattarsi al flusso di modifiche. Trovarlo presto davanti alle persone ti aiuterà in questo modo, poiché avrai più tempo per apportare le modifiche in modo appropriato.

L'ultima cosa che consiglierò è un paio di pratiche di sviluppo specifiche che possono essere di grande aiuto in questo tipo di situazione:

  1. Codice modulare: se non altro, assicurati di abbattere il codice in metodi brevi e leggibili con un'unica responsabilità e un nome significativo.
  2. Test di unità: ciò che è spesso frainteso sui test di unità è che hanno un valore relativamente basso nel determinare se il tuo codice soddisfa i requisiti. Dove splendono è quando si modifica il codice. Danno un feedback istantaneo quando hai rotto qualcosa. Tienili aggiornati e modifica i test che devi modificare prima di implementare la modifica.
risposta data 30.07.2018 - 16:49
fonte
2

La risposta di JimmyJames copre bene molti aspetti. Volevo solo aggiungere qualche altro punto:

Riduci i tempi di sviluppo

Assicurati di scrivere il minor numero possibile di codice. In particolare, devi assicurarti di dover solo cambiare codice in un posto ( DRY ) e non lo sono aggiungere campane e fischietti troppo presto ( YAGNI ).

Se trovi che stai modificando lo stesso codice più e più volte e che la struttura sta soffrendo, allora con ogni mezzo rifattore per fermare il software entropying ulteriormente.

Aumenta la responsabilità

Assicurarsi che tutte le modifiche siano documentate. Saresti stupito di quante esigenze scompaiano quando c'è una traccia cartacea!

Assicurati che tutte le modifiche siano verificabili . Desideri come "che dovrebbero sembrare più snelli" e "quella forma potrebbe fare con il riordino" sono fognature temporali. Assicurati che le modifiche possano essere dimostrate.

Infine, se lo sviluppo è il tempo inscatolato per dire, uno sprint quindi ci sarà meno la tentazione di un infinito armeggiare.

Come ultimo take-away, fare pace con il fatto che il software spesso cambia (per molte ragioni) ti farà andare avanti senza problemi.

    
risposta data 31.07.2018 - 16:24
fonte
2

Leggendo la tua storia, una cosa spicca per me. Il tuo atteggiamento è molto reattivo / reattivo / seguendo. Ti aspetti che i tuoi stakeholder abbiano una visione e ti forniscano compiti intelligenti e a prova di futuro. Il problema ovviamente è che non sono così intelligenti o previdenti. Hanno solo alcune idee selvagge e scoprono solo cosa c'è di sbagliato in quelle idee quando mostri loro quello che hanno chiesto.

Quindi, invece di bloccarli su ciò che hanno chiesto e produrlo senza pensarci, dovresti fare un brainstorming con loro fino a quando non avrai tutti una visione di ciò che vuoi puntare. Quindi puoi fare il primo passo verso l'obiettivo (lontano).

Il tuo (e intendo il tuo "in senso plurale") è troppo piccolo ora. Ovviamente vuoi andare lontano ma non sai ancora in quale direzione. Pensa un po 'più grande. Piuttosto che fare un passo impulsivo verso una direzione casuale, prova a pensare almeno un paio di passi avanti e assicurati di sapere dove (idealmente) vuoi finire. Aiutare le parti interessate a sviluppare una visione può semplificarti la vita e rendere il tuo lavoro più gratificante.

    
risposta data 31.07.2018 - 20:25
fonte
-2

Comprendi che non ti viene pagato per creare software "buono".

Ti viene pagato per completare richieste di funzionalità il più velocemente possibile con zero difetti.

Questo è possibile, puoi essere bravo a farlo e esserne orgoglioso. L'azienda accetta il debito tecnico.

  • Scrivi un sacco di test in modo da essere certi dei difetti zero.
  • Ottieni l'accesso alle specifiche e modifica le richieste in modo da non essere incolpato per aver scritto la cosa sbagliata.
  • Ottieni il tuo processo CI in posizione in modo da non dover svolgere alcuna attività di infrastruttura / implementazione.
risposta data 30.07.2018 - 17:02
fonte

Leggi altre domande sui tag