Questi sono segni di un cattivo sviluppatore? [chiuso]

Ero solito incolpare il cambiamento delle specifiche dei clienti per il marciume del codice, senza rendermi conto che i modelli di business cambiano ed è il mio lavoro sviluppare in modo adattabile. Ora lo vedo come un segno di un cattivo sviluppatore (sono cambiato!).

Ma ora vedo altri "capricci" in me stesso. Qualche volta di recente mi sono ritrovato a dire "è come cercare di inserire un piolo quadrato in un foro circolare", e mi ritrovo a incolpare l'indecisione del cliente per un progetto che non sta avanzando.

Ci sono segni che dovrei cercare dove dovrei cambiare il mio atteggiamento? Il cliente ha sempre ragione o a volte sono giustificato a sentirmi frustrato?

Non direi che sei un cattivo sviluppatore. Essere consapevoli dei problemi ti porta già oltre questa definizione.

I requisiti cambiano. Questo è un dato di fatto. Un buon sviluppatore deve tenerne conto. Molte moderne tecniche di programmazione aiutano a far fronte a questo.

Rimanere fedeli alle specifiche originali non è realistico. Inoltre, non è realistico cambiare continuamente i requisiti.

Il cliente sicuramente non ha sempre ragione. È "giusto" più spesso di quanto desideriamo che sia (comunque, cerca di accontentarlo se non è completamente spento). Ma quando lo vedi guidare il progetto nella direzione sbagliata, cerca di sostenere le cose che pensi siano giuste.

Non ci sono regole rigide su queste cose e nemmeno gli sviluppatori bravi ed esperti non hanno raggiunto lo "Zen" perfetto. L'unico approccio sbagliato non sta cercando di migliorare su questi.

Ci sono casi in cui è il client. Ma anche questo è il tuo problema

Ci sono casi in cui è lo sviluppatore e ci sono casi in cui è il cliente. Ma di solito sono entrambi il tuo problema, quindi un atteggiamento di incolpare se stessi tende ad avere più successo, perché si sbaglia sul lato della risoluzione dei problemi invece che sul puntamento indifeso delle dita. Pertanto, lo troverai spesso in sviluppatori più esperti.

Un atteggiamento ancora migliore è l'IMHO a guardarlo senza colpa: "è colpa dei clienti che ho un codice scadente, perché cambia sempre i requisiti" quindi diventa "questo cliente sta cercando di capire cosa vuole, quindi feedback, prototipazione rapida e flessibilità sono maggiori importante di completezza, robustezza e velocità ".

Una specie di mente zen: non giudicarla, guardala come è.

Innanzitutto, un cliente non sa cosa vuole finché non lo vede. Fa parte del fascino delle piccole iterazioni del paradigma Agile con un forte coinvolgimento del cliente. In secondo luogo, non aspettarti che un prodotto sia "completo" quando hai completato il codice.

Microsoft utilizza un prodotto chiamato "Watson" (il messaggio di feedback di invio che viene visualizzato quando Windows si espande) al fine di rintracciare i problemi direttamente a un client. La tracciabilità è un buon modo per rintracciare i problemi agli utenti che li sperimentano. È possibile ottenere la tracciabilità chiedendo. Oppure, se si dispone delle risorse, integrare la funzionalità nei prodotti. La chiave sta monitorando i problemi / i miglioramenti in modo che possano essere risolti.

Infine, il client può essere instabile. In questi casi, provo a concentrarmi sul segreto dell'iceberg .

Il mutare dei requisiti è un fatto difficile della vita; ma il marciume del codice non è causato da questo.

Il marcio del codice si verifica quando ci sono alcune parti del codice che non si esercitano frequentemente; quindi quando si apportano alcune modifiche che "non dovrebbero influenzare nient'altro", è possibile introdurre dei bug. In altre parole, il codice che non vede la luce del giorno decomporsi lentamente e non si può dire quando ha smesso di funzionare.

Sì, è colpa tua e non dell'utente.

La vera soluzione? prova frequentemente tutto il tuo codice. Naturalmente, il modo migliore è di avere test automatici con una buona copertura.

L'indecisione del cliente può essere un grosso problema e se non sei tu il responsabile della gestione della relazione con il cliente, potrebbe essere molto difficile da gestire. Puoi parlare con la persona che ha a che fare con il cliente e spiegare con calma che i progressi non possono avvenire fino a quando il cliente non prende una decisione. Se sei responsabile del rapporto con il cliente, si deve dire al cliente che hanno bisogno di prendere una decisione prima che il progetto possa continuare. Potrebbe non essere che il tuo atteggiamento abbia bisogno di una revisione, solo un minuto di meditazione per calmarti. ;)

Javier sottolinea che cambiare i requisiti è un fatto difficile della vita. Anch'io sono frustrato da queste situazioni perché troppo spesso mi trovo a lavorare su un prodotto in cui lo sviluppatore deve prendere decisioni. La mia opinione era "Perché il management non riesce a capire questo con il cliente?", O "Perché abbiamo iniziato questo progetto se il cliente non sa cosa voleva?", "È così tanto mal di testa quando cambiano così in ritardo nello sviluppo ".

Semplice fatto: questo accadrà sempre , non solo nella programmazione / sviluppo software, ma in ogni ambito della vita. Il mondo sarebbe semplicemente un posto molto noioso e molto diverso se le persone non cambiassero mai idea, non si adattassero mai, non affrontassero mai il cambiamento. Le persone hanno la tendenza a guardare ciò che viene dato e migliorarlo. Non fai la stessa cosa con il tuo codice? Se ho un blocco di codice di cui non sono soddisfatto (è inefficiente, disordinato), lo migliorerò. (Il sistema operativo si lamenta con me? ... a volte, se sto usando un determinato sistema operativo senza nome, ma generalmente no)

Come programmatori dobbiamo cogliere le opportunità per migliorare le cose e non essere depressi o infastiditi da loro. Cogli l'occasione per parlare con le persone, migliorare il tuo stile, migliorare la tua etica del lavoro, affrontare le cose con una mente aperta, spingerti ad essere migliore di come eri ieri. Vai avanti nella tua carriera e non accontentarti troppo facilmente.

Capisco che non tutti saranno d'accordo con questa risposta, ma penso che sia importante che le risposte a questa domanda coprano una prospettiva più ampia.

Quando interagisci con un client, non stai programmando; stai imparando e insegnando.

Tieni i clienti informati e istruiscili sul processo. Il cambiamento avverrà. Fai sapere loro che proverai ad implementarli, ma costerà di più. Lascia che decidano.

Non entrare nei dettagli tecnici anche quando la domanda che pongono è di natura tecnica. Sei tentato perché ti sentirai un po 'sulla difensiva e vorrai affrontare una sfida / scatenarti. Non farlo; non si preoccupano dei dettagli e smetteranno di ascoltare dopo 45 secondi.

Se non gli hai detto in anticipo, non aspettarti che conoscano gli standard del settore e le migliori pratiche o qualsiasi altra scusa per fare ciò che fai. Lo odio quando non vedo una commissione fino alla fine solo per avere il venditore di dirmi che è standard nel settore. Non dovrei aspettarmelo. La mia risposta è: "Anche farmi sentire un idiota è uno standard?"

Quando sei con un cliente, presta più attenzione a loro di chiunque altro o altro nella stanza. I cani domestici sono dei geni in questo; soprattutto se hai cibo.

È una cattiva gestione dei requisiti o una cattiva analisi. Il tuo analista aziendale (se ne hai uno) o chiunque ottenga i requisiti deve sedersi con il cliente e cercare di ottenere tutti i requisiti, anche quelli a cui il cliente potrebbe non pensare. I clienti di solito non sanno tutto quello che vogliono, un grande analista aziendale li aiuterà a capire tutto.

Questo è il motivo per cui dovresti sempre ottenere una configurazione del documento sui requisiti aziendali e firmare prima che qualsiasi applicazione vada oltre la fase di prototipazione / ricerca.

Ora, l'idea che questo documento sia in realtà definitivo è errata, ma ciò dovrebbe aiutarti a farti un'idea migliore di ciò che il cliente desidera effettivamente. E fintanto che scrivi il codice pensando alla manutenibilità, puoi ridurre al minimo i tuoi problemi.

E se hai mai bisogno di una scusa per ricorrere, puoi incolpare eventuali ritardi sul BRD, su cui il cliente ha firmato, non includendo tale e tale funzionalità, ecc.

(Certo, questa è solo una scusa nel caso in cui ne abbiate bisogno. Dovreste sempre pianificare che cambino qualcosa )

Nella citazione di Emerson, "Una follia consistenza è il folletto delle piccole menti ..." la parola più spesso trascurata è sciocca . La coerenza non è negoziabile in alcuni contesti, ma spesso sostituisce il pensiero e l'analisi critici.

Da un lato, molti modelli di sviluppo sono progettati specificamente per aiutare l'ambiente che stai descrivendo; quindi se ti accorgi di dover violare il tuo modello, allora o non lo stai implementando nel modo giusto, o hai il modello sbagliato.

D'altra parte, se hai una giustificazione ben motivata e sostenibile per violare le tue regole e puoi mostrare che il tuo metodo canaglia produce un codice più pulito e più sostenibile, allora non dovresti aver paura di prendere la strada ragionevole.