Umgang mit Mitarbeitern, die neue Frameworks in Software für kritische Systeme verwenden möchten, aber ich nicht

Ich glaube, ich habe anfangs zugestimmt, ein neues Framework zu verwenden, aber nach Risikoanalysen und Audits der aktuellen Software zögere ich, ein neues Framework (z. B. Angular) für kritische Systeme zu verwenden.

  • Der aktuelle Entwicklungsstack kann sowohl von mir als auch vom Mitarbeiter unterstützt werden.
  • Die Einstellung von "neuem Framework"-Personal würde viel kosten, wir haben nicht das Budget, um diese Entwickler einzustellen (ich bin mir bewusst, dass dieser Mitarbeiter sowieso gehen möchte).
  • Wenn wir ein neues Framework verwenden, müsste ich es lernen (ich habe weder die Zeit noch das Interesse).
  • Das Framework wurde bereits nicht abwärtskompatibel aktualisiert, ich mache mir Sorgen, wenn es wieder passiert.
  • Die Anforderungen an die externe Prüfung sind hoch, der "Papierkram" / die Validierung schwer, daher würde ich lieber ein möglichst einfaches System / Stack verwalten, das einfach zu warten ist.
  • Sogar das visuelle Thema, ich sage, bleiben Sie bei unserem 5 Jahre alten "Bootstrap", es macht keinen Sinn, ein neues hinzuzufügen.

Ich habe sie darauf aufmerksam gemacht, aber sie verstehen es immer noch nicht. Sie sind ein besserer Entwickler als ich, und sie sagen, dass ein "neues Framework" eine "schnellere" Entwicklung ermöglichen wird. Aber aus meiner Sicht ist eine solide Auslieferung und Wartbarkeit wichtiger. Vor allem, wenn sich das Personal ändert.

Ich habe sie einige Apps im "neuen Framework" (Dashboards/Widgets) entwickeln lassen, da ich verstehe, dass es einige Karriereentwickler geben sollte, aber für kritische Systeme ist es zu riskant.

Ist der Entwickler nur um sich selbst besorgt und nicht um das Team/Projekt? Wenn sie hier nicht glücklich sind, soll ich sie drängen zu gehen?

Unter „schnell“ versteht er aus seiner Sicht die Implementierung, die Codierung und die Fähigkeit, sich an zukünftige Änderungswünsche anzupassen – das sehe ich. Aber für mich ist es nicht nur die Codierung, wir haben Tests und Dokumentation, neue Fehler durch den Wechsel zu einem neuen Stack usw. Die alten Tools/aktuellen Stacks, die wir haben, haben wir ausgebügelt - sie sind "ausgereift". Mit einem neuen Set gibt es neue Probleme zu lösen – genau wie beim Wechsel zum aktuellen Stack gab es Probleme zu lösen.

Update - Mir wurde von diesem Entwickler gesagt, dass das, was ich gesagt habe, Bull*** ist, laut im Korridor, ähnlich in einem Gemeinschaftsbereich vor Menschen. Ich verstehe, dass es Konflikte gibt, aber ist das ein guter Weg, um mit Ihrem Vorgesetzten oder sogar mit jemandem, den Sie leiten, umzugehen? Es fühlte sich an, als hätte man es mit einem Kind/Teenager zu tun. Wenn ich dem COO nicht zustimme, habe ich ihm ein paar Links und Quellen geschickt.

Um dies zu einer Frage am Arbeitsplatz zu machen, was ist Ihre berufliche Beziehung? Mitarbeiter, Teamleiter, Manager, Firmeninhaber?
Sie sagten, Sie hätten eine Risikoanalyse und Audits durchgeführt. Haben Sie den Geschäftsleuten dann nicht die Kosten und Risikokosten für die Änderung des Rahmens gegeben? Geschäftsleute sind diejenigen, die das Geld halten, wenn es zu viel kostet, werden sie nicht weitermachen. Es sei denn, die Entwickler können selbst ein Audit durchführen, um zu beweisen, dass es weniger kosten würde, als bei der aktuellen Lösung zu bleiben, was ich bezweifle, wenn Sie das mit zwei Personen aufrechterhalten können.
Gute Frameworks brechen die Abwärtskompatibilität in ihren LTS-Versionen nicht. Nur Sicherheits-/Fehlerbehebungen, die auftauchen können, und im Allgemeinen wird ein gutes Framework mindestens 2-3 Jahre lang LTS haben und Richtlinien für die Verwerfung bieten, um auf die nächste LTS-Version zu aktualisieren.
@Trevor Sie können Stammeswissen mit jedem Framework erstellen. Frameworks lösen dieses Problem nicht.
Es könnte sein, dass sie einen Veralterungsdruck spüren. Ich hatte ein großes Team, das mit überwältigender Mehrheit ein neues Framework auswählte, nur weil es nicht das nächste Jahrzehnt damit verbringen wollte, an etwas zu arbeiten, das 10 Jahre alt war. Der Nebeneffekt war, dass wir Kandidaten hatten, die an die Tür klopften, um unserem Team beizutreten, weil alle hörten, dass es das heißeste neue Ding war. War es technisch die beste Entscheidung? Vielleicht. Aber war es die richtige Personalentscheidung? Ja. Ironischerweise ist es weniger wahrscheinlich, dass Teammitglieder gehen, wenn sie das Gefühl haben, auf der neuesten Technologie zu sein – obwohl dies ihre Lebensläufe verbessert hat.
Nur neugierig. Was ist Ihr aktueller Tech-Stack? Möglicherweise gibt es andere Stacks, die einfacher und so modern wie Angular sind (z. B. vue.js?), die Sie verwenden könnten.

Antworten (6)

Ist der Entwickler nur um sich selbst besorgt und nicht um das Team/Projekt?

Dies ist eine gängige Denkweise für geschäftsorientierte Menschen. In meiner langen Erfahrung war es nie wahr. Entwickler kümmern sich um das System: Das Geschäft hängt davon ab, dass das System funktioniert, also wollen sie ein Qualitätssystem erstellen. Sie erwarten auch, in Zukunft viele Male über einen langen Zeitraum nach neuen Dingen gefragt zu werden. Da sie diejenigen sind, die die Anforderungen tatsächlich umsetzen müssen , sind sie sich genau bewusst, was dies erschweren könnte. Der Entwickler versucht natürlich, Lösungen für diese erwarteten Probleme zu finden. Sie versuchen, sich auf geschäftliche Anforderungen vorzubereiten.

Sie sind ein besserer Entwickler als ich und sagen, dass ein "neues Framework" eine "schnellere" Entwicklung ermöglichen wird.

Sie zitieren hier "schneller". Ich bin mir nicht sicher, ob Sie dem Entwickler in diesem Punkt nicht glauben oder an seinem Wert zweifeln.

Aber aus meiner Sicht ist eine solide Auslieferung und Wartbarkeit wichtiger.

Dies stellt eine falsche Dichotomie mit schneller dar. Der Entwickler hält diese Dinge wahrscheinlich für implizit. Mit anderen Worten: Aktuell können wir eine solide Liefer- und Wartbarkeit bieten. Wenn wir auf das neue Framework umstellen, können wir schneller eine solide Bereitstellung und Wartbarkeit bereitstellen .

Andererseits heben Sie gültige technische Punkte hervor. Der Plattformwechsel ist wirklich ein großes Unterfangen. Ich würde es mir nicht leicht machen.

Ich schlage vor , den Entwickler nach bestimmten Schmerzpunkten im aktuellen System zu fragen. Gehen Sie davon aus, dass sie gute Gründe haben, darüber nachzudenken, was sie tun, und fragen Sie danach. Wurden sie gezwungen, hässliche Hacks zu verwenden, die sich im ganzen System häufen? Verbringen sie Zeit damit, Fähigkeiten zu schaffen, die bereits in modernen Systemen vorhanden sind? Ist das aktuelle System schlecht strukturiert und sie müssen damit kämpfen, um Dinge zu erreichen, die einfach sein sollten?

Wenn es spezifische Probleme gibt, wollen sie diese Probleme lösen. Wenn der Plattformwechsel zu viel ist, fragen Sie, ob sie weniger drastische Wege zur Lösung vorschlagen können. Vielleicht haben sie ein paar Ideen. Oder Sie stellen fest, dass die Probleme wirklich erheblich sind und das Verbleiben beim aktuellen System das größere Risiko darstellt.

Sie schreiben: „Entwickler kümmern sich um das System“. Ja, ich stimme zu. Aber gerade jüngere Entwickler haben vielleicht andere Prioritäten als erfahrenere Entwickler. Und das Management hat wieder andere Prioritäten. Ich denke, wir sollten nicht davon ausgehen, dass sie alle die gleichen Prioritäten haben.
Ich habe sicherlich Entwickler gekannt, die daran interessiert waren, das neue Glänzende zu erkunden, weil es neu und glänzend war, unabhängig davon, ob es tatsächlich die richtige Antwort für das Unternehmen war oder nicht. Dennoch ist der Rat, nach bestimmten Fahrgründen zu fragen, ausgezeichnet.
@BenBarden Ich muss deine Worte verdoppeln. Ich habe eine ganze Reihe von Entwicklern gesehen, die neue Technologien vorangetrieben haben (und einige Male auch sehr alte), nur weil es das war, was ihnen gefiel, und nicht das, was das Beste für das vorliegende Problem wäre. Das Erlernen neuer Techniken ist gut - sie ohne angemessene Sorgfalt über ein Problem zu zwingen, ist es nicht.
Nachdem ich gesehen habe, dass so viele Geschäftsleute die technischen Implikationen von etwas nicht verstehen und den Entwickler genau mit diesen Begriffen abtun, bin ich skeptisch geworden. Wenn ein Entwickler davon spricht, etwas „schneller“ zu machen, liegt das daran, dass die aktuelle Situation es schmerzhaft langsam macht. Das ist eine geschäftliche Auswirkung, für die Geschäftsleute allzu oft blind sind.
Als Techniker, der derzeit das Chaos eines Entwicklers aufräumt, der darauf bestand, die glänzenden neuen Dinge zu verwenden, ohne ihren tatsächlichen Wert zu berücksichtigen, würde ich sagen, dass diese Medaille definitiv zwei Seiten hat. Einige der glänzenden neuen Dinge, die er eingeführt hat, sind tatsächlich ziemlich hilfreich, aber einige waren eine große Zeitverschwendung. Es ist klar, dass er nicht viel über die tatsächlichen geschäftlichen Bedürfnisse nachgedacht hat, also scheinen die Dinge, die erfolgreich waren, genauso viel Glück zu haben wie alles andere ...
Es gibt unzählige Business Cases, die in beide Richtungen gehen. Wenn Leute "NoSQL" hinterherjagten und es dann mit PHP zum Laufen brachten und ihr Geschäft stark transaktionsbasiert ist, dann ist das einfach Dummheit. Wenn Sie darauf bestehen, traditionelles RDBMS zu verwenden, aber dann JSON-Blobs speichern, ist es auch dumm.

Wenn Sie der Personenmanager sind, treffen Sie die Entscheidung. Es ist schön, wenn sich alle einig sind, wichtig ist, dass alle die Entscheidung respektieren .

Sie sollten die Entscheidung treffen, die für das Unternehmen am besten ist. Es ist gut, Code zu haben, der bei Bedarf von Ihnen oder von einem neuen Entwickler ohne Spezialkenntnisse gehandhabt werden kann. Andererseits ist es gut, ein Framework zu verwenden, wenn es wirklich hilft und nicht nur in Mode ist. Alles, was eine Änderung Ihres bestehenden Codes erfordert, ist negativ. Es ist gut, einen begeisterten Mitarbeiter zu haben, der bestrebt ist, gute Ergebnisse zu erzielen, um zu beweisen, dass er Recht hat. Es ist Ihre Aufgabe, die Vor- und Nachteile abzuwägen, zu entscheiden, was am besten ist, und die Entscheidung zu treffen.

Wie wäre es, wenn Sie gemeinsam mit allen eine Liste mit Vor- und Nachteilen der verschiedenen Frameworks erstellen. Es sollte technische Aspekte enthalten, was mit den Frameworks getan oder nicht getan werden kann, wie schnell Dinge erledigt werden können, Stabilitätsprobleme, Geschichte (ein Framework ist vielleicht stabil, das andere ist brandneu und hat vielleicht noch einige Fehler). usw.

Ich denke, es ist am besten, dies zusammen mit dem Team in einer mehr oder weniger zufälligen Reihenfolge zu erstellen. Vielleicht wollen die Entwickler zuerst über die guten Dinge am neuen Framework sprechen und später fragen Sie sie nach Stabilitätsproblemen usw. In diesem Stadium geht es nur darum, Informationen zu sammeln.

Und nachdem das erledigt ist, können Sie sich die Prioritäten ansehen. Dh für ein Projekt oder einen Teil des Projekts sollte das Interface vielleicht trendy aussehen und vielleicht ist das mit dem neuen Framework einfacher zu bewerkstelligen. Und für einen anderen Teil ist es vielleicht wichtiger, dass alles 100% stabil ist, auch wenn es länger dauert usw.

Wenn Sie dies gemeinsam mit dem Team tun, sollten Sie alle zu dem gleichen Schluss kommen, welches Framework wofür verwendet werden sollte.

Aber am Ende des Tages sind Sie der Manager und dafür verantwortlich. Es ist also dein Kopf, wenn etwas schief geht. Sie müssen entscheiden, am besten mit dem Team, aber notfalls auch gegen deren Rat (nachdem Sie alle die Vor- und Nachteile kennen).

und die Kosten für die Neuentwicklung der Systeme
Ich stimme voll und ganz zu, außer dass das OP den betreffenden Entwickler diese Arbeit ausführen lassen sollte. Lassen Sie sie die Vor- und Nachteile herausarbeiten und eine Präsentation vor dem gesamten Team halten, um alle zu überzeugen, warum ihr Ansatz vorteilhaft ist.
@TheoTiger: Wenn du diesen einen Entwickler schlecht aussehen lassen willst, dann tu das. Wenn Sie ein glückliches Team wollen, dann bin ich sicher, dass es besser ist, das Team zusammenarbeiten zu lassen und gemeinsam herauszufinden, was das Beste ist.
@Edgar Das Team herausfinden zu lassen, ist eigentlich Teil dessen, was ich vorgeschlagen habe: Wenn dieser Entwickler eine Idee hat, um die Entwicklungsstrategie des Unternehmens zu verbessern, lassen Sie ihn einen Pitch machen und das Team darüber diskutieren. Wenn sie alle überzeugen können, warum ihr Ansatz gut ist, gut. Wenn nicht, erhalten sie Feedback, warum ihre Idee nicht in allen Aspekten überlegen ist und erfahren, wie Entscheidungen im Unternehmen getroffen werden. Beides sind wichtige Lektionen, die sie durch diese Praxis lernen könnten.

Ist der Entwickler nur um sich selbst besorgt und nicht um das Team/Projekt?

Professionals sind immer um sich und ihre Karriere besorgt, und wenn das Projekt / Team dazu passt, umso besser. Das ist vollkommen akzeptabel. Ihr Kollege möchte irgendwohin gehen, wo er diese neuen Technologien einsetzt, und wahrscheinlich viel besser bezahlen als Sie.

Wenn sie hier nicht glücklich sind, soll ich sie drängen zu gehen?

Sie drängen niemanden zu gehen. Sie sprechen mit ihnen über ihre zukünftige Karriere in Ihrem Unternehmen, setzen Erwartungen, hören Beschwerden und sprechen darüber, wie sie als Führungskraft besser für sie arbeiten können. Wenn der einzige Weg, wie jemand glücklich sein wird, darin besteht, dorthin zu gehen, wo die glänzende und sexy Technologie verwendet wird, ist das etwas, was Sie aus ihm heraus erahnen müssen, nicht etwas, das Sie ihm sagen.

Es hört sich so an, als würden Sie den Entwickler bereits seine Fähigkeiten in neuen Projekten üben lassen, und Sie haben den Grund erklärt, warum Sie das sensible System nicht auf neuere Technologien migrieren. Vielleicht haben sie es nicht verstanden, vielleicht hast du es nicht richtig erklärt. Betonen Sie unbedingt, dass dies wenig mit der tatsächlichen Entwicklungszeit zu tun hat und alles mit externem Druck.

Eigentlich nein - ich würde sagen, dass ich als Profi immer um das Projekt/Team besorgt bin und wenn meine Karrieren/Interessen dazu passen, umso besser.

Sie haben zwei Probleme, die miteinander in Konflikt stehen könnten

  1. Verwalten des "technischen Stacks"
  2. Führung einer technischen Person

Die Verwaltung des „technischen Stacks“ entscheidet darüber, welche Sprachen, Tools, Frameworks und Testsysteme das Unternehmen verwendet – insbesondere für kritische Produktionsaufgaben. Kein Entwickler sollte berechtigt sein, diesen Stack zu ändern. Dies ist eine Entscheidung, die in der Befehlskette nach oben geht, da sie die Compliance und Auditierung Ihres Unternehmens betrifft. Viele Entwickler sind sich nicht aller Kosten bewusst, die ins Spiel kommen. Wenn Ihr Top-Management vorher nicht beteiligt war, empfehle ich, ihm eine Präsentation darüber zu machen, was die Probleme wirklich sind – warum Sie den aktuellen Technologie-Stack haben, wie hoch die Kosten für Änderungen sind und wie Sie Änderungen präsentieren werden sie in der Zukunft. Kurz gesagt, Sie ziehen Ihre gesamte Managementkette, um Sie bei Ihren Entscheidungen zu unterstützen. "Entwickler, dies ist der technische Stack des Unternehmens XYZ.

Hat sich ein Unternehmen nun für den „technischen Stack“ entschieden, geht es um den Umgang mit einem Entwickler, der ein neues Framework einsetzen möchte. Sicherlich können solche für unkritische Aufgaben verwendet werden, um herauszufinden, wie hoch die gesamte Bandbreite der Kosten sein könnte. Ich empfehle jedoch, einen schriftlichen Prozess zur Bewertung neuer Technologien zu haben, die für kritische Produktionsarbeiten in Betracht gezogen werden könnten. Auch hier müssen die Ergebnisse dieser Bewertung mit einer Kosten-Nutzen-Analyse in der Befehlskette nach oben gehen, um das Top-Management von einem Wechsel zu überzeugen.

Ich sage das, nachdem ich ein Entwickler war, der neue Technologien in Projekten versteckte und solche Dinge benutzte, um zu versuchen, das Management auf solche neuen Technologien umzustellen. Ich kannte nicht alle Kosten, die ich dem Unternehmen aufbürden wollte. Ich habe mich geirrt. Das ist ein Verhalten, das nicht bei kritischen Projekten vorkommen muss.

Als Software-Profi, der in diesem Geschäft seit ... (koff, koff, keuch) ... "schon eine ganze Weile" ist, ist die Grundsituation, die Sie jetzt beschreiben, "Legacy -Systeme".

Zum Beispiel: „Mein jetziger Arbeitgeber stellt seit mehr als 85 Jahren Sofas her.“ Als IBM das „ System/36 “ zum ersten Mal vorstellte, kauften sie eines. Als "RPG" die beste Sprache der Wahl war, haben sie Berge von Code damit geschrieben ... und sie verkaufen immer noch Sofas!" (Und: "Diese Sofas sind immer noch bequem - wetten, Sie kennen jemanden, der eines besitzt.")

Daher gibt es und wird es immer eine „Dichotomie“ geben zwischen den Technologien, für deren Verwendung wir uns entschieden haben, und den Technologien, die wir heute lieber verwendet hätten, wenn sie schon erfunden worden wären. Aber wir können niemals erwarten, dass "neue Programmierer" dies verstehen ... noch nicht. 🤷‍♂️

Umgang mit Mitarbeitern, die neue Frameworks in Software für kritische Systeme verwenden möchten, aber ich nicht
AntwortenHierDatenschutz-Bestimmungen1y, 1v