Come programmatore, come posso accelerare l'adozione e la comprensione delle regole aziendali?

Per me, è leggendo e comprendendo le basi di codice.

Lo dico per due motivi principali:

1. Le persone fanno schifo. Oh, non di proposito (di solito), ma negli affari ho scoperto che le persone spesso hanno una comprensione leggermente diversa delle regole aziendali. E ognuno ha il proprio modello mentale che a sua volta perde fedeltà mentre cercano di comunicarlo a voi. Ma il codice non mente. Le persone possono pensare quello che vogliono su come le cose sono supposte per funzionare, ma il codice è giusto.

2. Costruisci innanzitutto una fondazione. Quindi, se ognuno ha il proprio modello mentale di cosa sono questi termini e processi specifici del business, come si costruisce il proprio? Per me, e mi aspetto per molti programmatori, costruisco i miei modelli mentali al meglio dal codice. Il codice ha schemi. Il codice ha astrazioni. Ho molta esperienza nell'assumere codice e costruire un modello mentale da questo. Una volta che ho almeno una vaga forma di ciò che le cose esistono e come si relazionano, allora posso parlare agli uomini d'affari. Quindi posso porre le domande giuste e inserire meglio le risposte nel puzzle.

Non essere troppo duro con te stesso. A volte mi chiedo perché si siano anche preoccupati di chiamarli "regole" di business, ma suppongo che chiamarle "i modi in cui facciamo tipicamente le cose a meno che non ci siano altre cose applicabili, le facciamo in modo diverso" probabilmente li insulteremmo. Gli affari sono disordinati. Gestiscono le esigenze di clienti, agenzie legali, contabilità, regolamenti, venditori, dipendenti, dirigenti e amministrazioni locali. Non hanno sempre una ragione.

Penso che il modo migliore sia quello di assicurarti di trascorrere del tempo con il maggior numero di uomini d'affari che puoi. Questo può essere difficile per alcune persone in posizioni tecniche.

1. Risparmia tempo e sii rispettoso delle loro, ma cerca di ottenere il massimo che puoi.
2. Dovrai fare domande. Non pensano come programmatori e rompono tutto e hanno una comprensione completa di come le informazioni si relazionano l'una con l'altra.
3. Non fingere come capisci. Se sapessi quanto gli altri uomini d'affari ti farebbero fare entrambi i lavori. Vedi # 2.
4. Non aspettarti documentazione. Offri molte lodi se ne hai mai.
5. Fai attenzione alle critiche. I processi e le procedure possono avere ridondanze e altre efficienze potenziali, ma ci può essere una ragione per questo. Scopri perché, ma non essere scioccato quando dicono "Abbiamo sempre fatto così."
6. Sii cortese, gentile e condividi i tuoi snack. Hai a che fare con le persone. Di Ciao. Chiedi come stanno. Chiedete perché sono entrati nel settore, da quanto tempo sono con la compagnia.

Non sei un vuoto chiamato programmatore, sei una persona. Fai sapere loro che sei lì per rendere più facile il loro lavoro. Sfortunatamente, puoi essere l'eroe o la capra. È la natura della nostra attività.

Raccomando di leggere un libro intitolato I 5 elementi del pensiero efficace di Edward Burger e Michael P. Starbird. È legato alla comprensione di nuovi concetti in generale, ma penso che si applica a questa situazione.

Ecco alcuni punti interessanti del libro:

Padronanza delle basi

Se non conosci le basi, costruirai la tua comprensione su fondamenta instabili. Quindi devi chiedere a quelle domande stupide che nessun altro chiede.

Consenti agli errori di essere la tua guida

A volte aiuta a fare domande che sono chiaramente sbagliate in modo da poter scoprire la tua mancanza di comprensione. (Es .: Vuoi dire che gli amministratori hanno accesso a tutti i documenti? Oh, perché?)

Insegna o spiega ad altri

Quando provi a insegnarlo a qualcun altro, inizierai a scoprire dove non riesci a capire.

Spero che ti aiuti!

Come sviluppatore ho realizzato che traduco direttamente l'attività in codice, strutture dati, classi possibili, ecc ... Vado da qualcosa di astratto e spesso, indefinito a qualcosa di specifico, qualcosa con "forma". Comincio a codificare immediatamente e, la mancanza di informazioni , mi porta a frequenti refactories. Ogni refactor mi fa pensare che ci siano troppe lacune nella mia comprensione del business .

Come ho iniziato a risolvere questo?

Mi sforzo di leggere tutti i documenti fatti durante l'analisi funzionale e le fasi precedenti. Provo a farlo come se fossi il cliente o l'utente finale . Devo capire cosa sta cercando il cliente con tali applicazioni e requisiti. Ma ho bisogno di stare lontano da Dev I'am.

Il nostro lavoro ci fornisce una grande competenza che i clienti non hanno. Pensiamo in strutture condizionali in un modo che gli altri non fanno. Quindi inizio ad affrontare i requisiti. Alla ricerca di contraddizioni o incoerenze . Un po 'di cervello che si aggira intorno a ciò che ho capito. Formulare scenari ipotetici.

Mi conduce a domande e dubbi. Scrivo tutti e finalmente incontro un incontro con chiunque possa risolvere i miei dubbi.

Riassumendo, cambio il mio punto di vista. Provo a guardare il problema da un'altra prospettiva. Ma ho messo alcune abilità di dev sul processo. Cosa finisce in un buon gruppo di domande e dubbi da risolvere. Una volta risolto, la mia comprensione del business è più profonda.

Studio > Dubbi > Domande > Risposte > Comprensione (ripetere il ciclo più e più volte)