Ich möchte die Situationen vermeiden, in denen meine Entwickler das gemeinsame Wissen (Lösungen für die aufgetretenen Probleme, coole Tipps, häufige Fehler, Verknüpfungen zum Erreichen bestimmter Ziele, Konfigurationsprobleme, Teilanforderungen usw.) nicht miteinander teilen . Ich nehme die Situation in Betracht, wenn ein solcher Kommunikationsmangel zufällig ist (ein Ergebnis von Missverständnissen oder unangemessenem Management) - ich denke nicht über Situationen nach, in denen Entwickler das Wissen bewusst für sich behalten.
Ich glaube, dass die folgenden Techniken äußerst nützlich sind, um den Informationsfluss innerhalb des Entwicklerteams zu verbessern:
Irgendwelche weiteren Ideen? Welche Techniken verwenden Sie (oder haben Sie) in Ihrem Unternehmen? Wie würden Sie Entwickler ermutigen, das Wissen untereinander zu teilen?
Ich werde ein paar mehr hinzufügen
Ein internes twitter-ähnliches Dienstprogramm. Vielleicht ein Wiki, wenn du es zur Arbeit bringen kannst, ich persönlich finde es ein bisschen zu viel. Aber Twitter ist anders. "habe gerade eine Erweiterungs-Methode hinzugefügt, um einer Like-Klausel in einem Zeilenfilter zu entkommen" und solche Sachen.
Manche Leute mögen es ein wenig aufdringlich finden, aber einen gemeinsamen Ort für Dienstprogramme, damit Sie wissen, wo Sie suchen und string.CountOccurrences nicht in der Codebasis verstreut ist.
Vertrauen.
Sie dürfen "dumm" erscheinen, aber bitte fragen , wenn Sie nicht wissen oder nicht ganz verstehen, was ich sage. Und bitte sag mir, wenn ich falsch liege (ich habe es nicht bemerkt, weil ich genauso dumm bin.)
Noch ein paar Dinge:
Muster & amp; Practices Meetings - Diese müssen nicht jede Woche sein, aber es sollte etwas Zeit darauf verwendet werden, wo das Team verschiedene offene Fragen diskutieren kann und einen Konsens für Dinge hat, die vielen Leuten Kopfschmerzen ersparen können.
Kulturfaktor - Bietet der Arbeitsplatz genug Sozialisation, um dem Team zu helfen, oder könnten einige Teambildungsübungen, z. ein Hindernisparcours oder Kochen zusammen, nützlich sein, um etwas Dynamik zu etablieren. Gibt es eine Demut unter den Entwicklern, so dass es keine großen Egos gibt, die ein Problem sein können? Ein weiterer Faktor hier ist, darüber nachzudenken, wie du das beantworten würdest: Würdest du in eine lokale Kneipe gehen und mit deinen Teamkollegen etwas trinken gehen? Wenn ja, dann haben Sie hier ein paar gute Punkte, wenn nicht, dann könnte es hier eine Untersuchung geben.
Retrospektive Nachbereitung - Wie werden Ideen in Retrospektiven betrachtet und umgesetzt? Wie werden Meetings im Allgemeinen behandelt?
Demos innerhalb des Teams - Wenn eine Story fertig ist und einige große Codepunkte enthält, dann sollte es vielleicht eine kleine Demonstration für das Team geben, um zu sehen, was getan wurde und anderen zu zeigen, was getan wurde dass das Wissen verbreitet wird. Dies kann mit meinem ersten Punkt in Bezug auf etwas, das zur weiteren Kommunikation beiträgt, in Einklang gebracht werden.
Ich bin ein großer Befürworter des Arbeitens in Paaren. Es ist ein guter Weg, Wissen zu vermitteln und Kommunikationswege offen zu halten. Versuchen Sie auch, die Paare für jedes Projekt zu mischen.
Wenn Sie ein Team haben, das ausreichend klein ist und SVN commit Kommentare verwendet, und ein Tool ausnutzt, das einen RSS-Feed generiert (wie Trac zum Beispiel), kann dies eine einfache und effiziente Art der Kommunikation sein.
Dafür gibt es mehrere Voraussetzungen, die ganz einfach zu erreichen sind: - sich häufig verpflichten (das ist an sich gut, da es jedem ermöglicht, von den lokalen Änderungen jedes Programmierers zu profitieren und Probleme frühzeitig zu erkennen); - Verwenden Sie ausführliche Kommentare (was gut ist, da es leichter nachvollziehen lässt, was geändert wurde, falls etwas zusammenbricht); - Stellen Sie sicher, dass alle Nutzer die Feeds lesen (besser noch, über einen RSS-Reader informiert).
Natürlich gibt es keine Möglichkeit, auf solche Kommentare "zu antworten", aber wenn jemand wirklich antworten muss, ist es wahrscheinlich zwischen dieser Person und dem Committer, also ist Mail in der Regel genug.
Ein anderes nützliches Werkzeug ist es, jeden Entwickler zu bitten, sagen wir einmal pro Woche, eine ungefähre Liste von 10 Empfehlungen für andere Programmierer zu einem Thema zu schreiben, mit dem er / sie wirklich vertraut ist.
Zeit.
Wenn du aus deinem staubigen Büro gehst, um deine Gedanken zu klären, dir wirklich die Zeit zu nehmen, zu einem Vortrag oder einer Schulung zu gehen, hilft das alles, Wissen zu verbreiten.
Es ist auch einfach zu budgetieren: N Entwickler gehen für T Stunden zu treffen.
"On the Job" Training ... Die Dinge, die Sie für Ihre spezifische Arbeit brauchen, können nur von jemandem gelernt werden, der den Job kennt.
Im aktuellen Klima, unter dem gegenwärtigen Druck (muss jetzt versenden), braucht niemand Zeit, um etwas vollständig zu erklären. Nur wenn die Leute entspannt sind, sind sie bereit für den Informationsaustausch. Die Leute sind entspannt, wenn sie genug Zeit haben.
Abgesehen davon müssen Sie auf einen bestimmten Linker-Fehler stoßen, bevor Sie wirklich anfangen darüber nachzudenken. Ohne die Zeit zu denken, zu fragen, zu lesen, wirst du nicht in der Lage sein, das Wissen zu bekommen. Du kannst es nicht auf ein offizielles Linker-Training verschieben.
Viel schwerer zu budgetieren: Entwicklerin Mary hat die Entwicklerin Sophie über anderthalb Stunden über dynamische Verbindungen gefragt. Am nächsten Tag ging sie mit einigen Fragen zurück. Erfahrene Entwickler verbringen mehr Zeit mit dem Verteilen, während jüngere mehr Zeit zum Lernen benötigen.
Ich habe viele Ansätze ausprobiert und bin ein großer Fan, wenn ich paarweise an Projekten arbeite und regelmäßige Diskussionen oder Treffen mit dem Team mache.
Ich habe aber auch festgestellt, dass das Beste, was ich tun kann, darin besteht, eine Kultur der ständigen Kommunikation zwischen den Entwicklern zu fördern. Ich versuche alle meine Entwickler miteinander kommunizieren zu lassen, während sie arbeiten - nicht einmal bis zu einem wöchentlichen oder monatlichen Treffen.
Für mich ist das ein wenig komplizierter, da die meisten meiner Entwickler nicht am gleichen Ort sind. Daher haben wir einen einzigen XMPP-Chatroom-Setup, und wir alle sind immer eingeloggt, wenn wir an dem Projekt arbeiten. Einige der Entwickler (einschließlich mir) werden sich auch während unserer Bürozeiten einloggen.
Ich mache das gleiche mit den Leuten in meinem Büro - wir neigen dazu, ein ziemlich ruhiger Haufen zu sein, aber ich bin sehr offen dafür, dass Leute sich gegenseitig mit Fragen unterbrechen oder sich einen Stuhl nehmen und sich jederzeit zu einem Brainstorming hinsetzen .Ein Teil der Gründe dafür ist, dass ich versuche, die Kommunikation nicht auf die Arbeit oder ein bestimmtes Projekt zu beschränken. Mein Gefühl ist, dass die Leute über andere, nicht arbeitsbezogene Dinge reden werden, ob ich das nun fördere oder nicht. Ich würde den "Wasserkühler" lieber in einem offiziellen Kanal sprechen lassen, als draußen.
Damit fühlen sich alle wohler, die Fragen zu stellen, die "offensichtlich" erscheinen. Außerdem stellen die Leute ständig Fragen, da sie genau dort sind und gewohnt sind, mit jedem zu reden. Es ist leicht zu ignorieren, wenn es nötig ist, aber es ist auch viel einfacher, einfach eine allgemeine Frage zu stellen und zu sehen, ob jemand Ideen hat, ohne sich wie ein Schmerz zu fühlen, usw.
Meine Erfahrung ist, dass die Zeit, die durch die Unterbrechung verloren geht, viel kleiner ist als die Zeit, die gespart wird, weil eine Gruppe immer bereit ist, ein Problem zu lösen.
Sozialisierung und gemeinsames Ziel fördern immer den Austausch von Informationen.
Ich arbeitete in einer Firma, wo wir jeden Freitag Mittagstreffen für Entwickler hatten. Das Management würde Essen bereitstellen, während die Entwickler ihr Wissen teilen mussten. Präsentieren Sie ein Werkzeug oder eine Technik, die Sie kürzlich gelernt haben, oder geben Sie eine Demo eines Projekts, an dem Sie gerade arbeiten, usw. Es war nicht auf die Technologien beschränkt, die das Team zu dieser Zeit nutzte, die Entwickler wurden ermutigt, neue Technologien zu lernen und dem Team eine Demo zu geben.
Und bei meiner jetzigen Arbeit haben wir monatliche IT-Gruppentreffen, bei denen Entwickler von verschiedenen Teams manchmal die Projekte vorführen, an denen sie gearbeitet haben.