Wie kann ich lernen, besser mit Kollegen aus einem anderen Beruf zu kommunizieren?

Sind Bücher überhaupt der richtige Weg, oder gibt es andere Möglichkeiten, wie ich mehr darüber lernen kann, wie ich am besten mit diesen Kollegen kommunizieren kann?

Die Art und Weise, wie Sie Ihren Ansatz ursprünglich beschreiben, stimmt mich etwas pessimistisch hinsichtlich seiner Machbarkeit. All das zu lernen, was man möglicherweise (oder auch nicht ) möglicherweise im Voraus benötigt, um ein besseres Verständnis für das Handwerk des Programmierers aufzubauen, könnte einfach zu viel Zeit in Anspruch nehmen.

• Softwarespezifikationen, Problemverfolgung, Schätztechniken, Designansätze und Entwicklungsmethoden, Funktions- und Regressionstests, technische Schulden und Wartungsüberlegungen usw. usw. – sich auf all dies einzulassen, könnte so sein, als würde man aus einem Wasserschlauch trinken.

Ich denke, die realistischere Art der Kommunikation mit Programmierern für einen Nicht-Programmierer, der nur die häufigsten Konzepte und Probleme beim Erstellen von Software verstehen möchte, sind normale 1:1-Gespräche .

Eine Referenz dazu finden Sie in den ausgezeichneten Artikeln The Update, The Vent, and The Disaster . Dieser Artikel wurde aus der Perspektive eines Entwicklerteam-Managers geschrieben, aber meiner Erfahrung nach funktionierte ein ähnlicher Ansatz auch in einer Zusammenarbeit zwischen einem Kunden/Designer und einem Programmierer, wie Sie ihn beschreiben.

... Ich behaupte nicht, dass jedes 1:1 eine gewundene Angelegenheit ist, um tief verborgene, aufkommende Katastrophen zu entdecken, aber Sie möchten einen wöchentlichen Ort schaffen, an dem Unzufriedenheit leise auftreten kann. Ein 1:1 ist Ihre Chance, wöchentliche vorbeugende Wartungsarbeiten durchzuführen und gleichzeitig den Zustand Ihres Teams zu verstehen.

...Der Klang, der eine erfolgreiche 1:1-Kur umgibt, ist Stille. Das gesamte Zuhören, Fragen und Diskutieren, das während eines 1:1-Gesprächs stattfindet, ist vorbeugende Wartung durch das Management. Sie werden sehen, wenn das Interesse an einem Projekt zu schwinden beginnt, und Maßnahmen ergreifen, bevor es zu Unzufriedenheit im Job wird. Sie hören von Spannungen zwischen zwei Mitarbeitern und moderieren eine Diskussion, bevor es in einer Besprechung zu einem Streitgespräch kommt. Ihre Belohnung für eine Kultur des gesunden 1:1 ist ein deutlicher Mangel an Drama.

• ^{Ein sehr starker Punkt des obigen Artikels ist, dass er in sich abgeschlossen ist, in dem Sinne, dass er neben der Erläuterung der Vorteile auch eine Reihe praktischer Empfehlungen enthält, die es einem im Grunde ermöglichen, mit dem Üben regelmäßiger 1: 1-Übungen zu beginnen, ohne in andere Quellen zu graben (obwohl nach zusätzliche Informationen schaden nicht, wissen Sie).}

Mit regelmäßigen Einzelgesprächen können Sie bestimmte Themen auswählen und sich darauf konzentrieren, die in jedem Moment von besonderer Bedeutung sind. Wenn Sie es richtig machen – wenn Sie sorgfältig sprechen, fragen und zuhören – haben Sie genug Zeit, um benötigte Ressourcen zu finden und zu studieren, ohne von unerwarteten Dringlichkeitsangelegenheiten unter Druck gesetzt zu werden: „Ihre Belohnung für eine Kultur des gesunden 1:1 ist ein deutlicher Mangel des Dramas" .

_{In Bezug auf Bücher, da Sie Code Complete erwähnt haben, kann man wahrscheinlich nichts falsch machen, wenn man es als allgemeine Referenz verwendet (hier spreche ich von der zweiten Ausgabe, die ich studiert habe). Es ist ein Meisterwerk, ein grundlegender und gut präsentierter Überblick über die professionelle Softwareentwicklung, der eine gründliche Analyse für jeden erdenklichen Bereich davon bietet. Da Sie es bereits haben, ziehen Sie es in Betracht, das Kapitel über kollaborative Entwicklungspraktiken zu überfliegen : Soweit ich mich erinnere, war es das überzeugendste von allem, was ich bisher zu diesen Themen gelesen habe.}

_{Code Complete ist eine wirklich tiefgründige Ressource, großartig für ein gründliches Studium - aber genau aus diesem Grund würde ich wirklich zögern, es jemandem zu empfehlen, der eine schnelle Einführung in die Konzepte der Softwareentwicklung benötigt. Für Letzteres würde ich lieber Facts and Fallacies of Software Engineering auswählen - ein kleines, leicht zu lesendes Buch. Die in jedem Abschnitt bereitgestellten Referenzen ermöglichen bei Bedarf ein tieferes Studium des Themas. Empfohlene Lektüre für diejenigen, die daran interessiert sind, Software richtig zu machen.}

Wie in anderen Antworten erwähnt, gibt es viele großartige Bücher. Aber uns um Empfehlungen zu bitten, ist nicht der beste Ansatz: Jedes Mal, wenn ich mehr über die Domäne eines Fachexperten erfahren musste, habe ich am meisten gewonnen, wenn ich diese Person um Empfehlungen gebeten habe . Sie und Ihre Kollegen sind Partner, die auf ein gemeinsames Ziel hinarbeiten, und es ist in ihrem besten Interesse, dass Sie mehr lernen, ohne Ihre Zeit mit Dingen zu verschwenden, die nicht hilfreich sind. Sie sind in der besten Position, um Sie zu führen.

Für die Kommunikation ist es wichtiger, die Lebensweise einer anderen Person oder Gruppe zu verstehen, als unbedingt die wichtigsten Punkte aller Schritte ihres Berufs zu kennen. Ich würde mich konzentrieren auf:

• Kriegsgeschichten – die Leute wollen sie nicht nur erzählen, sondern aufmerksames Zuhören wird Ihnen viel darüber sagen, wie sie ihre Arbeit sehen, in welchem ​​Umfeld sie arbeiten und was in ihrer Welt schwer oder leicht ist – alles wichtige Dinge, die Sie wissen sollten Zusammenarbeit. Plus, die PR-Seite – Leute mögen es, wenn man ihnen zuhört, und die Chance zu bekommen, einem neuen Typen ihre Kriegsgeschichten zu erzählen, und nachdenkliche Fragen zu bekommen, wird auch ein positives Gefühl Ihnen gegenüber erzeugen.

• Fachjargonfindung - Bei dieser Art von Arbeit gibt es eine TONNE Fachsprache. Tools, Sprachen, Prozesse, Methoden, Modelle und mehr – alle haben eindeutige Namen. Einige umfassen die Branche (setzen Sie ein J davor und es hat wahrscheinlich etwas mit Java zu tun), andere sind einzigartig für das Büro (wie der TPS-Bericht über Büroräume). Wenn ich hier hochfahren musste, ist Wikipedia meine erste Verteidigungslinie, gefolgt von der Frage nach Terminologiewörterbüchern und internen Websites, die Prozesse definieren.

• Insbesondere Code Complete ist eine interessante Lektüre, da es um das Geschäft einer guten Softwareentwicklung geht. Es kann eine nette Ressource dafür sein, da es eher um gute Möglichkeiten geht, Dinge zu tun, als um die Anleitung der Grundlagen der Sache. Eine Sache, auf die Sie achten sollten, ist, dass jede Softwaregruppe ihre eigenen Arbeitsweisen haben wird, die sich an Best Practices halten oder nicht. Seien Sie also vorsichtig, wenn Sie auf der Grundlage eines Buches wie diesem einseitige Annahmen treffen.

• Sprechen Sie mit dem Programmierer und Kunden - Manchmal ist es ein Nachteil, alles darüber zu wissen, wie jemand seine Arbeit macht. Der wichtige Teil ist sicherzustellen, dass Sie klar kommunizieren und ihnen die Möglichkeit geben, das zu tun, was sie tun, ohne durch Unwissenheit behindert zu werden. Sprechen Sie viel darüber, warum Sie tun möchten, was Sie tun möchten, fragen Sie nach Empfehlungen, bitten Sie um Feedback, ob Sie sich klar ausgedrückt haben, bitten Sie um eine Wiederholung Ihrer Anfrage oder bieten Sie dasselbe an - und fragen Sie warum, warum, warum.

• Bitten Sie darum, Zeuge der Arbeit zu werden – ich habe bei der Softwareentwicklung festgestellt, dass es einen Arbeitsstil und eine magische Chemie gibt, wie man in diesem Bereich arbeitet, die kein Buch zusammenfassen könnte. Die Nerd-Höhle ist ein Teil davon, aber es steckt noch mehr dahinter, und es kann sein, dass Sie nur, wenn Sie durch sie gehen, die wahren Schmerzpunkte und glorreichen Momente des Jobs erfahren. FYI - Rands in Repose ist keine schlechte Seite für mehr Entwickler-Insider-Informationen, aber er kann oft verkürzte oder angenommene kulturelle Metaphern verwenden, die für einen Außenstehenden möglicherweise nicht universell sind ... nicht sicher - ich habe ihn immer nur mit gelesen eine Insidersicht.

Wenn Sie nicht wirklich daran interessiert sind, Programmierer zu werden, ist das Lesen von Programmierbüchern möglicherweise nicht der beste Weg, um zu lernen, wie man mit Programmierern kommuniziert, da sie voll von Dingen sind, die Sie wahrscheinlich nicht brauchen werden.

Stattdessen würde ich vorschlagen, einfach nach Begriffen zu fragen, die Sie nicht verstehen, wenn sie auftauchen, oder sie aufzuschreiben, wenn es nicht unbedingt erforderlich ist, dass Sie die Definition sofort kennen, und sie später zu googeln. Während Sie die Bedeutung eines Wortes lernen, stoßen Sie oft auf verwandte Wörter, die Sie nicht verstehen, und können danach fragen oder diese ebenfalls googeln.

Es sollte nicht lange dauern, bis Sie sich mit der am häufigsten verwendeten Terminologie für Ihre Situation vertraut gemacht haben und in der Lage sind, sowohl mit dem Programmierer als auch mit dem Kunden in ihrer Sprache effektiv zu kommunizieren.

Persönlich ziehe ich es vor, Begriffe aufzuschreiben und sie später selbst nachzuschlagen, es sei denn, ich muss die Bedeutung von etwas sofort kennen, um meine Arbeit effektiv zu erledigen, aber wie Shana in einem Kommentar unten erwähnt hat, wenn Sie im Voraus sagen, dass Sie nicht sehr sachkundig sind , das gibt anderen die Möglichkeit, Wörter zu verwenden, die Sie mit größerer Wahrscheinlichkeit verstehen, und sie werden wahrscheinlich empfänglicher für grundlegende Fragen sein, die Sie möglicherweise haben.

Hier gibt es einige großartige Antworten auf die (ursprüngliche, spezifische) Frage, aber wie derzeit gestellt:

Was kann ich tun, um die gebräuchlichsten Konzepte aus einem anderen Beruf besser zu verstehen, damit ich effektiver mit Fachleuten und Kollegen aus diesem Bereich kommunizieren und zusammenarbeiten kann, ohne tatsächlich ihren Beruf zu lernen?

Ich würde vorschlagen, dass dies ein Beispiel für eine allgemeinere Situation ist, der ich häufig begegnet bin, und zwar nicht nur in der Softwarebranche. Aus meiner Sicht ist das Ziel des OP, in möglichst kurzer Zeit ein schlagkräftiges, multidisziplinäres Team zu bilden.

Die Haupthindernisse dafür sind normalerweise das Verständnis der Arbeitsabläufe der anderen Berufsgruppe sowie des verwendeten Jargons.

Es ist tendenziell viel schwieriger, mit Bereichen umzugehen, die unterschiedlich und getrennt sind, aber ein „Laie“ würde das Gleiche sehen – Geologie und Geophysik zum Beispiel – vielleicht als Teil der Notwendigkeit einer separaten Identität, die entstehen kann, wenn Menschen zuerst sind ausgebildet.

Ich habe dies auf verschiedene Weise gelöst (als Teammitglied, Leiter und Manager) und während Selbstbildung (über Bücher, Videos, Blogs, Artikel) und Einzelgespräche ihre Rolle gespielt haben, haben wir es getan auch einige andere wichtige Dinge ins Spiel bringen, über die es sich vielleicht lohnt nachzudenken.

• Wir haben ein internes Wiki, das verwendet wird, um Jargon, Terminologie, Arbeitsabläufe und Prozesse zu definieren. Es trägt dazu bei, das, was wir tun, robust zu machen, aber es ist ein großartiger Ausgangspunkt.
• wir schicken Leute zu (formalen) Schulungskursen (eine Einführung in XXX)
• Wir haben gelegentlich kurze Präsentationen darüber, wie/warum Menschen auf bestimmte Weise arbeiten

Für kleine, agile (im nicht codierenden Sinne!) Teams, die darauf angewiesen sind, dass technische Experten gut zusammenarbeiten, können diese Ansätze dazu beitragen, die Lernkurve etwas zu verkürzen.

Ich würde jedoch vorschlagen, dass sich alle „Fraktionen“ des Teams in der Mitte treffen müssen, damit dies effektiv ist.

Aus organisatorischer Sicht kann es sinnvoll sein, die Unterstützung des Managements zu erhalten, insbesondere wenn Schulungen oder „Overhead“-Zeiten erforderlich sind. Dies kann eine Herausforderung sein, aber hoffentlich werden sie die Notwendigkeit erkennen, eine effektive, robuste und skalierbare multidisziplinäre Gruppe zu schaffen.

Während es viele gute Bücher über Entwicklung gibt, ist die Head First-Reihe von O'Reily eine der besten Buchreihen, die ich je gesehen habe, um Anfänger und Leute, die sich nur für Entwicklung interessieren, mit dem Jargon vertraut zu machen und tatsächlich ein wenig über Entwicklung zu lernen .

Ich habe unten einige meiner Favoriten aufgeführt, die ich mit den Lernenden teilen kann

1. Head First Design Patterns - Ideal zum Erlernen der Grundlagen von Design Patterns, die Entwickler ständig verwenden
2. Softwareentwicklung von Kopf bis Fuß – Beginnen Sie hier, um einen großartigen Überblick über den Softwareentwicklungsprozess und die Fachsprache zu erhalten
3. Head First Programming - Dies ist ein Leitfaden für Lernende und verwendet Python, aber es ist auch ein großartiger Ausgangspunkt
4. Objektorientiertes Design und Analyse von Kopf bis Fuß - Ideal für ein tieferes Verständnis dieser Techniken, die häufig bei der Arbeit mit Entwicklern auftauchen

Jetzt weiß ich, dass die Buchreihe auf den ersten Blick vielleicht ein bisschen kitschig aussieht, aber glauben Sie mir, sie ist effektiv und macht Spaß zu lesen. Wenn ich mich für Sie entscheiden müsste, zuerst mit einem Buch zu beginnen, entweder das Softwareentwicklungsbuch oder das Programmierbuch, nur um die richtige Fachsprache und den richtigen Prozess bei der Arbeit mit Ihrem Entwickler zu verstehen.

Ich hoffe das hilft.

Wenn ich richtig liege, dann glaube ich, dass Sie keine langen Codes für das Projekt schreiben werden. Ihr Hauptziel ist es, sich von Zeit zu Zeit mit den erfahrenen Entwicklern abzustimmen.

• Es ist ein großes Projekt, wie Sie erwähnt haben, also gehe ich davon aus, dass es modulweise gehen muss, dh das gesamte Projekt ist in verschiedene Module unterteilt, die pünktlich geliefert werden müssen.
• Programmieren ist nichts anderes, als die Komplexität realer Probleme im Codestil zu brechen.
• Versuchen Sie, jedes Modul zu verstehen und auf welcher Grundlage das Projekt in verschiedene Module unterteilt ist.
• Überlegen Sie logisch, warum ein Modul während der Entwicklungsphasen Zeit in Anspruch nimmt.
• Koordinieren Sie sich mit dem Team und versuchen Sie, sich mit jedem Mitglied abzustimmen, und hören Sie vor allem zu, was Ihr Teamkollege vorschlägt.
• Fragen Sie sie ehrlich nach den Hindernissen, denen sie während des Entwicklungsprozesses begegnen könnten.
• Wenn Sie der Meinung sind, dass jemand Anleitung/Unterstützung für die Aufgabe benötigt, von der Sie denken, dass sie auf Ihrer persönlichen Ebene keine große ist, versuchen Sie, dass das Senior-Mitglied mit dem Mitglied zusammenarbeitet, um die Produktivität zu steigern und die Zeitpläne zu verkürzen.

Für die technischen Hinweise können Sie einige gute Ruby/Python-Bücher lesen oder sogar einige Online-Kurse über das Internet anbieten. Überprüfen Sie http://codeacademy.com/ -> gut, um ebenfalls zu beginnen. Sie können auch einen Text wie diesen über die agile Entwicklung agile Entwicklung wiki

Ich glaube, diese Punkte werden Ihnen nicht nur beim aktuellen Projekt helfen, sondern auch bei anderen Projektmanagements.

Kurze Antwort: Fragen Sie Ihre Programmiererschule nach diesen Themen, die Sie vielleicht fragen. Ich hoffe, Sie haben eine freundliche Umgebung und er wird Sie gerne auf die richtige Quelle verweisen.

Zusätzlich zum klassischen Buch "Code Complete" würde ich dringend empfehlen, die - Fakten und Irrtümer der Softwaretechnik zu berücksichtigen . Dieses Buch ist eine Art Offenbarung und enthält eine Reihe wahrer Fakten, die durch Statistiken und Forschungen bewiesen wurden.

Das Erstellen von Software ist eine „New Kid on the Block“-Technologie. Auch wenn es für diejenigen, die den größten Teil ihrer Karriere in diesem Bereich verbracht haben, nicht so erscheinen mag, sind Softwareentwickler im Gesamtschema der Berufe relative „Neulinge“. In der kurzen Geschichte des Softwarebereichs wurden viele Fakten identifiziert und viele Irrtümer verbreitet. Um diese Fakten und Irrtümer geht es in diesem Buch.

Abhängig von den Anforderungen der Anwendung, an der Sie arbeiten würden, müssen Sie sich jedoch möglicherweise auch ein Framework-/sprachspezifisches Buch besorgen.

Ich möchte ein besseres Verständnis für das Handwerk des Programmierers aufbauen, um die Kommunikation mit meinem Programmierer sowie dem Kunden zu verbessern.

Schauen Sie nach, ob es Code Camps in Ihrer Nähe gibt, bei denen Entwickler zusammenkommen und während des Camps Dinge bauen, die sehr aufschlussreich sein könnten. Es kann auch Benutzergruppen oder Meetups geben, in denen sich Entwickler treffen können, was nützlich sein kann, um mit anderen Entwicklern in Kontakt zu treten, um ein besseres Gefühl für sie zu bekommen und zu versuchen, bis zu einem gewissen Grad Verallgemeinerungen vorzunehmen, obwohl man vorsichtig sein muss, wenn es um die Abhängigkeit von Allgemeingültigkeiten geht nicht universell anwendbar.

Was kann ich tun, um die gebräuchlichsten Konzepte aus einem anderen Beruf besser zu verstehen, damit ich effektiver mit Fachleuten und Kollegen aus diesem Bereich kommunizieren und zusammenarbeiten kann, ohne tatsächlich ihren Beruf zu lernen?

Sie könnten sich das SDLC ansehen , das bei großen IT-Projekten hilfreich sein kann, obwohl ich eher versucht wäre, vorzuschlagen, sich der Slang-Begriffe bewusst zu sein und dann in einem sozialen Umfeld darüber zu sprechen, damit Sie verstehen, was sie bedeuten. Kludge, Hack und Patch wären nur ein paar Wörter, von denen ich mir vorstellen könnte, dass sie leicht falsch interpretiert werden könnten, wenn man den Kontext ihrer Verwendung nicht kennt. Der Schlüssel hier wäre, den verwendeten Jargon aufzugreifen, der leicht bekannt sein kann oder nicht. Eine andere Möglichkeit besteht darin, verschiedene Unternehmen innerhalb Ihrer Spezialisierung zu recherchieren und eine Reihe von Akronymen zu kennen.

Unterschätzen Sie nicht den Wert, einfach mit Ihrem Programmiererkollegen zu sprechen.

Bücher sind in Ordnung, aber Ihr Ziel hier ist es, Ihre Fähigkeit zu verbessern, mit Ihrem Partner zu kommunizieren. Betrachten Sie die Verbesserung Ihres Verhältnisses, wenn Sie ausdrücklich den Wunsch zeigen, mehr darüber zu erfahren, was er oder sie tut.

Zusätzlich zu Ihrer Lernerfahrung hilft es Ihrem Programmierer, sich als wertvoller Partner zu fühlen, und ermutigt ihn hoffentlich dazu, mehr über Ihre Arbeit zu erfahren .

Die obigen Buchvorschläge sind großartig und Sie können daraus lernen ... vergessen Sie nur nicht, auch mit Menschen zu sprechen!

Zusätzlich zu den anderen Buchvorschlägen empfehle ich Designing from Both Sides of the Screen: How Designers and Engineers Can Collaborate to Build Cooperative Technology , das den Fortschritt eines (fiktiven) Softwareprojekts aus der Sicht eines UX-Designers beschreibt (Ellen Isaacs) und seinem Entwickler (Alan Walendowski), die Herausforderungen, denen sie begegnen, und die Kompromisse, die sie eingehen, wenn sie zusammenarbeiten müssen, um das gemeinsame Ziel zu erreichen.

Als Programmierer habe ich beobachtet, dass der Grund für die angespannte Kommunikation mit Nicht-Programmierern ganz einfach ist.

Programmierer müssen sehr, sehr genau denken. Sie denken so, weil sie in der Lage sein müssen, einem Computer zu kommunizieren, wie er funktioniert, und sie benötigen sehr genaue Anweisungen.

Die meisten Menschen denken oder kommunizieren nicht auf diese Weise.

Beispielsweise könnte jemand im Vertrieb vorschlagen: "Sie wissen, was helfen würde, ein neues Tool zur Generierung von Leads!"

Der UI-Typ denkt: "So wird es aussehen", ohne ein bestimmtes Maß an Präzision. Er wird sich sehr auf seinen kreativen/künstlerischen Instinkt verlassen, und wenn er überhaupt gut ist, auf solide Designprinzipien mit einem fundierten Fundus an Forschung und Daten.

Der Programmierer wird denken: „Wie werden Leads generiert? Wie sollten sie gespeichert werden? Wie sollten sie präsentiert werden? Was ist mit der Sicherheit? Welche Art von Sicherheit? Einfache Transportschichtverschlüsselung oder Datenverschlüsselung? Welche Art von Verschlüsselung? Welche Art von Block Verschlüsselungsmodus?" usw usw usw

Programmierer müssen so denken, weil sie das Ding von Grund auf neu aufbauen müssen. Es ist wie ein Zimmermann, der sich Gedanken über die richtigen Schrauben oder über städtische Verordnungen machen muss, während sich Laien auf allgemeine Dinge wie den Wunsch nach einem Haus beziehen.