TECH-BRANCHE : Wir arbeiten nicht. Null.

[Graustein]

vor 38 Minuten schrieb bigvic:

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 

Da liegt es nicht am Puffer sondern fehlender Kommunikation. Ganz einfach 

und ein Sales der Puffer einbaut? Nie gesehen 

Eher wird der Aufwand gedrückt und jaja das geht ganz schnell 

[Rienne]

vor 11 Minuten schrieb bigvic:

Absolut, 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

Da sind wir wieder bei dem Problem, was hier teils schon angesprochen wurde: Etliche "moderne" Softwareentwicklungsunternehmen schreiben sich AGIL auf die Fahne, aber es wirklich anwenden, so wie es gedacht ist, macht keiner. Eine dynamische Zeitschätzung sollte es im agilen Umfeld nicht geben. Da sollte feststehen, zu welchem Zeitpunkt mit wie viel Ressourcen das Produkt fertig zu sein hat. Der Umfang des Produktes ist das, was bei agiler Entwicklung variabel sein sollte. Und die Umfangsschätzung der Sprints (wenn man jetzt von SCRUM bei dem agilen Team ausgeht) liegt dann alleine bei den Entwicklern, ohne dass dort noch x Ebenen ihren Teil dazu "puffern". Aber das ist halt leider oftmals nur auf dem Papier die agile Softwareentwicklung.

Bearbeitet 18. April 2023 von Rienne

[bigvic]

Im Artikel hat auch schon diese Ebene / Methodik eine Dynamik mit massiver Ueberschätzung der Aufwände und daher kein Allheilmittel, sondern Kontraproduktiv in der Praxis.

[Rienne]

vor 17 Minuten schrieb allesweg:

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

Wieso sollte Ebene X und Ebene Y, die selber keinen weiteren Zeitaufwand mit dem Projekt haben, sondern rein administrativ agieren (sprich Zeitaufwand an Gesamtprojekt z.B. <1%) für ihren Aufwand einen Puffer von 300% anwenden, aber diejenigen, deren Projektbeteiligung wesentlich höher liegt, nur 20%?
Wenn schon jede Ebene Puffer einplanen darf, dann sollte dieser auch entsprechend deren eigener Aufwände mit dem selben Satz berechnet werden und nicht einfach auf die Gesamtzeit aufgeschlagen werden, oder?
Um bei dem Beispiel von @bigvic zu bleiben: Ich glaube kaum, dass Sales selber noch einmal einen Aufwand von 20% der vom PL gemeldeten Zeit an dem Projekt hat.

[allesweg]

Wieso darf überhaupt irgend jemand Puffer einplanen?

Wieso fehlt das gegenseitige Vertrauen?

[Graustein]

Was hat das mit Vertrauen zu tun?

wenn mich der Sales fragt wann ich x für den Kunden fertig habe, dann sag ich: wenn alles klappt zu x aber lass uns lieber y sagen weil es könnte z passieren.

meistens kauft der Kunde auch x Stunden aber abgerechnet werden dann y, nach Aufwand halt.

vielleicht bin ich da auch nicht faul genug oder bescheißer genug oder kann halt genug selber entscheiden.

[allesweg]

vor 8 Minuten schrieb Graustein:

wenn mich der Sales fragt wann ich x für den Kunden fertig habe, dann sag ich: wenn alles klappt zu x aber lass uns lieber y sagen weil es könnte z passieren.

gerade hieß es doch noch, dass ich statt des tatsächlichen Aufwandes x vorsätzlich Puffer einplane und nur y kommuniziere?! Und auf dieses y schlägt Sales dann nochmal was auf, wodurch wir bei z landen!

[Graustein]

Dass hieß es in bigvics ausgedachten Beispiel, sicherlich nicht in meiner Realität 

[allesweg]

vor 4 Stunden 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.

Hervorhebung durch mich.

[Rienne]

vor einer Stunde schrieb allesweg:

Wieso fehlt das gegenseitige Vertrauen?

Wie ich schon im ersten Post zu dem Beispiel von @bigvic sagte: Das Problem bei seinem Beispiel ist die Kommunikation (oder, wie du es nennst: das Vertrauen). Dass man einen Puffer einplant, ist mMn ganz normal (denn Verzögerungen und unvorhersehbare Dinge können immer passieren und man möchte ja auf jeden Fall, dass man bei seinem verkauften Projekt mind. mit plus-minus Null raus geht und idealerweise mit einem Plus). Das Problem bei dem aufgeführen Beispiel ist, dass jede Ebene, die irgendwie mit dem Projekt zu tun hat, jedes mal noch einmal einen Puffer aufschlägt. Wäre da eine klare Kommunikation à la "Bitte plant euren idealen Zeitaufwand, in den von uns angesetzten Tagessätzen sind bereits ggf. anfallende Mehraufwände eingerechnet." oder "Die Sales Abteilung verkauft pauschal x% mehr von dem euch geschätzten Aufwand, so dass ihr bitte keinen Puffer einplant." oder "Wir sind uns bewusst, dass es zu Verzögerungen/Mehraufwand kommen kann, daher bitten wir euch (Entwickler) eine reale Aufwandsschätzung auf die ihr dann noch einmal 20% aufschlagt." Dann weiß auch die PL, dass Puffer bereits eingeplant ist und muss nicht selber noch einmal etwas für den Aufwand der Entwickler aufschlagen und die Sales-Abteilung muss auch nicht noch einen Mehraufwand einplanen, der dann an die Entwickler in Form von "Ihr habt ja x Tage geschätzt, wir haben x+z Tage daraus gemacht (also lasst euch ruhig Zeit )."
Von einer hinzugefügten Marge ist ja gar nicht die Rede, denn der Preis, den der Kunde am Ende zahlt, sollte nichts mit dem möglichen Däumchendrehen der Entwickler, die unproduktiv sind, zu tun haben.

 

  

vor einer Stunde schrieb bigvic:

Im Artikel hat auch schon diese Ebene / Methodik eine Dynamik mit massiver Ueberschätzung der Aufwände und daher kein Allheilmittel, sondern Kontraproduktiv in der Praxis.

 Das ist aber ein Problem auf mehreren Ebenen. Wenn die Entwickler ihre Aufgaben künstlich aufblähen, muss meiner Meinung nach der Scrummaster eingreifen. Wenn die Inkrements sich zu langsam entwickeln, sollte der Product Owner nachhaken. Wenn die Stakeholder jedoch bereit sind für so einen geringen Mehrwert (wie im Artikel angesprochen) die entsprechende Summe Geld zu zahlen, sind sie doch auch in gewisser Weise Schuld daran, dass die großen US Techkonzerne so arbeiten, wie sie arbeiten. Und ja, früher oder später wird diese Blase sicherlich platzen. Für einen Großteil der deutschen Softwareentwicklung (außer vielleicht bei den immer wieder scheiternden und aufgeblähten SAP-Projekten) sehe ich dieses Problem jedoch eher nicht.

 

 

Bearbeitet 18. April 2023 von Rienne

[allesweg]

vor 3 Minuten schrieb Rienne:

Dass man einen Puffer einplant, ist mMn ganz normal [...] also lasst euch ruhig Zeit

womit wir wieder beim

vor 5 Stunden schrieb bigvic:

Spruch von 1955: “Work expands so as to fill the time available for its completion.”

ankommen.

Und somit beim künstilchen Aufblähen des Aufwandes.

 

Ich bleibe bei meiner Ansicht, dass geplanter Puffer schädlich ist.

 

[skylake]

In meiner Zeit in der Wirtschaft kann ich bestätigen, dass mehr gechillt als gearbeitet wurde. Die einzige Ausnahme waren freiberufliche Auftragsarbeiten und selbst da wurde sehr großzügig die Stunden abgerechnet.

Ganz extrem war es in einer Firma, die für einen medizinischen Großkunden die Software betreut/entwickelt hat. Dort gab es Monate, in der neben sehr gemächlichen Bugsuchen nichts passiert ist. Also um 9 auftauchen, maximal 2 Stunden arbeiten und der Rest wurde mit rumsitzen, surfen und Mitarbeiterpflege verschwendet. 

Das hat allerdings weder den Chef gestört, noch den Kunden. 😅. Ich hatte die Zeit dann genutzt noch in Vollzeit zu studieren, während ich in Vollzeit angestellt war 😇. 

[Graustein]

vor 9 Minuten schrieb allesweg:

Hervorhebung durch mich.

Und jetzt? Da steht nicht ich rede nicht darüber wie der Aufwand sein könnte. Und selbst wenn ich alles für mich behalte und nur sagen 3 Tage obwohl es im besten Fall in 2 Tagen fertig ist: kein anderer wird da noch Puffer drauf schlagen. Wieso auch. Das ist doch alles BS und wenn es vorkommt falsch. Puffer kann nur der nennen der ausführt. 
ansonsten ist es,  wie nennt man das heute: übergriffig 

jeder andere MUSS Rücksprache mit dem ausführenden halten. 

[Rienne]

vor 1 Minute schrieb allesweg:

Ich bleibe bei meiner Ansicht, dass geplanter Puffer schädlich ist.

Deswegen sage ich ja, sofern die Entwicklung wirklich so agil wäre, wie diese sich auf dem Papier immer darstellt, benötigt man gar keine dynamische Zeitschätzung geschweige denn Puffer, da die Zeit fix ist. Stattdessen sollte man klar sagen: "Ich schaffe in der veranschlagten Zeit x folgenden Punkte." Sollte das mal nicht der Fall sein, wandern die nicht erledigten Dinge in den nächsten Sprint und man passt seine (auf Erfahrung beruhende) Zeitschätzung an.

Ich selber bin auch kein großer Fan von der angeblichen Scrum-Teams vieler Firmen, denn die leben oftmals dann doch noch zu sehr in der klassischen Projektwelt. Ich persönlich bin da bei @0x00 und finde einen leichten Kanban-Approach besser als diese angeblich strikte Rumscrumerei, die sowieso schon alleine bei Teamgrößen und Scopes verletzt wird. Nicht ohne Grund hagelt es auch immer wieder Kritik an SCRUM (alleine der oftmals unnötige Zeitaufwand ohne jeglichen Mehrwert von Dailies - aber man muss sie ja halten, weil das ist so vorgegeben).

[bigvic]

vor 16 Minuten schrieb Rienne:

Für einen Großteil der deutschen Softwareentwicklung (außer vielleicht bei den immer wieder scheiternden und aufgeblähten SAP-Projekten) sehe ich dieses Problem jedoch eher nicht.

Echt nicht? Gerade die T-Systems dieser Nation sind ja bekannt genau dafür und nicht ohne Grund nicht wettbewerbsfähig / unprofitabel.

[allesweg]

Ach es liegt an der Methode Scrum, dass Schätzungen vorsätzlich mit Puffer versehen werden? Und wenn man Kanban macht, passiert das nicht?

[bigvic]

**Achtung: Triggerwarnung**

Wenn wir mal von der groben Korrektheit des Artikels ausgehen als Gedankenexperiment .. was wäre mir denn dann als "Betroffener" besonders wichtig um das irgendwie auszuhalten um das Beste draus zu machen? Bitte keine Antwort posten

Bearbeitet 18. April 2023 von bigvic

[Graustein]

btw IT ist heute also nur SWE?

Administration, Support, usw gibt es nicht mehr? Macht alles Chat GPT? 😉

[allesweg]

@bigvic das wäre mir dann wichtig:

[bigvic]

Ein Bekannter hat sich das gekauft um immer "online" zu sein: https://www.amazon.de/AUS-Schalter-Treiberfreier-Mausbeweger-Bildschirmschoner-Schlaf-Modus-Schwarz/dp/B09HC4T4M4/ref=mp_s_a_1_1_sspa?adgrpid=71592994539&hvadid=597501240689&hvdev=m&hvlocphy=1003293&hvnetw=g&hvqmt=e&hvrand=6801355952902773618&hvtargid=kwd-926654544916&hydadcr=619_2598824&keywords=automatischer+mausbeweger&qid=1681818900&sr=8-1-spons&sp_csd=d2lkZ2V0TmFtZT1zcF9waG9uZV9zZWFyY2hfYXRm&psc=1

[0x00]

Für Windows empfehle ich die "Awake" Funktion der Microsoft PowerToys.

[bigvic]

Adminrechte notwendig?

[Graustein]

Also doch ein Troll Faden 😉

[0x00]

vor 34 Minuten schrieb bigvic:

Adminrechte notwendig?

Zum installieren? Ja. Hinterher selbstverständlich nicht mehr.

[Perceptor]

Ich weiß nicht wo euer Problem ist. Wir bekommen gutes Geld für eine Thematik die viele Menschen abstrakt finden, abschreckt und sich manchmal lustig machen. Das heißt aber, dass wir unser Können nicht beherrschen. Es wird nur selten gefragt, weil keiner so genau weißt was genau wir machen, nur das es sehr kompliziert sein muss. Egal ob wir viel machen oder wenig. Drei Zeilen Code hinzuschreiben ist immer noch mehr Aliensprache als ein Brief vom Amtsgericht. Und nur dafür gibt es gutes Geld.😁