Ich bin technischer Referent, aber ich habe den Vorsprung für technische Entscheidungen verloren

Diese Zeile zerstörte mein Vertrauen in die Führer Ihrer Firma:

Keine Test-Driven Development und keine Unit-Tests mehr.

Das ist so eine schlechte Entscheidung, ich kann mir nicht vorstellen, irgendwo zu arbeiten, das sich so verhält oder glaubt. Sie werden 10 bis 100 Stunden damit verschwenden, Fehler zu beheben, weil sie 1 Stunde sparen möchten, indem sie keine testgetriebene Entwicklung oder Komponententests verwenden.

Das ist schlechte Programmierung, schlechtes Geschäft und verrät einen Mangel an Verständnis für Systemdenken. Solchen Leuten kann man nicht trauen. Sie sind nicht in der Lage, in JEDEM Geschäftsbereich zuverlässig gute Entscheidungen zu treffen.

Ohne Systemdenken werden Ihnen Führungskräfte auf lange Sicht schaden.

Raus jetzt.

Denken Sie daran, dass Codierung nicht im luftleeren Raum existiert. Selbst weniger idealer Code kann echte geschäftliche oder humanitäre Probleme lösen.

Qualität ist kein Alles-oder-Nichts-Ansatz. Es gibt sicherlich Situationen, in denen ein Team so jung ist, dass die Einführung von Komplexitäten die Produktivität und Moral beeinträchtigen und nicht einmal die grundlegenden Ziele des gesamten Projekts erreichen kann.

Ich vermute, Sie selbst haben Ihre Karriere nicht mit TDD, Mocking, Programmierung von Schnittstellen, Abhängigkeitsinjektion, Komposition über Vererbung, verteilter Versionskontrolle und dergleichen begonnen.

Versuchen Sie Kompromisse einzugehen. Erstellen Sie mit den Chefs einen Plan für die Einführung moderner Softwareentwicklungspraktiken im Laufe der Zeit. Bieten Sie an, dem Rest des Teams diese Prinzipien beizubringen, indem Sie persönliches Mentoring, Lunch-and-Learns oder selbstgesteuertes Training nutzen.

Sehen Sie, ob es nette Funktionen gibt, die das Team verwenden kann, um mit Techniken zu experimentieren, die für sie neuer sind, wo Sie die Codequalität, Überprüfungen, das Bestehen von Tests und alles andere, was Sie für notwendig halten, überwachen würden.

Es geht darum, ein Gleichgewicht zwischen unmittelbarer Produktivität und langfristigen nachhaltigen Entwicklungspraktiken zu finden.

Das wird natürlich Zeit brauchen, und Sie müssen feststellen, ob diese Zeit Ihre persönliche Investition wert ist. Wenn die Chefs nicht bereit sind, Kompromisse einzugehen, wird diese Entscheidung wahrscheinlich für Sie getroffen.

Ich habe diesen Kampf mehr als zweimal gekämpft.

Folgendes werden Sie irgendwann feststellen: Keine Führungskraft will zugeben (und wahrscheinlich sogar sich selbst gegenüber), dass sie Müll produziert. Sie werden sich entweder dem Schmerz stellen und die notwendigen Änderungen vornehmen, um ein gutes Produkt herzustellen, oder sie werden die Entscheidung mit einer Kombination aus Kummer über eine Budgetkrise und irrationalen Rationalisierungen, wie Sie sie oben skizziert haben, „begründen“.

Die Organisation hat gesprochen, und man kann nicht dagegen ankämpfen UND gleichzeitig ein gutes Produkt liefern.

Entweder Sie schließen sich damit ab, Ihren Namen auf etwas zu setzen, von dem Sie wissen, dass es nicht Ihren Standards entspricht, oder Sie finden einen Ort, an dem Ihre Talente und Standards von Nutzen sind.

Es ist nicht Ihr Produkt, im Grunde müssen Sie sich anpassen oder weitermachen.

Als Freelancer sollte man das schon einmal erlebt haben. Sie müssen innerhalb dessen arbeiten, was die Leute, die Sie bezahlen, Ihnen erlauben. Es ist offensichtlich, dass sie Ihren Führungsstil nicht mögen und dass Sie ihr Team stören. Nachdem sie ihre Optionen (ohne Sie) überprüft haben, haben sie sich folgendes ausgedacht.

Stellen Sie sicher, dass Sie bezahlt werden, und versuchen Sie, zu guten Konditionen zu gehen, wenn Sie bereit sind, aber ärgern Sie sich nicht über ein Produkt, das Sie nicht besitzen.

Nur ein Vorschlag, aber Programmierkenntnisse sind nicht alles, wenn man mit einem Team in irgendeiner Art von Führungsrolle arbeitet. Sie könnten viel besser nach Soloprojekten suchen, die Ihre Fähigkeiten wirklich zum Leuchten bringen können. Das ist einer der Gründe, warum ich oft Jobs ablehne, an denen ein unbekanntes Team beteiligt ist, das es nicht selbst erledigen könnte (wenn sie kompetent und effizient wären, würden sie mich nicht brauchen). Ich bevorzuge es, entweder alleine oder mit meinem eigenen Team bei Null anzufangen. Weniger Kopfschmerzen und mehr Arbeitszufriedenheit (normalerweise auch mehr Geld).

Setzen Sie Ihr Geld dort hin, wo Ihr Mund ist. Verlassen.

Kündigen Sie von der Position, indem Sie die gesamte Managementkette darüber informieren, dass Sie nicht in der Lage sind, das zu erfüllen, wofür Sie eingestellt wurden, und kündigen Sie als Freiberufler daher lieber von dem Vertrag, als eine unterdurchschnittliche Entwicklungsleistung zu unterstützen. Informieren Sie sie darüber, dass dies ein Vertragsbruch ist (vorausgesetzt, Sie wurden eingestellt, um diese Entscheidungen tatsächlich zu treffen) und Sie es daher nicht für gerechtfertigt halten, Ihre Zeit – und ihr Geld – mit Ihrem Gehalt zu verschwenden.

Es gibt nicht viel, was Sie tun können. Sofern Sie keine Hintergedanken haben (das Geld für einige andere Projekte brauchen), ist dies der aufrichtigste Weg, damit umzugehen, da Sie persönlich mit dem Verlauf des Projekts zu kämpfen haben.

Wenden Sie sich alternativ an eine höhere Stelle und versuchen Sie, einen Weg zu finden, die Dinge auf einem akzeptablen Niveau zum Laufen zu bringen. Es ist jedoch möglich, dass sie mit Leuten zusammenarbeiten, die lieber Burger bei McDonalds umdrehen sollten - das sieht man in ziemlich vielen größeren Unternehmen. Ich wurde einmal eingestellt, um VB-Entwicklern C# beizubringen. Ein einmonatiger Lehrplan, komprimiert auf 3 Tage ("Wir können nicht zulassen, dass sie einen Monat lang nicht arbeiten, und sie sind alle erfahrene Entwickler"). Nun, die erfahrenen Entwickler kannten den Unterschied zwischen einem Array und einem Hashtable/Wörterbuch auf einer grundlegenden Ebene nicht, also war die ganze Zeit verschwendet. Das ist das Niveau in manchen Unternehmen.

Du kannst nicht dagegen ankämpfen. Der Fisch fängt am Kopf an zu stinken - das ist Management. Sie zahlen im Laufe der Zeit dafür. Aber es ist nicht deine Aufgabe, es zu ändern. Wenn du es nicht ertragen kannst, geh.

Ich würde mich auf verschiedene Dinge konzentrieren. Da:

Keine Test-Driven Development und keine Unit-Tests mehr.

Das ist ärgerlich, aber verständlich. Es ist ein riesiger Paradigmenwechsel und es passt am besten zu einem brandneuen Projekt, nicht zu einer Fortsetzung eines alten.

Keine solch anspruchsvollen Code-Reviews.

Das ist auch verständlich. IMHO sollte das Anspruchsniveau schrittweise erhöht werden, damit die Menschen neue Fähigkeiten erlernen können.

Einige kopieren und einfügen aus der alten Version der Anwendung, um für andere Entwickler schnell zu gehen.

Das ist verständlich und kann in Ordnung sein - wenn diese alten Teile des Durcheinanders gut vom Rest des Projekts getrennt werden.

Jetzt haben Sie die Dinge aufgelistet, die sie fallen gelassen haben, aber die Liste kann nicht beurteilt werden, ohne zu wissen, wie viele Ihrer Empfehlungen noch vorhanden sind. Wenn diese 3 die Eckpfeiler Ihrer Methodik waren, ist von Ihrem Design nichts mehr übrig, und das ist schlecht. Wenn das nur 3 von 15 waren, dann ist das meiste noch vorhanden, und diese 3 fallen zu lassen, ist wirklich das, was auf dem Etikett steht: den Schock für verbleibende Programmierer abfedern.

Aber der andere Teil ist für mich am beunruhigendsten:

Wir hatten ein Meeting (also ohne mich) und wir haben einige von Ihnen empfohlene Methoden fallen gelassen.

Sie haben Sie gebeten, etwas zu entwerfen, und dann haben sie das Design geändert, ohne Sie zu konsultieren. Das ist die rote Fahne. Entweder für sie oder für Sie – denn es könnte sein, dass Sie sich einfach weigern, ihre Argumente zu hören, bis zu dem Punkt, an dem sie eine direkte Anweisung erteilen müssen.

Wenn Sie der Meinung sind, dass sie den größten Teil Ihres Plans fallen gelassen haben, kann dies bedeuten, dass sie nichts verstehen. Sie wollen, dass ihr Code verbessert wird, sie können Ihr Gehalt zahlen, aber sie zahlen nicht die wahren Kosten: den Aufwand. Es ist wie bei einem Mann, der Proteinergänzungen kauft, in der vergeblichen Hoffnung, dass ein Produkt ihnen auf magische Weise Muskeln ohne Bewegung verleiht. Proteinergänzungen funktionieren nicht auf diese Weise und Sie sind auch kein magisches Produkt, das ihren Prozess reparieren kann, ohne ihn zu ändern. Es ist erschreckend, wie viele Leute denken, dass Wunderkugeln echt sind.

Andererseits strebt die kommerzielle Softwareproduktion nicht nach absoluter Perfektion, es wird gerade genug Mühe (was Zeit bedeutet, was wiederum Geld bedeutet) in Perfektion investiert, um heute noch mehr Aufwand (sprich: Zeit, sprich: Geld) zu sparen auf lange Sicht. Jede Behebung kostet Geld und ist nur dann vertretbar, wenn es noch mehr kostet, den Fehler zu belassen. Worin Sie wirklich gut sein müssen, sind Kompromisse. Nicht jeder ist für den Job geschaffen (es hilft sicherlich nicht, zu perfektionistisch zu sein), der einzige Weg, das herauszufinden, ist, es zu versuchen.

Ob die verbleibende Gestaltungsfreiheit ausreicht, müssen Sie selbst entscheiden. Wenn Sie das Gefühl haben, dass sie Sie für einen Job eingestellt haben und jetzt sagen, dass Sie den Job nicht machen können, dann kann es nur Zeitverschwendung sein, dort zu bleiben.

Sie können den Job immer als Lektion behandeln. Distanziere dich, beobachte und lerne. Auch wenn Sie technisch perfekt sind, brauchen Sie immer noch die Fähigkeit, mit anderen Menschen zusammenzuarbeiten. Heck, die Arbeit mit Menschen, die nicht so gut sind wie Sie, erfordert noch mehr von dieser Fähigkeit.

Ich würde mich nicht zu sehr auf die getroffenen Entscheidungen konzentrieren. Die wichtige Information hier ist: Sie haben es sich zur Aufgabe gemacht, ohne Sie ein Treffen über Dinge abzuhalten, die in Ihrer Verantwortung lagen. Es zeigt einen Vertrauensverlust in dich.

Sie müssen zuerst verstehen, woher das kam. Sie sehen technisch angemessen aus, wenn man bedenkt, was von Ihnen verlangt wurde: Sie haben sie als solche überzeugt. Aber sie haben dich nicht eingestellt, weil du technisch gut bist, sie haben dich eingestellt, um ein Problem zu lösen, das sie hatten, und dachten, du könntest das.

Ich sehe mehrere Probleme, die mit dieser Dissonanz passieren könnten (die Tatsache, dass Sie denken, dass sie Sie für eine Sache eingestellt haben, verglichen mit dem wahren Grund):

1. Fehlende Tore:

   • Haben sie dir gesagt, was sie von dir erwarten?
   • Hast du gefragt, was sie wollten?
   • Hast du etwas verpasst, was sie dir gesagt haben?
   • Vielleicht haben Sie gehört: "Wir wollen Qualitätssoftware!" als sie meinten "Wir wollen eine Software, die Menschen benutzen!".

2. Mangel an Transparenz: Sie kommen zu diesem neuen Job und wenden alle bewährten Verfahren an, die in Ihren Bereichen bekannt sind.

   • Wie haben Sie darüber kommuniziert?
   • Bist du zu schnell gefahren?
   • Waren sich alle der Konsequenzen bewusst, weil es immer einen Kompromiss gibt?
   • Haben Sie erklärt, dass die Lernkurve die Produktivität beeinträchtigt?

3. Unterstützung von unten: Ihre Methodik hat das Leben Ihres Teams beeinflusst, es muss überzeugt werden, dass es in die richtige Richtung geht.

Ich kann an dieser Stelle nur spekulieren, aber ich kann verstehen, warum innerhalb weniger Monate die Entwickler ausgeflippt sind, weil sie den Mehrwert der Änderungen (noch) nicht sehen, und Ihre Chefs ausgeflippt sind, weil die Features nicht kommen so schnell, wie sie dachten, Sie würden liefern, und die Entwickler schlagen unzufrieden auf sie zurück.

Aus dieser Erfahrung müssen Sie für das nächste Mal lernen, da die Dinge in Ihrem Fall ziemlich weit fortgeschritten sind.

Aber wenn es etwas zu retten gibt, dann durch Vertrauen und Geduld. Wenn überhaupt,

• Gehen Sie mit dem Strom, indem Sie die Probleme anerkennen, die sie angesprochen haben.
• Akzeptiere die meisten ihrer Änderungen und füge deine wertvollsten Punkte hinzu (nur unter der Bedingung, dass du hier eine Zukunft sehen würdest)
• Machen Sie einen Zeitplan, um die besten Praktiken langsam aber sicher wieder einzuführen, und erklären Sie, welche Probleme diese Methoden beheben (keine Notwendigkeit für Fallschirme in Autos, aber ein Sicherheitsgurt kann helfen ;)

Überzeugen Sie die Leute, koste es, was es wolle, auf Ihrer Seite zu stehen, denn wenn Sie das nicht können, ist Ihr Kampf verloren.

Ich bin mir der genauen Details Ihrer Situation nicht sicher, aber technisches Fachwissen zu haben und ein Team zu führen, um Dinge auf eine bestimmte Weise zu tun, sind meiner Meinung nach zwei verschiedene Dinge. Das Buch „Extreme Ownership“ geht tief in die Teamdynamik ein, vielleicht wäre es hilfreich.