https://www.golem.de/news/tech-branche-wir-arbeiten-nicht-null-2304-173002.html

Interessanter Artikel und ich kenne einige denen es auch so geht.

Kann ich als Supporter/Trainer/Tester/BugFinder/Entwickler Nerver/ usw nicht nachvollziehen, aber sicher gibt es solche, bei uns sitzen die aber idR nicht im Tech bereich sondern im Sales, viel bla bla aber wenn mal was getan werden muss, äh ja TECHIES helf doch mal der Kunde aht eine 0815 Frage die schon im datenblatt steht aber ich hab ja null Ahnung hehe

Uff wo man will man denn da anfangen, da läuft ja alles schief was schief gehen kann...

Weil von Agilität die Rede ist, denke ich, dass die Firma sich das nur auf die Stirn schreibt, aber nicht wirklich agil arbeitet (wie man es sehr sehr oft, auch in anderen Auswirkungen, sieht). Ich weiß jetzt nicht ob die in dem Team nach Scrum arbeiten (wird zwar ein mal erwähnt, aber im allgemeinen Context und nicht auf die Fima bezogen), aber damit sollte sowas nicht passieren, da:

• Normalerweise will der PO, dass möglichst viel in kurzer Zeit gemacht wird. 
• Normalerweise haben die Entwickler die Pflicht, möglichst gut zu schätzen. Hier wird bewusst (!) deutlich mehr geschätzt, als benötigt wird. Jeder weiß es und niemand macht was dagegen. 
• Normalerweise sollten die Entwickler an ihren Schätz-Fähigkeiten arbeiten, wenn sie dauernd extrem ungeanu sind. So dass diese von Sprint zu Sprint genauer werden. Woran liegt das Verschätzen? Fehlendes Fachwissen? Aufgaben nicht granular genug / zu granular?
• Normalerweise werden Metriken betrachtet, wie viel im Sprint zu welcher bearbeitet wurde (z. B. durch Betrachtung des Burndown-Charts). Wenn dauernd mehr Zeit als Story Points übrig ist, ist das ein Zeichen dafür, dass das Team nicht ausgelastet ist, also müsste man hier die Story-Points pro Sprint erhöhen.
• Normalerweise ist der SM dafür veantwortlich, dass jeder sich seiner Rolle sowie Rechte und Pflichten auch bewusst ist.

Das Problem ist wie so oft nicht Agilität oder davon abgeleitete Arbeitsmodelle, sondern fehlendes Bewusstsein gepaart mit falscher Anwendung. Die Rollen wissen nicht, was sie zu tun haben (Pflichten) und leben ihre Freiheit (Rechte) zu sehr aus. Oder viel schlimmer: sie wissen es und nutzen es bewusst bis ins Extreme aus.

Nachdem ich das Original gelesen habe muss ich sagen, ich stimme in weiten Teilen zu. Vor allem der Punkt, dass in kleinen Firmen mehr Arbeit getan wird als in Großen würde ich so zu 100% unterschreiben. Je größer das Umfeld, desto einfacher ist es sich hinter der Arbeit anderer Leute zu verstecken. Ebenso fügen die zig Ebenen an Managern über den eigentlichen Arbeitern eher überschaubaren Wert hinzu.

Auch wenn alles was @pr0gg3rsagt in der Theorie richtig ist sagt mir meine persönliche Erfahrung etwas anderes. Da wird dann ewig geschätzt, geplant und refined und das immer mit dem ganzen Team, auch wenn das vielleicht nur 2 bis 3 Leute betrifft und der Rest nur zuhört. Und ich frage mich immer warum? Warum ist es wichtig zu wissen wann was fertig ist und wie viel wir noch in den Sprint packen können? Am Besten finde ich da noch SAFe, da werden dann die nächsten zwei Monate geplant und spätestens ab Sprint 2 schießt eh irgendwas quer. Und Gott bewahre den, der dringend was vom SAFe Team braucht. Da muss dann erst ein Task erstellt, geschätzt und priorisiert werden und der wird dann auch allerfrühestens im nächsten Sprint abgearbeitet.

Mir gefällt der Kanban Approach den wir mittlerweile fahren besser: Wir ziehen genug Sachen aufs Board, damit alle was zu tun haben und arbeiten einfach nach Prio von oben nach unten. Und wenn nicht mehr genug auf dem Board ist, ziehen wir einfach neue Sachen rein - ganz unabhängig davon welchen Tag wir haben. Refined wird regelmäßig gemeinsam, allerdings wird nur ein kleiner Task Breakdown gemacht, Aufwand wird nicht geschätzt. "It's done when it's done". Was würde ein Aufwand ändern? Wir arbeiten eh nach Prio immer am Wichtigsten. Und wenn was Wichtiges gemacht werden muss, dann wird halt auch mal neu priorisiert.

Über Dailies lässt sich meiner Meinung nach streiten, was uns geholfen hat ist zu schauen, dass wir wirklich immer on Topic bleiben und ggf. Diskussionen auf nach dem Daily verschieben. Retros hingegen finde ich super wertvoll, wenn man offen reden kann und die Probleme dann auch angegangen werden. Bei uns hat sich dadurch schon einiges gebessert.

Ich bin mittlerweile ganz glücklich in meinem Team, ich kenne aber auch ganz andere Beispiele. Wichtig ist, dass die Teammitglieder Bock auf das haben was sie tun, Entscheidungen gemeinsam getroffen werden (was nicht heißt, dass immer alle d'accord sein müssen) und nicht am User vorbei entwickelt wird. Wenn die letzten zwei Punkte nicht erfüllt sind, dann geht es ganz schnell bergab - erst Recht in Kombination. Tendenziell gilt auch je mehr Management involviert ist, desto schlechter. Management ist dafür da Ablenkungen von außen abzuwehren und dafür zu sorgen, dass das Team richtig arbeiten kann. Sobald es anfängt reinzureden wie gearbeitet werden soll wird's schwierig. Vor allem wenn das Management versucht die Techies zu überstimmen, das killt auch enorm viel Vertrauen und Motivation.

Der letzte Punkt von mir ist noch die Teamgröße. Zu viele Köche verderben die Suppe. Ich finde Teams von im Optimalfall 4, maximal 6 Entwicklern gut. Bei allem darüber arbeiten die Leute nicht mehr an den gleichen Sachen, was zur Folge hat, dass man nicht weiß wovon der Andere spricht - gerade für Meetings ist das fatal, weil die eine Hälfte immer schläft.

Was ich noch ganz interessant finde sind die Parallelen zu https://medium.com/@pravse/the-maze-is-in-the-mouse-980c57cfd61a

Hier noch ein paar Schlagsätze aus dem Artikel:

• Viele träumen davon, fürs Nichtstun bezahlt zu werden.
  Doch wir müssen ständig so tun, als würden wir arbeiten und das kann extrem frustrierend und kräftezehrend sein.

• Wir arbeiten nicht, wir reden über Arbeit.

• Wenn außerdem jede einzelne Aufgabe so aufgebläht wird und niemand etwas sagt, möchte man das System nicht infrage stellen.

• Die Technik ist nicht der einzige Sektor, der von Unproduktivität durchsetzt ist. Aber die Technologiebranche ist besonders anfällig dafür. Ein Grund ist, dass technische Arbeit von Geschäftsleuten nur schlecht verstanden wird.

• Aus Angst vor einem Jobwechsel klammert sie sich an ihren derzeitigen Job, in dem sie gut bezahlt wird, wenig leistet und wenig lernt. So geht es vielen Beschäftigten in der IT.

Ich kann vielen Punkten leider zu oft zustimmen. Ich höre diese Situationen oft (meist hinter vorgehaltener Hand), wenn man mit Branchenkollegen spricht. Und wenn man mit Nicht-ITlern spricht die sind dann oft erstaunt wie das alles funktionieren kann (insbesondere wenn man dann noch den Lohn anschaut). 

Das ist ja alles auch nichts wirklich neues und man kennt ja den Spruch von 1955: “Work expands so as to fill the time available for its completion.”. Ich bin daher gespannt wie sich das in den nächsten Jahre korrigiert.

 

Bearbeitet 18. April 20232 j von bigvic

vor 9 Stunden schrieb pr0gg3r:

Woran liegt das Verschätzen? Fehlendes Fachwissen? Aufgaben nicht granular genug / zu granular?

Gegenseitiger Vertrauensmangel. "Ich muss mehr schätzen, weil ich sowieso runter gehandelt werde!" vs. "Da ist Puffer eingeschätzt, den muss ich runter handeln!"

Dazu kommt dann noch

vor 9 Stunden schrieb pr0gg3r:

 Aufgaben nicht granular genug / zu granular?

.

 

vor 9 Stunden schrieb pr0gg3r:

Normalerweise ist der SM dafür veantwortlich, dass jeder sich seiner Rolle sowie Rechte und Pflichten auch bewusst ist.

In welcher Hierarchieebene ist der SM? Teamleiter? Abteilungsleiter? Und in welcher Hierarchieebene ist der PO? Oder gar die Stakeholder? Bzw. wie schnell holt ein Stakeholder welche weisungsbefugte Hierarchieebene? Wie hierarchisch ist das Unternehmen? Stehen die agilen Werte nur auf irgend welchen lustigen Plakaten oder werden sie gelebt?

.

vor 9 Stunden schrieb 0x00:

Und ich frage mich immer warum?

Abwälzen der Verantwortung: Man hat keinen vergessen einzuladen und keiner der drölfundzig Anwesenden hat widersprochen!

vor 9 Stunden schrieb 0x00:

Mir gefällt der Kanban Approach den wir mittlerweile fahren besser: Wir ziehen genug Sachen aufs Board, damit alle was zu tun haben und arbeiten einfach nach Prio von oben nach unten.

Aberaber wie könnt ihr dann Termine zusagen? Weil das wird zum 1. Oktober gebraucht!!! 😇

vor 9 Stunden schrieb 0x00:

nach Prio von oben nach unten

Ja Moment, wer sagt denn, dass eure Prio mit meiner übereinstimmt? Und ICH bin nunmal der allerwichtigste Stakeholder! Mein Thema muss als ERSTES erledigt werden!!!!

vor 9 Stunden schrieb 0x00:

Der letzte Punkt von mir ist noch die Teamgröße. Zu viele Köche verderben die Suppe. Ich finde Teams von im Optimalfall 4, maximal 6 Entwicklern gut. Bei allem darüber arbeiten die Leute nicht mehr an den gleichen Sachen, was zur Folge hat, dass man nicht weiß wovon der Andere spricht - gerade für Meetings ist das fatal, weil die eine Hälfte immer schläft.

Eingeschränkte Zustimmung - leider in die Richtung, dass man dieses fehlende Verständnis auch in kleinen (Kopfmonopol-)Teams haben kann.

 

 

vor 41 Minuten schrieb bigvic:

Ich höre diese Situationen oft (meist hinter vorgehaltener Hand), wenn man mit Branchenkollegen spricht.

Aber im eigenen Unternehmen gibt es so was natürlich nie nicht. Wie beim Bürgergeld: Alle anderen würden faul daheim hocken, die faulen Säcke, aber man selber: Niemals!

vor 10 Stunden schrieb 0x00:

Vor allem der Punkt, dass in kleinen Firmen mehr Arbeit getan wird als in Großen würde ich so zu 100% unterschreiben. Je größer das Umfeld, desto einfacher ist es sich hinter der Arbeit anderer Leute zu verstecken.

Aber er sagt ja auch, nur Selbstständige Arbeit ist Arbeit, jeder AN (ob 20 Mann Firma oder 20.000) macht keine richtige.
Sorry, aber auch selbstständige können ihrem Kunden 40h Arbeit verkaufen und machen das dann an 3 Tagen, wenn der Kunde eben zu doof ist um zu wissen was dahinter steckt.

Wie gesagt kann ich davon nichts wirklich nachvollziehen und ich arbeite in einem der größten deutschen Unternehmen.
Ja, man kann seinen Workload drücken, ja man kann andere manchmal für sich arbeiten lassen, aber der Titel sagt: Wir machen nix, die ganze zeit. 0% Arbeit. Und so sachen wie, das dauert max 2h aber wir planen mal 2 Leute ne ganze Woche ein, kenne ich nicht.

Das mag es in US Tech Firmen geben wo tausende eingestellt werden, für die es eigentlich keine Arbeit gibt, ich kann aber hier sagen, von den Entwicklern die ich kenne, den Testern, den Projekten, da mag nicht jeder 100% geben (ich auch nicht - weil das auch nicht immer möglich ist). Aber zwischen 0% und 70% liegen immer noch Welten.

Auch wenn mein Chef mich fragt, wie lange brauche ich für x, dann sag ich erst mal etwas mehr, aber nicht um dann abzugammeln sondern um einen Puffer zu haben falls ich mich verschätzt habe. Wenn ich früher fertig bin, freuen sich alle und dann kann man den nächsten Task angehen. (siehe ST und Scotty wann ist der Warp Kern wieder lauffähig? Ich brauche 5 Stunden, ich gebe dir 3, ich machs in 1)

vor 2 Minuten schrieb Graustein:

Auch wenn mein Chef mich fragt, wie lange brauche ich für x, dann sag ich erst mal etwas mehr, aber nicht um dann abzugammeln sondern um einen Puffer zu haben falls ich mich verschätzt habe.

Was würde denn passieren, wenn du statt der genannten x Tage 1,2x Tage brauchen würdest?

Weshalb ist es für dich besser, wenn du nach 0,75x Tagen fertig bist?

Weshalb ist es okay, sich in die eine Richtung zu verschätzen, aber nicht in die andere?

Es ist beides ok, aber es ist doch besser etwas Puffer zu haben? Besser bin ich schneller fertig als langsamer, muss man das erklären?
Es reißt mir aber auch keiner den Kopf ab wenn ich sage, es hat halt x Zeit länger gedauert, aber ich finde es einfach besser fürher oder on time fertig zu sein.
Gerade weil bei mir auch Kunden direkt involviert sind.
Wenn ich also sage 2 Tage und es dauert 3 Tage und der Kunde hat die 2 Tage eingeplant, muss daher dann umplanen.
Ist doch doof. Wenn ich sage 4 Tage, aber ich bin nach 3 fertig, hat der Kunde seine Sache genau dann wenn er es braucht/eingeplant hat.
Ich verstehe also die grundsätzliche Frage nicht, denn es ist einfach logisch, dass es immer besser ist etwas Buffer zu haben. Haben ist besser als brauchen. Natürlich sag ich nicht, ich brauche 2 Wochen und bin nach 3 tagen fertig uns spiel mir dann an den Eiern.
Also man sollte schon relativ gut schätzen. Da man selten auf die Minute genau schätzen kann, schätzt man halt lieber etwas mehr.

vor 24 Minuten schrieb allesweg:

Weshalb ist es okay, sich in die eine Richtung zu verschätzen, aber nicht in die andere?

Genau das Verständnis fehlt aber leider vielen, dass beides ähnlich schlecht ist. Ich erlebe es auch oft, dass jede Ebene immer mehr Puffer draufschlagen und zum Schluss sind die Zeiträume enorm. Und das ist auch eine Spirale wie schön im Artikel beschrieben. Und das ist dann wieder schwer zu durchbrechen, denn was passiert wenn man für einen 2 Stunden-Task 1 Woche Zeit hat? Richtig, viele machen den Task am Ende der Deadline und siehe da man hat 1 Woche gebraucht 😏

Meiner Meinung nach muss man eine Kultur schaffen, bei dem es Positiv ist, wenn man sagt "Hey, ich bin schon fertig mit dem Task. Was kann ich jetzt tun!".

 

Bearbeitet 18. April 20232 j von bigvic

Gut, dass ihr immer alle on Time seit und auch bei Verabredungen immer auf die Sekunde genau da seit. Keine Minute früher oder später (btw was ist besser -  ich bin 15 Minuten zu früh am Kino mit meinen Freunden oder 15 Minuten zu spät -  natürlich on time wäre besser -  wann fahrt ihr zu einem Termin, wenn ihr 9 Uhr da sein müsst und es dauert bei optimalem Verkehr 30 Minuten - 8:30 los oder? ;-))
Scheinbar alle Bandarbeiter wo man auf die Sekunde seine Arbeit abschätzen kann, ich brauche x zeit um 3 Pakete einzupacken....

Dachte wir sind in der IT, wo alles komplex ist, jeder jeden Tag 100 neue Dinge lernt und man ja 24/7 sich weiterbilden muss
Aber trotzdem kann man seine komplexe Arbeit auf die Minute genau einschätzen

 

Wie gesagt, es ist sicher nicht gut wenn man für einfachste Dinge die 10x Zeit sagt. Das ist schlecht.
Ich sehe aber nichts schlechtes daran wenn ich statt 3 tagen nur 2 brauche. Ich sitze wie gesagt dann ja auch nicht rum, das hat ja dann auch nix damit zu tun, dass man Puffer aufschlägt, sondern einfach ne faule Sau ist.

Mal ein Beispiel aus meinem Leben:
Wir haben eine SW mit diversen Versionen. Manche Kunden haben noch sehr alte Versionen und wollen jetzt upgraden.
Die SW läuft noch auf Server 2008, die neue kann da nicht laufen, sie wollen auch einen neuen Server mit Server 2019 usw.
So dann hab ich einen Service, sie geben mir ihr altes Backup, ich spiele das in eine alte VM, mache diverse Upgrades und gebe denen dann ein Backup ihrer Config für die neuste Version, die sie dann einspielen können.
Nun fragt mich der Kunde/Sales wann/wie lange braucht es. Wenn alles klappt usw ist das an einem Tag locker erledigt.
Sag ich einen Tag? Hell no, i dont. Warum?
Manchmal kommt es zu Problemen, dann wäre es doof, wenn der Kunde extra vor Ort gefahren ist um das Update einzuspielen, ich sag also ok wir brauchen 2 Tage. Ich hab einen Tag Puffer, wenn etwas passiert, kann ich das noch lösen, Kunde zufrieden, dass alles im Zeitrahmen war. Wenn ich früher fertig bin mache ich halt andere Dinge.

Aber das ist wie gesagt vielleicht auch so ein Support/Trainer Ding. Hier ist immer was zu tun, Tickets kommen rein, einfach liegen lassen oder sagen: Für das um heben deiner Lizenz, was mich 5 Minuten kostet brauch ich 2 Tage? Keine Chance.
Nix tun fällt auf.

vor 19 Minuten schrieb bigvic:

Meiner Meinung nach muss man eine Kultur schaffen, bei dem es Positiv ist, wenn man sagt "Hey, ich bin schon fertig mit dem Task. Was kann ich jetzt tun!".

^^THIS!

vor 2 Minuten schrieb Graustein:

Gut, dass ihr immer alle on Time seit

Ich plane so, dass ich mit den üblichen zu erwartenden Unwägbarkeiten zum vereinbarten Zeitpunkt am vereinbarten Treffpunkt bin. Sobald absehbar ist, dass ich den Termin signifikant nicht einhalten kann, informiere ich alle relevanten Personen über die akutell zu erwartende Verspätung. Falls eine Ortsverlegung möglich ist und die Verschiebung minimiert, schlage ich diese vor.

Bin ich zu früh, nutze ich die Zeit zum Lesen/Hörbuch hören, Verabreden mit anderen Leuten am anderen Tag, ...

vor 9 Minuten schrieb Graustein:

Scheinbar alle Bandarbeiter wo man auf die Sekunde seine Arbeit abschätzen kann, ich brauche x zeit um 3 Pakete einzupacken....

Nein, ich arbeite ein Paket ab, während mindestens ein weiteres Arbeitspaket vollständig geklärt bereit liegt. Und ein weiteres, drittes Arbeitspaket ist der zeitnahe Termin zur Abklärung des vierten Arbeitspakets, für welches ich AP1 unterbreche.

Unfair später was rein zu editieren
Aber ja dem kann ich auch zustimmen und so ist es zumindest hier im Team/Firma (eigentlich) auch.
Ich kann jetzt nicht für jeden sprechen, aber keiner bläht seine Aufgaben künstlich auf um dann abzuchillen.

vor 6 Minuten schrieb allesweg:

Ich plane so, dass ich mit den üblichen zu erwartenden Unwägbarkeiten zum vereinbarten Zeitpunkt am vereinbarten Treffpunkt bin

So mache ich es ja auch, nur ist man dann halt öfter mal zu früh fertig, wenn alles läuft wie es laufen sollte. Was ja laut dir auch nicht so toll ist, es ist aber immer noch besser als zu spät da zu sein/fertig zu werden.
Unwägbarkeiten können auch mal wegfallen. Oder kürzer sein oder auch mal länger oder mehr oder weniger.
Und wenn im Treffen Beispiel nur ich dann halt 20 Minuten warten muss weil zu früh ist das doch eben besser als wenn 3,4,5 andere 20 Minuten warten weil halt.

Ich würde auch gerne behaupten, dass ich nicht arbeite.
Aber wahrscheinlich ist das Unternehmen zu klein, bzw. die Abteilung zu klein dafür. Wir kommen Teilweise (Krankheit, Urlaub, Corona) nicht bei größeren Projekten weiter, weil das Tagesgeschäft eben dazu zählt.

Folgenden Punkt würde ich mal aufgreifen:

• Aus Angst vor einem Jobwechsel klammert sie sich an ihren derzeitigen Job, in dem sie gut bezahlt wird, wenig leistet und wenig lernt. So geht es vielen Beschäftigten in der IT.

Ich selbst bin zufrieden mit meiner Situation und sehe mich als IT-Sachbearbeiter, der seine Aufgaben abarbeitet. Richtig stark weiterentwickeln tu ich mich wahrscheinlich nicht mehr, ich passe mich dem Markt und dem Unternehmen an und arbeite mich in neue Thematiken relativ schnell ein.
Meinen Job will ich zumindest auf die nächsten 5 Jahre gesehen nicht wechseln. Ich werde gut bezahlt, die Arbeitszeiten sind auch in Ordnung, die Vorgesetzten sind gut und ich habe es nicht weit ins Büro.

In anderen Unternehmen, würde ich sicherlich noch mehr und schneller lernen und mich weiterentwickeln, aber darauf liegt mein Fokus nicht mehr, das Privatleben ist mir hier wichtiger.
Das beobachte ich auch in meinem Umfeld, vor ein paar Jahren wollten alle viel und schnell Geld verdienen, jetzt ist der private Ausgleich aber wichtiger und wichtiger Zeit mit Familie und Freunden zu verbringen und nicht täglich 10h im Büro zu sein.

 

Wenn man unbedingt Schätzungen abgeben muss, dann bin ich ein Fan von drei verschiedenen Schätzungen: Best, worst und average case. Die drei können auch identisch sein, aber ein "Wenn X passiert, dann brauchen wir Y Manntage" ist realistischer anstatt pauschal eine Zahl zuzuweisen.

Witzigerweise habe ich aber auch die Erfahrung gemacht, dass man sich für eine Deadline (unterbewusst?) mehr reinhängt, einem Task mehr Zeit zuzuweisen resultiert i.d.R. darin, dass er auch länger braucht. Ich glaube bei den meisten ist das noch nicht einmal Absicht, das ist einfach die menschliche Natur. Erlebe ich bei mir selbst auch immer wieder so.
Wie @bigvic schon sagte: "Work expands so as to fill the time available for its completion". Es ist aber auch nicht so, als das man dann bis zur letzten Stunde nichts tut und dann auf einmal alles hektisch abarbeitet, ich zumindest versuche Sachen sauberer/besser zu machen, wenn ich weiß, dass ich mehr Zeit habe. Vielleicht refactored man dann mal den anliegenden Code, der einem schon immer ein Dorn im Auge war, anstatt nur die benötigte Funktionalität einzubauen, wenn man zwei Tage mehr Zeit hat.

 

vor 40 Minuten schrieb Graustein:

Aber er sagt ja auch, nur Selbstständige Arbeit ist Arbeit, jeder AN (ob 20 Mann Firma oder 20.000) macht keine richtige.

Das ist so nicht richtig:

Zitat

The title of this article says I’ve almost never worked when employed in tech. But that doesn’t mean I’ve never worked. In fact, I’ve worked really hard and been part of amazingly productive teams which delivered top-notch products in record time (and clients loved them). The thing is, this hasn’t happened in a traditional environment, that is, when employed full time by a mid-sized or large tech company. It was only when working as a freelancer or for early-stage start-ups that I’ve witnessed productive tech work.

Das wiederrum ist völlig richtig:

vor 40 Minuten schrieb Graustein:

Sorry, aber auch selbstständige können ihrem Kunden 40h Arbeit verkaufen und machen das dann an 3 Tagen, wenn der Kunde eben zu doof ist um zu wissen was dahinter steckt.

Habe ich auch so schon ähnlich erlebt. Da waren es keine Selbstständigen, sondern externe Dienstleiser, aber trotzdem. Mein Kollege ist seit fast einem Jahr in einem Kundenprojekt (großes, börsennotiertes deutsches Unternehmen) und laut eigener Aussage hätte er seine gesamte Arbeit in einer Woche erledigen können. Natürlich hat er auch anfangs nachgehakt ob das wirklich notwendig ist, wieso so wenig passiert, wieso alles überschätzt wird, wieso sie dauernd das Rad neu erfinden und zudem am User vorbeientwickeln, das ganze Paket halt. Aber wenn die (vokale) Mehrheit (inkl. Management) das anders sieht, dann hörst du irgendwann auf diese Fragen zu stellen. Es gibt halt sinnvolleres als jedes Mal wieder gegen die gleiche Wand zu rennen.
Dennoch ist das ganze auch für ihn sehr frustrierend, er will ja was machen. Stattdessen gibt es einen Haufen überschätzter Bullshit-Tasks. Kein Wunder, dass er mit dem Gedanken spielt die Kündigung einzureichen. 

Was eigentlich eine gute Überleitung zu den Punkten von @bigvic ist:

vor 1 Stunde schrieb bigvic:

Viele träumen davon, fürs Nichtstun bezahlt zu werden.
Doch wir müssen ständig so tun, als würden wir arbeiten und das kann extrem frustrierend und kräftezehrend sein.

Ich (und viele meiner Kollegen) träumen davon spannende Aufgaben zu lösen. Wenn ich das nicht haben kann, dann will ich wirklich fürs Nichtstun bezahlt werden. Heißt ich brauche gar nicht aufzukreuzen und kann irgendwas machen. So zu tun, als würde man arbeiten, ist definitv einfach nur extrem frustrierend und wahnsinnig kräftezehrend.

vor 1 Stunde schrieb bigvic:

Wir arbeiten nicht, wir reden über Arbeit.

Geht oft mit dem ersten Punkt einher und korrelliert stark mit der Anzahl der Meetings. Also ja, definitv. 

vor 1 Stunde schrieb bigvic:

Wenn außerdem jede einzelne Aufgabe so aufgebläht wird und niemand etwas sagt, möchte man das System nicht infrage stellen.

Erstens vielleicht das - je nachdem wie rebellisch man selber ist. Aber selbst der Rebellischste hört irgendwann auf, weil es nichts bringt und einen selbst nur zermürbt. "Love it" oder "Leave it" ist oft einfacher als "Change it".

vor 1 Stunde schrieb bigvic:

Die Technik ist nicht der einzige Sektor, der von Unproduktivität durchsetzt ist. Aber die Technologiebranche ist besonders anfällig dafür. Ein Grund ist, dass technische Arbeit von Geschäftsleuten nur schlecht verstanden wird.

Könnte sein, keine Ahnung. Oft sind das Problem aber auch die Geschäftsleute (sprich Management) selbst. Diese sind ja für einen Großteil der Meetings verantwortlich und damit einer der größten Zeitfresser. Auch kann von der Seite extrem viel Motivation gekillt werden, wenn das Management versucht den Technikern die Technik zu erklären, unnötige Requirements stellt und Micromanagement betreibt. In allen mir bekannten Fällen ist das Management der Hauptverursacher des Problems.

vor 1 Stunde schrieb bigvic:

Aus Angst vor einem Jobwechsel klammert sie sich an ihren derzeitigen Job, in dem sie gut bezahlt wird, wenig leistet und wenig lernt. So geht es vielen Beschäftigten in der IT.

Weiß ich nicht. Kommt denke ich ganz stark auf die Person und deren aktuelle Lebenssituation drauf an. Ich kenne mehrere Leute, die nicht lange gefackelt und dann auch gewechselt haben, als sie gemerkt haben, dass sie hier nichts ändern können. Ich kenne aber auch Leute, die immer noch den selben (laut eigener Aussage unnötigen) Job machen oder lange gezögert haben. Kann man so pauschal nicht sagen, aber 100k bei langweiligen oder unnötigen Aufgaben ist halt oft attraktiver als 70k und dafür Bleeding Edge Themen in einem motivierten Team.

Wie gesagt, ich habe das Problem zum Glück (aktuell) nicht, kenne aber leider Einige, die genau damit kämpfen. Manchmal kann man etwas ändern, manchmal hilft aber auch nur ein Team- oder Projektwechsel. Wenn es hart auf hart kommt, muss man aber leider Gottes oft zur Kündigung greifen. Das ist oft so tief im Mindset der entscheidenden Personen verankert, da trifft man auf unbewegliche Fronten. "Change it" ist da selten eine Option, bleibt also nur "Love it" oder "Leave it". Und wenn genug Personen "Leave it" wählen, vielleicht findet dann auch irgendwann ein Change statt. Hey, man wird ja noch träumen dürfen...

vor 3 Minuten schrieb 0x00:

Das ist so nicht richtig:

Doch, steht da doch:
 

vor 4 Minuten schrieb 0x00:

It was only when working as a freelancer or for early-stage start-ups that I’ve witnessed productive tech work

Ok, und Start-ups ganz zu Beginn wo jeder noch 80h arbeitet weil man Arbeit für 10 hat aber nur zu 3 ist.

Ein 50 Mann KMU ist kein Start-up, 99,99% der FIrmen in Deutschland sind keine Start-up und noch weniger early stage.
Wir arbeiten also alle nix. Außer jemand hier wäre in einem early-stage startup?

Von daher halte ich den Artikel eben für Käse, klar er spricht ein paar Punkte an, aber im großen kann ich es nicht nachvollziehen, aber ich bin auch kein Twitter Entwickler der von 9-10 ein Meeting hat, dann 2h yoga und entspannung macht, am nachmittag nochmal 1 meeting und dann um 3 uhr feierabend macht

vor 48 Minuten schrieb Graustein:

So mache ich es ja auch, nur ist man dann halt öfter mal zu früh fertig, wenn alles läuft wie es laufen sollte.

Wenn sich das häuft, schätzt man zu defensiv.

 

vor 50 Minuten schrieb Graustein:

Und wenn im Treffen Beispiel nur ich dann halt 20 Minuten warten muss weil zu früh ist das doch eben besser als wenn 3,4,5 andere 20 Minuten warten weil halt.

Richtig. Weil einmal sind es 20 Personenminuten, im anderen Fall 60-100 Personenminuten. Nur: Wie oft kommt es vor, dass man 20 Minuten Puffer vor dem Meeting einplanen muss? Im Büroalltag weniger, bei Reisetätigkeit gerne auch mal etwas mehr.

Beispiel aus einem klitzekleinen Projekt:

3 Personen, jeder braucht realistisch 5 Tage = 15 Tage.
Aber die Personen wollen alle Puffer und sagen daher zum Projektleiter bei der Aufwandschätzung, dass sie 7 Tage brauchen = 21 Tage. Der PL ist natürlich Profi und rechnet mit 20% Risikopuffer = 25  Tage. Der Sales dankt dem PL und macht 30 Tage draus, denn bisschen Marge muss ja sein.

Tada .. Projektaufwände verdoppelt. Und nun denkt man mal an grössere Projekte mit viel mehr Personal & Ebenen 

Bearbeitet 18. April 20232 j von bigvic

@bigvic bei deinem Beispiel sehe ich aber eher das Problem in der internen Kommunikation. Wenn klar kommuniziert wird, wer von den Beteiligten einen Puffer einplanen darf und in welchem Umfang, sollte es auch nicht zu einer so extremen "Fehleinschätzung" kommen.
Wenn natürlich jede Ebene, die selber gar keinen "aktiven" Anteil am Projekt hat, sondern nur administriert/verkauft auch der Meinung ist, man müsse noch zusätzliche Zeit einplanen, die bereits in der Ebene davor eingeplant wurde, ist es natürlich klar, dass es zu solch aufgeblähten Aufwänden kommt.

vor 2 Minuten schrieb Rienne:

Wenn natürlich jede Ebene, die selber gar keinen "aktiven" Anteil am Projekt hat, sondern nur administriert/verkauft auch der Meinung ist, man müsse noch zusätzliche Zeit einplanen, die bereits in der Ebene davor eingeplant wurde, ist es natürlich klar, dass es zu solch aufgeblähten Aufwänden kommt.

In dem Fall ist die von Sales draufgeschlagene Zeit aber ja direkt Profit.. der Kunde des Projekts bezahlt das ja am Ende.

Und eventuell fallen da dann noch so Dinge drunter wie "die ersten paar Supportanfragen umsonst" etc.

Wieso darf $EbeneX Puffer einplanen, ich auf $EbeneY aber nicht?

Wenn auf $EbeneX n % Puffer eingeplant werden dürfen, wieso sollte ich diese nicht auf $EbeneY nutzen?

@RienneAbsolut, aber leider ist das oft genau so der Fall, denn jeder will auf der "sicheren Seite sein" und "lieber zu viel als zu wenig Puffer" planen. Denn weniger Zeit brauchen ist ja immer besser als zu viel

Es braucht sehr sehr viel Überzeugungsarbeit und Uebung für transparente und ehrliche Aufwandsschätzung.

Und wenn man im realen Markt agiert, dann bekommt man das Feedback ja irgendwann, wenn man auf einmal die Deals verliert, da zu teuer. Bei einer internen IT fällt sowas nicht so schnell auf - hat aber ggf. umso heftigere ad hoc Konsequenzen .

Bearbeitet 18. April 20232 j von bigvic

vor 2 Minuten schrieb Brapchu:

In dem Fall ist die von Sales draufgeschlagene Zeit aber ja direkt Profit..der Kunde des Projekts bezahlt das ja am Ende

ich weiß nicht wie das bei euch ist, aber wir zahlen unsere Dienstleister nach Aufwand also nö, eher sagt der Kunde dann "juhu, ging doppelt so schnell und kost' nur die Hälfte" und wundert sich vielleicht, warum der Dienstleister so ungenaue Zeitangaben macht.

@Brapchu klar ist der Aufschlag des Sales aus deren Sicht Profit, aber nur, wenn dieser Aufschlag auch nur auf dem Papier für den Kundenvertrag so bleibt und nicht als Zeit an die Entwickler weitergegeben wird, denn normalerweise sollte der angestrebte Profit schon im normalen Stundensatz der verkauften Ressourcen enthalten sein. Wenn der Kunde bereit ist, mehr zu zahlen, super. Wenn aber intern gesagt wird: Ihr habt für die geschätzen 21 Tage jetzt 30 Tage Zeit, ist das was anderes.

vor 5 Minuten schrieb Bitschnipser:

ich weiß nicht wie das bei euch ist, aber wir zahlen unsere Dienstleister nach Aufwand also nö, eher sagt der Kunde dann "juhu, ging doppelt so schnell und kost' nur die Hälfte" und wundert sich vielleicht, warum der Dienstleister so ungenaue Zeitangaben macht.

Hmm, euer Dienstleister ist wohl nicht sehr gewinnorientiert

Wenn der Kunde 30 Tage abnickt, dann werden idR auch 30 Tage verrechnet und wenn man weniger braucht .. super, mehr Marge.

Bearbeitet 18. April 20232 j von bigvic