Ich arbeite in einem mittelgroßen Team (mehr als 20 Entwickler), bei dem die Kommunikation zwischen den Teammitgliedern meiner Meinung nach nicht so gut ist wie möglich.
Wie die meisten Teams haben wir wahrscheinlich mehrere Systeme, die wir bauen und warten. Wir verwenden in unserer Arbeit auch Dutzende verschiedener Werkzeuge wie Visual Studio 2008, Subversion, Resharper, Tibco, TeamCity etc.
Wir entwickeln auch mit einer "Agile" -Methode ... und ich ziehe das in Anführungszeichen, da es mehr wie "Rush, um diese Funktion in so schnell wie möglich zu bekommen ... ... Wir werden die Spezifikation für Sie in etwa einer Woche haben. ... fangen Sie jetzt an, daran zu arbeiten, aber stellen Sie sicher, dass Sie das Gerät testen und den Code von jemandem überprüfen lassen. "
Aus diesem Grund haben wir Systeme, die schlecht entworfen sind und daher schwierig zu warten sind. Daher enden wir mit einer Handvoll Menschen als "Gurus", die mit den von ihnen geschaffenen Systemen vertraut sind.
>Außerdem müssen wir aufgrund der Geschwindigkeit der IT-Branche im Allgemeinen neue Technologien und die neuesten Versionen der von uns entwickelten Tools verwenden.
Mein Punkt ist nicht, sich zu beschweren und zu sagen: "Oh, wehe, mir sind die Dinge schwer". eher meine Sorge ist, dass wenn unser Team besser kommuniziert, wir in dieser Spur stecken bleiben werden.
Lassen Sie mich versuchen zu erklären, was ich meine, indem ich ein bisschen besser kommuniziere ...
Vor kurzem haben wir gerade von VS2005 auf VS2008 umgestellt ... was in meinen Augen großartig ist, weil ich gerne mit der neuesten Technologie arbeite. Und wir sind auch von CruiseControl.Net zu TeamCity gewechselt ... was gut und gut ist.
... aber ... wir haben nie wirklich etwas über VS2008 oder die neuen Features von C # 3.0 gelernt ... und nicht einmal ein Memo über TeamCity ... Als IT-Leute scheinen wir uns anzupassen und zu erwarten lerne wie wir gehen.
Jetzt kann ich das natürlich herausfinden, indem ich Blogs lese und den neuesten Nachrichten über die Werkzeuge, die ich benutze, folge ... was ich tue ... aber die Praxis des kontinuierlichen Lernens wird nicht wirklich von jedem auf der Welt praktiziert so dass Sie am Ende mit Leuten arbeiten, die neue Funktionen nutzen, ohne sie wirklich zu verstehen ...
Außerdem wurde unser Team vor kurzem damit beauftragt, Code-Reviews zu erstellen ... aber ohne Anleitung, was das wirklich bedeutet .... im Moment bedeutet es nur, dass Sie Ihren Code jemandem geben ... über das Team und lassen Sie sich Ihren Code ansehen ... ob für zwei Sekunden oder zwei Stunden ist es nicht wirklich gut etabliert oder einheitlich über das Team .... wenn sie überhaupt überhaupt gemacht werden ...
Dasselbe gilt für das Schreiben von Komponententests ... wir wurden ermutigt, sie zu schreiben ... aber es wurde nicht wirklich im Team kommuniziert, was der beste Weg ist, sie zu schreiben ... also versuchen einige Entwickler zu schreiben Sie finden es schwierig und schreiben entweder schlechte Unit Tests oder geben auf und entscheiden Unit Tests sind eine schlechte Idee ...
Die Idee, die ich zur Verbesserung der Situation entwickelt habe, besteht darin, eine Reihe von Treffen als ein Entwicklerforum zu organisieren ... in diesen Sitzungen würde ein anderes Mitglied ein anderes Thema vorstellen, dem die restliche Zeit gewidmet ist Diskussion unter den Entwicklern.
Eine Woche lang könnte das Thema ein fortgeschrittenes neues Feature von C # und den empfohlenen Best Practices dafür sein .... und das nächste könnte über Code Reviews sein und worauf sollte man achten ... während das nächste eine Einführung sein könnte ein obskures Altsystem ..... die Diskussionen könnten dann von den Entwicklern benutzt werden, um ihre Erfahrungen und Probleme zu teilen. Letztendlich wäre es das Ziel, einen Ort zu haben, an dem Ideen und Informationen frei zwischen den Entwicklern ausgetauscht werden können.
Ich habe das Buy-in von meinen Managern und einigen meiner Mitentwickler bekommen, um etwas in Gang zu bringen ... aber mir wurde gesagt, dass eine solche Idee schon einmal ausprobiert wurde und schließlich ausstarb.
Ich möchte, dass diese Idee Erfolg hat und nicht etwas ist, das ich ganz alleine durchsetzen werde, nur um es sterben zu lassen, wenn ich schließlich von dieser Gesellschaft wegkomme.
Wie kann ich mein Team ermutigen, besser zu kommunizieren? Klingt meine Idee eines Entwicklerforums nach einer guten Idee? Was kann ich tun, um ein Aussterben zu verhindern?
Gibt es etwas Besseres, das ich stattdessen tun kann, worüber ich nicht nachdenke?
Mehr als nur eine Reihe von Treffen zu beginnen ... Wie kann ich mein Team ermutigen und beeinflussen, damit es als Team auftritt? Ich genieße meinen Job sehr und glaube, dass ich mit einer exzellenten Gruppe von Entwicklern zusammenarbeite ... aber ich möchte auch wirklich das Team in einem Bereich bereichern, den ich im Moment etwas vermisse. Wie mache ich das effektiv?
Es klingt für mich so, als ob Ihrem Team eine technische Führung fehlt.
Diese Person würde sich vom Management leiten lassen und es in praktische Schritte umwandeln, die der Rest des Teams nutzen kann.
Zum Beispiel:
Sie erwähnen, dass Sie zahlreiche Produkte in Ihrem Team verwenden und diese manchmal aktualisieren, ohne dass dem Team Notizen oder Schulungen gegeben werden.
Der technische Leiter würde die Produkte und deren Verwendung im Idealfall in einem Wiki dokumentieren, damit andere dazu beitragen können und Erfahrungen mit dem neuen Produkt haben, so dass sie jedem bei Bedarf helfen können.
Der technische Leiter würde auch Anleitung geben, sei es eine E-Mail, ein Dokument, ein Wiki-Artikel usw., wie das neue Produkt zu verwenden ist.
Diese Person würde eine Anleitung zur Durchführung von Codeüberprüfungen geben, nachdem sie sich mit dem Management, leitenden Entwicklern usw. getroffen hat.
Bei neuen Entwicklungen oder großen Feature-Anfragen wäre der technische Leiter an der Gestaltung beteiligt, so dass ein Peer-Review stattfindet und das Wissen im Team verteilt wird.
Der Schlüssel zu all dem ist es, die Arbeit für jeden einfacher und produktiver zu machen. Es ist wahrscheinlich ziemlich klar, wer diese Person ist, denn sie werden das respektierteste Mitglied sein, das jeder an die Wand bringt. Dieser Person muss etwas Zeit gegeben werden, um diese Rolle zu übernehmen.
Wenn Sie das nicht sind, werden Sie wahrscheinlich nicht viel Glück dabei haben, die Leute davon zu überzeugen, ihre Arbeitsweise zu ändern.
Außerdem hilft es enorm, einmal im Monat ein informelles Mittagessen einzunehmen, Fußball oder was auch immer, wo Teammitglieder informell binden können.
Teamgeist ist schwer zu erzwingen. Die meisten Versuche, die Leute zur Zusammenarbeit zu bewegen, sind besser. Es muss gepflegt und angebaut werden.
Statt einer Reihe von Treffen, wie wäre es mit einem Mittagessen im Team (im Unternehmen) einmal im Monat oder so. Etwas informelles, das keine Arbeitszeit beeinträchtigt. Nichts Formelles, sondern eine Chance für Leute, miteinander zu reden und zu "binden". Wenn die Leute können, können ein paar Drinks oder ein Kartenspiel am Abend helfen. Es ist wichtig, dass es freiwillig und nicht formell ist.
Die Paarprogrammierung kann dabei helfen, Wissen zu vermitteln und Menschen dabei zu helfen, einander zu kennen und zu verstehen. Es lohnt sich also, darüber nachzudenken.
Aber der Führungsstil in Ihrem Unternehmen scheint gegen die Dinge zu arbeiten.
"Rush, um diese Funktion in so bald wie möglich zu bekommen ... wir werden die Spezifikation für Sie in ungefähr einer Woche haben ... fangen Sie gerade jetzt an, daran zu arbeiten, aber stellen Sie sicher, es zu testen und es von jemandem überprüft zu bekommen" .
Das lässt die Dinge sehr in der Luft liegen. Jemand hat über Dinge gelesen, die Entwicklerteams tun sollten, ist aber nicht bereit, die Zeit (auch Geld) in die Dinge richtig zu stecken. Das wird Entwickler entrechtet und motiviert machen, was einem Team schadet.
Es ist schwer, eine definitive Antwort zu geben .. abgesehen davon, etwas auszuprobieren und zu hoffen, dass einige von ihnen haften bleiben
Vermeide lokale Wissensinseln - PairProgramming funktioniert möglicherweise. Wenn A sich für eine Aufgabe in einem Bereich anmeldet, in dem X über Erfahrung oder Zeit verfügt, könnte er X bitten, sich mit ihm zu paaren. Der Prozess des Implementierens der Aufgabe verbreitet die Dinge in Xs Kopf, ist eine Echtzeit-Code-Überprüfung und hilft dabei, die durchschnittliche Teamfähigkeit / Kompetenz / Code-Vertrautheit zu erhöhen. Es ermutigt auch die Menschen miteinander zu reden, anstatt zusammen zu tun ..
Dynamisches Tempo der Tech-Evolution - Fakt des Lebens ... muss sich daran gewöhnen. Unter Verwendung von Entwicklerforen, Lunchbox-Foren, Brown Bag-Sitzungen, Wikis, Buchclubs, Online-Foren usw. könnte es funktionieren. Hängt davon ab, was die Personen in Ihrem Team als bevorzugte Einnahmequelle wählen. Arbeiten Sie an Feedback ... Wenn das Team das Gefühl hat, dass es von den Entwicklerforen profitiert, werden sie es unterstützen. Wenn es ausstirbt, denke darüber nach, warum es nicht kleben bleibt. Versuche etwas anderes mit den erlernten Lektionen.
Slack - ein oft übersehener Aspekt. Stellen Sie sicher, dass die Leute Zeit haben, jemandem zu helfen .. nicht ständig hinter einer Frist zu laufen.
Schaffen Sie eine Umgebung, die Menschen ermutigt und erleichtert, sich zu äußern .. anderen zu helfen .. und sie dann den Individuen zu überlassen, damit sie zusammenkommen. Viel Glück.
Vielleicht geht es Ihnen weniger um Kommunikation als um die Motivation Ihrer Teamkollegen. In einem intellektuellen Feld wie dem Programmieren muss die Motivation aus dem Praktiker kommen. Ohne das ist es schwierig, zu weit zu kommen. Wenn das der Fall ist, müssen Sie zu einem anderen Ort weitergehen.
Das erste Ding ist, alle physischen Wände abzubrechen, indem man das Team zur gleichen Position bewegt, prefable, der jeden im gleichen Raum setzt.
Verwenden Sie als zweites Release-Planungssitzungen. Das heißt, Ihr Team schätzt gemeinsam mit dem Kunden jede Story, die für die kommende Veröffentlichung entwickelt werden muss. Ich werde die Kommunikation zwischen den Teammitgliedern verbessern, da es sich um technische Probleme und Problemlösungen handelt. Sie schätzen und führen, wenn sie richtig gemacht werden, zu Einschätzungen hinsichtlich der Schätzungen und des Entwurfs. Verfolgen Sie die Veröffentlichungsplanung mit dem Treten jeder Iteration (am besten eine Woche Iteration) mit einem Iterationsplanungsmeeting. Hier unterteilt das Team jede Geschichte in eine Reihe kleiner Aufgaben, die für die Implementierung dieser Iteration geplant sind.
Drittens, starten Sie die Paarprogrammierung. Zwinge es nicht, aber ermutige es stark. Stellen Sie außerdem sicher, dass Paare nur für einen Tag oder so paaren. Dh Paare drehen. Das baut kollektiven Code-Besitz und Teamgeist auf, da es "unser Code" und nicht "sein Code" ist.
Oh, und endlich: Lerne immer über "uns" und das "Team" zu reden. Zeigen Sie niemals mit den Fingern.
Wie können Sie Ihre Kollegen ermutigen, besser zu kommunizieren? Mit gutem Beispiel vorangehen.
In meiner Firma haben wir oft den Begriff "etwas fahren". Jemand muss ein Projekt fahren, muss das Testen vorantreiben usw. Das heißt Verantwortung für diese Aufgabe übernehmen und aktiv weiterführen. Erwarten Sie von Ihren Kollegen nicht nur, dass sie Informationen teilen, ihnen zeigen, was zu tun ist und wie sie es tun.
Wenn Sie einige nette neue Details über VS2008 herausfinden, teilen Sie sie mit ihnen. Aber sei dabei professionell. Erzähle es nicht einfach den beiden Jungs, mit denen du heute einen Kaffee trinkst, bereite eine kleine Präsentation oder ein Word-Dokument vor, das deine Ergebnisse beschreibt, und teile es allen Teammitgliedern mit. Ich würde definitiv lieber eine kurze Präsentation geben, anstatt nur eine E-Mail zu senden, aber das ist vielleicht nicht möglich.
Sie können dies zu regelmäßigen Informationsaustauschsitzungen hinzufügen, aber ich denke, es ist wichtig, dass Sie dieselbe Einstellung in Ihrer täglichen Arbeit beibehalten. Tu es nicht einfach, lebe es.
(Oh mein Gott, ich höre mich wie einer dieser dumm überbezahlten Motivationstrainer an! Naja, vielleicht haben sie Recht und verdienen das ganze Geld ;-))
Es wird immer Leute geben, die deine Leidenschaft teilen und dich begleiten. Es wird auch immer Entwickler geben, die die 9 bis 5'er sind. Nichts kann dagegen getan werden.
Wenn Sie Management kaufen, dann laufen Sie damit. Management-Buy-In ist das, was ich am schwierigsten gefunden hätte. Hoffentlich, wenn andere mit Ihnen an Bord kommen, wird der Rest in Einklang gebracht. Viel Glück!
Tags und Links agile