Einführung neuer Themen für Mitarbeiter

Ich habe versucht, Mitarbeitern Themen wie Unit-Tests, Abhängigkeitsinjektion, Umkehrung der Kontrolle usw. vorzustellen. Ich habe Mini-Vorträge und Demonstrationen gehalten und diese Themen während des Mittagessens vorgeschlagen und gelernt. Die Rezeption war im Allgemeinen positiv und die Menschen sehen Wert in solchen Themen.

Obwohl sie von diesen Themen angezogen zu sein scheinen, war die Akzeptanz sehr gering. Wenn ich mit ihnen darüber spreche, lautet die Antwort im Allgemeinen wie folgt:

Ich werde es das nächste Mal versuchen. Ich möchte nur dieses Projekt aus der Tür bekommen.

Ich habe das Gefühl, dass das meiste, was sie gesehen haben, nur Demonstrationen vom Typ Vortrag sind und sie keine praktische Erfahrung haben. Was kann ich tun, um sie voranzutreiben? Ich möchte sie nicht dazu zwingen, Code zu schreiben, wenn sie nicht wollen, weil es wie "Hausaufgaben" erscheint und sie einen schlechten Eindruck hinterlassen.

Unsere Projekte lassen im Allgemeinen keine Zeit zum Experimentieren, daher scheuen die Leute neue Technologien. Dies lässt Entwicklern keinen Raum, um zu versuchen, während der Entwicklungsphase neue Dinge zu integrieren.

Gibt es lustige oder interessante Übungen (Solo oder Team), die es ihnen ermöglichen, mehr praktische Erfahrungen mit diesen Themen zu sammeln? Ich hoffe, etwas zu finden, das genug Interesse weckt, damit sie bereit sind, eine Stunde ihres Tages einzuplanen, um an etwas Ordentlichem zu arbeiten, oder genug Interesse, damit sie ihre eigene Zeit untersuchen können.

Um eine Idee zu "beweisen" und damit wirklich in den Kopf eines Menschen zu implantieren, reicht Theorie (Sprechen) nie aus.

Sie müssen diese Praxis in Ihrem eigenen Code verwenden und sie "entdecken" lassen, dass sie Probleme auf nette Weise gelöst hat.

Das bedeutet, dass Ihre Praktiken effektiv sein müssen und Sie es offensichtlich machen sollten.

Auf diese Weise wird das Lesen Ihres Codes sie inspirieren, da sie "es in Aktion sehen".

Gehen Sie nicht davon aus, dass es ausreicht, nur zu sagen, wie es funktioniert.

Wenn sie aus Erfahrung nicht bereit sind, das anzuwenden, was Sie ihnen beibringen wollen, bedeutet dies, dass sie sich nicht darum kümmern. Sie verschwenden wahrscheinlich Ihre Zeit, indem Sie versuchen, ihnen die Themen vorzustellen, denn wenn sie die tatsächlichen Vorteile dieser Themen verstehen, möchten sie sie anwenden und keine Ausreden dafür geben, warum sie dies nicht können.

Es ist so, als würde man versuchen, etwas Besseres einzuführen als das, was derzeit verwendet wird, und leere Blicke oder sofortige Antworten erhalten, warum dies nicht möglich ist. Es ist bezeichnend, dass die andere Person es nicht wirklich als Vorteil ansieht (denn wenn sie in der Lage wäre, den Vorteil zu sehen, würde sie keine Entschuldigung geben).

Traurig aber wahr. Vielleicht ist Ihre Situation anders, aber ich bin in der Vergangenheit ein paar Mal darauf gestoßen, und am Ende war es schmerzlich offensichtlich, dass sich niemand außer mir für diese Themen interessierte. Letztendlich traf ich die Entscheidung zu gehen und zu versuchen, Mitarbeiter zu finden, die sich darum kümmern. die Art von Leuten, die mich entweder nicht brauchen, um die Themen vorzustellen (weil sie sie bereits kennen / verwenden) oder die es sofort akzeptieren, anstatt zu sagen, wie sie es nicht können.

Ich habe viele "Best Practices" gesehen, die in Ungnade gefallen sind und sich nie wieder daran gewöhnen. Es gibt viele Arten von Projekten und solche Techniken sind nicht für alle Projekte geeignet. Stellen Sie sicher, dass das, was Sie verkaufen, wirklich hilft.

Wenn Sie damit beginnen und die Leute sehen, dass Sie besonders produktiv sind oder Code mit besserer Qualität produzieren, werden sie später einen anderen Blick darauf werfen. Überlegen Sie genau, ob der zusätzliche Aufwand Ihrem Projekt wirklich hilft. Nicht jede App braucht es.

Wenn Sie Ihre Kollegen zur Teilnahme motivieren können, können Sie Coding Dojos organisieren . Dies sind Programmierherausforderungen, bei denen sich die Teilnehmer bewusst auf die Verbesserung der Praxis konzentrieren. Vielleicht führt die Teilnahme an einem testgetriebenen Dojo Ihre Kollegen dazu, die Vorteile von TDD zu erkennen.

Alternativ müssen diese Dinge manchmal von der Kultur auferlegt werden. Es fällt mir auf, als ob die Kultur in Ihrem Unternehmen darin besteht, sie nicht zu brauchen.

Wenn sie zu einer Anforderung für den Projektabschluss werden (wahrscheinlich eine Managemententscheidung), werden Sie feststellen, dass sich die Anwendung dieser Tools und die Kultur allmählich ändern.

Die beste Vorgehensweise ist realer Produktionscode. Katas sind eine nette Einführung, aber meiner Erfahrung nach halten Sie nicht das gleiche "Eureka!" Momente, in denen man es wirklich sieht .

Sie haben jedoch darauf hingewiesen, dass die Zeitpläne "keine Experimente zulassen". Es ist wirklich eine einfache Lösung. Sie tun bereits die Dinge, die Sie unterrichten möchten. Lassen Sie also eine offene Einladung, sich mit Ihnen zu paaren, während Sie die fantastische neue Funktion X implementieren. Lassen Sie sie an der Tastatur sitzen und tippen, während Sie " Rücksitz fahren ". Dadurch können sie ein gewisses Muskelgedächtnis und Selbstvertrauen aufbauen.

Viel Glück bei Ihren Bemühungen.