Wie geht man mit einem älteren Kollegen mit potenziell schlechten Arbeitsgewohnheiten um?

Die anderen Antworten decken viel ab, aber ich werde etwas anderes hinzufügen.

Warum erlauben Ihre Prozesse ihm den offenen Zugriff auf jeden Produktionsserver?

Sie sollten Ihr Bereitstellungssystem so einrichten, dass es automatisiert, reproduzierbar und geschlossen ist – niemand sollte in der Lage sein, das Bereitstellungssystem zu umgehen.

1. Entfernen Sie alle Entwicklerzugriffe auf die Produktionsserver. Erlauben Sie ihnen den Fernzugriff auf die Systemprotokolle und die Debugger, aber das war es auch schon.

2. Führen Sie Ihre gesamte Codeerstellung und Paketierung über ein Continuous-Integration-System wie TeamCity aus.

3. TeamCity erstellt Ihre spezifischen Branches und Tags in Git – lassen Sie die Komponententests und Integrationstests ausführen.

4. Stellen Sie Ihren gesamten Code über ein automatisiertes Bereitstellungssystem wie Octopus Deploy bereit – dies nimmt die gepackte Ausgabe Ihres CI-Systems und stellt sie auf automatisierte und reproduzierbare Weise in jeder von Ihnen eingerichteten Umgebung bereit. Es kann bestimmte Zweige in Ihrer Entwicklungsumgebung bereitstellen, diese Pakete zu UAT oder Produktion hochstufen, und es wird Ihren Entwicklern niemals erlauben, in der Produktion herumzuspielen. Es gibt Ihnen auch ein vollständiges Prüfprotokoll darüber, was wo bereitgestellt wurde.

Verwenden Sie die Prozesse, um die Einschränkungen für Ihre Entwickler durchzusetzen – bis Sie dies tun, wird immer jemand Ihre manuellen Prozesse umgehen, weil er „besser als Sie“ ist.

Wenn Ihre Entwickler keine Administratorrechte für die Produktionsserver haben, können sie Ihre Prozesse nicht umgehen.

Ihre Deployment-Prozesse sind Teil Ihres Systems – im Falle eines Serverneuaufbaus sollten Sie in der Lage sein, Ihren gesamten Code auf die gleiche Weise wie zuvor bereitzustellen. Sie werden dies unglaublich schwierig finden, wenn der Bereitstellungsprozess manuell ist, da so viel undokumentiert ist, während bei einem automatisierten Bereitstellungsprozess zumindest die Automatisierungskonfiguration als minimale Dokumentation fungiert – Sie klicken nur auf eine Schaltfläche und haben alle relevanten Pakete bereitgestellt auf den neuen Server. Keine Aufregung, keine Probleme, einfach erledigt.

Bearbeiten: Siehe auch meine Antwort auf So vermeiden Sie schlechte Arbeitspraktiken von Mitarbeitern , da dies auch für Ihre Situation relevant ist. Sie müssen als Torwächter fungieren, und dazu müssen Sie tatsächlich einige Tore in die Praxis umsetzen.

Zweite Bearbeitung: Ein paar Leute in den Kommentaren haben die Besorgnis geäußert, dass dies keine sofortige Lösung ist - leider, es sei denn, der betreffende Entwickler hat über Nacht eine Offenbarung, dann wird nichts weniger als das Verlassen des Entwicklers eine sofortige Lösung sein.

TeamCity und Octopus Deploy (Sie müssen diese nicht verwenden, es gibt andere da draußen) sind recht einfach einzurichten und in Betrieb zu nehmen - sie sollten ungefähr einen Tag dauern, um installiert und konfiguriert zu werden, plus ungefähr eine Stunde pro Projekt Aufbau.

Aber selbst der Beginn des Prozesses zur Automatisierung des Bereitstellungsprozesses sollte beim Entwickler des Problems etwas auslösen – es sollte ihm sofort zeigen, aus welcher Richtung der Wind weht, und das kann ausreichen, um ihn dazu zu bringen, eine Entscheidung in die eine oder andere Richtung zu treffen. Sollten sie mit dem Teamlead bleiben und zurückfallen, oder sollten sie weiterhin abgeschottet bleiben und riskieren, gehen zu müssen ...

Eine andere zu berücksichtigende Sache ist, dass dieser Entwickler anderen Teammitgliedern zeigt, dass sie mit schlechten Praktiken davonkommen können - ich wette, es gibt andere Teammitglieder, die still und leise Korrekturen in der Produktion vornehmen, Fehler vertuschen usw. Das sind die Dinge, die schnell dazu führen, dass Sie im Bedarfsfall kein identisches Produktionssystem mehr aufbauen können. Und glauben Sie mir, es wird entstehen.

Lassen Sie ihn wissen, dass er an Ungehorsamkeit beteiligt ist und dass seine Ungehorsamkeit Konsequenzen haben wird. Sagen Sie ihm, dass ein Teil Ihrer Arbeit darin besteht, die Integrität des Software-Engineering-Build-Prozesses zu schützen, und er macht einen Hasch daraus.

Wenn er fortfährt, unterbrechen Sie seinen Zugriff auf den Master- und den Produktionsserver. Sagen Sie ihm dann, dass er sich auf einem PIP befindet, wo seine erste Aufgabe darin bestehen wird, Ihnen zu erklären, wie er beabsichtigt, seinen Code in Zukunft auf den Master und die Produktionseinheit hochzuladen (*).

Als Teamleiter benötigen Sie einen erfahrenen Entwickler. Du brauchst keine Kopfschmerzen. Insbesondere ein Kopfschmerz, der die Primadonna spielt und so tut, als würden die Regeln für alle außer ihm gelten.

(*) Er muss es dir sagen, weil du es ihm bereits ausdrücklich gesagt hast und er das, was du gesagt hast, nicht ernst genug genommen hat, um es zu verstehen. Wenn die Vernunft nicht funktioniert, versuchen Sie es mit Religion, z. B. mit dem "Blitzschlag auf der Straße nach Damaskus" - ich bin äußerst flexibel in meinen Managementmethoden und meinem Ansatz :)

Und wenn er gebeten wird, alles zu organisieren, kommt er zurück und sagt, dass er höhere Prioritäten hatte, wie die Bereitstellung neuer Dinge in der Produktion.

Von allem in der Frage scheint mir dies der beste Ansatz zu sein, um zu handeln. Wer setzt seine Prioritäten? Wenn Ihre Teams wie unsere organisiert sind, liegt es in der Verantwortung des Teamleiters, seine Prioritäten zu setzen. Lassen Sie ihn also wissen, dass Sie erkennen, dass Sie ihm Ihre Prioritäten nicht ausreichend mitteilen und dass Sie zusätzliche Anstrengungen unternehmen werden, um sicherzustellen, dass sie richtig kommuniziert werden.

Eine Person wie diese wird höchstwahrscheinlich eine Antwort erhalten, da dies nicht das erste Mal ist, dass ihr jemand dies sagt. Ich kann nicht sagen, wie diese Antwort lauten wird, aber sie wird dem eigentlichen Problem viel näher kommen. Es wird offen sein, damit Sie besser damit umgehen können.

Vielleicht bin ich zu subtil. Nur für den Fall, ich werde direkter sein. Jeder in der Position eines „leitenden Entwicklers“ sollte wissen, wie sehr er es vermasselt, wenn die Führung anbietet, ihm zu „helfen“, indem er „zusätzliche Anstrengungen unternimmt, um sicherzustellen, dass die Prioritäten klar sind“. Sie sollten schnell erkennen, dass das wirklich bedeutet, dass sie dabei sind, jegliche Wahlfreiheit in ihrem Ansatz zu verlieren, bis sie sich formieren.

Machen Sie deutlich, dass dies unbedingt erforderlich ist.

Hast du das schon gemacht? Als Manager weiß ich, dass es schwierig sein kann, Mitarbeiter direkt zu konfrontieren, wenn sie etwas Inakzeptables tun. Du erwähnst, dass es ein Gespräch in etwa so gab:

Sie: Können Sie bitte Ihren Code organisieren und den Entwicklungsworkflow, den wir besprochen haben, richtig verwenden?

Leitender Entwickler: Dazu bin ich noch nicht gekommen, weil ich diese dringenden Features herausbringen muss.

Was ich mich frage ist, was war Ihre Antwort darauf? Haben Sie deutlich gemacht, dass Sie mit dieser Priorisierung nicht einverstanden sind und fortan keine Neuentwicklung mehr erfolgen soll, bis er den richtigen Prozess implementiert? Wenn nicht, dann hat der leitende Entwickler wirklich keine klare Botschaft erhalten. Er könnte denken, dass seine Wahl unter den gegebenen Umständen die richtige war.

Der erste Schritt besteht darin, klar zu sagen, was Sie erwarten.

Ich sehe viele Antworten, die darauf hindeuten, dass Sie ihn wissen lassen, dass sein Job auf dem Spiel steht usw. Aber tun Sie das nicht, bis dieser grundlegende Schritt erfolgt ist. Er muss wissen, dass dieser Entwicklungsprozess obligatorisch ist und seine Einrichtung Vorrang vor allem anderen hat.

Der zweite Schritt besteht darin, ihn beim Erlernen des Prozesses zu unterstützen.

Ich würde ihm anbieten, sich von einem anderen Entwickler zeigen zu lassen, wie es aufgebaut ist. Sie sagen, dass sein Mangel an Git-Wissen das Problem ist (obwohl er behauptet, es zu wissen). Wenn Sie sich dessen nicht zu 100 % sicher sind, müssen Sie es nicht direkt ansprechen. Weisen Sie einfach darauf hin, dass es für ihn einfacher und schneller wäre zu sehen, wie jemand anderes es bereits eingerichtet hat, und es würde sicherstellen, dass alle Dinge auf die gleiche Weise tun.

Wenn es auf lange Sicht ein konsistentes Muster gibt, die Tatsache, dass er etwas nicht weiß, mit Problemumgehungen zu verbergen, dann ist dies ein Problem, das auf irgendeine Weise angegangen werden muss (da es ziemlich schädlich sein wird).

Schritt drei ist eskalieren – nur wenn die oben genannten Punkte nicht funktionieren.

Andere Antworten haben Hinweise dazu gegeben.

Ihren bevorzugten Commit-Pfad obligatorisch zu machen, ist an sich eine gute Praxis, aber verwenden Sie ihn nicht, um dieses Problem zu lösen.

Das grundlegende Problem ist, dass der leitende Entwickler Ihre Rolle als Teamleiter respektieren und von Ihnen eingeführte Praktiken akzeptieren muss. (Umgekehrt müssen Sie Ihre Erwartungen auch klar kommunizieren, wenn dies nicht der Fall ist). Dies nicht zu tun und stattdessen das Problem mit Technologie zu überspielen, wäre ein Fehler.

Sobald jedoch die oben genannte Kommunikation stattgefunden hat, wäre es eine gute Idee, den Prozess auch obligatorisch zu machen.

Sie benötigen eine ordnungsgemäße Codekontrolle und -überprüfung. Wenn er den Prozess versteht und ohne außergewöhnlich guten Grund dagegen verstößt, brauchen Sie ihn nicht im Team. Sag es ihm.

Prioritäten: Es liegt in Ihrer Verantwortung, die Prioritäten klar zu machen. Wenn er in eine andere Richtung geht, nachdem Sie dies getan haben und er bestätigt hat, brauchen Sie ihn nicht im Team. Sag es ihm.

Erinnern Sie ihn gegebenenfalls daran, dass sich die Bewertung seiner Arbeit durch den Teamleiter auf seine Jahresbilanz auswirkt.

Geben Sie ihm eine faire Chance zu erklären, warum dieser eine Fall etwas Besonderes war ... aber wenn er keine angemessene Verteidigung hat (Ihrer Meinung nach nicht seine) und er nicht bereit ist zu versprechen, dass es nicht wieder vorkommen wird, dann schon Zeit für ein Gespräch mit seinem Vorgesetzten.

Hier sind 2 Angriffslinien notwendig:

1. Sie brauchen einen Prozess, der es einfach macht, das Richtige zu tun, und schwer, das Falsche zu tun.
2. Das Team muss sich darauf einigen/akzeptieren, was das Richtige ist.

Die Antwort von moo deckt bereits 1 ab, also konzentriere ich mich auf 2).

Ihr Team sollte wissen, dass es einen stabilen Branch, einen einigermaßen stabilen gemeinsam genutzten Branch und eine gemeinsame Merge-Strategie benötigt, die sicherstellt, dass die Leute wissen, welche Änderung sich in welchem ​​Branch befindet, was bedeutet, dass jeder Dinge durch Branches in der gleichen Reihenfolge zusammenführt. Wenn sie das nicht wissen, schicken Sie sie zu einer obligatorischen Schulung, die von einem Dritten durchgeführt wird . Ja, es ist teuer, aber ein Team zu haben, das Branching nicht versteht, ist auf lange Sicht teurer.

Sie können normalerweise andere Entscheidungen, wie das Öffnen eines temporären Unterbranch für ein Feature, dem Team überlassen, solange Sie sicherstellen müssen, dass Entscheidungen, die das Team betreffen, vom Team getroffen werden und nicht von einem einzelnen Entwickler.

Sie können die Teamarbeit mit Retrospektiven erleichtern, Meetings, bei denen das Team nach jedem Feature/Meilenstein/Sprint zusammenkommt und bespricht, wie es als Team besser hätte sein können – die Häufigkeit dieser sollte etwa einmal alle 1-4 Wochen sein, und Sie können Finden Sie tonnenweise Material über Retrospektiven online. Wenn das Team sich mit Verzweigungen auskennt, sollte Ihr einzelner Entwickler während der Retrospektiven vom gesamten Team kritisiert werden, nicht von Ihnen. Sie können dann das Team anleiten, automatisierte Prozesse einzurichten, die es einfacher machen, Dinge richtig zu machen, und sehr schwer, Dinge falsch zu machen. Dies sind die Prozesse, die in der Antwort von moo beschrieben werden.

Im Allgemeinen können Sie als direkter Vorgesetzter einen großen Prozess, mit dem Ihr Team nicht einverstanden ist, nicht einfach implementieren und durchsetzen, ohne dass ein sehr hohes Risiko von Folgen besteht. Wenn sie sich nicht mit der richtigen Verzweigung auskennen, müssen Sie sie auf „den richtigen Weg“ schulen, dann können Sie kleinere Prozesse implementieren und durchsetzen, um sie zu zwingen, als Team zu arbeiten: Eine gängige Methode in Ihrem Fall besteht darin, einen Code zu verlangen Überprüfung einer Zusammenführung mit „Develop“ und „Master“; Wenn das nächste Mal eine Zusammenführung falsch gemacht wurde, können Sie jetzt 2 Personen fragen, was schief gelaufen ist, den Programmierer und den Prüfer.

Sie tun dies, indem Sie strenge, physische Richtlinien einführen, die erfordern, dass Änderungen in einem bestimmten Repo überprüft werden oder dass sie nicht bereitgestellt werden, was bedeutet, dass die Arbeit nicht erledigt wird, was bedeutet, dass er seine Arbeit nicht erledigt, und das ist ein Grund dafür Beendigung. Wenn Ihre Teamstruktur „entspannt“ ist und Entwickler Schlüssel für die Produktion haben und selbst bereitstellen können, oder über DB-Anmeldeinformationen verfügen, um DB-Schemaänderungen selbst bereitzustellen, und nicht die vom MANAGEMENT EINGEFÜHRTEN PROTOKOLLE durchlaufen , ist die Schlussfolgerung einfach: du kommst nicht gut zurecht. Das Management in einer Softwareentwicklungsumgebung besteht hauptsächlich darin, die Teamregeln und -protokolle zu entwerfen, an die sich die Teammitglieder halten MÜSSEN, und nicht täglich die Entwickler zu babysitten.

Sie fordern Ihre Untergebenen nicht auf, die Dinge auf eine bestimmte Weise zu tun. Sie haben alle notwendigen Werkzeuge zur Verfügung, um sie zu zwingen, die richtigen Protokolle zu befolgen. Dies ist kein Problem mit Ihrem Mitarbeiter, sondern ein Problem mit Ihrer Organisation und einem Mangel an Strukturen und Regeln, die das Leben einfacher, einfacher und effizienter machen.

Es gibt eine Möglichkeit, an die niemand gedacht hat: Dass dieser leitende Entwickler einfach nicht versteht, wie der Workflow funktionieren sollte und was er tun muss, um innerhalb dieses Workflows zu bleiben. Dass er nie gelernt hat, Git richtig einzusetzen.

Wenn er Git direkt verwendet, sind alle Dinge, die er tun muss, eigentlich ziemlich kompliziert, also haben Sie hoffentlich noch ein Tool. Sourcetree funktioniert recht gut; Ich bin sicher, es gibt andere. Einmal richtig eingerichtet (was ein Schmerz sein kann), macht es das Leben viel einfacher.

Nehmen Sie einen der Entwickler, der alles richtig macht, und überprüfen Sie mit ihm, wie die Maschine dieses Typen eingerichtet ist. Hat er die Werkzeuge, die alle anderen haben? Wenn nicht, richten Sie sie ein. Kann er einen Zweig erstellen? (Auf meinem Rechner wählen Sie den Zweig aus, von dem Sie verzweigen möchten, wählen einen Menüpunkt aus und geben den Namen des neuen Zweigs ein). Ohne die richtigen Werkzeuge ist es ein Schmerz. Vielleicht weiß er wirklich nicht, wie das geht.

Gehen Sie mit ihm durch alle Dinge, die er tun muss. Lassen Sie ihn alle Schritte aufschreiben, die er tun muss. Das habe ich gemacht, als ich Git zum ersten Mal benutzt habe: Ich habe alles aufgeschrieben. Beim zweiten und dritten Mal verfeinerte ich das Geschriebene, weil es nicht ganz funktionierte und es Situationen gab, mit denen ich nicht gerechnet hatte. Vom vierten bis zum zehnten Mal habe ich meine Notizen benutzt, um Dinge zu erledigen, und dann brauchte ich sie nicht mehr. Ich konnte jemanden sehen, der nicht wusste, welche Werkzeuge er verwenden sollte und wie er sie verwenden sollte, zu stolz oder eigensinnig war, jemanden um Hilfe zu bitten, und auf dem Weg ein unheiliges Chaos verursachte.

Wow. Einfach wow. Das ist so zutiefst unprofessionell, es ist unglaublich. Aber sprechen Sie zuerst mit der Personalabteilung, um sicherzustellen, dass sie an Bord sind und dass Sie nichts tun, was ein rechtliches Problem für Ihr Unternehmen darstellen könnte. Dann sprechen Sie mit ihm, berücksichtigen alle Ratschläge der Personalabteilung und sagen ihm, dass Sie Schritte unternehmen werden, um ihn aus dem Team zu entfernen, wenn er dies noch einmal wiederholt. Was wahrscheinlich von der Firma bedeutet.

Stellen Sie sicher, dass die Personalabteilung versteht, welchen Schaden dieses unverantwortliche Verhalten anrichten kann.

Wie man ihn zum Aufhören überredet: Mindestens zwei Antworten hier führen dazu, dass er nicht dort angestellt wird, wo er jetzt ist, wenn er nicht wechselt. Das sollte überzeugen. Darüber hinaus ist es zutiefst unprofessionell und gefährlich, dies zu sagen.

Was sind die Risiken: Ein defekter Produktionsserver ist das kleinere Risiko. Ein Produktionsserver, der kostspielige Fehler macht, ist das große Risiko. Stellen Sie sich einen E-Commerce-Server vor, der Mehrwertsteuer berechnet, anstatt Mehrwertsteuer auf den Preis hinzuzufügen. Sie werden viele, viele sehr zufriedene Kunden haben.

Ist das ein Blocker: Nicht wirklich. Wenn ich einen Zweig mache, erwarte ich voll und ganz, dass der Entwicklungszweig geändert wird, wenn ich zusammenführen möchte, also gibt es keinen Unterschied. Wenn er über den Develop-Branch zum Master-Branch geht, ist das eine andere Sache. Wer für den Master-Zweig verantwortlich ist, erwartet eine große Überraschung. Wenn ich andererseits für den Master-Zweig verantwortlich wäre, würde alles, was nicht autorisiert ist, entfernt werden, und wer auch immer es tun würde, würde in Schwierigkeiten geraten.

Zusammenfassung:

• Abgesehen von den technischen und gesellschaftlichen Problemen, die von anderen angesprochen wurden, haben Sie einen großen unmittelbaren Bedarf – die Aktionen dieser einzelnen Person können die Möglichkeit eines katastrophalen Ausfalls an einem einzigen Punkt erzeugen.

  • dh während die meisten „Katastrophen“ passieren, weil mehrere scheinbar nicht zusammenhängende und statistisch unwahrscheinliche Ereignisse zufällig gleichzeitig aufgetreten sind. In diesem Fall kann ein einziges Ereignis ausreichen.

• Während Ihre Sorgfalt hoffentlich darauf gerichtet ist, die Ergebnisse für Ihren Arbeitgeber zu optimieren, ist es auch ratsam, sich Gedanken über Ihre eigene Position zu machen.

  • Das heißt, der Entwickler und damit Sie als sein Manager setzen das Projekt möglicherweise (und werden es wahrscheinlich) dem Risiko eines größeren Verlusts aus (gemessen in Bezug auf Zeit, Ressourcen, Notwendigkeit, Arbeit zu replizieren, Systemintegrität, Kundenvertrauen und mehr und mehr). letztendlich in $. Wenn ein solches Ereignis eintrat und schwerwiegend war, auch wenn es sich nicht um den „schlimmsten Fall“ handelt, gibt es keinen Grund zu der Annahme, dass Sie Ihren Arbeitsplatz nicht verlieren werden.

• Der oben genannte Verlust von noch unbekannter Größenordnung kann jederzeit eintreten – nächste Woche, heute oder nie.

• Systeme sind normalerweise so angeordnet, dass der Umfang/die Reichweite/das Ausmaß der Folgen aller vernünftigerweise vorhersehbaren Ereignisse erkennbar sind. In dieser Situation ist dies nicht der Fall, und dies muss sofort behoben werden.

  • Obwohl Sie wissen, dass die Handlungen des Mitarbeiters Sie in Gefahr gebracht haben, sind Sie sich der potenziellen Folgen wahrscheinlicher, möglicher und schlimmster Ereignisse bisher nicht bewusst. Festzustellen, was Sie nicht wissen, ist der erste Schritt, um die Dinge richtig zu stellen.

  • Sie sind in der Lage, sofort Maßnahmen zu ergreifen, um festzustellen, was Ihnen an der gesamten Situation unbekannt ist. Tun Sie dies. Jetzt. Legen Sie dann fest, welche Schritte dringend sind und welche sich möglicherweise etwas verzögern, und beginnen Sie dann mit der Behebung

__________________________________________________

Neue Frage für Ihre Liste:

Q0: "Was sind meine dringendsten Prioritäten?"

A0: STELLEN SIE SICHER, dass das, was Sie haben, gegen katastrophale Verluste stabil ist.

Es klingt nicht so, als wäre es.
Wenn nicht, machen Sie es so.
Jetzt!

_________________________

Die möglichen kurzfristigen Gefahren & Folgen & der beste Weg nach vorn:

Das Folgende soll nicht unhöflich, sondern „robust“ sein. Sagen Sie auf jeden Fall, wenn Sie nicht einverstanden sind. Wenn Sie damit einverstanden sind. tun Sie JETZT etwas Passendes.

Sie (oder andere) erwähnen „Maschine gestohlen , Unsicherheit in Bezug auf „ Backups “ usw. ...
Wenn dies in signifikanter Weise passiert ist, sollten Sie entlassen werden und würden es wahrscheinlich auch, nachdem Sie alle möglichen Abhilfemaßnahmen implementiert haben .

Sehen Sie sich ohne weitere Eingaben Ihre 2. (jetzt 3.) Frage an, entscheiden Sie, welche Risiken existieren KÖNNTEN, von denen Sie nichts wissen, weil das System nicht kontrolliert wird, und ergreifen Sie sofortige Maßnahmen, um diese Risiken zu beseitigen. Dies kann das Einfrieren aller Aktivitäten und/oder Dateien und/oder ??? vom Entwickler. Binden Sie sie also in den Prozess ein.

______________

Vorschläge für Punkte im Rahmen eines (dringenden) Interviews mit dem Entwickler:

Ich verstehe, dass xxx der Fall ist. Ist das so ja/nein?
Wenn ich das falsch verstehe, bitte klarstellen.

OK - wenn yyy passiert, was wird das Ergebnis sein?
(Wenn die Antwort falsch ist, sagen Sie warum und iterieren Sie, bis eine Einigung erzielt wird.
(Wenn die Iterationsschleife nach einer übermäßigen Zeit nicht geschlossen wird, verwenden Sie '45 Clear ' oder ein akzeptables lokales Äquivalent :-( :-))

Sobald Schlussfolgerungen hinsichtlich der Konsequenzen gezogen werden. Das ist für mich nicht akzeptabel. Dies bringt mich/das Unternehmen/das System in eine unzumutbare Gefahrensituation. Dies MUSS gestern angegangen werden. Ich bin dabei, xxx zu implementieren. Sind Sie einverstanden? / Können Sie Alternativen vorschlagen? Auch hier kann sich eine iterative Schleife ergeben. Auch hier kann die Verwendung von "GOTO" erforderlich sein ( oder nicht :-} ).

Wenn Sie dies oder etwas Ähnliches nicht tun, werden Sie als Konsequenz entlassen. Irgendwann.