Come fornire valore? [chiuso]

Le metodologie agili sono così popolari perché hanno tanto successo a fornire solo le cose che forniscono valore aziendale il più rapidamente possibile. Tutto ciò che è fatto che non fornisce valore di business, indipendentemente da quanto elegante, lucido, intelligente o intelligente è uno spreco di denaro.

Concentrati su ciò che è importante

Gli sviluppatori non sono interessati al valore aziendale perché non sono uomini d'affari, se lo fossero avessero ottenuto un MBA non un diploma CS. Ciò che l'Agile Methodolgies come SCRUM, ad esempio, fornisce trasparenza, priorità e direzione agli sviluppatori su ciò che è importante per il business pur lasciando agli sviluppatori il controllo della come parte del processo di sviluppo, elimina tutto il tempo che molti sviluppatori sprecano facendo e ri-facendo solo per il gusto di "hacking" o "sarebbe bello se" codificante.

Ingegnere per il LifeCycle

La manutenzione dei progetti Agile è molto meno costosa dei progetti a cascata, perché la manutenzione è incorporata nel processo attraverso il concetto di Technical Debito , le cose che potrebbero non essere ideali ma opportune sono documentate e elencate come il potenziale lavoro da svolgere più avanti nel backlog, sono tutte tracciate, con priorità e giustificate. Ottimizzazione prematura inutile e scrittura di codice per caratteristiche che non sono richieste dal proprietario del prodotto, quindi non aggiungono valore aziendale e non vengono utilizzate o aggiungono complessità per motivi di "progettazione", causando problemi di manutenzione più orribili di qualsiasi altra cosa. La cosa bella è che se la prima volta ti basta abbastanza non c'è tanto da fare in seguito.

Aggiunta di valore come legacy

Migliorare il processo e la cultura è l'unica cosa che puoi "lasciare indietro" che avrà un valore duraturo. "Clean Code" che è l'esempio del design non sopravvivrà al primo contatto con uno sviluppatore di manutenzione Junior o addirittura uno senior nella maggior parte dei casi. Tutte le basi di codice di qualsiasi dimensione non trival si trasformano in un Big Ball of Mud alla fine con l'entropia, questo è inevitabile. Ma cambia nel modo di pensare e il processo dura da progetto a progetto.

Non sono sicuro di comprendere appieno la tua domanda (è un po 'complicata), ma credo che la cosa più importante sia l'atteggiamento orientato al cliente. Potrebbe essere ancora più importante delle grandi conoscenze tecniche e delle capacità di codifica. Un grande programmatore privo di orientamento al cliente può facilmente mettere insieme un'app tecnicamente sorprendente, performante e solida - che semplicemente fa qualcosa di completamente diverso da quello che il cliente desiderava davvero.

La programmazione è fondamentalmente basata sulla traduzione di desideri e idee umani poco chiari, non chiari, a forme comprensibili dalla macchina, quindi necessariamente rigorose e vincolate. Gran parte di questo processo richiede abilità come la comunicazione, l'empatia, la gestione dei conflitti, ecc. Non necessariamente tutti noi sviluppatori abbiamo bisogno di queste capacità, ma più sono e meglio è.

Questo è qualcosa che raramente ho visto dai consulenti per ovvi motivi. Il modo migliore per aggiungere valore è rendersi spendibili per buone ragioni. per esempio. Rendi comprensibile il loro lavoro. Mantieni i co-sviluppatori nel ciclo. Insegna alle tecniche appropriate dei co-sviluppatori ecc ...

Prima di tutto, il cliente deve essere completamente investito nell'idea che qualsiasi valore reale abbia luogo. Come sviluppatori dovremmo cercare di risolvere i problemi che i clienti stanno affrontando o di trovare modi per migliorare ciò che fanno. La mia opinione è che l'utente medio spende troppo tempo a raccogliere dati, mentre il loro vero lavoro dovrebbe essere l'utilizzo o l'analisi di tali dati, non la raccolta.

Un problema nel far investire il cliente è l'effetto "campo dei sogni". Spesso i clienti non sanno cosa vogliono veramente finché qualcosa non viene costruito per loro. Questo è il motivo per cui spesso ci sono così tante modifiche ai requisiti dopo il fatto. Il cliente non capisce cosa è possibile finché non vede qualcosa di concreto che può capire.

Un buon sviluppatore capirà questo, capirà le esigenze del cliente e tenterà di anticipare quali caratteristiche porteranno valore che il cliente non ha ancora immaginato.

Nel mio lavoro, ci sono volte al codice (perché la funzione deve essere effettivamente inserita) e ai tempi per giustificare il non cambio del codice (quando il rischio non è grande).

Mi sembra che quello che ti è successo è che sei passato da un programmatore a un ingegnere. Un ingegnere non è una scimmia del codice. Un ingegnere comprende l'impatto di ciò che fa e ne tiene conto prima di agire. Dovrei dire "bravo" ingegnere, suppongo.

Riguardo le caratteristiche / lavoro "segreti". Ci sono infatti tempi (e culture di lavoro) in cui sai che bisogna fare qualcosa per risolvere questo problema, e hai speso un sacco di sforzi per convincere i responsabili delle decisioni ad acquistare che questo lavoro è necessario. Dopo aver ascoltato per la prima volta (o fingendo di ascoltare, comunque), sono d'accordo sul fatto che vedono il tuo punto di vista, ma non possono giustificare la spesa e il rischio di qualunque cosa tu volessi fare.

Allora vai e fallo comunque. Una volta ottenuto il prototipo e funzionante all'80%, lo si rivela ai colleghi, ai manager e ai responsabili delle decisioni, i quali, ritenendolo "per lo più fatto, hanno bisogno di qualche modifica", vi dicono di andare avanti e completarlo. In genere questo tipo di cose viene fatto fuori orario ed è praticamente l'unico modo in cui le cose normalmente migliorano.

"... è più importante produrre velocemente veloce ed economico ..."

Più che essere una dichiarazione sul settore della programmazione, penso che tu abbia praticamente inchiodato il mantra della nostra società moderna.

Il modo più importante per aggiungere valore a uno sforzo software è comunicazione , non codice.

Comunicazione scritta

• Il progetto ha una wiki? La prima pagina del wiki è buona, con una bella panoramica di alto livello?
• Qualcuno ha parlato con utenti reali e ha scritto un riassunto di ciò che hanno detto?

Comunicazione verbale

• Puoi servire come tecnico commerciale per il prodotto, accompagnando il team di vendita per rispondere a domande tecniche?

Nota: contrassegnando questo come wiki della comunità in modo che altre persone possano aggiungere esempi.

Conoscenza del dominio

Le conoscenze di lavoro del dominio in cui stai scrivendo il software contribuiscono a fornire un notevole valore per il business.

• Uno sviluppatore della NASA con esperienza in ingegneria aerospaziale.