Als ein Entwickler; Keine Zeit zum Testen bekommen, extreme Deadlines erhalten und vom Manager nicht angehört werden

Vor ein paar Monaten habe ich einen Job von jemandem übernommen, der aus den gleichen Gründen gekündigt hat, aus denen ich heute hier bin. Die Aufgabe umfasste die Entwicklung einer internen Anwendung, die hauptsächlich von den Mitarbeitern verwendet werden sollte. Die Person, die das Projekt aufgab, war noch nicht einmal annähernd fertig mit der Bewerbung, wurde aber krank und müde von Stress, extremen Fristen usw. Zu der Zeit schien es eine großartige Gelegenheit zu sein. Ich habe viel mehr Erfahrung als der vorherige Entwickler und das Projekt sah nicht so schwierig aus, also nahm ich das Projekt an.

Die Treffen verliefen großartig; Die Leute hörten auf meinen Rat. Wir haben in relativ kurzer Zeit große Sprünge gemacht. Fehler wurden behoben, die Benutzeroberfläche wurde überarbeitet, ein Großteil des Codes wurde im Hinblick auf die Wiederverwendbarkeit umgestaltet. Die Anwendung fing endlich an, wie etwas auszusehen und zu funktionieren.

Nach einer Weile wurden neue Funktionen angefordert, geplant und ausgeführt. Im Laufe der Zeit stellte der Manager immer wieder neue Funktionsanfragen, die er in extrem kurzer Zeit erledigen wollte. Zum Beispiel ein voll funktionsfähiges, produktionsreifes Flottenmanagementsystem in 14 Tagen, von Grund auf neu.

HINWEIS: Der Manager hat wenig bis gar keinen technischen Hintergrund.

Das hatte zur Folge, dass ich entweder schlecht geschriebenen und ungetesteten Code abliefere oder die vorgegebenen Deadlines nicht einhalte. Zwei schreckliche Situationen meiner Meinung nach.

Ich habe versucht, in Besprechungen darauf hinzuweisen, aber es wurde abgewunken mit Begründungen wie: "Der Endbenutzer sieht die Tests nicht, solange es funktioniert und gut aussieht, ist es in Ordnung, die Markteinführungszeit ist wichtiger." Und der letzte Grund, den ich am meisten hasse, war: "So ein kluger Entwickler wie Sie muss das in x Zeit erledigen können."

Wie kann ich deutlich machen, dass eine produktionsreife Anwendung oder Funktionen nicht in kurzer Zeit erstellt werden? Dass ein Prototyp nicht das fertige Produkt ist und dass die Codeabdeckung, das Testen, das Freigeben von Betas usw. äußerst wichtig sind, um Qualität zu liefern?

Haben Sie versucht, die Bemerkung „so ein kluger Entwickler wie Sie“ umzukehren, indem Sie diese Anmeldeinformationen und Ihre Erfahrung verwendet haben, um zu erklären, warum diese Fristen unmöglich sind? Mit anderen Worten, was haben Sie tatsächlich versucht, bevor es keine Wirkung hatte?
Haben Sie darauf hingewiesen, dass dies der Grund dafür ist, dass der letzte Entwickler aufgehört hat? Oder, ich schätze ganz allgemein, was (wenn überhaupt) haben Sie eigentlich zu Ihrem Chef über seine unangemessenen Fristen gesagt?
@Lilienthal Ich habe das tatsächlich versucht, es hat ungefähr 5 Minuten lang funktioniert. Das letzte, was ich versucht habe, war, mit ihm zu Mittag zu essen, um zu versuchen, ihm zu erklären, wie Softwareentwicklung tatsächlich funktioniert. Welche Voraussetzungen erfüllt sein müssen, bevor es in die Produktion geht, am Beispiel einiger bekannter, relativ einfacher Anwendungen. Dies wurde als unwichtig abgetan, so arbeiten wir nicht.
@Odysee Oof, dann hast du mein Mitgefühl. Erwägen Sie, diesen Kommentar zu Ihrem Beitrag hinzuzufügen, obwohl ich vermute, dass Sie bereits viel Input erhalten und entschieden haben, was Ihre nächsten Schritte sind.
@BernardDy Wenn überhaupt, jetzt, da dieser Beitrag mehr und bessere Antworten enthält als das Ziel, auf das Sie hingewiesen haben, würde ich sagen, dass der Zielbetrug rückgängig gemacht werden sollte. Habe diesen anderen Beitrag als Dupe von diesem gestimmt
@Odysee, "Erwägen Sie, diesen Kommentar zu Ihrem Beitrag hinzuzufügen" - noch besser, erwägen Sie, diesen Kommentar zum Code hinzuzufügen!
Der wichtige Punkt ist wirklich: Niemand hat Zeit/Budget, Software zu bauen, ohne sie zu testen. Es ist nicht billiger, Tests wegzulassen, und es kostet auch nicht weniger Zeit.
Schwierige Frage, die wichtig sein könnte: Könnte dies der Grund dafür sein, dass der Code von Anfang an so ein Durcheinander war, als Sie ihn bekamen, aufgrund von Missmanagement und Management-bedingtem Mangel an Fokus auf Qualität, anstatt auf Entwickler-Inkompetenz? Wenn dies der Fall ist, können Sie dieses Problem möglicherweise nicht beheben.

Antworten (11)

HINWEIS: Der Manager hat wenig bis gar keinen technischen Hintergrund.

Dieser Manager hatte also vermutlich Zeit, sich einen technischen Hintergrund anzueignen, hat dies aber nicht getan. Wieso den? Er ist entweder desinteressiert oder nicht in der Lage. Behalten Sie das im Hinterkopf.

"Ich brauche ein Flottensystem in 14 Tagen".

Es tut mir leid, Boss, aber es dauert 28 Tage. Das ist das früheste, was ich liefern kann.

Es besteht keine Notwendigkeit, und es ist selbstzerstörerisch, einem solchen Manager den Softwareentwicklungsprozess zu erklären. Ihre Schätzungen müssen die „Steuer“ für Tests, Bereitstellung und Fehlerbehebungen enthalten. Beziehen Sie es einfach in Ihre Entwicklungszeit ein.

Wenn Sie mit der Programmierung eines solchen Systems fertig sind, es aber noch nicht getestet ist, sagen Sie ihm, dass es noch nicht fertig ist.

Ein besserer Ansatz wäre jedoch eher ein agiler Ansatz, bei dem Sie einige Funktionen implementieren und testen und diese ihm vorlegen. So sieht er etwas.

Sie könnten den Zeitplan wie folgt weiter aufschlüsseln:

  • Erstanwendung: 8 Tage
  • Bereitstellungsfunktion: 3 Tage
  • Tracking-Funktion: 5 Tage
  • Automatische Verlängerungsfunktion: 7 Tage

Wenn Sie so etwas tun, können Sie wahrscheinlich mit einem viel längeren Zeitplan davonkommen, als wenn Sie nur das gesamte Projekt zitieren würden. Der Manager ist zufrieden, da er in 8 Tagen etwas sehen wird und nicht in den 14, die er wollte. Es spielt keine Rolle, dass es keine echten Funktionen gibt. Sagen Sie nicht, dass für die anfängliche App eine Webanwendung erstellt, eine Datenbank entworfen usw. sein muss. Es ist ihm einfach egal.

Nach den kurzen Informationen in Ihrer Frage scheint dies eine großartige Gelegenheit zu sein. Sie leiten Ihr Projekt und können nicht an Ihren Fähigkeiten als Projektingenieur arbeiten. Außerdem werden Sie Ihre Fähigkeiten entwickeln, technische Ideen mit dem Untechnischen zu verhandeln. Das sind alles sehr wertvolle Erfahrungen. Viel Glück.

Sie sagen: „Ich habe noch nie ein Projekt unvollendet gelassen.“ Es ist Zeit zu beginnen.

Jeder Profi wird irgendwann einen Job kündigen, wenn der Kunde unvernünftig ist. Es gibt Chefs und Kunden, die nicht zufrieden sein können und gefeuert werden müssen. Wenn ich bereit bin, aufzuhören und zur Tür hinauszugehen, bin ich in allen Meetings oder Verhandlungen viel stärker.

Nachdem Sie an einem Flottenmanagementsystem gearbeitet haben, gibt es absolut keine Möglichkeit, eines in 14 Tagen zu liefern. Es ist fast unmöglich, das Problem in 14 Tagen zu definieren, geschweige denn zu lösen.

Dies ist kein allgemeiner Ratschlag für *jedes* IT-Projekt da draußen; Es ist speziell für diese Situation, in der eine scheinbar unmögliche Aufgabe von einem Management gestellt wird, das nicht zuhören will (oder kann), auch wenn Sie einfach nicht sofort aufhören wollen. Arbeiten Sie natürlich weiter an den "zwischenmenschlichen" Gesichtspunkten, um eine angemessene Lösung für die Kernprobleme zu finden.

Ich war in solchen Situationen. Auf technischer Ebene ist der Weg klar: solide, moderne Entwicklungspraktiken – agil, BDD/TDD, Automatisierung. Das bedeutet:

  • Tests werden vor den Code geschrieben, wobei ein einzelner Test und der Code verschachtelt werden, um diesen Test grün zu machen. Fühlen Sie sich frei, mit Integrationstests anstelle von Unit-Tests zu beginnen. Sie werden irgendwann umständlich (weil sie langsamer sind, um die gesamte Testsuite auszuführen), sind aber großartig, um schnell loszulegen.
  • Außer dem Minimum, das einen roten Test grün werden lässt, wird kein Code geschrieben.
  • Der Test ist Ihre Spezifikation. Wenn Sie es nach Hause hämmern wollen, verwenden Sie Cucumber. Dinge, die nicht getestet werden, sind nicht spezifiziert, und Dinge, die nicht spezifiziert sind, sind undefiniertes Verhalten.
  • Wann immer es irgendeine Art von "Werkzeug"-Arbeit gibt, auomatisieren Sie diese sofort. ZB Ihre Bereitstellung. Halten Sie es am Anfang einfach, auch wenn es nur hartcodierte Servernamen usw. sind, aber machen Sie es automatisiert. Die Zeitersparnis summiert sich hier wirklich schnell.
  • Sie arbeiten in einem agilen Framework wie Scrum oder Kanban. Wenn Ihr Management und Ihr Unternehmen sowieso nicht technisch versiert sind, würde ich auf Kanban setzen – was einfach bedeutet, dass Sie Ihre Arbeit in kleine, gut sichtbare Scheiben schneiden und WIP als höchste Priorität vermeiden.
  • Liefern Sie so schnell wie möglich eine erste funktionierende Version. Ein ganzes Flottenmanagement ist für 14 Tage zu viel, aber in 14 Tagen kann man was rausholen. Alles . Auch wenn es sich nur um eine einfache Webseite handelt, die durch eine Basisauthentifizierung geschützt ist und eine Liste der Autos im Pool anzeigt. Dann gehen Sie von dort aus weiter. Behandeln Sie dies nicht als "Prototyp" oder ähnliches, Sie werden nie die Zeit haben, bei Null anzufangen; Behandeln Sie es ab Tag 1 als Produktionscode.
  • Geben Sie keine Gesamtschätzungen ab. Statt „ich brauche 28 statt 14 Tage“ (was sowieso Quatsch ist, deine Anforderungen sind sicherlich nicht klar genug, um die 28 Tage überhaupt zu berechnen) sag „Klar Chef, ich fange sofort mit der Arbeit an. Siehe, hier ist der Rückstand /Kanban-Board, haben Sie Einfluss auf die Reihenfolge der Dinge?" usw. Wenn sie fragen "wann bist du fertig", antworte "Das kann ich nicht genau sagen, aber du siehst, wie ich die Aufgaben in vergleichbare Teile aufgeteilt habe, wir werden in den nächsten Tagen sehen, wie schnell die Arbeitsprozesse ablaufen, okay?" .
  • Gewöhnen Sie sie daran, dass Sie keine riesigen Projektpläne erstellen oder dass Software nach 14 Tagen aus dem Nichts als vollwertig erscheint. Machen Sie ihnen bewusst, wie ein Kanban-Board funktioniert, geben Sie ihnen vielleicht jeden Tag einen 15-minütigen Bericht, um sie „ins Boot“ zu holen. Ihre Geschwindigkeit wird ziemlich offensichtlich sein, es besteht keine Notwendigkeit, sich zu erklären, solange Sie ihnen zeigen, dass jeden Tag einige kleine inkrementelle Schritte herauskommen.
  • Wenn sie mit Fristen zu Ihnen kommen, finden Sie heraus, wie Sie die Arbeit auf das absolut notwendige Minimum reduzieren können; das in möglichst kleine einheiten aufteilen (die hoffentlich einzeln an die produktion geliefert werden können) und einfach crunchen. Lassen Sie sich , ich wiederhole, nicht unter Druck setzen, 18-Stunden-Tage oder ähnliches zu machen. Es funktioniert nicht. Ihre Produktivität lässt ohnehin nach einem normalen Arbeitstag nach. Burn-out verringert Ihre Geschwindigkeit unglaublich.
  • Vergessen Sie die Idee von "fertig". Die Software ist fertig, wenn der letzte Server ausgeschaltet ist. Sie werden nie ein leeres Backlog haben. Wichtig ist, dass du deine eigenen Standards hoch hältst (weil du weißt , dass du ohne sie mittelfristig scheitern wirst ) und dass du eine gesunde Geschwindigkeit behältst, die du auf unbestimmte Zeit halten kannst. Ja, das sind Schlagworte, aber sie haben tatsächlich eine Bedeutung.

Bleiben Sie auf persönlicher/IPS/menschlicher Ebene ruhig und hacken Sie weiter. Vermeiden Sie nicht-technische Diskussionen. Beschweren Sie sich nicht, aber sagen Sie, wenn Sie mehr Ressourcen (schnellerer PC, mehr serverseitige Knoten/RAM/HDD usw.) benötigen, um Ihre Entwicklung zu beschleunigen. Geben Sie ihnen Lösungen für individuelle Probleme; Seien Sie mutig und entscheiden Sie, wie Sie Dinge implementieren oder wo Sie Aufgaben in kleinere, lieferbare Einheiten aufteilen. Lassen Sie sich vom Kanban-Board sagen, dass es nicht so schnell geht, wie sie wollen, machen Sie das nicht selbst.

Viel Glück!

Ich sehe mehrere Probleme in der Kommunikation und im Verständnis zwischen Ihnen und Ihrem Vorgesetzten.

Warum überhaupt testen?

Es klingt, als hätten Sie das Testen als zusätzliches Arbeitspaket vorgestellt. Es ist keine zusätzliche Arbeit (oder sollte es nicht sein ), sondern ein fester Bestandteil Ihrer Arbeit. So wie ein Bauarbeiter kein Gebäude bauen kann, ohne sicherzustellen, dass alle Wände gerade sind, können Sie keine zuverlässige Software ohne Tests erstellen.

Erwähnen Sie das Testen nicht als separates Arbeitspaket, sondern kalkulieren Sie die Zeit für die Implementierung einschließlich des Testens ein. Es gibt nicht das eine ohne das andere.

Schnippe mit den Fingern und fertig!

Ihr Vorgesetzter hat offensichtlich kein Verständnis dafür, wie Softwareentwicklung funktioniert. Indem Sie viele Probleme in kurzer Zeit behoben haben, haben Sie seine Überzeugung bestätigt, dass Sie ein Zauberer sind, der Software aus dem Hut zieht.

Versuchen Sie ihm zu erklären, dass Sie keine bunten Fenster / Seiten erstellen, sondern Code . Komplizierter Code, vergleichbar mit komplizierten Bedienungsanleitungen für Computer. Es wird nicht umsonst Programmiersprache genannt .

So wie kein Autor eine ausführliche Bedienungsanleitung erstellen kann, können Sie ein kompliziertes Feature nicht in wenigen Tagen erstellen.

Ein Fuhrparksystem ist kein einfacher Absatz in einem Handbuch; es ist ein komplett neues Handbuch. Wenn Ihr Manager Ihnen nicht glaubt, bitten Sie ihn, Ihnen das Flottensystem zu beschreiben, jedes einzelne Detail bis hin zu dem Ort, an dem die Schlüssel für jedes Auto aufbewahrt werden.

Ein kluger Kerl wie Sie kann schneller

Weigern Sie sich, unrealistische Fristen zu akzeptieren. Listen Sie die Arbeitspakete auf, die Sie erledigen müssen, und wie viel Zeit Sie für jedes Paket einschätzen, rechnen Sie die Zeiten zusammen und setzen Sie Ihre eigene Deadline.

Das könnte die Stimmung Ihres Vorgesetzten verderben, zumal Sie am Anfang wie von Zauberhand so schnell gearbeitet haben. Untermauern Sie Ihre Schätzungen und Fristen mit Fakten und Listen; Machen Sie sie realer als die Vorstellung Ihres Managers.

Alles ist am wichtigsten

Erstellen Sie eine priorisierte Rangfolge aller Funktionen wie das Aufkleben von Haftnotizen auf eine Tafel. Jedes Feature hat einen Rang, und Sie implementieren sie in der Reihenfolge ihres Rangs. Wenn (oder besser gesagt, wenn) Ihr Manager neue Funktionen wünscht, lassen Sie ihn sie in diese Rangliste einsortieren. Das macht deutlich, dass manche Dinge warten müssen, bis andere fertig sind.

Immer noch nicht fertig???

Das ist mein herzlichster Rat: Lassen Sie sich aus Liebe zu sich selbst nicht ausbrennen! Du bist ein Mensch und kannst nur so viel und so hart arbeiten, bevor du dich selbst auffrisst. Arbeiten Sie so gut und so schnell, wie Sie es vernünftigerweise über einen längeren Zeitraum durchhalten können. Dinge, die nicht rechtzeitig erledigt werden, müssen warten. Machen Sie Ihrem Vorgesetzten klar, dass Sie alles in Ihrer Macht stehende tun, aber auf keinen Fall seine unrealistischen Erwartungen erfüllen können.

Sie haben hier zwei grundlegende Möglichkeiten.

  1. Sie codieren sich den Arsch ab und liefern das ungetestete Ergebnis in der angegebenen Zeitskala. Bekräftigen Sie erneut die Tatsache, dass es weitgehend ungetestet ist und daher das Risiko besteht, dass es kaputt geht oder nicht vollständig den Anforderungen entspricht, da im Ressourcen- / Projektplan keine Zeit dafür vorhanden war.

  2. Sie codieren es richtig und testen es, während Sie fortfahren. Dies dauert natürlich länger, liefert aber bessere Ergebnisse.

Bieten Sie dies Ihrem Vorgesetzten als Option an.

Unverblümt:

Willst du es jetzt machen oder willst du es richtig machen?

Und seien Sie bereit, diese Entscheidungen mit Zeitschätzungen (sowohl für die Entwicklung als auch für die Qualitätssicherung) zu untermauern, und wiederholen Sie, dass Sie nicht beide in die gleiche geschätzte Zeit passen können.

"Beides" ist hier in der realen Welt keine Option. Es sei denn, Sie erhalten mehr Stellen für die Analyse/Tests/QA.

Die Antwort, nach der ich gesucht habe - ein Manager hat seine Sicht auf Geschäftsziele. Wenn es für das Unternehmen besser ist, Funktionen schnell zu präsentieren (auch wenn sie fehlerhaft und teilweise kaputt sind), kann dies eine Wahl sein. - Der wichtige Teil ist, klar zu kommunizieren, was die Kompromisse sind. Aber die Definition von Geschäftszielen ist nicht die primäre Aufgabe des Entwicklers.
Die Antwort wird oft lauten: "Ich möchte, dass es jetzt erledigt wird, dann können Sie es in Zukunft verbessern", fürchte ich, also funktioniert dieser Ansatz nicht wirklich. Pete hat Recht – du solltest nicht lügen, aber du solltest alle technischen Details verschleiern: Das Projekt ist nicht fertig, bis es [leise] richtig gemacht ist und das war’s. "Ich möchte es in 14 Tagen" "Tut mir leid, aber es wird länger dauern. Ich schätze eher 3 Monate" Zeitraum. Wenn das nicht akzeptiert wird und man in eine Ecke gedrängt wird, dann geht man.
Wenn Sie es ungetestet liefern, werden Sie für alle Probleme auf der ganzen Linie verantwortlich gemacht, selbst wenn die Leute, die die Lieferung entgegennehmen, es angenommen und unterschrieben haben, in dem Wissen, dass es ungetestet ist und Sie es als solches unter Druck geliefert haben. Dort gewesen, erledigt, Kündigungsschreiben bekommen.

Leider gibt es keinen guten Weg, damit umzugehen, der Ihnen nicht einige Schmerzen bereiten wird.

Decken Sie sich zuerst ab. Stellen Sie sicher, dass Sie Ihrem Chef E-Mails senden, in denen Sie erklären, dass die Zeitpläne unrealistisch sind und dass Sie, um sie auch nur zu versuchen, angemessene Tests überspringen müssen. Geben Sie an, dass Sie sich darüber unwohl fühlen und glauben, dass dies verschiedene Probleme verursachen wird, wie z. B. Produkte von schlechter Qualität und technische Schulden. Bewahren Sie auch Kopien aller E-Mails auf, die Ihr Chef Ihnen mit der Bitte um neue Funktionen sendet.

Als nächstes suchen Sie nach einem besseren Job. Leider müssen Sie in einer solchen Situation entweder gehen oder Ihr Chef muss gehen, und Sie können nicht wirklich darauf setzen, dass Sie es nicht sind.

Schließlich tun Sie, was Sie können, um die Fristen einzuhalten. Wenn Sie für irgendetwas verantwortlich gemacht werden, weisen Sie darauf hin, dass Sie Ihren Chef vor diesen Problemen gewarnt haben und dass er dafür verantwortlich ist, nicht darauf zu reagieren.

Es könnte genau das sein, was im Sinn ist. „Tun Sie etwas einigermaßen Dummes und Verrücktes, das ihn dazu zwingt, nach neuen Optionen zu suchen. In der Zwischenzeit werden wir die Position finden, die er einnehmen soll, wenn seine aktuelle Situation zusammenbricht.“
Diese Antwort ist bis zum letzten Absatz gut. Das zeigt dem Manager nicht, dass es unmöglich ist, es zeigt, dass Sie einen Rückzieher machen und seine Einschätzung über Ihre akzeptieren. Das OP muss nicht völlig stur sein, aber es sollte auch nicht vor dieser kurzen Frist kapitulieren, die sich wahrscheinlich in lange Arbeitszeiten, endlose Belästigungen und anderen Stress verwandeln wird, den das OP nicht braucht. Auch wenn Sie Ihrem Chef sagen: „Ich habe es dir doch gesagt“, bringt das nichts außer mehr Stress.

Es ist ungesund, so weiter zu arbeiten. Als IT-Profis können (und tun) wir manchmal viele Stunden arbeiten. Wenn Sie regelmäßig 60-70 (oder mehr) Stunden arbeiten, haben Sie ein riesiges Problem und Sie werden derjenige sein, der darunter leidet.

Mein aktueller Arbeitgeber versteht Work-Life-Balance. Die meisten Wochen sind 40 Stunden und dann bin ich fertig.

Bei meinem vorherigen Arbeitgeber war dies nicht der Fall.

Wir handhabten es, indem wir spezifische Anforderungen einholten, die von allen Beteiligten (intern und/oder extern) abgesegnet wurden, bevor irgendwelche Arbeiten durchgeführt wurden. Die Projektplanung wurde in MS Project (oder einem anderen Projektplanungstool) geführt. Alle Änderungen gegenüber dem ursprünglichen Plan wurden in Project eingegeben, um die Auswirkungen auf den Zeitplan zu bestimmen. Änderungen mussten auch von den Stakeholdern unterschrieben genehmigt werden. Wenn es sich um eine kleine Änderung handelt, kann eine E-Mail ausreichen. Alle größeren Änderungen (wie das Hinzufügen eines Flottenmanagementsystems) erfordern Änderungen in der Dokumentation (Geschäftsanforderungen, Designanforderungen, technische Spezifikationen usw.), bevor die Änderung vorgenommen wird.

Zusammen mit den anderen guten Antworten habe ich ein weiteres Tool für Ihre Werkzeugtasche als Entwickler.

Erklären Sie Ihrem Vorgesetzten das folgende Dreieck:

Schnell, gut oder günstig: Wählen Sie zwei aus

Die Idee dabei ist, dass Sie/Ihr Vorgesetzter nur 2 Optionen auswählen. Es gibt keine Option "Alle Optionen abrufen", da dies einfach nicht der Fall ist. Selbst kleine Projekte brauchen Zeit, um richtig zu werden, und Ihr Projekt ist nicht klein.

Ich arbeite alleine an einem Albtraum einer über 20 Jahre alten Frankenstein-App bei der Arbeit. Ich soll „alles reparieren“ und gleichzeitig Kundenwünsche bearbeiten. Zum Glück: Mein Vorgesetzter, Chef und Chef des Chefs weiß, dass dies in dem von noch höheren Stellen vorgegebenen Zeitrahmen nicht möglich ist, also lasse ich mich dafür nicht durch den Dreck ziehen. Ich werde vielleicht immer noch wegen dieses Problems kritisiert, aber ich habe mehrere Leute, die mich unterstützen, die das obige Dreieck verstehen.

Es hört sich so an, als hätten Sie dieses Backup nicht, also stellen Sie die Aufzeichnung richtig. Wie andere Antworten sagten, wenn Sie "beschuldigt" werden, ein "kluger Typ wie Sie" zu sein, feuern Sie zurück mit:

Ein kluger Kerl wie ich weiß, was in dem von Ihnen geforderten Zeitrahmen möglich ist, und das ist nicht möglich.

Achten Sie darauf, es ernst zu sagen. Lächle nicht, mach es todernst. Wenn Sie nicht kapitulieren oder anderweitig verhandeln, wirken Sie vielleicht stur, aber der Manager kann Sie nicht dazu bringen, etwas zu versuchen, von dem Sie wissen, dass es unmöglich ist, und Sie dann für seine Fehler verantwortlich machen. Ich habe so ziemlich jede andere Taktik ausprobiert, und dies scheint die einzige zu sein, die nicht ständig nach hinten losgeht.

Ich habe verhandelt, kapituliert, „nur die Arbeit erledigt“ und verschiedene Kombinationen dieser drei und es kommt immer wieder zurück, um mich in den Hintern zu beißen. Jeder Fehler oder jede fehlende Funktion wird zu meiner Schuld. Es können zwei oder mehr Jahre vergehen, und es heißt immer noch „dein Chaos, mach es in Ordnung“.

Übrigens, ich bin nicht jemand, der das Wort "unmöglich" oft verwendet, aber dies scheint eine dieser notwendigen Zeiten zu sein.

Was soll man über "billig" sagen, wenn es nur ein fest angestellter FT-Entwickler ist, der das Projekt durchführt?
@krubo Sie können billig zu einer geringeren Anzahl von Mitarbeitern, die an dem Projekt arbeiten, übersetzen + kein Bonus für inkrementelle / Überstundenentwicklungen . In diesem Fall stellt das OP dem Unternehmen die billigste Arbeit zur Verfügung, die es bekommen kann.

Sie sagen, Ihr Manager hat keinen Programmierhintergrund. Programmierer sind für ihn also eine Blackbox. Er erzählt ihnen Dinge und sieht, wie lange sie brauchen, um etwas zu finden. Er stellt fest, dass sie, wenn er ihre allzu pessimistischen Vorhersagen außer Acht lässt, in kürzerer Zeit mehr liefern.

Die Lösung besteht darin, angemessenes Feedback zu geben. Es gibt keine proportionalen Kosten dafür, dass er Sie leiden lässt und seine Arbeiter ausquetscht.

Stellen Sie also zuerst sicher, dass Sie eine Papierspur erhalten. Lassen Sie sich jeden Auftrag schriftlich geben. Lassen Sie ihn jede Stunde abzeichnen, die Sie Überstunden machen müssen. Bringen Sie ihn dazu, Ihre Aussagen zu unterzeichnen, dass der Code ungetestet ist. Du musst deinen Arsch bedecken, weil Scheiße gegen die Wand schlagen wird , und du musst deinen Arsch bedecken, um klar zu machen, dass es nicht deine Scheiße ist.

Ich würde empfehlen, auch Ihre Möglichkeiten zu prüfen, sich gewerkschaftlich zu organisieren. Je nachdem, wie vernünftig die Unternehmenshierarchie ausfällt, ist dies möglicherweise nicht erforderlich, kann sich jedoch als nützlich erweisen, um etwas zu bewirken, wenn das obere Management ebenfalls apathisch oder inkompetent ist.

Entweder das, oder steigen Sie aus, solange Sie können, und kommen Sie an einen Ort, an dem Sie als nachhaltige Arbeitsquelle und nicht als Brennholz geschätzt werden.

Sie sollten den Scotty-Faktor verwenden : Wann immer Ihr Manager eine Funktion anfordert, präsentieren Sie zuerst eine geschätzte Dauer, bevor er Zeit hat, Ihnen seine Erwartung mitzuteilen. Diese geschätzte Dauer multiplizierst du mit 4 und lässt dich dann von ihm aushandeln.

Beispiel

Manager: Wir brauchen ein produktionsreifes Flottenmanagementsystem in...

Sie [unterbrechen]: Sicher, ich kann das in 4 Monaten schaffen.

Manager: Oh, ich dachte an zwei Wochen.

Sie: Haha, toller Witz! Sie wissen, dass XYZ seit 10 Jahren an ihrem Flottenmanagementsystem arbeitet und gerade ihre erste stabile Version veröffentlicht hat?

Manager: Nun, wir haben höchstens zwei Monate...

Sie: Ich sehe, was ich tun kann.

PS: In diesem Umfang (mit 4 multiplizieren) ist dieser Trick nur in einem Arbeitsumfeld wie dem Ihren notwendig. Aber es schadet nicht, in jedem Projekt immer ein bisschen Pufferzeit einzuplanen, denn wir Menschen neigen dazu, Dinge zu planen, von denen wir wissen, dass sie passieren, aber die Dinge, die unerwartet passieren, nicht berücksichtigen können.

"Ich werde sehen, was ich tun kann" Du hast dich gerade in eine Ecke gedrängt ;)
@LightnessRacesinOrbit ja, eine Ecke, die doppelt so hoch ist wie Ihre tatsächliche Schätzung. . .
@iheanyi Es stellt sich heraus, dass ich nicht lesen kann;)

Es gibt eine häufig zitierte und bekannte Beziehung von drei Faktoren: Ergebnis

Qualität, Dauer und Preis

Nur zwei davon können erreicht werden. Es ist in der Informatik so gut getestet, dass wir einfach davon ausgehen können, dass es wahr ist. (Lassen Sie es mich wissen, wenn Sie dies nicht tun.)

Es ist eine tatsächliche Tatsache, nicht etwas, über das Sie verhandeln können, wenn er versucht, es durchzusetzen, selbst mit vorgehaltener Waffe.

Der Chef weiß oder versteht es nicht: Das zeigt er mit

Der Endbenutzer sieht die Tests nicht , solange es funktioniert und gut aussieht , ist es in Ordnung, die Markteinführungszeit ist wichtiger

Er will alle drei : keine Testergebnisse in schlechter Qualität, und der Endverbraucher sieht das deutlich als „es funktioniert nicht (teilweise – das reicht, um es nutzlos zu machen)“.