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

Sono stato uno sviluppatore per un po '. Sono tutt'altro che il migliore là fuori. (Mentre mi siedo da solo in questa stanza, mi chiedo se sono anche il migliore qui.) Tuttavia, sono arrivato a capire i miei strumenti e ho avuto fiducia nella mia capacità di ragionare e apprendere.

Quando inizio un nuovo lavoro, credo sempre di poter imparare la base di codice se è una lingua che conosco. Se non è un linguaggio o un framework che conosco, credo di poter afferrare i concetti abbastanza per impararlo (e solo leggere la documentazione). Questa è una parte del nostro set di competenze come programmatori e sono orgoglioso di poter essere all'altezza di questo standard.

Per tutto questo, però - uno dei miei principali punti deboli è l'apprendimento e l'interiorizzazione delle regole di business per il cliente per cui lavoro in modo rapido - sia che io sia un dipendente retribuito o un appaltatore. Sto bene con i codebase, ma le regole e i processi aziendali per un'azienda specifica sembrano sempre impiegarmi un po 'a comprendere appieno. (Ad esempio, questo può essere un tripup quando si riscrivono le applicazioni aziendali.)

Come sviluppatore, qual è il modo migliore per assimilare le regole e i processi aziendali in modo rapido ed efficiente? È possibile senza essere un esperto in materia o semplicemente avere anni di esperienza con il cliente, la società o l'azienda?

Per me, è leggendo e comprendendo basi di codice.

Lo dico per due motivi chiave:

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

2. Costruisci prima una fondazione. Quindi, se ognuno ha il proprio modello mentale di quali sono questi termini e processi specifici del business, come costruisci il tuo? Per me, e mi aspetto per molti programmatori, costruisco i miei modelli mentali meglio dal codice. Il codice ha schemi. Il codice ha astrazioni. Ho molta esperienza nel prendere il codice e costruirne un modello mentale. Una volta che ho almeno una vaga forma di ciò che esiste e di come si relazionano, allora posso parlare con gli uomini d'affari. Quindi posso porre le domande giuste e adattare meglio le loro risposte al puzzle.

Non essere troppo duro con te stesso. A volte mi chiedo perché si preoccupino persino di chiamarli "regole" aziendali, ma immagino che chiamarli "modi in cui facciamo le cose a meno che non ci siano altre cose che si applicano, quindi le facciamo diversamente" probabilmente li insulterebbero. Gli affari sono in disordine. Gestiscono le esigenze di clienti, agenzie legali, contabilità, normative, fornitori, dipendenti, dirigenti e amministrazioni locali. Non hanno sempre un motivo.

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

1. Preventivi il tuo tempo e rispetta il loro, ma ottieni il più possibile.
2. Dovrai porre domande. Non pensano come programmatori, scompongono tutto e hanno una comprensione completa di come le informazioni si relazionano tra loro.
3. Non fingere come capisci. Se tu sapessi tanto quanto gli altri uomini d'affari ti farebbero fare entrambi i lavori. Vedi # 2.
4. Non aspettarti documentazione. Offri molti elogi se mai ne ricevi.
5. Aspetta le critiche. I processi e le procedure possono presentare ridondanze e altre potenziali efficienze inn, ma potrebbe esserci un motivo. 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. Chiedi perché sono entrati nel settore, da quanto tempo sono in azienda.

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

Consiglierei di leggere un libro intitolato The 5 Elements of Effective Thinking di Edward Burger e Michael P. Starbird. È legato alla comprensione di nuovi concetti in generale, ma penso che si applichi a questa situazione.

Ecco alcuni punti interessanti del libro:

Padroneggia le basi

Se non conosci le basi, costruirai la tua comprensione su una base instabile. Quindi devi porre quelle domande stupide che nessun altro pone.

Lascia che gli errori siano la tua guida

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

Insegnalo o spiegalo agli altri

Quando provi a insegnarlo a qualcun altro, inizierai a scoprire dove hai difficoltà a capire.

Spero possa aiutare!

Come sviluppatore mi sono reso conto che traduco direttamente il business in codice, strutture di dati, possibili classi, ecc ... Vado da qualcosa di astratto e spesso, indefinito a qualcosa di specifico, qualcosa di "forma". Comincio a scrivere immediatamente il codice e, la mancanza di informazioni , mi porta a frequenti rifattori. Ogni refactor mi fa pensare che ci siano troppe lacune nella mia comprensione del business .

Come ho iniziato a risolvere questo?

Mi costringo a leggere tutti i documenti realizzati 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 tale applicazione e requisiti. Ma ho bisogno di stare lontano dal dev. Sono.

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 a confrontarmi con i requisiti. Alla ricerca di contraddizioni o incoerenze . Un po 'di brain storming attorno a ciò che ho capito. Formulazione di scenari ipotetici.

Mi porta a domande e dubbi. Scrivo tutti quanti e alla fine ho fissato 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à degli sviluppatori sul processo. Ciò che finisce in una buona serie 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)