Ci sono molti libri fantastici là fuori, come indicato in altre risposte. Ma chiederci consigli non è l'approccio migliore: ogni volta che ho bisogno di saperne di più sul dominio di un esperto in materia, ho ottenuto il massimo chiedendo consigli a quella persona . Tu ei tuoi colleghi siete partner che lavorano per un obiettivo comune ed è nel loro interesse che tu impari di più senza perdere tempo in cose che non aiutano. Sono nella posizione migliore per guidarti.

I libri sono anche la strada da percorrere o ci sono altri modi in cui posso imparare di più su come comunicare al meglio con questi colleghi?

Il modo in cui descrivere originariamente il tuo approccio mi rende un po 'pessimista sulla sua fattibilità. Imparare tutto ciò che è necessario (o non ) eventualmente necessario per costruire un migliore apprezzamento del mestiere del programmatore potrebbe richiedere troppo tempo.

• Specifiche del software, monitoraggio dei problemi, tecniche di stima, approcci di progettazione e metodologie di sviluppo, test funzionali e di regressione, debiti tecnici e considerazioni sulla manutenzione ecc. ecc. ecc.

Penso che il modo più realistico di comunicare con i programmatori per un non programmatore che desidera solo comprendere i concetti e le questioni più comuni coinvolti nella creazione di software siano i normali 1: 1 .

Per un riferimento su come farlo, prendi in considerazione un eccellente articolo The Update, The Vent e The Disaster. Questo articolo è stato scritto dalla prospettiva di un team manager di sviluppo, ma nella mia esperienza un approccio simile ha funzionato anche in una collaborazione tra un cliente / progettista e un programmatore come descrivi.

... Io ' Non sto suggerendo che ogni 1: 1 sia un affare tortuoso per scoprire disastri emergenti profondamente nascosti, ma vuoi creare un luogo settimanale in cui l'insoddisfazione potrebbe apparire silenziosamente. Un rapporto 1: 1 è la tua occasione per eseguire la manutenzione preventiva settimanale, comprendendo anche la salute del tuo team.

... Il suono che circonda il regime di successo di 1: 1 è il silenzio. Tutti gli ascolti, le domande e le discussioni che avvengono durante un rapporto 1: 1 sono manutenzione preventiva gestionale. Vedrai quando l'interesse per un progetto inizia a diminuire e agisci prima che diventi insoddisfazione sul lavoro. Sentirai parlare della tensione tra due dipendenti e modererai una discussione prima che diventi un incontro urlante in una riunione. La tua ricompensa per una cultura del sano 1: 1 è una netta mancanza di drammaticità.

• ^{Un punto molto forte dell'articolo precedente è che è auto- contenuto , nel senso che oltre a spiegare i benefici, fornisce anche una serie di consigli pratici che consentono fondamentalmente di iniziare a praticare i normali 1: 1 senza scavare in altre fonti (anche se cercare informazioni aggiuntive non farà male, sai ).}

Con i normali 1: 1 sarai in grado di scegliere e concentrarti sull'apprendimento di argomenti particolari che sono di specifica importanza in ogni dato momento. Se lo fai bene, se parli, chiedi e ascolti attentamente, avrai abbastanza tempo per trovare e studiare le risorse necessarie, senza essere pressato da questioni urgenti inaspettate: "La tua ricompensa per una cultura del 1: 1 sano è una netta mancanza di drammaticità ".

_{Per quanto riguarda i libri, dal momento che hai menzionato Codice completo, probabilmente non si può sbagliare usandolo come un riferimento generale (qui sto parlando della Seconda Edizione, quella che ho studiato). È un capolavoro, una panoramica fondamentale e ben presentata dello sviluppo di software professionale che fornisce un'analisi approfondita per ogni area immaginabile di esso. Dato che ce l'hai già, considera di sfogliare il capitolo sulle Pratiche di sviluppo collaborativo : a mio ricordo è stato il più avvincente di tutto ciò che ho letto su questi argomenti fino ad ora.}

_{Code Complete è una risorsa davvero profonda, ottima per uno studio approfondito, ma proprio per questo, esiterei davvero a consigliarlo a qualcuno che necessita di una rapida introduzione ai concetti di software sviluppo. Per quest'ultimo, preferisco scegliere Fatti e errori dell'ingegneria del software: un libro piccolo e di facile lettura. I riferimenti forniti in ciascuna sezione consentono uno studio più approfondito dell'argomento, se necessario. Letture consigliate per chi è interessato a ottenere il software corretto.}

Per la comunicazione, è più importante comprendere lo stile di vita di un'altra persona o gruppo che conoscere necessariamente i punti principali di tutte le fasi della loro professione. Mi concentrerei su:

• Storie di guerra - non solo le persone vogliono raccontarle, ma ascoltare attentamente ti dirà molto su come vedono il loro lavoro, l'ambiente in cui lavorano e ciò che è difficile o facile nel loro mondo - tutte cose fondamentali da sapere per la collaborazione. Inoltre, il lato delle pubbliche relazioni: alle persone piace essere ascoltate e avere la possibilità di raccontare a un nuovo ragazzo le loro storie di guerra e ricevere domande ponderate, genererà sentimenti positivi nei tuoi confronti.

• Ricerca gergale : c'è un sacco di gergo in questo tipo di lavoro. Strumenti, linguaggi, processi, metodologie, modelli e altro hanno tutti nomi univoci. Alcuni coprono il settore (mettete una J davanti ad esso, ed è probabilmente qualcosa legato a Java), alcuni sono unici per l'ufficio (come il rapporto TPS nello spazio ufficio). Quando ho dovuto intensificare qui, Wikipedia è la mia prima linea di difesa, seguita dalla richiesta di dizionari terminologici e siti interni che definiscono i processi.

• Codice Completo, in particolare - è una lettura interessante perché riguarda il business di un buon sviluppo del software. Potrebbe essere una bella risorsa per questo, poiché si tratta di buoni modi di fare le cose, piuttosto che il come delle basi della cosa. Una cosa da tenere d'occhio è che ogni gruppo di software avrà i propri modi di lavorare che possono o meno aderire alle migliori pratiche, quindi diffidare di fare ipotesi unilaterali basate su un libro come questo.

• Parla con il programmatore & client - A volte sapere tutto su come qualcuno fa il suo lavoro è un danno. La parte importante è essere sicuri di comunicare chiaramente e lasciare loro la capacità di fare ciò che fanno senza fornire ostacoli per ignoranza. Parla molto del motivo per cui vuoi fare quello che vuoi fare, chiedi consigli, chiedi feedback se sei stato chiaro, chiedi di riaffermare la tua richiesta o offri lo stesso - e chiedi perché, perché, perché.

• Chiedere di assistere al lavoro - Ho scoperto che nello sviluppo del software c'era uno stile di lavoro e una chimica magica nel modo in cui si lavora questo campo che nessun libro potrebbe riassumere. La Nerd Cave ne fa parte, ma c'è di più, e può darsi che solo camminandoci sopra otterrai quelli che sono i veri punti deboli e i momenti gloriosi del lavoro. Cordiali saluti - Rands in Repose non è un brutto sito per maggiori informazioni interne agli sviluppatori, ma spesso può usare metafore culturali presunte o brevi che potrebbero non essere universali per un estraneo ... non sono sicuro - L'ho letto solo con un punto di vista interno.

Se non sei realmente interessato a diventare un programmatore, leggere libri di programmazione potrebbe non essere il modo migliore per imparare a comunicare con i programmatori, poiché saranno pieni di cose di cui probabilmente non avrai bisogno.

Invece, ti suggerirei semplicemente di chiedere i termini che non capisci man mano che vengono fuori, o di scriverli se non è imperativo che tu ne conosca subito la definizione e di cercarli su Google in seguito. Spesso mentre impari il significato di una parola, ti imbatterai in parole correlate che non capisci e su cui puoi chiedere o anche quelle su Google.

Non dovrebbe volerci molto per essere al corrente della terminologia più comunemente usata per la tua situazione e per essere in grado di comunicare in modo efficace sia con il programmatore che con il cliente usando il loro linguaggio.

Personalmente preferisco scrivere i termini e cercarli io stesso in seguito, a meno che non sia necessario conoscere immediatamente il significato di qualcosa per svolgere il mio lavoro in modo efficace, tuttavia, come ha detto Shana in un commento qui sotto, se sei sincero sul fatto di non essere molto informato, ciò offre agli altri l'opportunità di usare parole che è più probabile che tu capisca e che probabilmente saranno più ricettivi alle domande rudimentali che potresti avere.

Ci sono alcune ottime risposte qui alla domanda (originale, specifica), ma come attualmente posta:

Cosa posso fare per comprendere meglio i concetti più comuni di un'altra professione in modo che io può comunicare e lavorare in modo più efficace con professionisti e colleghi di quel campo, senza effettivamente imparare la loro professione?

Suggerirei che questo è un esempio di una situazione più ampia che ho spesso incontrato, e non solo nell'industria del software. Dal mio punto di vista, l'obiettivo del PO è creare un team multidisciplinare efficace nel più breve tempo possibile.

La chiave gli ostacoli a questo di solito sono la comprensione dei processi di flusso di lavoro utilizzati dalle altre professioni, così come il gergo utilizzato.

Tende ad essere molto più difficile quando si ha a che fare con aree distinte e separate, ma un "profano" lo vedrebbe allo stesso modo, ad esempio geologia e geofisica, forse come parte della necessità di un l'identità può nascere quando le persone vengono prima addestrate.

Ho risolto questo problema in diversi modi (come membro del team, leader e manager) e mentre l'autoeducazione (tramite libri, video, blog, articoli) e le discussioni individuali hanno fatto la loro parte, abbiamo anche messo in gioco altre cose chiave a cui vale la pena riflettere.

• abbiamo un Wiki interno che viene utilizzato per definire il gergo, la terminologia, i flussi di lavoro e il processo . Fa parte di rendere solido ciò che facciamo, ma è un ottimo punto di partenza.
• inviamo persone a corsi di formazione (formali) (un'introduzione a XXX)
• abbiamo occasionali , brevi presentazioni su come / perché le persone lavorano in determinati modi

Per team piccoli, agili (nel senso non di codifica!) che fanno affidamento su esperti tecnici che lavorano bene insieme, questi approcci possono aiuta a ridurre il tempo della curva di apprendimento.

Suggerirei, tuttavia, che tutte le "fazioni" della squadra debbano incontrarsi a metà affinché ciò sia efficace.

Da un punto di vista organizzativo può essere utile ottenere il consenso della direzione, soprattutto se sono necessari formazione o tempo "overhead". Questa può essere una sfida, tuttavia si spera che vedranno la necessità di essere in grado di creare un gruppo multidisciplinare efficace, solido e scalabile.

Anche se ci sono molti buoni libri sullo sviluppo, una delle migliori serie di libri che abbia mai visto per portare principianti e persone semplicemente interessate allo sviluppo fino ad accelerare il gergo e imparare un po 'di sviluppo è la serie Head First di O'Reily.

Di seguito ho incluso alcuni dei miei preferiti da condividere con gli studenti

1. Head First Design Patterns - Ottimo per le basi dell'apprendimento di Design Patterns che gli sviluppatori usano sempre
2. Head First Software Development - Inizia qui per una grande panoramica del processo di sviluppo del software e del gergo
3. Head First Programming - Questa è una guida per studenti e utilizza Python, ma è anche un ottimo punto di partenza
4. Head First Object Oriented Design and Analysis - Ottimo per una comprensione più approfondita di queste tecniche che spesso emergono quando si lavora con gli sviluppatori

Ora so che la serie di libri potrebbe sembrare un po 'stupida all'inizio, ma credetemi, sono efficaci e un effettivamente divertente da leggere. Se dovessi scegliere prima che tu inizi con uno, il libro sullo sviluppo del software o uno sulla programmazione solo per ottenere il gergo e il processo giusti quando lavori con il tuo sviluppatore.

Spero che questo aiuti.

Se ho ragione, allora credo che non scriverai codici lunghi per il progetto. Il tuo obiettivo principale è coordinarti di volta in volta con sviluppatori esperti.

• È un grande progetto come hai menzionato, quindi presumo che debba andare dal punto di vista del modulo, cioè l'intero progetto è diviso in diversi moduli che devono essere consegnati in tempo.
• La programmazione non è altro che rompere la complessità dei problemi del mondo reale nello stile del codice.
• Cerca di capire ogni modulo e su quale base il progetto è suddiviso in diversi moduli.
• Pensa logicamente perché un modulo è consumare tempo durante le fasi di sviluppo.
• Coordinarsi con il team e cercare di coordinarsi con ogni membro e ascoltare ciò che suggerisce il proprio compagno di squadra.
• Chiedere onestamente l'ostacolo potrebbero dover affrontare durante il processo di sviluppo.
• Se pensi che qualcuno abbia bisogno di guida / supporto per il compito che i giovani considerano a livello personale non è un compito importante, prova il membro anziano in collaborazione con il membro per migliorare la produttività e ridurre le tempistiche.

Per i contatti tecnici puoi seguire alcuni buoni libri Ruby / Python o anche Alcuni corsi online sono presenti anche sul web. Controlla anche http://codeacademy.com/ -> buono per iniziare. Puoi wiki anche del testo come questo sullo sviluppo Agile Sviluppo Agile

Credo che questi punti non solo ti aiuteranno nel progetto recente, ma ti aiuteranno anche durante altri progetti anche gestioni.

Risposta breve: chiedi al tuo college programmatore di questi argomenti che potresti chiederti. Spero che tu abbia un ambiente amichevole e sarà più che felice di indirizzarti su una fonte giusta.

Oltre al classico libro "Code Complete", consiglio vivamente di considerare il - Fatti e errori dell'ingegneria del software . Quei libri sono una specie di rivelazione e contengono una serie di fatti veri comprovati da statistiche e ricerche.

La pratica della creazione di software è una tecnologia "new kid on the block". Anche se potrebbe non sembrare così per coloro che sono stati sul campo per la maggior parte delle loro carriere, nello schema generale delle professioni, i costruttori di software sono relativi "neofiti". Nella breve storia del campo del software, sono stati identificati molti fatti e sono stati promulgati molti errori. Questi fatti e errori sono ciò di cui tratta questo libro.

Tuttavia, a seconda dei requisiti dell'applicazione su cui lavoreresti, potresti anche aver bisogno di ottenere un framework / linguaggio specifico libro.

Vorrei costruire un migliore apprezzamento del mestiere del programmatore, al fine di migliorare la comunicazione con il mio programmatore, così come il cliente.

Dai un'occhiata se c'è ci sono code camp nella tua zona dove gli sviluppatori si riuniranno e costruiranno cose durante il camp che potrebbero essere piuttosto illuminanti. Potrebbero esserci anche gruppi di utenti o Meetup in cui gli sviluppatori potrebbero riunirsi che potrebbero essere utili per socializzare con altri sviluppatori per avere un'idea migliore di loro e provare a fare generalizzazioni in una certa misura, anche se bisogna stare attenti alla dipendenza da generalità non è universalmente applicabile.

Cosa posso fare per comprendere meglio i concetti più comuni di un'altra professione in modo da poter comunicare e lavorare in modo più efficace con professionisti e colleghi di quel campo, senza effettivamente imparare il loro professione?

Potresti esaminare l ' SDLC che può aiutare con i grandi pezzi dei progetti IT anche se sarei più tentato di suggerire di essere consapevole dei termini gergali e poi parlarne in un contesto sociale in modo da poter capire cosa significano. Kludge, hack e patch sarebbero solo alcune parole che immagino possano essere facilmente interpretate male se non si conosce il contesto di come vengono utilizzate. La chiave qui sarebbe raccogliere il gergo utilizzato che può o non può essere facilmente conosciuto. Un altro percorso è considerare la ricerca di varie aziende all'interno della tua specializzazione, oltre a conoscere una serie di acronimi.

Non sottovalutare il valore di parlare solo con il tuo collega programmatore.

I libri vanno bene, ma il tuo obiettivo qui è migliorare la tua capacità di comunicare con il tuo partner. Considera il miglioramento del tuo rapporto se dimostri esplicitamente il desiderio di saperne di più su quello che fa.

Oltre alla tua esperienza di apprendimento, aiuterà il tuo programmatore a sentirsi come un partner prezioso e, si spera, li incoraggerà a saperne di più su ciò che tu fai, in natura.

I suggerimenti sui libri sopra sono fantastici e puoi imparare da loro ... ma non dimenticare di parlare anche alle persone!

Oltre agli altri suggerimenti di libri, consiglierei Designing from Both Sides of the Screen: How Designer and Engineers Can Collaborate to Build Cooperative Technology, che descrive il progresso di un (immaginario) progetto software dal punto di vista di un progettista UX (Ellen Isaacs) e del suo sviluppatore (Alan Walendowski), delle sfide che incontrano e dei compromessi che fanno perché devono lavorare insieme verso l'obiettivo comune.

Come programmatore, ho osservato che il motivo per cui la comunicazione è tesa con i non programmatori è abbastanza semplice.

I programmatori devono pensare in modo molto, molto preciso. La pensano in questo modo perché hanno bisogno di essere in grado di comunicare a un computer come operare e richiedono istruzioni molto precise.

La maggior parte delle persone non pensa o comunica in questo modo.

Ad esempio, un addetto alle vendite potrebbe suggerire: "Sai cosa aiuterebbe, un nuovo strumento per generare lead!"

Il ragazzo dell'interfaccia utente pensa: "Assomiglierà a questo ", senza una determinata quantità di precisione. Si affiderà molto al suo istinto creativo / artistico e, se è valido, i principi di sound design con un corpo di ricerca e dati supportati.

Il programmatore penserà: "Come verranno generati i lead? Come devono essere archiviati? Come devono essere presentati? E ​​la sicurezza? Che tipo di sicurezza? Crittografia a livello di trasporto semplice o crittografia dei dati? Che tipo di crittografia? Che tipo di modalità di crittografia a blocchi? " etc etc etc

I programmatori devono pensare in questo modo perché devono costruire la cosa da zero. È come un falegname che deve pensare al tipo giusto di viti da usare o alle ordinanze cittadine mentre i laici si relazionano con loro in generale, come semplicemente volere una casa.