So stellen Sie sicher, dass Ihr Unternehmen nicht unter Wasser geht, wenn Ihre Programmierer die Lotterie gewinnen

Ich habe ein paar Programmierer unter mir, alle machen es offensichtlich sehr gut und sehr klug. Vielen Dank.

Das Problem ist jedoch, dass jeder einzelne von ihnen für einen Kernbereich verantwortlich ist, von dem niemand im Team die geringste Ahnung hat, was er ist. Das bedeutet, dass wenn jemand von ihnen ausgeschlossen wird, meine Firma als Unternehmen tot ist, weil sie nicht ersetzbar sind.

Ich denke darüber nach, neue Programmierer hinzuzuziehen, um sie abzudecken, für den Fall, dass sie von einem Bus angefahren werden oder zurücktreten oder was auch immer. Aber das fürchte ich

1. Die alten Programmierer könnten sich der Idee des Wissenstransfers aktiv widersetzen und befürchten, dass ein Backup ihren Wert mindert.
2. Ich habe kein System, um den Technologietransfer zwischen verschiedenen Entwicklern zu erleichtern. Selbst wenn ich sie dazu auffordere, kann ich nicht garantieren, dass sie es richtig machen.

Meine Frage ist,

1. Wie man es den alten Programmierern so vorstellt, würden sie zustimmen
2. Welche Systeme verwenden Sie, um diese Art von "Backup" zu ermöglichen? Ich kann verstehen, dass Sie eine Codeüberprüfung durchführen können, aber gibt es eine einfache Möglichkeit, dies durchzuführen? Ich denke, wir sind nicht bereit für eine vollständige Überprüfung des Check-in-Codes.

Wie man es den alten Programmierern so vorstellt, würden sie zustimmen

Präsentieren Sie das Problem offen, natürlich so, dass sie es nicht als Bedrohung sehen, sondern als Chance, das Team und das Projekt zu verbessern. ZB "Ich möchte, dass andere wissen, was Sie wissen, wenn Sie entlassen werden" ist offensichtlich ein falscher Ansatz :-) "Ich möchte das reibungslose Funktionieren des Projekts sicherstellen, auch wenn einige von Ihnen in den Urlaub fahren oder krank werden " ist viel besser.

Normalerweise erleben die Entwickler die Probleme jedes Mal selbst, wenn einige von ihnen im Urlaub sind und sie für sich selbst aufkommen müssen. Darüber hinaus fühlen sich gute Entwickler für das Projekt, an dem sie arbeiten, verantwortlich, sodass sie dieser Idee wahrscheinlich zustimmen werden. Geben Sie ihnen dennoch Zeit, um zu diskutieren und sich (hoffentlich) auf die Idee einzulassen. Geben Sie ihnen außerdem die Möglichkeit, mitzuteilen, wie und mit wem sie ihr Wissen im Team teilen. Es könnte sich herausstellen, dass Joe es gut findet, mit Jim zu arbeiten (und sein Wissen zu teilen), aber nicht mit Jack usw.

Welche Systeme verwenden Sie, um diese Art von "Backup" zu ermöglichen? Ich kann verstehen, dass Sie eine Codeüberprüfung durchführen können, aber gibt es eine einfache Möglichkeit, dies durchzuführen? Ich denke, wir sind nicht bereit für eine vollständige Überprüfung des Check-in-Codes.

In unserem Team verwenden wir neben Code- / Design-Reviews auch

• Rotation von Aufgaben und Verantwortungsbereichen zwischen Teammitgliedern (jeder von uns hat seine Hauptverantwortungsbereiche, aber ab und zu erledigen wir Aufgaben in einem Bereich, der einem anderen Teammitglied besser bekannt ist)
• Präsenzveranstaltungen zum Wissenstransfer (normalerweise, wenn die oben genannten Aufgaben erforderlich sind, aber auch bevor jemand das Team verlässt)
• Team / Projekt Wiki

Die Codeüberprüfung allein reicht möglicherweise nicht aus, da ein Entwickler in vielen Bereichen in der Regel viel mehr zu wissen hat, als direkt aus dem Code lesbar ist. Mit anderen Worten, es gibt auch das Domain-Modell . Sie können lesen, was der Code tatsächlich tut, aber ohne das Modell wissen Sie nicht warum .

Eine Möglichkeit, sie zum Teilen ihres Wissens zu motivieren, besteht darin, sie zu bitten, ihre Arbeit anderen Menschen kurz vorzustellen . Normalerweise sind Programmierer sehr stolz auf ihre Arbeit, und dies wäre eine Chance, dies zu demonstrieren. Eine Präsentation ist eine gute Gelegenheit, um einige der Macken zu zeigen, die Außenstehende selten kennen.

Seien Sie auch offen und sagen Sie allen, dass Sie alle ein Schema für den Wissensaustausch entwickeln müssen, falls jemand von einem Bus angefahren wird. Ich halte das nicht für unvernünftig. Es passiert gerade in meiner Firma, und obwohl einige davon defensiv sind, wissen sie, dass es getan werden muss.

Vielleicht könnten sie paarweise an einigen Dingen arbeiten, wenn sie neugieriger Natur sind, sollte es kein Problem geben.

Die Aktualisierung der internen Dokumentation der Software sollte der erste Schritt sein, bevor Sie neue Mitarbeiter einstellen. Sicher, es bedeutet, dass Ihre wertvollen Programmierer einige Zeit mit Office- und UML-Tools anstelle der IDE verbringen, aber ich denke, es lohnt sich auf jeden Fall.

Sobald Sie eine aktuelle Dokumentation haben, können Sie Ihre Programmierer überprüfen lassen, um sicherzustellen, dass jeder versteht, was die anderen geschrieben haben. Immer noch keine Notwendigkeit für neue Leute.

Dann können Sie erwägen, neue Leute einzustellen. Oder auch nicht, abhängig von der Arbeitsbelastung in Ihrem Unternehmen.

Wenn Sie in einem großen Unternehmen arbeiten, können Sie HR anrufen und über dieses Problem sprechen. Glauben Sie mir, die Leute in der Buchhaltung haben das gleiche Problem, wenn das Schlüsselpersonal von einem Bus angefahren wird. Die Marketing-Leute werden auch große Probleme haben, wenn ein Schlüsselverkäufer in wichtigen Verhandlungen zum Zombie wird - das kommt oft vor, oder wie mir gesagt wurde.

Ich glaube, die richtige HR-Sprache dafür ist die Nachfolgeplanung . Möglicherweise verfügt Ihr Unternehmen bereits über Richtlinien und Rahmenbedingungen für den Umgang damit.

Ein Ort, an dem ich arbeitete, hatte das gleiche Problem. Sie stellten einen Junior-Entwickler ein, um mit jedem Senior-Entwickler zusammenzuarbeiten. Sie bildeten kleine Zweierteams, die gemeinsam an Projekten arbeiteten. Alle paar Monate oder Projekte wechselten sie die Nachwuchsentwickler zwischen den Teams. Auf diese Weise blieben die Senior-Entwickler die Fachexperten, aber die Junior-Entwickler begannen, sich ein genaues Bild von allen Systemen und ihrer Zusammenarbeit zu machen. Außerdem wurden mit der Teamgröße Verdopplungsprojekte schneller durchgeführt.

Bei größeren Projekten wurden Senior-Entwickler manchmal gebeten, für die Dauer eines Projekts als Junior-Entwickler auf einem anderen Teil des Systems zu fungieren, damit sie anfangen konnten, die anderen Systeme zu erlernen.

Der Schlüssel bestand darin, das Wissen und die Erfahrung der vorhandenen Entwickler zu respektieren und gleichzeitig das Team zu erweitern und zu vergrößern. Es war ein langsamer Prozess, aber im Laufe der Zeit hat alles gut geklappt.

Eines der Dinge, die erfolgreiche Open Source-Projekte so erfolgreich machen, ist das Fehlen von Code "Ownership". Damit meine ich, dass niemand der alleinige Betreuer eines Bereichs der Anwendung ist - jeder kann und wird ermutigt, Beiträge zu irgendeinem Teil der Anwendung zu leisten. Daran glaube ich fest.

Was Sie tun möchten, ist zu erklären, dass die Art und Weise, wie die Dinge sind, das Team, das Sie jetzt haben, tatsächlich verletzt. Hier sind die Punkte, die Sie vermitteln möchten, vorzugsweise in dieser Reihenfolge:

• Ich kann dich nicht befreien, an anderen coolen Sachen zu arbeiten, die auf den Hecht kommen, wenn du der einzige bist, der weiß, wie das funktioniert.
• Wir möchten, dass Sie in der Lage sind, einen schönen Urlaub zu verbringen, aber wir können es uns nicht leisten, weil niemand anderes das kann, was Sie tun.
• Es ist eine unangenehme Tatsache, dass die Leute ihren Job wechseln, weil sie mit ihrer aktuellen Position nicht zufrieden sind. Wir möchten Sie nicht verlieren, weil Sie sich in der Gegend gefangen fühlen, in der Sie arbeiten.

Persönlich hatte ich es mit einem verstorbenen Mitarbeiter zu tun. Obwohl es keine Informationssilos gab, traf der Verlust immer noch schwer. Die Chancen dafür liegen weit unter dem dritten Punkt.

Wenn Sie Ihren Fall veröffentlicht haben, wenden Sie sich an die entsprechenden Mitarbeiter, um Vorschläge zur Behebung des Problems zu erhalten. Kommen Sie natürlich mit. Ihre Ideen werden ihnen dabei helfen zu erkennen, dass sie Teil eines Teams sind und nicht nur für ihr Fachgebiet benötigt werden. Es mag sein, dass Jane ein Interesse an dem hat, was Joe tut, aber sie fühlt sich ein bisschen eingeschüchtert. Das Wissen kann helfen, den Wissenstransfer unterhaltsamer zu gestalten. Einige der Dinge, die Sie tun möchten, sind:

• Überquere das aktuelle Team. Kurzfristig kann es sein, dass Sie etwas an Effizienz verlieren, aber in einer Ecke der App werden möglicherweise einige Lehren gezogen, die auf andere Teile der App angewendet werden können. Lassen Sie Jane und Joe eine Weile zusammen an dem Projekt des anderen arbeiten.
• Eine Kultur des Wissensaustauschs fördern. Eine Firma, für die ich gearbeitet habe, hatte ein "Brown Bag Tech Talk" -Programm. Jeder kann zu jedem genehmigten Thema (in der Regel Einführung in Technologie oder Softwareprozesse) referieren. Die Firma sorgte für das Mittagessen und der Moderator bekam ein paar hundert Dollar für ihre Bemühungen.
• Mentoring sollte eine Lebenseinstellung sein. Das Mentoring anderer Menschen dient dazu, Sie zu befreien, neue Dinge zu tun, und Sie für das Unternehmen noch wertvoller zu machen.
• Finde Wege, um die Grenzen des Informationssilos zu überschreiten, ohne den Rang zu verlieren. Je mehr Spaß du machst, desto weniger bedrohlich wird es. Wenn die Leute in Ihrem Team so gut sind, wie Sie sagen, sind sie wahrscheinlich nicht ganz zufrieden mit dem, was die Dinge sind. Sie müssen beurteilen, ob das Team damit fertig wird, aber Sie können sich eine Woche aussuchen. Beginnen Sie hier immer mit sich selbst. Die Idee ist es, allen klar zu machen, was die Verantwortlichkeiten von "so-and-so" sind und wie sie die Probleme, die sie haben, besser lösen können. Solange Sie mit dem Nacken an der Leine beginnen, werden sie auf die Idee kommen, dass niemand ihren Job annehmen will

Versuchen Sie im Allgemeinen, sie davon zu überzeugen, dass Sie die Arbeit unterhaltsamer gestalten möchten, und Sie benötigen ihre Hilfe, um dies zu tun.

Praktikanten sind möglicherweise eine gute Idee. Sie werden den aktuellen Entwicklern direkt unterstellt, sodass sie sich nicht bedroht fühlen.

Wenn das Unternehmen wächst, brauchen Sie sowohl alte Entwickler als auch diejenigen, die es nach ihrem Praktikum geschafft haben.

Ich denke, das könnte funktionieren.

Wenn sich ein Manager plötzlich um Dokumentation und Nachfolgeplanung kümmert, ist dies im Allgemeinen ein starkes Warnsignal dafür, dass die Programmierer im Begriff sind, entlassen oder entlassen zu werden. Es ist eine solche Abweichung vom typischen Führungsverhalten und Anliegen, dass es alle Arten von Warnsignalen bei Programmierern auslöst.

Jeder muss alle seine Abläufe und Prozesse dokumentieren

Stufe 3 von " Warnsignale des Unternehmensschicksals ".

Als Alternative schlägt ein Aufsatz vor, dass wir eine Kultur des " Up or Out " fördern würden, obwohl das Gegenargument lautet, dass nur sehr wenige Unternehmen eine technische Karriereleiter haben, die in irgendeiner Weise dem finanziellen und Machtspektrum der (falschen) Karriereleiter ähnelt enthält.

Aufbauend auf dem Konzept der vollständigen Dokumentation, das @ammoQ in seiner Antwort begann ...

Ein guter Manager arbeitet daran, die Fähigkeiten seiner direkten Mitarbeiter so weiterzuentwickeln, dass jeder der Mitarbeiter sie ersetzen kann. Machen Sie Ihren Entwicklern klar, dass ein Mitarbeiter, der eine vollständige Transparenz seiner Arbeit gewährleistet, wertvoller ist als einer, der alle seine Arbeiten geheim und verborgen hält. Wenn der "geheime" Entwickler heute verstirbt, wäre es eine enorme Kostenbelastung für das Unternehmen, dieses verlorene Wissen wiederzugewinnen. Wenn der Mitarbeiter mit der vollständigen Offenlegung heute verstorben wäre, wäre das Unternehmen zwar immer noch ratlos, aber weniger verheerend. Daher hat der Mitarbeiter mit vollständiger Offenlegung mehr Wert.

Jeder Mitarbeiter, der versucht, verborgenes Wissen aufzubewahren, um sich gegen Entlassung zu schützen, ist auch gegen Beförderungen immun. Sie können einen Entwickler nicht in eine herausforderndere und lohnendere Position bringen, wenn es niemanden gibt, der die alltäglichen Aufgaben erledigt, mit denen er heute belastet ist. Wenn die alltäglichen Aufgaben vollständig dokumentiert und offengelegt sind, können Sie einen neuen Junior-Entwickler einstellen, um den vorherigen Entwickler in eine höhere Position zu befördern.

Dies bedeutet, dass auch Sie dokumentieren müssen, was Sie tun, und für jeden Ihrer direkten Mitarbeiter Schulungen durchführen müssen. Wenn Sie heute gestorben sind, könnte einer von ihnen für Sie tätig werden, bis ein Vollzeitersatz gefunden wurde.

Bevor ich neue Programmierer einbeziehe, möchte ich jeden von ihnen bitten, bei der Erstellung seines eigenen dokumentierten Erbes mitzuwirken.

Entweder mit einem Wiki oder einer 3-Ring-Bibel mit Dokumenten zu allen Aspekten ihrer Arbeit.

Oder wenn Sie eine wirklich detaillierte und gründliche Dokumentation wünschen, stellen Sie einen technischen Redakteur ein, um jeden Programmierer zu interviewen und dann eine Dokumentation von allem zu erstellen, was jeder tut, täglich, wöchentlich, monatlich, jährlich.

Machen Sie dann eine Wiki-Version davon, die Ihr Programmierer aktualisieren / bearbeiten / teilnehmen / kommentieren kann.

Dann haben Sie ein System, das mit der Zeit wächst und die Lernkurve für jeden neuen Programmierer verbessert.

Ehrlich gesagt ist es auch nicht ratsam, Programmierer nur in einem Kernbereich festzuhalten, es lohnt sich wirklich, Zug- und Kernarbeit zu überqueren.

Dann können Sie Ihr vorhandenes Personal nutzen, wenn 1 Person Urlaub macht oder so.

Wenn einer Ihrer Programmierer krank ist, rufen Sie ihn bei Fragen und Problemen wiederholt an.

Jedes Mal, wenn einer Ihrer Programmierer in den Ferien ist, rufen Sie ihn bei Fragen und Problemen wiederholt an.

Sie werden bald erkennen, dass es für sie und das Unternehmen besser ist , keine einzelnen Personen für die Kernbereiche zu haben.

Niemand möchte vom Bus angefahren werden, aber er möchte auch nicht kurzfristig das Projekt eines anderen übernehmen und sein Projekt auch beibehalten müssen. Dann läuft jeder Gefahr, sein Geschäft zu schließen.

Wenn Sie in Silos entwickeln, müssen Sie damit beginnen, Leute von einem Projekt zu einem anderen zu bewegen. Beginnen Sie mit der Dokumentation, der Codeüberprüfung oder der Behebung eines einfachen Fehlers. Kleinere Verstöße gegen den Kodexschutz / die Territorialität sollten angegangen werden, bevor dies zu weit aus dem Ruder läuft.

Es ist eine Effizienzillusion, einen einzelnen Spezialisten für einen Teil Ihres Codes zu haben.

Möchte jemand jemals in den Urlaub fahren?

Ich habe noch viel mehr Unternehmen untergehen lassen, weil das Management dumme Fehler gemacht hat. Sie werden nicht abstürzen und sich verbrennen, wenn ein oder zwei Ingenieure gehen. Sie müssen nur eine Weile härter arbeiten. Meine Güte, ich leite ein Offshore-Team, das vierteljährlich jemanden verliert. Beginnen Sie, die Aufgaben zu verschieben. Heute.