Bin ich überlastet oder einfach nur langsam?

Ich denke, es gibt mehrere Probleme, die angegangen werden müssen, aber das wichtigste, das ich lösen möchte, ist der Titel der Frage.

Etwas Hintergrundkontext:

Ich bin irgendwo zwischen einem Junior- und Mid-Level-Softwareentwickler; Ich habe 3 Jahre Branchenerfahrung. Ich arbeite in einem relativ kleinen Unternehmen (< 20 Softwareentwickler) und werde normalerweise entweder alleine oder in einem sehr kleinen Team an Projekten beteiligt. Diese werden von einem hochrangigen PM geleitet, der fast nichts mit der Entwicklung zu tun hat und über die Anfangs- und Endphase hinaus kaum in das Projekt involviert ist, und es gibt auch einen Teamleiter, normalerweise einen erfahreneren Entwickler, obwohl seine Rolle mehr ist vom Typ Scrum-Master, da sie normalerweise nicht aktiv an der Entwicklung beteiligt sind.

Da wir ein so kleines Unternehmen sind, müssen wir:

  1. Nimm jede Arbeit, die wir bekommen können, und
  2. Seien Sie so billig wie möglich

Die Art und Weise, wie wir billig bleiben, besteht darin, die Entwicklung im Grunde auf eine möglichst kurze Zeitspanne zu komprimieren. Das bedeutet, dass wir fast nie genug Zeit haben, um die Arbeit zu erledigen, wenn wir normale Arbeitszeiten haben; Daher ist es implizit erforderlich, dass wir Überstunden machen. Projekte haben in der Regel eine Laufzeit von wenigen Monaten.

Ich komme normalerweise zu dem Zeitpunkt in ein Projekt, an dem wir einige grundlegende, vage Benutzeranforderungen und vereinbarte Zeitpläne haben, und mir wird dann im Grunde gesagt: "Mach es."

Ich muss dann folgendes tun:

  • Verstehen Sie die Domäne und alle vorhandenen Codes und Tools, die sehr komplex sein können und sehr spezifische Kenntnisse erfordern
  • Verstehen Sie die Benutzeranforderungen, erstellen Sie beliebige Designs
  • Erstellen Sie Arbeitsaufgaben und zugehörige Zeitschätzungen
  • Entwickeln, testen und dokumentieren Sie die Lösung

Es scheint, als wäre das einzige, was in den Gesamtzeitplan des Projekts eingerechnet wurde, die Entwicklungszeit.

Es gibt normalerweise nicht viel Unterstützung. Intern kann der Teamleiter manchmal bei allgemeinen Softwareentwicklungsproblemen helfen, aber da er nicht wirklich auf niedriger Ebene in die Entwicklung des Projekts involviert ist, muss ich alle spezifischen Blockierungsprobleme alleine lösen. Auch die Kunden sind weitestgehend abwesend, abgesehen von Sprint-Reviews und gelegentlichem Beantworten von E-Mails.

Die schlimmsten Fälle sind normalerweise die Änderung vorhandener Legacy-Projekte, die aufgeblähte Codebasen haben und schlecht dokumentiert sind, und die ursprünglichen Entwickler sind nirgendwo zu finden; Ich brauche so lange, um diese zu verstehen und damit zu arbeiten.

Normalerweise habe ich das Gefühl, direkt dagegen zu sein, und es kann anstrengend sein. Aufgaben dauern fast immer länger als meine anfänglichen Schätzungen, was mich dann schlecht aussehen lässt, als wäre ich nicht produktiv. Normalerweise muss ich die Dinge gegen Ende überstürzen. Ich erzähle meinen Teamleitern davon, und sie sagen normalerweise etwas wie „Nun, tun Sie einfach so viel wie Sie können.“

Die Projekte werden (normalerweise) pünktlich und im Rahmen des Budgets geliefert, aber ich bin nie wirklich zufrieden mit ihnen; Ich bin nicht davon überzeugt, dass ich tatsächlich ein Produkt entwickelt habe, das den Wünschen der Benutzer entspricht, obwohl es technisch den meisten ihrer Anforderungen entspricht (einige Dinge müssen normalerweise aus Zeitmangel entfernt werden).

Ich denke, das Hauptproblem für mich sind die Projektzeitpläne (an deren Erstellung ich nicht beteiligt bin); Es macht mir nichts aus, all diese Arbeit zu erledigen, aber ich habe fast nie das Gefühl, dass ich genug Zeit habe, um es ohne Überstunden zu tun, was ich nicht auf unbestimmte Zeit tun kann, weil ich sonst ausbrenne (wie ich es in der Vergangenheit getan habe). Ist das normal? Bin ich nur ein langsamer Entwickler? Wenn ich langsam bin, auf welche Weise kann ich trotzdem ein effektiver Arbeiter sein?

Wir können Ihnen nicht wirklich sagen, ob Sie langsam sind oder nicht, aber wie häufig Überstunden gemacht werden und wie Sie mit einer zu kurzen Frist umgehen sollten, sind beide wahrscheinlich gute Fragen. Weiß Ihr (Produkt-)Manager, wie viele Überstunden Sie machen? Wurden Sie ausdrücklich gebeten, Überstunden zu machen? Ich sollte hinzufügen, dass jeder, egal wie langsam oder schnell, mehr Arbeit erhalten (oder übernehmen) kann, die er ohne Überstunden erledigen kann. Das sagt wirklich nicht viel über deine Fähigkeiten aus.
Danke für diese Kommentare; Ich denke, dass es sich auf jeden Fall lohnt, realistischere Zeitschätzungen vorzunehmen und nicht zu versuchen, sie in eine komprimierte Zeitskala zu stopfen, damit das Projekt normal aussieht und den PM glücklich macht. Wenn ich Aufgaben immer unterschätze, fühle ich mich unter Druck gesetzt, wenn sie unweigerlich länger dauern. Also denke ich, dass ich ab jetzt realistische, vielleicht sogar leicht überhöhte Schätzungen machen werde, auch wenn es die unrealistischen Projekterwartungen offenbart. Das ist nicht mein Problem; Ich kann in der vorgegebenen Zeit nur so viel leisten, ohne unbefristete Überstunden und Burnout.
@DaveyDaveDave du hast vollkommen Recht, ich habe genau dasselbe erlebt. Es ist einfach für mich, in die Denkweise zu verfallen: „Nun, ich kann ein bisschen länger bleiben und diese eine Sache zu Ende bringen …“ Es ist eine schlechte Angewohnheit, an der ich arbeite, um disziplinierter damit umzugehen.

Antworten (11)

Ich könnte Ihnen sagen "ja/nein, das ist/nicht vernünftig", aber wer sagt, dass ich entweder selbst kein langsamer Entwickler bin oder der gleichen Meinung wie Ihr Manager bin? Diese Dinge sind sehr subjektiv und schwer objektiv zu benennen.

Es gibt jedoch konkrete Grenzen, an denen Sie stoßen.

Arbeitszeiten, für einen. Werden Ihre Überstunden bezahlt? Denn wenn nicht, aber (implizit) erforderlich, ist das ein großes Warnsignal

Ich habe fast nie das Gefühl, dass ich genug Zeit habe, um es ohne Überstunden zu tun, was ich nicht auf unbestimmte Zeit tun kann, weil ich sonst ausbrenne (wie ich es in der Vergangenheit getan habe). Ist das normal? Bin ich nur ein langsamer Entwickler?

SELBST WENN (und das ist ein großes WENN) Sie wirklich ein langsamer Entwickler waren, sollte sich niemand dazu zwingen, wiederholt auszubrennen oder Aufgaben zu übernehmen, die er nicht bewältigen kann.

Unabhängig davon, ob das Unternehmen übermäßigen Druck ausübt oder Sie nur mit geringem Druck fertig werden können, müssen Sie auf sich und Ihre Bedürfnisse achten. Nicht jeder kann mit jeder Situation umgehen, und das ist vollkommen in Ordnung.

Ich erwähne das nicht, weil ich denke, dass Sie schuld oder unfähig sind (weil ich denke, dass die Firma hier schuld ist, dazu später mehr).
Ich erwähne das, weil es einen Grundton gibt, dass Sie Dinge auf sich nehmen, die Ihre geistige Gesundheit und Ihre Lebensqualität zum Wohle des Unternehmens, das niemals gesund ist, aktiv schädigen.


Es gibt auch die generische Trope des Managements, das Gewinne über vernünftige Grenzen hinaus maximiert. Dies gibt es in zwei Variationen: diejenigen, die die Ausgabequalität senken, und diejenigen, die den Druck auf die Mitarbeiter erhöhen, indem sie sie überarbeiten und/oder unterbezahlen.

Es scheint, als hättest du es mit beidem zu tun. Das Management lässt keine Zeit für angemessene Entwicklungspraktiken, wie Sie sie aufgelistet haben, und lässt somit nicht zu, dass die angemessene Arbeit geleistet wird, während es gleichzeitig seine Mitarbeiter überlastet, indem es sie dazu bringt, mehr Arbeit zu leisten, als sie vernünftigerweise in den Stunden erledigen können sie sind vertraglich vereinbart.

Ich kann Ihnen nicht sagen, was Sie tun sollen, aber aus Erfahrung sind solche Situationen aus der Position des Mitarbeiters schwer, wenn nicht gar unmöglich zu lösen. Der Fahrer des Autos hat die Kontrolle, das Auto gegen eine Wand zu steuern, wenn er dies wünscht, und das Management ist in ähnlicher Weise in der Lage, schlechte Geschäftsentscheidungen zu treffen und sich daran zu halten. Ich sage nicht, dass es gut ist oder dass wir tatenlos zusehen sollten, aber wenn es hart auf hart kommt, kann ein Mitarbeiter seinem Vorgesetzten nicht sagen, wie er sein Unternehmen führen soll – selbst wenn es schlecht geführt wird.

Es ist möglich, dass das Management einfach fehlgeleitet ist und zuhört, wenn ihm die Probleme erklärt werden, aber meiner Meinung nach (und meiner Erfahrung nach) sind die Chancen dafür sehr gering. Das Management hat bereits bewiesen, dass es den Gewinnen Vorrang vor der Lebensqualität der Mitarbeiter einräumt, und (leider) nur wenige Menschen würden auf Gewinne verzichten, um den Komfort anderer zu verbessern.


Dieser nächste Teil ist rein subjektiv und anekdotisch.

Sie sind auf viele, viele rote Fahnen gestoßen, denen ich zuvor begegnet bin.

  • Unternehmen, das ständig Druck auf seine Mitarbeiter ausübt
  • Kein Interesse an der Lebensqualität der Mitarbeiter oder irgendetwas anderem, das keinen direkten finanziellen Gewinn bringt
  • Nur der Gewinn und die Termine zählen ("aus Zeitmangel müssen meist mehrere Dinge de-scoped")
  • Kundenzufriedenheit wird ignoriert, wenn sie keine direkten Gewinne bringt ("[es ist nicht] das, was die Benutzer wollten, obwohl es technisch den meisten ihrer Anforderungen entspricht")
  • Kein vorausschauendes Denken oder Zukunftsplanung über den Liefertermin hinaus. Keine Dokumentation, aufgeblähte Codebasen, fehlende Tools oder einfaches Debugging, ...
  • Die Führungskräfte verfügen nicht über die Kernkompetenzen ihres eigenen Unternehmens (dh die Softwareentwicklung). Dies kann normalerweise abgemildert werden, indem Sie andere mit diesen Fähigkeiten um Rat fragen, aber in Ihrem Fall scheint dies vernachlässigt zu werden.
  • „Tu einfach so viel du kannst“ als Standard-Feedback von Teamleitern deutet darauf hin, dass Fristen als Druckmittel verwendet werden, im Gegensatz zu Zeitplänen, bei denen man vernünftigerweise davon ausgehen kann, dass etwas fertig ist. Auch in den besten Unternehmen kann es zu Verzögerungen kommen. Aber basierend auf Ihrer Beschreibung brennt das Unternehmen seine Mitarbeiter aus und bringt die Mitarbeiter dann dazu, die Tatsache zu decken, dass das Unternehmen sie ausgebrannt hat.

Ob Sie in einem solchen System bleiben wollen, ist Ihre Entscheidung. Das würde ich nicht tun, und ich habe jedes Projekt für jeden Kunden aufgegeben, bei dem sich die Probleme als endemisch erwiesen oder von gewinnorientierten Managern vorsätzlich aufrechterhalten wurden.

Sie müssen Ihre eigene Wahl treffen. Ich möchte hinzufügen, dass Sie bereits in der Vergangenheit ausgebrannt sind, was stark darauf hindeutet, dass die Situation, in der Sie sich derzeit befinden, nicht gut für Ihre Gesundheit ist, sowohl geistig als auch körperlich.

Kommentare sind nicht für längere Diskussionen gedacht; Diese Konversation wurde in den Chat verschoben .

Das Wichtigste, was Sie tun müssen, ist, Ihre Zeitpläne anzupassen und Ihre Schätzungen aufzufüllen.

Für mich klingt das so, als würden Sie "Schätzungen für sonnige Tage" abgeben, wie wir sie früher nannten. Ihre Schätzungen gehen davon aus, dass alles nach Plan und ohne Ablenkung läuft, wenn schon anhand der Beschreibung, die Sie uns gegeben haben, deutlich wird, dass Sie in einem absoluten Chaos arbeiten, in dem hinter jeder Ecke und in jedem Schatten böse Überraschungen lauern.

Nehmen Sie die größte Anzahl von Tagen, an denen Sie ein Ziel verfehlt haben, addieren Sie fünf dazu und füllen Sie Ihre zukünftigen Schätzungen um diesen Betrag auf. Wenn Sie anfangen, Fristen einzuhalten, können Sie diese Zahl anpassen.

„Erwartungen managen“ ist mehr als ein Schlagwort. Wenn Sie sagen, dass etwas vier Tage dauert und Sie in drei liefern, wird der Kunde sagen: „Wow, er hat für mich auf Hochtouren geschaltet“, und der Kunde wird zufrieden sein. Wenn es die gleichen drei Tage dauert, Sie aber zwei gesagt haben, wird der Kunde sauer sein, weil Sie zu spät kommen.

Außerdem gibt Ihnen das etwas Luft zum Atmen, falls etwas Unerwartetes passiert, sodass Sie nicht das Gefühl haben, auszubrennen.

Ihr Unternehmen hat eine chaotische Umgebung geschaffen, mit der Sie arbeiten können, aber Sie können die Standards eines geordneten Geschäfts nicht auf einen chaotischen anwenden. Sie müssen das Chaos in Ihre Schätzungen einpreisen.

Seien Sie auch nicht so streng zu sich selbst. Sie sind weder langsam noch überfordert. Sie müssen nur Ihre Erwartungen und die Ihrer Kunden anpassen, indem Sie die zusätzliche Zeit berücksichtigen, die Sie benötigen.

Bringen Sie außerdem Bedenken und Verzögerungen dem Management vor, sobald Sie sie haben. Ich habe meinen Leuten immer gesagt: „Vor einer Frist ist es ein Problem, danach ist es eine Ausrede.“

Wenn Sie beginnen, vom Management zurückgewiesen zu werden, sagen Sie einfach die Wahrheit: Sie tun mit den bereitgestellten Ressourcen alles, was Sie können.

Manchmal sagte ich zu meinem Management: "Ein Pint kann keine Gallone halten, wenn es ein Pint hält, tut es bereits das Beste, was es kann."

Diese Antwort gefällt mir besonders gut. Wenn Sie vom Management unter Zeitdruck gesetzt werden, wenn Sie die Fakten nicht ausreichend kennen, sollten Sie sich immer mehr Zeit nehmen. Wenn ich nach Zeitplänen gefragt werde, möchte ich hinzufügen, dass meine Schätzung davon abhängt, dass keine Hindernisse getroffen werden. Wenn Sie dann auf Probleme stoßen, die mehr Zeit in Anspruch nehmen, halten Sie das Projektteam auf dem Laufenden. Wenn Sie beschuldigt werden, können Sie sagen, dass die Projektspezifikation, die Sie erhalten haben, bevor Sie nach den Fristen gefragt wurden, unvollständig war. Fragen Sie also freundlich den BA, der sie zusammengestellt hat, warum.
Das Auffüllen der Schätzungen ist nicht immer so einfach. Ich habe vor einem Jahr als Junior-SW-Ingenieur angefangen und gab wirklich optimistische Fristen an, sagen wir 1 Monat statt 3-4 Monate, 1 Woche statt 1 Monat. Jetzt fange ich an, realistischere Schätzungen abzugeben, und die Nicht-SW-Leute mögen das überhaupt nicht. Früher lag der Druck auf mir, weil ich mehr Zeug versprochen hatte, als ich liefern konnte, jetzt müssen sie entscheiden, ob sie wollen, dass ich A oder B mache.
Ich bin mir nicht sicher, ob er diese Schätzungen vorschlägt, sondern lässt sie sich eher vom Management aufzwingen.
@nick012000 Wenn es auferlegt wird, ist es noch wichtiger, realistischere Schätzungen abzugeben, denn dann hat er ABSOLUT KEINE VERTEIDIGUNG gegen seine Chefs, wenn er es nicht tut
@Old_Lamplighter Also den Scotty-Faktor anwenden ?
@AndrewMorton absolut. Es gibt einen Grund, warum man so mitschwingte.
OP sagte: "Das Hauptproblem für mich sind die Projektzeitpläne (an deren Erstellung ich nicht beteiligt bin)"
@nick012000 Zur Verdeutlichung wird mir gesagt, dass es dieses neue Projekt gibt, für das wir uns bereits beworben haben und für das wir uns (ohne mein Wissen) auf einen Gesamtzeitplan geeinigt haben. Die Art und Weise, wie die Zeitpläne erstellt werden, besteht darin, dass der PM einen erfahrenen Entwickler fragt, was seiner Meinung nach eine angemessene Zeitspanne für die Durchführung des Projekts sein könnte, basierend auf einer Zusammenfassung und einem kurzen Blick auf die Anforderungen. Das können zum Beispiel 3-4 Monate sein. Ich erhalte dann diese Anforderungen und werde gebeten, Arbeitsaufgaben zu erstellen und Zeitschätzungen für sie vorzunehmen. Mein Fehler war, dass ich früher dachte, dass alles in diesen Zeitrahmen passen muss, was normalerweise nicht machbar ist.
@Touchdown auch, denken Sie daran, dass Fristen/Zeitpläne manchmal nicht sind. Ich habe mich einmal fast umgebracht, um eine Frist einzuhalten, nur um festzustellen, dass es eine "weiche Frist" war.
Das Verschieben der ETA funktioniert nur in einer gesunden Organisation oder zumindest in einer, die nur geringfügig schlecht ist und wieder in einen vernünftigen Zustand verschoben werden kann. Wenn Sie in einer toxischen Umgebung wie dem OP arbeiten, wird das OP nur schlecht aussehen, anstatt das Management darüber zu informieren, dass ein Problem vorliegt. Es ist möglich, aber unwahrscheinlich, dass das OP ein Treffen mit dem oberen Management vereinbaren könnte, um ihnen mitzuteilen, wie schlecht die Geschäftspraktiken sind, aber das ist nur möglich, wenn es sich um ein winziges Unternehmen handelt und sie nicht gierig oder völlig falsch informiert sind. Ich habe in einer sehr kleinen Firma gearbeitet, die wie die OPs wurde und ging, weil es unvernünftig war.
@computercarguy Wie hilfreich ist dieser Kommentar?
@Old_Lamplighter, Sie scheinen zu glauben, dass das OP das Problem beheben kann, indem es Projekte einfach anders schätzt, und mein Kommentar war zu sagen, dass das an toxischen Orten nicht funktionieren wird. Meiner Erfahrung nach bittet der Chef um einen Kostenvoranschlag, hält meinen Kostenvoranschlag für zu lang, kürzt ihn dann auf seinen eigenen Kostenvoranschlag und streitet mit mir darüber, warum meiner zu lang ist, unabhängig davon, warum ich meine für richtig halte. Dann beschweren sie sich, warum ich ihre kurze ETA nicht eingehalten habe. Der Chef entschied dann, dass ich ein schlechter Angestellter war, nachdem dies mehrmals wiederholt wurde, und erhielt einen PIP für ihre unvernünftigen Erwartungen.
Ein vernünftiger Arbeitsplatz wird verstehen, dass er zu viel Druck macht und nachlassen, aber es hört sich nicht so an, als würde der OP an einem dieser Orte arbeiten. Also ja, Ihre Antwort würde funktionieren, wenn der Chef vernünftig ist, aber nicht in dieser Situation.
@computercarguy also, die Alternative ist???????

Herzlichen Glückwunsch, Sie sind aus sehr guten Gründen auf das Projektmanagement-Dreieck gestoßen, das oft als „gut, schnell, billig: wählen Sie zwei“ zusammengefasst wird.

Sie arbeiten für eine Beratungsfirma, die auch als Body Shop bekannt ist, weil sie die Zeit (Karosserien) von Entwicklern wie Ihnen an Kunden verkaufen. Die zwei Punkte des Dreiecks, die eine Beratung implizit wählt, sind schnell und billig, weil ihre Kunden sich dafür entscheiden.

Mit anderen Worten, wenn Sie in einer Beratungsfirma arbeiten, dürfen Sie niemals qualitativ hochwertige Arbeit abliefern, weil das gegen ihr Geschäftsmodell verstößt. Wenn Sie versuchen, qualitativ hochwertige Arbeit abzuliefern, geraten Sie in eine Sackgasse wie den Support, weil Sie dem Unternehmen zur Last fallen, indem Sie sich mehr Zeit nehmen als ein Entwickler, der sich nicht um Qualität kümmert.

Dies wird sich nie ändern, solange Sie für dieses Unternehmen (oder überhaupt für eine Beratungsfirma) arbeiten. Vertrauen Sie mir - ich habe 8 Jahre lang bei einem gearbeitet (oder etwa 5 Jahre zu lange).

Daher ist die einzige Antwort auf Ihr Rätsel "anderen Job finden" - schwierig in diesem Wirtschaftsklima, aber nicht unmöglich. Vor allem, wenn Sie zeigen können, dass Ihnen die Codequalität am Herzen liegt – es gibt Entwicklungshäuser, die von Leuten geleitet werden, denen solche Dinge am Herzen liegen. Nur nie wieder für eine Beratung arbeiten.

Wirklich, die Frage, die Sie sich stellen sollten, ist: Wie lange können Sie es sich leisten, in einem Job zu bleiben, in dem Sie nicht die Gelegenheit bekommen, zu üben und zu lernen, wie man Software richtig macht ? Wie lange können Sie es sich leisten, in einem Job zu bleiben, der Sie aktiv zermürbt? Wie lange können Sie es sich leisten, in einem Job zu bleiben, der Sie sofort entlassen wird, wenn er jemanden findet, der in Bezug auf die ausgegebenen Codezeilen „produktiver“ ist als Sie?

Und seien Sie vorsichtig, wenn (hoffentlich wann) Sie sich entscheiden zu gehen. Das Unternehmen wird viel tun, um Sie zu halten, weil es versteht, dass ein Entwickler, der etwas gibt, nützlicher ist als eine fungible, hirntote, Code generierende menschliche Maschine - aber sie werden niemals in der Lage sein, das zu erreichen Versprechen, die sie Ihnen hinsichtlich der Verbesserung der Qualität geben werden. Auch diese Erfahrung habe ich wieder gemacht.

Einverstanden. Das Beste, was Sie tun können, ist, alle Erkenntnisse und Erfahrungen zu sammeln und zu einem besseren Job überzugehen.
Ich stimme der allgemeinen Meinung Ihrer Antwort zu, aber nicht alle Beratungsunternehmen sind so. Diejenigen, die für ihre Kunden teurer sind und ihren Entwicklern mehr zahlen, sind normalerweise weniger so.
@CodeCaster Und nicht alle Nazis sind schreckliche Menschen (Entschuldigung für die Berufung auf Godwins Gesetz), aber Sie hören nicht, dass die Leute über die guten 0,1% sprechen, gerade weil es eine winzige Minderheit ist. Dasselbe gilt für Beratungsunternehmen – es gibt Einhörner unter den Wölfen, aber den Fragesteller zu ermutigen, nach einem Einhorn zu suchen, wenn er am ehesten einen Wolf findet, ist nicht hilfreich.
Als jemand, der in einer Unternehmensberatung gearbeitet hat, kann ich kategorisch sagen, dass jedes Wort dieser Antwort wahr ist. Wenn Sie wirklich für Qualitätsarbeit geschätzt werden möchten, müssen Sie möglicherweise gehen - und mein Rat wäre, dies eher früher als später zu tun.
Dies - die Anreize in einem Unternehmen stehen einem Typ eines qualitätsbewussten Entwicklers gegenüber, der das OP eindeutig ist. Die einzigen Möglichkeiten sind zu gehen, auszubrennen und zu gehen oder als ausgebrannte Person zu bleiben.
@TomášKafka Ich habe leider die dritte Option gewählt. Es bedurfte eines längeren Krankenhausaufenthalts, bis ich endlich das Licht erblickte und herauskam. Hoffentlich kann ich jemand anderen davor bewahren.
Ich denke, das ist kulturabhängig, in meinem Teil der Welt sind Beratungsunternehmen gar nicht so schlecht. Ich bin mein Fall, wir haben den Vorteil von Kunden, die Wert auf gute stabile Lösungen legen und nichts dagegen haben, für Qualitätsarbeit extra zu bezahlen.
@Alex hört sich so an, als hätten Sie damals eine gute Beratung gefunden.
Ich denke, das ist eher " höchstens zwei auswählen". Glauben Sie mir, ich habe ein Management gesehen, das "gut, schnell, billig: Wir wählen keines" sagte.

Das ist einer der Gründe, warum ich mein jetziges Unternehmen verlasse. Aber kommen wir zu Ihnen, von dem Kunden, bei dem ich bin, wurde ich oft nach Besprechungen in ein Projekt gesteckt, um über Funktionen und Entwicklungszeit zu entscheiden, so oft erhielt ich eine E-Mail mit „Hey, Sie müssen dieses Ding machen bis zum 10. Juni“ (normalerweise gefolgt von „WT* ist das?“) und ich habe auch andere Projekte, an denen ich arbeiten kann, mache ich am Ende immer Überstunden, die mir nie jemand bezahlen wird.

Einen Tag nach dem dritten Mal, als dies passierte, nahm ich meine direkten Vorgesetzten, nennen wir sie Projektmanager, und in einem Meeting bat ich freundlich: „Bitte, bevor Sie Kunden Entwicklungszeit geben, lassen Sie uns darüber sprechen, denn es geht nicht nur darum, etwas zu tun, sondern auch Prioritäten zu managen und Überlieferungstage zu vermeiden", ab diesem Tag lief es etwas besser.

Mein Rat ist daher, eine sehr klare und prägnante Rede mit Ihren Projektmanagern zu halten und ihnen verständlich zu machen, dass SIE es sind , die einen Entwicklungsplan vorgeben, nicht sie, da sie nie beteiligt sind.

Um dies etwas zu erweitern: Der Entwicklungsplan sollte auf einer Mischung aus dem basieren, was der Produktmanager (und der Kunde) will und was möglich ist – eine Schätzung, die vollständig vom Entwicklerteam kommen sollte.
Das Gespräch mit Vorgesetzten ist zwar immer einen Versuch wert, aber es scheitert öfter als es funktioniert. Gelingt dies nicht, bleibt meist nur ein Arbeitsplatzwechsel.
Ja das ist richtig. Grundsätzlich muss Folgendes passieren: 1. Der PM muss nicht zu allem, was der Kunde will, Ja sagen, ohne die Entwickler zu konfrontieren. 2. Entwickler sollten in die Features-Diskussion mit dem Kunden einbezogen werden, um am Ende der Entwicklung einen genauen Zeitrahmen und ein besseres Produkt vorgeben zu können. Wenn Sie Gruppen haben, die nicht richtig zusammenarbeiten, wird es nur verwirrend, und ich schätze im Allgemeinen den nicht-technischen Filter nicht, den ein PM implementieren könnte, wenn er die Anfrage an mich weiterleitet.
Wie Sie sehen, funktioniert dies nur in einer gesunden Umgebung. Die OPs scheinen SOP zu sein, sich nicht um ihre Entwickler zu kümmern, nur um Geld und Fristen. Es ist wahrscheinlich, dass die CxOs einen Repräsentanten dafür bekommen wollen, „alles schnell und billig zu erledigen“, damit sie mehr Geschäfte machen können. Leider ist das überhaupt nicht gesund, was Sie und das OP sehen. Wenn es zu schlimm ist, wird das OP, wie Sie, nicht in der Lage sein, die Meinung der mgmts zu ändern, sodass das Verlassen möglicherweise die einzige Option ist.
Ja, ich weiß, aber der Versuch, den Weg der freundlichen Kommunikation zu gehen und auf die Probleme hinzuweisen, die dieses Management mit sich bringt, sollte die Dinge ein wenig aufwühlen. Wenn sich die Dinge nach diesem Treffen natürlich nicht ändern, sucht OP nach einem neuen Job, lauf weg! :)

Um zu beantworten, ob Sie langsam oder überlastet sind, sprechen Sie mit Ihren Teamkollegen. Sehen Sie, ob sie mit Ihren Schätzungen einverstanden sind und ob sie auch unbezahlte Überstunden machen müssen, um ihre Fristen einzuhalten. Wenn Sie sich alle einig sind, dass eine Aufgabe eine Woche dauern sollte, aber der Chef möchte, dass sie in 3 Tagen erledigt ist, wird er Sie nicht feuern, weil Sie eine Woche gebraucht haben, weil jeder Ersatz mindestens eine Woche dauern würde, um die gleiche Aufgabe zu erledigen.

Sie können auch prüfen, ob das Unternehmen Schwierigkeiten hat, Mitarbeiter zu rekrutieren und zu halten.

In dem unwahrscheinlichen Fall, dass Sie im Vergleich zu anderen mit der gleichen Erfahrung wirklich langsam sind, finden Sie heraus, welche Teile der Arbeit Sie schneller oder besser als sie erledigen, und sehen Sie, ob Sie seitwärts zum Verkauf/Projektmanagement/Testen wechseln können was immer dir passt.

In dem viel wahrscheinlicheren Fall, dass das Unternehmen Ihre Gesundheit und Freizeit für seine Gewinne opfert, interpretieren Sie „tun Sie, was Sie können“ als „tun Sie, was Sie in der von uns bezahlten Zeit tun können, und überlassen Sie das Problem dem Verkäufer, der unterbewertet hat um einen Vertrag zu gewinnen, der nicht profitabel war".

Pünktlich zu gehen muss nicht kämpferisch sein, insbesondere wenn es für einen Kollegen ein Problem darstellen würde, aber Sie haben (anders als die Direktoren) kein Eigenkapital am Unternehmen und profitieren nicht von Ihren Überstunden.

Ich habe dies getan und festgestellt, dass dies bei den Entwicklern, sogar bei den Senioren, ziemlich häufig vorkommt. einer sagte sogar, es sei „absolut verrückt“. Es ist beruhigend zu wissen, dass es doch nicht nur mir so geht. Es scheint nur der (widerwillig?) akzeptierte Entwicklungsansatz im Unternehmen zu sein.
Manager werden Sie absolut feuern, wenn Sie ihre unrealistischen Zeitrahmen nicht verwalten können. Sie glauben, dass sie in der Lage sein werden, jemanden zu finden, der besser, schneller und billiger ist, der einfach ohne Schulung in der SOP oder Codebasis in den Job einsteigen kann. Ich war auf beiden Seiten davon, sehr zu meinem Nachteil in beide Richtungen. Und der Verkäufer liegt „nie falsch“, es ist „immer“ der Entwickler, der nicht liefern kann, was jemand anderes versprochen hat. Es ist Blödsinn, aber so arbeiten viele Unternehmen. Ich war dort, habe das getan, möchte nicht noch einmal dorthin gehen.
@computercarguy - was ist passiert, nachdem sie jemanden gefeuert haben und nicht in der Lage waren, jemanden schneller zu rekrutieren?
@RobinBennett, ich weiß es nicht. Ich habe nie versucht, es herauszufinden. Ich dachte mir, wenn sie sich nicht um mich kümmerten, während ich dort arbeitete, würde ich mich auch nicht um sie kümmern, nachdem ich gegangen war. Ok, ich habe Jahre später ungefähr 1 Ort gehört, dass, nachdem ich gegangen war, eine ganze Reihe anderer Leute aus dem gleichen Grund gegangen sind. Und ich denke, da ist dieser andere Ort, der mich durch ein paar Offshore-Entwickler ersetzt hat. Ich bin mir sicher, dass viele der „Temp-to-Hire“-Plätze immer noch nicht eingestellt haben, da das normalerweise eine Farce ist, und nicht nur ich rede hier. Ich habe von Personalvermittlern gehört, dass der „Anstellen“-Teil nur dazu da ist, mehr Bewerber zu gewinnen.

Da wir ein so kleines Unternehmen sind, müssen wir:

  1. Nimm jede Arbeit, die wir bekommen können, und
  2. Seien Sie so billig wie möglich

Die Art und Weise, wie wir billig bleiben, besteht darin, die Entwicklung im Grunde auf eine möglichst kurze Zeitspanne zu komprimieren.

Ihr Unternehmen war also in der Lage, das Trifecta der Effizienz zu haben (Qualität, Management oder wie auch immer es genannt wird)? Menschen, Zeit und Geld ODER Schnell, günstig und gut (wobei Sie nur zwei auswählen können).

Wenn Sie billig sind und eine kleine Anzahl von Leuten haben, die die Arbeit per Stellvertreter erledigen. Sie müssen die Zeit betonen. Glaubst du, etwas dauert 10 Stunden? Schreibe 15 oder sogar 17 auf.

Ich habe mal ein Experiment gemacht. Ich habe aufgeschrieben, wie viel Zeit ich wirklich für etwas verbringe. Nicht nur tun, sondern aufhören, an etwas anderem zu arbeiten, überprüfen, suchen, speichern, zu meiner vorherigen Arbeit zurückkehren und genau dort sein, wo ich aufgehört habe. Aus 2 Minuten B-Job wurden 30 Minuten ohne A-Job.

Nun, wie Sie bemerkt haben, ist das ein Hit für Sie. Weil Ihr Unternehmen nicht über das Trifecta verfügt. Es zahlt die Zeit-/Budgetschuld bei Ihnen. Du machst Überstunden, verbringst Zeit damit, Dokumentationen oder Blöcke nachzuholen, während du denkst, DU leihst dir Zeit aus dem ganzen Projekt.

Das erste Problem, dem Sie sich stellen müssen, ist, dass das Unternehmen dies als IHR Problem ansieht. Das Produkt ist günstig und pünktlich. Es gibt also kein Problem mit der Verzögerung oder Verschiebung von Fristen. Sie haben auch keinen Zeitstempel "sehen Sie, dieses Problem hat 5 Tage gedauert, also mussten wir die Frist um 6 Tage verschieben".

Sie können die Überstunden zählen. Es ist messbar. Aber man kann nicht messen, wie sehr man sich die ganze Woche über anstrengt. Du machst vielleicht 2 Stunden zusätzlich zu deinen 8. Aber du könntest 15 Stunden hineinquetschen. Kein Bremsen, kein Prüfen, kein Wiederholen, Abstriche beim Schreiben von Dokumentationen etc.

Wenn Sie also Projektzeit nehmen und Überstunden hinzufügen, werden 75 % der Echtzeit benötigt, um das Produkt zu liefern. Produkt, mit dem Sie zufrieden sein werden, mit guter Gesamtqualität, Dokumenten usw.

Tu so viel du kannst sollte nicht interpretiert werden als „tu so viel du kannst in dieser Zeit“. Es sollte lauten: "Tue nur Dinge, die du KANNst, und tue nur Dinge, die du in ein bestimmtes Zeitfenster passen kannst".

Du könntest beides gleichzeitig sein. Für Ihre Arbeitsgeschwindigkeit (die nicht nur von Ihrer Leistung/Fähigkeit/Motivation, sondern auch von der Art der Aufgaben und der Qualität der Vorbereitung abhängt) haben Sie zu viele Aufgaben.

Alles, was Sie tun können, ist, die Überlastung anzunehmen und die Situation zu verbessern (Ablehnen, effizientere Verarbeitung, Feedback geben, um Redo zu reduzieren usw.). Die Frage, ob Sie zu langsam sind oder nicht, wird von Ihren Kollegen und Ihrem Vorgesetzten wahrgenommen - relativ zu den anderen Mitarbeitern. Stellen Sie einfach sicher, dass sie das vollständige Bild haben (gründlich, freundlich, hilfsbereit, zuverlässig sind oder weniger Nacharbeit erfordern, dann stellen Sie sicher, dass dies berücksichtigt wird).

Bitten Sie Ihren Chef, Artikel zu priorisieren, damit Sie weniger notwendige Artikel fallen lassen können, wenn Ihnen die Zeit ausgeht.

Auch wenn dies noch niemand erwähnt hat, ist „tu einfach so viel wie du kannst“ ein wichtiger Teil des agilen Prozesses. Grundsätzlich gibt es zwei mögliche Lösungen, wenn ein Projekt in Zeit- und Kostenbeschränkungen gerät: Die erste besteht darin, die Zeit und die Kosten des Projekts zu erhöhen, um alles abzuschließen (die Wasserfalllösung). Die zweite besteht darin, weniger kritische Teile des Projekts fallen zu lassen, damit Sie zum Stichtag ein Minimum Viable Product liefern können: der agile Ansatz.

Daher ist es wichtig, wenn Ihr Chef Sie bittet, „so viel wie möglich zu tun“, um ihn dazu zu bringen, die wichtigsten Teile des Projekts zu priorisieren, damit Sie sie zuerst erledigen können. Dann haben Sie am Ende so viel wie möglich getan, und was Sie in der verfügbaren Zeit nicht erledigt haben, wurde einfach nicht erledigt.

Ein gängiges Werkzeug für diese Art der Priorisierung in Agile ist MoSCoW: Must Do, Should Do, Could Do und Won't Do. Sie sollten vermeiden, mehr als 60 % Ihrer Story Point-Elemente Must zuzuweisen, um Flexibilität nicht zu verlieren.

Wenn Sie die Zustimmung Ihres Chefs dazu erhalten haben, kann es Ihnen auch helfen, das Gefühl zu beseitigen, dass Sie Überstunden machen müssen, um alles zu erledigen, weil Sie nicht alles erledigen müssen. Sie müssen nur so viel wie möglich in Ihrer normalen Arbeitszeit erledigen.

Danke, das ist eine gute Antwort und etwas, das ich mit meinem Vorgesetzten besprechen werde. Ich denke, mein Unternehmen macht nicht genau klar, wie viel Verantwortung Entwickler haben; Der agile Prozess wird nicht erklärt, uns wird nur gesagt: "Hier ist, was wir bis zu diesem Termin erledigen müssen." In gewisser Weise scheint es also so, als würde uns gesagt, dass wir agil sein sollen, aber wir erwarten, dass wir Waterfall liefern.
@Touchdown Ein gängiges Werkzeug für diese Art der Priorisierung in Agile ist MoSCoW: Must Do, Should Do, Could Do und Won't Do. Sie sollten vermeiden, mehr als 60 % Ihrer Story Point-Elemente Must zuzuweisen, um Flexibilität nicht zu verlieren.

Willkommen in der Softwareentwicklung! Jeder einzelne Entwickler hat dieselbe Erfahrung. Ihre einzigen Probleme sind Einschätzung und Work-Life-Balance, nicht "Langsamkeit".

Dass Sie langsam sind, ist genau das, was Ihr Projektmanager Ihnen weismachen will. Konzentrieren Sie sich auf eine genaue Schätzung, nicht auf „schneller sein“. Auf diese Weise können Sie, wenn Ihre Schätzung nicht mit der künstlichen Frist übereinstimmt, die schwierigen Gespräche über den Umfang und die Erwartungen sehr früh im Projekt führen, anstatt sehr spät. Und lassen Sie sich nicht Woche für Woche zu Überstunden drängen. Wenn Sie das tun, werden Sie unweigerlich ausbrennen und Sie werden unglücklich und weniger produktiv sein.

Woher wissen Sie, dass OP nicht langsam ist? Die Produktivität von Programmierern ist sehr unterschiedlich.
Es spielt wirklich keine Rolle, ob OP langsam ist oder nicht. Das Problem ist, dass die Erwartung an seine Produktivität seine tatsächliche Produktivität übersteigt. In der schlanken Fertigung wird dies Überlastung genannt und ist eine Form der Ineffizienz in der Organisation . Ein Junior-Entwickler ist vielleicht viel langsamer als ein Senior-Entwickler, aber er wird nicht über Nacht schneller, wenn er es sich wünscht. Ich sehe sein eigentliches Problem in der Erwartungshaltung und Schätzung, nicht in der Leistung. Wenn er wirklich keine Leistung erbringt, aber genau schätzt, kann das Management mehr Teammitglieder hinzuziehen oder Aufgaben neu zuweisen, bevor es zu einer Krise kommt.

Projekte in der Regel entweder alleine oder in einem sehr kleinen Team durchführen

Sehen Sie, wenn dies das nächste Mal passiert, wie sieht Ihre Leistung im Vergleich zum Rest des Teams aus? Wenn Sie 2 Wochen brauchen, um die 3-Tage-Schätzung fertigzustellen, sehen Sie nach, ob andere Ingenieure auch ähnliche Schätzfehler machen. Wenn sie eine Funktion entwickeln, gehen Sie ihren Code durch und versuchen Sie zu sehen, wie lange Sie dafür brauchen würden, und vergleichen Sie es mit ihrer Zeit.

Da Sie relativ neu sind, ist es in Ordnung, wenn Sie bei 60-70 % der Produktivität von Senioren liegen, aber wenn Sie bei 20-30 % liegen, ist das nicht gut.

Leider sind viele Auftragsarbeiten so. Die häufigste "Lösung" besteht darin, genau und nur das zu implementieren, was die Spezifikation erfordert. Das Testen beschränkt sich auf die genaue Art und Weise, wie die Spezifikation besagt, dass die Software verwendet wird. Vergessen Sie, gute Arbeit zu leisten, den Vertrag zu erfüllen und nicht mehr.

Als Beispiel kam einige Software, die vor ein paar Jahren vergeben wurde, zum Testen zu mir. Mir ist aufgefallen, dass es abstürzt, wenn Sie mehr als 20 Zeichen in eines der Eingabefelder eingeben. Als ich es abfragte, kamen sie mit einem Zitat zurück, um die Spezifikation zu ändern und zusätzliche Tests hinzuzufügen, da meine Firma ursprünglich nicht angegeben hat, dass "darf nicht abstürzen, wenn Sie mehr als 20 Zeichen eingeben".

Es ist scheiße, die meisten Leute hassen es, einen schlechten Job zu machen, wenn sie wissen, dass sie es besser können, aber es ist das, was Ihr Kunde will. Wenn sie mehr wollten, würden sie mehr spezifizieren und mehr bezahlen.

Die gute Nachricht ist, dass Sie mit 3 Jahren Erfahrung in einer Auswahl verschiedener Technologien lernen mussten, dass Sie in einer großartigen Position sind, um einen besseren Job als Entwickler auf mittlerer Ebene zu finden.