Kleine Anekdote: als ich in dem Unternehmen, in dem ich derzeit arbeite, angefangen habe, gab es Schulungen. Unter anderem die Schulung "Verschwendung". Da bekam man alle möglichen Dinge erklärt, was denn unnötige Tätigkeiten seien, die die Wertschöpfung mindern. Und wir wurden gefragt, welche Tätigkeit wir durchführen und ich meine Tätigkeit erklärt habe, bekam ich zu hören, dass ich 100% Verschwendung sei. Das motiviert doch für die nächsten Jahre
Dann stellt sich die Frage, warum du überhaupt angestellt wurdest. Irgendwer muss ja deinen Wert von X € plus Sozialabgaben für lohnenswert für das Unternehmen gesehen haben. ;-) Eine große Gefahr für Unternehmen ist auch, wenn alle an einem Strang ziehen, aber jeder in eine andere Richtung. Öfters sind Abteilungen ohne Abteilungsleiter deutlich effektiver als Abteilungen mit einem Manager, der nur Sauerstoff verbraucht.
Und hatte man recht, dass deine Tätigkeit unnütz war. Bei uns sind auch zig Leute beschäftigt, welche „wenn morgen nicht mehr da“ keiner bemerken würde.
@christianhabermann6527 Nichts kann man für $10 kaufen. Du musst einen Antrag stellen (das kostet schon mehr an Arbeitszeit/Lohnkosten!), der muss vom Chef genehmigt werden, der wird dann an den Einkauf weitergegeben, die verbringen zwei Wochen auf der Webseite des Herstellers, und kaufen dann das falsche Produkt, weil sie kein Wort Englisch verstehen. Ist aber immer noch besser als kostenlose Software. Du musst einen Antrag stellen, der muss vom Chef genehmigt werden, dann gibt's Sicherheitsbedenken ("kostenlose Software ist nichts, kann nichts und ist immer ein Risiko), es gibt ein Risk Assessment, ein Audit, ein Rechtsanwalt wird zur Lizenz-Situation befragt (CC BY-SA 4.0? Rembrandt? Ägypten? Bahnhof?), und irgendwann bekommst Du dann einen Anruf auf Deinem Handy (!), dass man wegen "unklarer Rechtslage" diese frei Software leider nicht einsetzen kann. Und wieso Du nicht an Dein Bürotelefon gehst! "Äh, ich bin schon seit fünf Jahren bei einer anderen Firma..."
Hallo David, echt ein Wahnsinn. Du erklärst einfach mal schnell in 15 Minuten alle wesentlichen Aspekte eines Softwareentwicklungsprozesses, die selbst größere Unternehmen mit viel Budget und Personaleinsatz weder verstanden noch umgesetzt haben! Vielen Dank dafür!
Wahnsinn! Das ist Eins zu Eins genau meine Erfahrung und war bis zum letzten Monat auch genau meine Situation in dem letzten Unternehmen. Es wurde der Chefetage so oft gesagt das es nicht mehr geht und das dringend Änderungen nötig sind, wenn man das Unternehmen weiter führen und aufbauen will. Leider ist absolut nichts passiert und es wurde immer schlimmer, Zeitfristen wurden kürzer, mehr Aufträge mit noch mehr Features und noch mehr Versprechungen gegenüber Kunden die nicht eingehalten werden konnten. Und am Ende von jedem Projekt wurde dann mit dem Finger auf den Developer gezeigt. Das Ende vom Lied war das auch in diesem Unternehmen, mit mir eingeschlossen, die gesamte Abteilung innerhalb von 2 Monaten gekündigt hat. Auf jeden Fall Daumen hoch für das super Video, sehr interessant und gut gemacht.
Und zum Punkt Refactoring kann ich nur sagen: es ist das beste was man machen kann. Egal was das Ziel ist. Manchmal erwische ich mich dabei, wie ich fremden Spagetticode 2h lang refakturiere, nur um dann in 30 min die eigentliche Änderung zu programmieren. Refacturing ist einfach eine Grundlage, die unter anderem auch dazu dient, in der Zukunft überhaupt noch Umsatz mit einer alten Idee/Code/Software machen zu können. Wer das nicht wahrhaben will, wird irgendwann immer an ein dead end kommen. Und was beim Refacturing auch nebenbei abfällt, ist manchmal ein Bugfixing, was dann auch die Qualität und die Stabilität des Code erhöht. Auch das wirkt sich indirekt auf den Umsatz aus. Im übrigen wirken sich normalerweise alle Aufgaben auf den Umsatz aus. Selbst wenn ich grad aufm Klo sitze und über einen Lösungsansatz nachdenke.
Das schreiben von Tests halte ich noch für wichtig, damit die Funktionalität auch langfristig sichergestellt werden kann. Und Tests schreiben kostet halt Zeit, ist aber aus genanntem Grund wichtig.
@@OpenGL4evergeb das nen DAU der zerpflückt dir deine Software in unter 60s.... Würden Entwickler vorher nachdenken wie einfach Abläufe zu halten sind und Oberflächen nicht überfrachtet werden sollten macht schon mal nen guten Anfang...
@@christianknuchel Bei Entwicklern gibt es keinen Fachkräftemangel, nur einen Mangel an billigen Arbeitskräften, die sich ausbeuten lassen. Es ist heftig wie viele Stellenbeschreibungen nach Senior Software-Engineers suchen und dann ein Einstiegsgehalt eines Fachinformatikers nach abgeschlossener Lehre anbieten
Ich bin 32 Jahre in der Business Software Entwicklung tätig mit 70/30 Schwerpunkt programmieren und Business Analyse. Ihre Darstellung bildet 100% meine Berufserfahrung ab. Auch ihre Ursachen Analyse ist absolut korrekt. Umsatzgeilheit ist der Hauptgrund...Unwissenheit ein wenig auch aber dieser Grund ist ein wesentlich geringerer Anteil. Ich habe das Glück in einem kleinen Scrum Team derzeit ganz gute Prozesse und Rollenaufteilungen zu erleben. Es gibt also Hoffnung für Software Entwicklung, auch in Deutschland 😊. Danke für Ihre klaren Worte.
>"Du bist da, um Tickets abzuarbeiten." Zusammem mit einer beziehungslastigen Kommunikation, wenig Offenheit für Neues im Entwicklerteam und mangelnde Entwicklungsprozesse, war das ein schwer erträglicher Zustand für mich. Ich war froh gekündigt zu haben
@@cantkeepitin Bei den Tickets hatte ich sehr oft den Eindruck, dass mehr gehen würde, wenn man den PO aus dem Prozess nimmt. Den den Kunden zufrieden machen ist eigentlich Hauptsache. Grosses Problem war aber die Ansicht von technischen Schulden als non-existent und das kategorisieren von automatischen Tests als unwesentlich. Geschweigedenn die kaum vorhandene Doku bzw. Nutzen der vorhandenen Doku. Ein "Kampf gegen Wind ühlen", @DavidTielke und die Personen, deren Hauptmotiv auf der Arbeit die Beziehungen waren und nicht die Leistung, haben mir als relativ junger Entwickler gezeigt, dass so eine "fachliche Sackgasse" noch nichts für mich ist.
@@cantkeepitin Ich würde hier "Tickets abzuarbeiten" interpretieren als: "fix den Bug und kümmere Dich sonst um nichts!". Das heißt, der Entwickler zählt nichts, und das wiederum heißt, langfristig sollte er gehen.
Diese Aussage, welche Ihnen da an den Kopf geknallt wurde, ist so unglaublich dumm. Tital wertschätzender Umgang. Es ist schwer zu glauben, dass das die Einstellung von Leuten im Unternehmen sein kann.
07:12 schön dargestellt. Die Rollen Stakeholder, Product Owner und Process Owner waren für mich immer etwas schwer zu verstehen, da bei meinen Arbeitgebern sonst immer jeder jede Rolle hatte - außer Support.
David Ich muss mich bei dir mal bedanken. Dein Content bringt mir und sehr wahrscheinlich vielen anderen Selbstständigen/Entwicklern eine menge Mehrwert. Es gibt ja viele Kanäle, wo man programmieren lernen kann aber dein Kanal zeigt nochmal was dazwischen so alles passiert und wie der ganze Prozess laufen sollte. Danke dir. Mach weiter so. :)
Danke für die Zusammenfassung. Das Thema spricht mir praktisch aus der Seele. Leider wird der Umsatz bevorzugt, als das man die Qualität im Fokus hält und einen Gesunden Umsatz pflegt.
Ich war in einem Team mit genau dieser Situation und es wird dich wenig überraschen, wir sind alle gegangen! Das Problem war in diesem Fall nicht die Unwissenheit. Die Entwickler wussten sehr gut welche Positionen hätten besetzt werden müssen. Das wurde vom Management allerdings nicht getan. Eigentlich wurde bei keinem Punkt jemals auf das Entwicklerteam gehört. Refactoring war bitter nötig, aber dazu wurde dem Team nie die Zeit gegeben. Stattdessen wurde ein Feature nach dem anderen rausgehauen. Die höheren Dienstgrade lief und dann immer rum, versprachen das Blaue vom Himmel und erzählten den Kunden, wie toll doch alles ist. Die Entwickler konnten dies nur mit Spott, Hohn und Kopfschütteln kommentieren. Genau wie in deinem Fall wurden auch neue Leute eingestellt allerdings nicht für die technische Betreuung oder Entwicklung. Es war der Vertrieb! Du siehst, deine Geschichte ist nicht so ungewöhnlich und auch das komplette Teams kündigen keine Seltenheit. Ich kann deinem Resümee nur zustimmen: Der Kunde ist selber schuld!
@@DavidTielke Ich kann dir tatsächlich sagen, was mit dem Unternehmen passiert ist. Erst heute habe ich ein Vertriebsmitarbeiter des Unternehmens getroffen der noch dort arbeitet. Es sind jetzt zwei Jahre her, seit wir weg sind. Zu unserer Verwunderung gibt es das Unternehmen immer noch. Der junge Mann, den wir damals als Azubi eingestellt haben, ist jetzt Leiter der Entwicklung. Wie sagt man so schön, unter den Blinden ist der einäugige König.Mag etwas seltsam klingen, aber er kennt das Produkt immerhin noch am längsten. Vieles von dem ursprünglichen Know-how meiner Kollegen und mir ist natürlich auf Nimmerwiedersehen verschwunden.Den Zeit, irgendetwas gründlich zu dokumentieren, hatten wir natürlich auch nicht. Das blieb auch im Rest des Unternehmens nicht unbemerkt. Viele Kunden haben gekündigt und auch langjährige Mitarbeiter aus dem Vertrieb sind auf dem Weg aus der Tür oder schon weg. Das ist alles sehr bedauerlich. Wir hatten ein wirklich gutes Team und haben an das Produkt geglaubt. Leider hat man die nötigen Änderungen, die wir immer wieder gefordert haben, nicht durchgeführt. Stattdessen wurde der Druck von oben immer größer. Natürlich gab es immer Floskeln, wie, wir müssen die Qualität verbessern. Aber solche Projekte wurden dann innerhalb weniger Tagen schon immer wieder abgebrochen, weil ein Kunde mit irgendeinem Wunsch kam, den wir dann ganz dringend umsetzen mussten. Dann kam wieder die Phase, wo die Geschäftsleitung sich wunderte, warum das Programm nicht richtig funktioniert. Im Grunde kam es ganz schnell zu einem regelrechten Exodus. Wenn der erste Entwickler geht, folgen die anderen relativ schnell den keiner will der Letzte sein, der das Licht ausmacht. Es war immer der Zusammenhalt der Kollegen, der uns dort hielt. Nachdem es die nicht mehr gab, hat sich alles sehr schnell in Luft aufgelöst. Es blieben nur die, die den Job dringend brauchten. Das sind dann meistens nicht die besten Entwickler. Persönlich kann ich sagen, dass es mir, nach dem ich das Unternehmen verlassen habe, auch gesundheitlich viel besser geht. Auch Menschen aus meinem Umfeld haben gemerkt, dass ich ein viel fröhlicher und ausgeglichener Mensch bin. Bei meinem neuen Arbeitgeber gibt es tatsächlich jemand, der sich um das well-being der Mitarbeiter kümmert. Das war für mich ein richtiger Kulturschock. Natürlich zum Guten! Ich möchte dir übrigens noch sagen, dass ich deine Videos super finde. Leute, die auf RUclips programmieren und Code zeigen gibt es zu genüge. Über das ganze drum herum im Leben eines Entwicklers erfährt man relativ wenig. Es ist prima, dass du dich diesen Themen annimmst.
Hey, unfassbar - der arme ex-Azubi :D Wie kann man als Unternehmen nur so fahrlässig sein, besonders wenn man ein offensichtlich so gut funktionierendes und harmonisches Team hat. Diesen "Herdentrieb", das wenn einer Kündigt die anderen auch gehen sehe ich leider auch sehr oft, meist in Teams die solche Charakteristiken haben wie dein ehemaliges. Ja, dieser Teil der "Mentalen-Gesundheit" wird leider auch oft nicht beachtet, das höre ich von Entwicklern nach Ihrem Wechsel immer wieder und auch die Erkenntnis das der Gehaltssprung totale Nebensache geworden ist bei sowas. Danke für Dein Lob, freut mich sehr das Dir meine Videos gefallen. Würde auch wieder gern mehr zu "praktischeren" Themen wie Architektur, Qualität und Tests machen, aber diese Themen hier schlagen einfach in meinen Projekten immer wieder durch :) Schön das Du dabei bist! Gruß David
Ich denke dass Problem ist bei kleinen unternehmen und startups eher ser Fall und verbessert sich mit zunehmen Wachstum im Bestfall. Bei Daimler, Bosch etc. ist sowas weniger ein Problem - da ist jede Stelle doppelt oder dreifach besetzt...
@@mxz2024Bei größeren Unternehmen ist es sehr davon abhängig wie fähig das untere Management wie Gruppenleiter oder Teamleiter sind. Abteilungsleiter sind oft schon eher "Politiker" als Experten. Hierdurch kann sich der Gruppenleiter oft aus Problemen heraus reden ohne dass es verifiziert wird. Also entweder: Das (ein einfacher Datenabgleich) war technisch hoch komplex. Oder. Ich kann nichts dafür, mein Untergebener hat es verbockt. In beiden Fällen kann der Untergebene schon vorher gewarnt haben. Womöglich sogar bis zum Abteilungsleiter eskaliert haben. Oder noch weiter. Es führt dann nur dazu dass dann auch der Abteilungsleiter dem Gruppenleiter erst recht deckt weil sonst ja der Abteilungsleiter mit verantwortlich ist. Im Extremfall kann sogar jemand zusätzlich eingestellt werden und noch einige hunderttausend mehr ausgegeben werden um so von dem ursprünglichen Problem abzulenken. Hatte einmal in einer Chipfertigung beobachten können. Wafer wurden bearbeitet und dann unzureichend geschützt über Jahre gelagert. Also ohne Schutzatmosphäre oder ähnliches. Wobei ich finde das beste wäre gewesen diese Chips fertig zu stellen und dann erst zu lagern. Wäre aber wohl zu teuer gewesen. Anscheinend hatte der Fertigungsplaner das Problem bis zur Werksleitung hoch gemeldet. Entsprechend hoch war das Interesse andere Schuldige zu finden. Jedenfalls wurde dann ein Fertigungsplaner gesucht der den Auftrag bekommen sollte alle möglichen alten Anlagen die noch in diversen Prototypen Abteilungen standen in einer (neuen?) Halle wieder zu vereinen und aus diesen inzwischen defekten Wafern komplette Steuergeräte zu produzieren. Ich schätze bei all den Kosten sollte niemand mehr nach der wahren Ursache suchen. Ob das "funktioniert" hat kann ich nicht sagen.
Bei Kaputtgespart denke ich sofort an das Straßen- und Schienennetz Deutschlands. Jahrelang nur das Nötigste und nun soll das von jetzt auf gleich alles gefixt werden und möglichst wrnig kosten. Finde den Fehler.
@fairphoneuser9009 - Verstehe Deinen Vorwurf nicht, was bitte ist daran Clickbait? Es geht um einen Fehler den (immo) 90% der Unternehmen machen und der aus meiner Sicht und meiner Erfahrung der größte in der Softwareentwicklung allgemein ist. D.h. der Titel "Größte Fehler in der Softwareentwicklung den viele machen" liefert zu 100% meine Erkenntnis dazu und die Szene aus dem Vorschaubild wird auch geklärt, weil das Team aufgrund des Fehlers gekündigt hat.
@alexanderbehling4680 - Ja, da sind die Ursachen ja ähnlich. Da wurde genutzt, genutzt und genutzt und wenig in die Nachhaltigkeit des Netzes investiert. Genau so ist es auch bei der Softwareentwicklung. Gruß David
Danke, das ist sehr lehrreich. Ich, kurz vor dem Ruhestand, habe als Bauer einer Messmaschine Software geschrieben und alle Rollen allein ausgeführt. Der Stakeholder war schon da. Nun wird das Produkt mit ca 3 Jahren Verspätung auf neue Füße gestellt (externe Softwarefirma) Dass ich kein BournOut hatte grenzt an ein Wunder.
Wow dann bin ich ja froh dass bei uns viele dieser Schlüsselpositionen besetzt sind. Das Einzige, was uns fehlt, ist der Scrum Master, aber in der Zeit wo wir einen hatten, hat diese Person auch quasi gar nix gemacht. Unsere Kommunikation zwischen Product Owner und Entwicklung läuft auch so gut, weil bereits viel Erfahrung da ist. Und so ein Mitarbeiterzufriedenheits-Mensch gibt es bei uns auch nicht, bzw übernehmen unsere Teamleiter diese Aufgabe. Alles in allem bin ich jetzt durch dieses Video extrem dankbar über meine Firma, bei der sehr viel richtig läuft und ich mich als Entwicklerin sehr wohl fühle 😊
Das Steak bei Stakeholder :'D.. Sehr gutes Video David! Mit der ein oder anderen Aussage hat man sich dann doch "erwischt" gefühlt und man kann dadurch ehernachvollziehen was du meinst :) Lg
Ja, in meiner Truppe ist es bedauerlicherweise ähnlich. Mein Team und ich sind damit beschäftigt, eine veraltete Umgebung mit Entwicklung und Wartung am Laufen zu halten. Die neue Umgebung versucht bereits seit etwa 8 Jahren, die Legacy-Anwendung abzulösen. Als Konsequenz wurden uns finanzielle Mittel gestrichen, obwohl wir gleichzeitig zusätzliche Aufgaben aus dem Fachbereich übernehmen sollen. Angesichts dieser Situation überlege ich ernsthaft, im nächsten Jahr den Arbeitsplatz zu wechseln, falls sich nichts ändert. Unserem Management haben wir die Situation ausführlich geschildert und warten nun darauf, dass neue Mitarbeiter eingestellt werden. Es ist für uns mit nur 3 Mitarbeitern nicht machbar, gleichzeitig neben der Entwicklung auch den Support und das fachliche Wissen aufzubauen. Früher hatten wir 8 Entwickler und 4 Fachkräfte, die uns dabei unterstützt haben.
Hey, ja geht in eine ähnliche Richtung - leider erlebe ich das auch sehr oft, das bei vermeintlichen Neuentwicklungen plötzlich das alte außer Acht gelassen wird und nur noch mit Halbgas weitergefahren wird - und irgendwie soll das dann funktionieren... Gruß David
Ich empfehle dir so schnell wie möglich das Schiff zu verlassen. Es wird nichts ändern. Ich habe dasselbe schon erlebt. Es wurde nur noch schlimmer. Am Ende habe ich es bereut nicht früher gegangen zu sein.
@@DavidTielkeJa, das kenn ich auch aus meinem jetzigen Unternehmen. Neuentwicklung versucht, viel zu unrealistische Zeitpläne aufgestellt, wo jeder Entwickler gesagt hat, das kann nicht funktionieren. Knapp 2 Jahre später wurde das Projekt eingestellt und bei der Legacy Software sind 2 Jahre Bugs aufgelaufen. Kunden unzufrieden und viele Entwickler sind wegen der Einstellung der Neuentwicklung gegangen. Das ist auch der Grund, warum ich auch der Entwicklung weg bin. Unfähiges Management und BWLer, die von nix ne Ahnung haben, und davon ausgehen, in der Entwicklung ist alles nur 'ein Knopf drücken, und fertig!' ...
Ich finde deine Videos und die Themen über die du sprichst unfassbar wertvoll. Und das Ganze kann auch auf andere Bereiche ausgeweitet werden und beschränkt sich oft nicht nur auf klassische Software Entwicklung. Als Designer in einer Agentur, der in vielen Web-Projekten arbeitet erlebe ich leider oft ähnliche Situationen.
Genau diese Prozedur hatte ich damals bei meine ersten Arbeitgeber... Die Entwickler schreien nach Zeit zum refactoring und Testautomatisierung, aber stattdessen war alles dem Marketing/Vertrieb hörig: Neue Features über alles. Ich bin sehr froh, dass mein aktueller AG genau das Gegenteil ist, wir wirklich in einem Team arbeiten, wir Zeit haben für Sachen wie technische Schulden, Test- und Deploymentpipelines und die Geschäftsleitung auch aktiv auf die Empfehlungen und Anforderungen der Entwickler reagiert.
Das Gleiche erlebte ich vor einigen Jahren. Dann kam eine Entwicklerin, die sich das ansah und anbot Scrum einzuführen. Damit wurden die Rollen eingeführt und aus der Gruppe ein Team geformt. Danach war das Thema Kündigung unter den Arbeitnehmern vom Tisch.
Als Solo-"Künstler" decke ich quasi alle Rollen allein ab. Aber da meine Kunden im Großen und Ganzen zufrieden sind und meine "Produkte" sauber laufen (in ca.98% der Fälle), kann ich schon etwas besser sehen, warum ich mich permanent ausgebrannt fühle. Vielleicht sollte ich mal Urlaub machen, indem ich endlich eine gechillte Festanstellung in einem wirklich guten Team anfange. Just dreamin'
Das habe ich nach 12 Jahren "Selbständigkeit" genau so gemacht. Ich bereue es nicht. Bei meinem Arbeitgeber wird inzwischen jede der Rollen bekleidet. Gut, wir schuften an einem Monolithen mit einer bescheidenen Architektur und extremer Komplexität aber man kann nicht alles haben. ...und DevOps ist noch nicht ganz am Start. Ich habe die One-Man-Show erst gegen Freelancing getauscht und dann gemerkt wie gut mir wieder regelmäßiger Kontakt mit Menschen tut. Aber ich war auch lange überzeugt, ich wäre kein guter Team Player und könnte es alles besser alleine bieten. Wie gesagt: Ist geil mit Arbeitskollegen und dass man nicht der einzige ist, der die brennende Hütte gerade löschen kann.
Man könnte fast meinen Du warst bei uns. Aber noch haben nur einzelne Devs gekündigt. Es gibt eine erstaunlich hohe Fluktuation bei neuen Devs (5 Jahre und weniger) am Ende bleiben immer nur die 10+ und entsprechend angestaubt ist auch alles... "Leider" gibt es einen sehr hohen Wiedererkennungswert in Deinem Video, das erschreckt mich in 2023, da gerade Devs sich mittlerweile den Arbeitgeber aussuchen können und nicht mehr anders herum.
Hey, so fangen leider die meisten Kommentare hier an :) Ist leider kein so einfaches Thema, das Zitat in einem anderen Kommentare "Der Fisch stinkt vom Kopf" passt wohl auch bei Euch ganz gut :) Gruß David
Die Frage "Was bei meinem Kunden schief gelaufen [sic] ist" wird leider überhaupt nicht beantwortet. "Nichts ist passiert" und alle Entwickler haben gekündigt ist keine Antwort, sondern nur ein Endergebnis Aber für mich klingt das so, als habe die Beratung im Wesentlichen daran bestanden zu sagen, "macht mal 'ne Gruppe". Ok ein bisschen mehr wars sicherlich, aber all das schöne Gerede und das Commitment von Management und Kunden helfen herzlich wenig, eingefahrene Gewohnheiten zu ändern. Mich erinnert das unvermittelt an die Folge, wo Jamie Oliver einer Amerikanerin, die sich und ihre Familie nur mit Fast-Food ernährt, einen Haufen Gemüse in den Kühlschrank stopft und sich dann ein paar Tage später wundert, dass nichts davon gekocht wurde. Um so etwas zu ändern, muss man jeden Tag dran bleiben und es Vorleben. Sprich: die eigentliche Beratung fängt an, wenn der Berater teil des Teams ist (z.B. als Scrum-Master) und auch von der Geschäftsführung die Befugnisse und Möglichkeiten für Änderungen bekommt. So kann man auch langfristig etwas ändern. Aber das erfordert natürlich auch ein erheblich größeres "Commitment" des Beraters zu einem Kunden.
Leider wahr. Wenn das das Ergebnis einer Beratung ist, bin ich über die großen Zahlen auf der Website nicht überrascht. 350 Projekte - da geht kein Commitment.
Deine stimme ist so angenehm, dass ich das Video angeschaut habe während ich was anderes gemacht habe und im Gedanken abgeschweift bin. Jetzt muss ich das Video von vorne schauen :D
Danke David, genau das ist das Problem. Unwissenheit, Verbohrtheit an alte Strukturen festhalten, Desinteresse. Der Fokus ist Umsatz, die Qualität darf nix kosten, weder Zeit noch Geld, ansonsten, wird wiedermal schnell schnell irgendwas irgendwo, implementiert. Die Softwareentropie nimmt seinen Lauf. Das große Heulen kommt später.
Hallo David, tolles Video. Sehr genau auf den Punkt. Ist echt erschreckend wie oft man genau solche Zustände vorfindet. Spannend ist auch: Bei uns findet gerade quasi die Umwandlung vom Team zu Gruppe statt. Um den Umsatz anzukurbeln wird ein funktionierendes Team (5 Leute) auseinander gerissen und innerhalb kürzester Zeit sind 3 neue Softwareprojekte hinzugekommen, die dann jeweils mit 1,5 bis 2 Leuten aus dem Team besetzt wurden. Damit ist ein erfolgreiches Team in 4 strauchelnde "Gruppen" transformiert worden. Was mir noch aufgefallen ist: Am Anfang sprichst Du von Idee und Vision mit unterschiedlichen Symbolen. Später scheinen die Symbole irgendwie vertauscht. Hatte mich kurz irritiert und ich frage mich ob ich das falsch verstanden habe oder da tatsächlich die Symbole falsch waren. So oder so kommt die Botschaft aber an. Und +1 für die Verwendung von FontAwesome - wenn ich das richtig erkannt hab ;-)
Wenn man täglich inhaltslose Rituale des agilen Arbeitens ausführt kann man sich Vision, Architektur und sogar saubere Implementation sparen. Dann fügt sich auf wunderbare Weise alles ganz von selbst zu einem Superprodukt zusammen. Das ist ja das tolle am Agilen, niemand muss mehr sein Gehrin benutzen, alles ist so einfach. Und ja, meine Hand ist inzwischen in meinem Gesicht festgewachsen.
110% Bestätigung! Mittlerweile ignoriere ich den ganzen agilen-jeden-tag-5-Meetings Scheiß. Bin zwar unten durch, aber wenigstens kann ich in Ruhe arbeiten.
Sorry, aber dann macht ihr agile Softwareentwicklung falsch. Wenn die Meetings ein Selbstzweck sind, dann stimmt was nicht. Im Moment gibt es so eine Gegenbewegung zu agil. Das liegt aber daran, daß die meisten Firmen es schlicht und einfach falsch machen.
@@uran238fr Deswegen meinte er ja inhaltsleere Rituale. Man kann sie auch sinnvoll füllen und in Frequenz und Dauer reduzieren. Aber manche machen das nicht und das führt dann zu Leuten wie hier, die sich resigniert ausklinken. Bisher war ich fast nur in guten agilen Teams. Nur als agil/lean mal in einem nicht-SW-Entwickler Team eingeführt wurde, endete es in unendlichen Labermeetings ohne Sinn. Das war furchtbar aber ich bin schnell weg von da.
Lieber David, vielen Dank für deine Videos! Du sprichst mir bei vielen deiner Themen aus der Seele und ich ertappe mich immer wieder dabei wie ich denke "Jepp, genau so war es in Unternehmen xy" oder "Ja, wäre doch eigentlich mega, wenn auch mal jemand so arbeiten würde.". Insbesondere der Faktor Burnout wird immer wieder komplett übersehen und es wird so lange immer mehr Druck und Verantwortung auf die Entwicklung gelegt, bis die Leute keine Lust mehr haben dauerhaft die Schuldigen zu sein und nie zur Ruhe zu kommen. Man sagt ja "Der Krug geht so lange zum Brunnen bis er bricht."
Wow, vielen Dank für dein Video. Ich bin als Seiten Einsteiger ins DEV Team gekommen. Und so wie du es gezeigt hats habe ich es nie verstanden. Nun weiss ich wie ich meine Arbeit vorbereiten muss das die Kollegen im Team es auch nutzen können. Vielen Dank!!!!🥰😍
Ich sagte letztens zu meinem Chef, dass wir eine Software-Bastelbude sind. Er stimmte zu. Verbessert hat sich absolut nichts. Prozesse werden aufgebläht und Grundsätzliches, wie bspw.weise ein Qualitätsmanagement existieren faktisch nicht. Ich warte seit über zwei Jahren auf eine stable Release, während ich dev betas auf die Kundensysteme aufspielen muss, um den großen GAU zu verhindern. Hier wird sich kaputt gespart. Das ist auch hauptsächlich der Grund, dass ich nicht an das Produkt und auch nicht mehr an die Firma glaube. Daher werde ich mich in absehbarer Zeit lösen. Ach ja, auf die Gesundheit wird geschissen. Man ist ja selbst schuld, wenn man zu viel arbeitet.
Vor 25 Jahren war Objektorientierung das Allheilmittel, dann kamen SW-Komponenten, Model-driven Development, extreme programming, agile Software-Entwicklung, ... ... aber die Knackpunkte sind noch immer die gleichen - kann das wirklich sein ? Faszinierend.
Das ist ein generelles Problem, in allen Unternehmen, dass die Manager keine Ahnung vom Produkt, der Entwicklung und den Details haben und nicht auf diejenigen hören, die es besser wissen. Ein Hauptgrund dafür ist, dass viele Leute in Management-Positionen oder anderen Führungspositionen Narzissten und/oder Psychopathen sind, sich also für die Besten und Größten halten, die niemals Fehler machen können. Wenn irgendwas nicht läuft, dann ist es niemals ihre Schuld, es sind immer die anderen, Empathie kennen sie nicht und können sich somit eben nicht in andere heineinversetzen und verstehen dann gar nicht, warum gekündigt wird.
Hehe, im Kern durchaus was wahres dran, aber die Aussage so zu pauschalisieren halte ich für nicht richtig. Ich kenne viele sehr gute Führungskräfte, aber natürlich auch sehr schlechte. Das kann man in jedem Fall so nicht sagen :) Gruß David
@@fx-bx8cs es gibt auch die "berufenen" Führungskräfte. Denen man das quasi angehängt hat. Unter so einem arbeite ich, ein vielseitig kompetenter Mensch, und ein Vorbild. War aber in Unternehmen, wo deine Aussage auch zutrifft :) Auch die Besitzer von Unternehmen fühlen sich gerne wie Könige in ihrem Reich.
Ja super Thema, danke das Du das ansprichst. Ich finde man sollte nicht vergessen, dass es auch schon ganz vorne - bei der Idee - zu massiven Problemen kommen kann. Es gibt einfach Software, die wird nicht benötigt oder die Idee ist einfach schlichtweg schlecht. Das muss ganz früh schon aussortiert werden, sonst reitet man jahrelang ein totes Pferd. Und ich glaube das passiert schon sehr häufig und keiner redet gerne drüber. Ich finde die Value Proposition also welchen Wert die Software tatsächlich erzeugen soll deshalb ein entscheidendes Kriterium, sozusagen die Single Source of Truth für das gesamte Projekt. Wenn das schon nicht passt und es keiner (Management!) merkt, tja gute Nacht. Ich finde wir haben speziell in DE ein massives Problem was die Qualität von (IT) Management angeht: Einfach absurd schlecht was da an vielen Stellen geschieht!
Hey, ja absolut - den Punkt meinte ich mit Vision. Da wird genau die Value Proposition rausgearbeitet. Aber ich habe auch schon in einigen Projekten erlebt, das dort schon erkannt wurde, das die Idee schlecht ist und trotzdem wurde das Projekt gestartet. Gruß David
Ich denke ein Problem hierbei ist die sogenannte "sunken cost fallacy"; d.h. man möchte ein Projekt oder Produkt. nicht mehr fallen lassen, weil man bereits viel Geld hereingesteckt hat. Das tote Pferd, das man dann reitet, wird dadurch aber nicht lebendig. Besser ein Ende mit Schrecken als Schrecken ohne Ende.
Ich persönlich kenne mich kaum mit Dev Ops und automatisierten Tests aus, daher ist der Trick einfach, das auch wegzulassen und einfach im Wilden Westen zu arbeiten. Ansonsten ist die Aufteilung genau wie du das erklärt hast, kündigen kann ich leider nicht, ich müsste sofort in einen neuen Job starten können und ich werde gefühlt immer weiter abgehängt, weil sich die Lücken langsam auftun :/
Ich glaube das ist ein sehr deutsches Problem, da hier oft die Entscheider davon absolut keine Ahnung haben, weil sie dies selbst nie gemacht haben. War jetzt schon zwei mal in USA und da sieht die Welt ganz anders aus. Bei den Unternehmen wo ich war, wurden Kritierien wie test coverage, code Qualität etc. gemessen, es gab oncall Kalender, Code Reviews etc. Auch wenn das bei weitem nicht perfekt war, hilft es extrem.
Sehr schön zusammengefasst. Ich arbeite für ein Maschinenbauunternehmen, bei dem sich all diese Probleme noch mit zwei weiteren vermischt, erstens nimmt keiner Software ernst (ist eben eine Notwendigkeit, nicht Kerntätigkeit), und zweitens sprechen die Systemingenieure direkt mit den Softwareentwicklern an dem Prozess vorbei, und ich als Product Owner und Architekt (in einigen Projekten) werde dann außen vor gelassen. Die Software sieht dementsprechend aus, ist nicht wartbar, und die Entwicklung dauert länger und wird teurer, als wenn man den Prozess einhalten würde. Aber man hat ja dazwischen immer wieder gespart!
Team, 3 Entwickler, gefühlt hat jeder jede Rolle. Dokumentation pflegen inkl. Handbücher kommt auch noch dazu. Das klappt besser, als es klingt aber ich denke, da wäre viel Potential nach oben.
Hey, ja diesen Aspekt habe ich nachher herausgeschnitten, weil das Video schon viel zu lang war. Oft funktioniert das auch "irgendwie" und wird als normal angenommen und die Unternehmen haben gar keine Ahnung davon, wie viel besser es laufen könnte! Gruß David
Manche Probleme treten auch erst bei größeren Teams auf, da die Kommunikation immer schwieriger wird je mehr Personen und Abteilungen involviert sind. Bei einem kleinen Team kann das noch ganz gut ohne festgeschriebene Prozesse gehen.
Ja kleine Teams unter 7 Leute die gut zusammenarbeiten erledigen viel intuitiv richtig. Wobei man bestimmtes besser auskoppeln sollte. Zum Beispiel Tests und Nutzerhansbücher...
Wir haben einen großen Teil der Positionen formell auch nicht besetzt aber. Einige unserer Mitarbeiter haben isaqb Schulungen gemacht und führen die Architektur Ideen und Planungen im Zuge des Sprint plannings aus. Feel good Manager haben wir auch nicht aber der teamlead kümmert sich um uns, er fragt sogar welches Bier wir am liebsten trinken damit der Kühlschrank nicht immer mit dem selben Zeug gefüllt ist. Bugs haben bei uns immer die oberste prio im Sprit und werden immer sofort abgearbeitet. Mind 20-30% gehen regelmäßig für refactoring drauf (zb bei Updates von Bibliotheken, breaking changes, besseres state management usw.). Insgesamt bin ich aber recht zufrieden und fühle mich wohl an dem Produkt zu arbeiten.
Hey, ob die nun formell besetzt werden oder implizit ist nicht ausschlaggebend, sondern das die Tätigkeit durchgeführt wird. Ob derjenige dazu den Hut auf hat, oder nicht spielt keine Rolle. WENN es aber eine definitive Rolle gibt, kann man alles einfacher kontrollieren und verbessen - das ist der Vorteil. Aber: glückwunsch zu dem Team, alles richtig gemacht :) Gruß David
Das kommt mir auch alles bekannt vor. Ich vermisse Prozessbeschreibungen und Unit-Tests. Stattdesssen gab es "weiter so" mit weniger Leuten. Jetzt bin ich auf dem Weg raus und bin auf Jobsuche.
Vielen Dank für das sehr informative Video. Auch ich muss leider sagen, dass ich nur zu gut mit den angesprochenen Themen vertraut bin, da diese größtenteils auf das Unternehmen zutreffen, für das ich seit acht Jahren als Softwareentwickler arbeite (3 davon die Ausbildung). Aber insbesondere bezogen auf die letzten vier Jahre, wo wir einige große Kunden dazugewinnen konnten. Im Hauptsystem bin ich Architekt (nur für Teilbereiche), Entwickler und DevOps. In einem umfangreichen Zusatzmodul für einen Kunden übernehme ich fast alle Rollen alleine. Und die seit kurzem diagnostizierte Konsequenz davon: schwere Erschöpfung / Depression aufgrund des enormen Stresses. Und das alles gerade mal 5 Jahre nach Abschluss der Ausbildung. Ich hoffe, dass es jetzt besser wird, entweder mit dem aktuellen Arbeitgeber, der von den Konsequenzen echt geschockt war, oder einem anderen. Jedenfalls lasse ich meine Gesundheit da nicht mehr drunter leiden. Bin auch etwas erstaunt darüber, wie viele Kommentare man hier von Personen findet, die mit gleichen / sehr ähnlichen Problemen im Unternehmen zu kämpfen haben.
Sehr schön zusammengefasst. Deswegen ist es so wichtig das im Vorstand immer jemand sitzt der auch Ahnung von der Softwareentwicklung hat. Damit nicht solche Entscheidungen getroffen werden.
Sehr interessanter Einblick. War vor 20, 50, Jahren auch in anderen Branchen. Immer wenn der Boom vorbei ist.Tja nun ist das Problem in der IT-Branche. Ständiges Wachstum, durch ständig Veränderungen und maginale Verbesserung. No limits, no border, no respect. Wenn wundert es wenn aus Mitarbeitern erst Personal wurde und dann human ressourcen (HR). Die Siebträgerkaffeemaschine wichtiger die Kantine, Bonis statt Urlaub und Homeoffice statt Feierabendbier mit Kollegen oder Treffen in der Teeküche auf einen Plausch,
13:39 "Haben wir den Scrum Master nicht ist das Projekt zum Scheitern verurteilt". Also ich hab ganz ehrlich noch nie gesehen, dass der Scrum Master irgendwas sinnvolles leistet, fand ich immer Zeitverschwendung.
Hey, dann hast du bisher nur schlechte Scrum Master gehabt - der sollte normalerweise in jedem Sprint daran arbeiten den Prozess, die Artefakte, die Qualitygates und alles um den Ablauf herum besser zu machen. Die Rolle richtig zu besetzen ist eine der wichtigsten Punkte in der Entwicklung. Was macht Euer Scrum Master die ganze Zeit? Gruß David
Ich kenne auch keine sinnvollen Scrummaster. Zumindest nicht als separate Person. Als Rolle kann das jemand nebenbei machen und dann funktioniert auch die Rolle.
Genau meine Erfahrung. Scrum-Master bringen nur etwas wenn sie auch mitprogrammieren. Sie sollen ja den Prozess an sich verbessern und dazu braucht es gestandene Leute die das Team nach Außen vertreten können. Und keine Ja-Sager-Typen deren Kernkompetenz Jira-Tickets sind.
ich arbeite seit 2010 in der software entwicklung und hab viel erlebt, was hier auch angesprochen wird. interessantwerweise hat sich das stark verbessert seit ich (seit 2021) selbstaendig arbeite und fuer projekte als freelancer dazu geholt werde. Seit dem arbeite ich nur noch in gut funktionierenden teams. Woran das liegt ist spekulation. grundsaetzlich bin ich aber froh, die erfahrung in verschiedenen, nicht gut funktionierenden unternehmen gearbeitet zu haben. Am ende bin ich immer vor dem Bunrout abgesprungen, aber ich habe extrem viel gelernt und vor allem verstehe ich was im ganzen passiert und merke auch bei vorstellungsgespraechen schnell ob das projekt laeuft und ob ich da was bewirken kann.
Ich hab eine Zeit lang in einem kleinen Scrum Team ohne Product Owner gearbeitet. Das hat ein Entwickler nebenbei gemacht bzw. irgendwann hat er quasi nix anderes mehr gemacht. Nach einer Zeit hat er dann gekündigt, weil sein Traumjob nunmal Programmierer war (das Coding ist es doch, was wir lieben^^). Dann wurd zum Glück jemand dafür eingestellt, der sich voll drum kümmert. Es gab vernünftige Tickets etc., das ganze Team war zufriedener und produktiver.
Es ist sowieso so absurd, dass Leute die ihren Job am besten machen aus diesem Grund aus diesem Job raus "befördert" werden. Kann mir durchaus vorstellen, dass er der PO wurde weil er eben der augenscheinlich beste Programmierer war, muss hier genau aber natürlich nicht der Grund sein. Damit verliert man aber den Programmier und bekommt einen semi guten, unzufriedenen PO. Worst of both worlds. Aber ich sehe es immer mehr, dass es genau so in Betrieben läuft und ich kann es beim besten Willen nicht nachvollziehen. Vor allem wird man oft auch noch besser bezahlt obwohl man einen schlechteren Job macht.
@@TheThursty100 Es mag dir absurd erscheinen, aber genau das ist mir auch passiert. Ich habe immer weniger programmiert, was mich sehr frustriert hatte. Bei einem Bewerbungsgespräch, bei dem ich meinen Wunsch zu wechseln begründen sollte, wurde ich dann gefragt, ob ich überhaupt noch regelmäßig entwickle und das noch könnte. Das war für mich ein Alarmsignal!
@@AtomicKnights Es erscheint mir absurd, dass das der Prozess ist. Du bestätigst mir die Absurdität, ich habe ähnliches durchgemacht und andere aus meinem Team ebenso. Das Absurde ist nicht, dass ich mir nicht vorstellen kann, dass es passiert, das Absurde ist DASS es passiert. Es ist absurd von den Führungskräften die die Beförderung bzw. die Aufgaben Verteilung so umlegen. Je besser man ist, desto weniger macht man das worin man gut ist, weil man darin gut ist. Das ist das Absurde und es ist absurd, dass das so weit verbreitet als Gang und gäbe angesehen wird und stattfindet. Das ist der ideale Karriere-Gang.
@@TheThursty100 en.wikipedia.org/wiki/Peter_principle Ich finde (IT) Management (in DE zumindest) einfach grausam schlecht. Die kennen keine best practices, kennen keine moderne SW Entwicklungsprozesse, kennen keine menschlichen Faktoren, haben Digitalisierung nicht verstanden... absurd schlecht. Und an den mythical man month glaube die auch noch alle. Ich höre 5 Tage die Woche soviel Bullshit, das das Wochenende manchmal nicht ausreicht das wieder zu vergessen 😞
Wann erfolgt die Dokumentation? Wann werden die Anforderungen getestet? Wer sagt dem Kunden, dass seine Wünsche nicht erfüllt werden können? Es können zwar alle Wünsche für sich erfüllt werden, aber nicht alle zusammen.
Hey, - Dokumentation: Meist bei der Erarbeitung durch die Struktur (Epics, Features) und ggf. weitere Dinge, die über die "Definition of Ready" geeregelt werden, ist aber abhängig wie Euer Prozess ist - Anforderungen Testen: Einmal im Review und ggf. danach in einem Testing-Prozess - Kunden erklären: Der Product Owner, da er derjenige ist der Bestimmt, was aus fachlicher Sicht in das Projekt kommt Gruß David
Bekommst jetzt doch mal n Abo, nachdem Video letztens mit dem Gehalt nach der Ausbildung war ich echt eher der Meinung "Nicht schon wieder einer, der auch die Sichtweise hat den "Neulingen" eher wenig zu zahlen." Jetzt nach ein paar Videos kann ich einfach nur absolut vieles nachvollziehen, super Content und super Sichtweisen =)
Also was die ganzen Rollen angeht, möchte ich mal kurz aus meiner Erfahrung anregen: In unserem Team hat die Rollenbesetzung dazu geführt, dass einzelne im Team - ich sage mal - mit Scheuklappen herumgelaufen sind, ihre Rolle als die Entscheidene wahr genommen und verteidigt haben und somit viel Zeit mit unnötigen Diskussionen und Blockaden vertan haben. Ich habe das dadurch gelöst, dass Rollen schon mal getauscht und/oder flexibel geändert werden konnten. Das fördert Verständnis, Kommunikation und auch die Stimmung im Team...
Hey, naja, bei all den Rollen muss man sich auf eine gemeinsame Strategie einigen - ohne die wird es schwierig. Das mit dem vertauschen sehe ich kritisch, da man für einige Rollen schon sehr tiefgreifende Expertise benötigt und die hat bei Weitem nicht jeder. Gruß David
@@DavidTielke Ja, für effektives Arbeiten ist ein fröhliches Ringelreihen nicht sehr produktiv, aber für die Erweiterung des Horizontes ist ein eigenverantwortlicher Einblick - quasi als Ersatzspieler - für eine begrenzte Zeit sehr hilfreich. Nebenbei hatte ich die Möglichkeit, die Fähigkeiten der Kollegen in den anderen Fachgebieten besser beurteilen zu können und bei längeren Ausfällen eines Kollegen "besser" zu reagieren. Ich musste ja nicht mehr ins kalte Wasser springen... Ansonsten hast Du vollkommen Recht, David. Gruß Andreas
Ich kein Entwickler, bin aber als Netzwerker für das Netz in einem Konzern zuständig, da gibt es viele Parallelen 😅 Da muss man auch mal aufräumen alles glatt ziehen, die Architektur anpassen und nicht immer nur kurzfristig auf Anforderungen reagieren. Sonst passieren ähnliche Dinge wie hier beschrieben.😊
Jepp administration same thing bei den meisten Firmen is das IT immer noch der Blinddarm der Firma die is halt da und tut nur weh wenns ne blinddarmentzündung gibt.
Stimmt genau! Vor allem bei größeren Kunden erlebe ich genau diesen Pattern immer wieder. Oft fehlt beim Kunden schlicht die Einschicht, dass gewisse Fehler, sind sie einmal gemacht worden, nur sehr schwer zu korrigieren sind. Meistens geht das, wie Du auch sagst, einher mit dem Management by Numbers Anti-Pattern.
Das Video müsste jeder Projektmanager sehen. Ich programmiere Industriemaschinen. Es gibt viele Unterschiede zum klassischen Programmieren, diese Probleme hier sind leider auch größtenteils vertreten. Ein großer Unterschied ist aber, dass die Vision bereits klar ist, weil die Maschinen im CAD dargestellt werden können. Es kommt aber leider oft vor, dass ich dann feststelle, dass die Vision mit der geplanten Hardware nicht umsetzbar ist.
Ich bin zwar kein Softwareentwickler, aber man könnte das bei uns quasi auch schon so im übertragenen Sinne anwenden. Wir sind eigentlich ein Team von 7 Staplerfahrer. 2 fürs Abladen, zwei für Auslagerung und drei für Einlagerung. Jetzt sind zwei/ drei Staplerfahrer dauerhaft krank. Einer im Urlaub. Somit ist es natürlich schwierig die Waren ein- und auszulagern. Zumal wir auch wegen arbeitssicherheit enorm viele Anforderungen erhalten haben, wie wir unsere Arbeit zu machen haben. Das kostet viel Zeit. Man gibt zehntausende von Euros aus für Geländer, Ampelanlagen, Beschilderungen und sonstigen Kram. Dabei wird unser Standort spätestens 2026 eh geschlossen. Also was das Betriebsklima angeht, hat sich das dahingehend sehr verändert. Man ist quasi nur noch in einer Gruppe.
Hey, oh ja, da hast Du recht - sehr gutes Beispiel. Stelle mir nur gerade die Frage, warum meine Videos einem Staplerfahrer angezeigt werden, der kein Softwareentwicker ist... Komisch. Trotzdem schön das Du da bist und Danke für dein passendes Beispiel! Gruß David
habe zwei Arbeitgeberwechsel gebraucht um jetzt in einem Team zu arbeiten bei denen wirklich jede rolle von einer person belegt ist und scrum wirklich gelebt wird. So schnell werden die mich nicht los. Es ist ein segen, sich als entwickler mal wirklich aufs entwickeln konzentrieren zu können
Herzlich Willkommen in meinem Leben! Das sind genau die Kämpfe die ich täglich austragen muss ein Kampf gegen Windmühlen… Danke David wirklich auf den Punkt gebracht… Ich würde sagen ein typisch deutsches Problem was unter anderem dazu führt, dass gestandene große Softwareunternehmen eben nicht aus Deutschland kommen…
Ich habe selbst vor längerer Zeit in so einem Unternehmen gekündigt. Heute bin ich selbst IT-Berater und kenne dieses Chaos, wenn ich bei einem neuen Kunden mit der Arbeit beginne. Welche Rolle oft auch noch gebraucht wird: Cloud Architect und Cloud Engineer (erste, wenn nicht durch die Architektenrolle abgedeckt). Dazu ist es aufgrund des Fachkräftemangels oft erforderlich, Haupt- und Sekundärrollen zu definieren. Oder Instrumente wie Pair-Programming einzusetzen. Ich helfe selbst auch bei Implementierungen mit. M.M.n. ist wegen dem Fachkräftemangel einfach eine Hands On Mentalität und Lernbereitschaft erforderlich.
ich habe das in meinen wirtschaftsinformatik studium rauf & runter lernen müssen & dachte damals, dass das mega der standard ist & alle firmen so arbeiten. Als ich dann in die Berufswelt eingestiegen bin (als Entwickler) habe ich sofort gemerkt, dass nur ein sehr geringer Bruchteil der Software Branche in diesen Themen Ahnung hat. Selbst gestandene C-Level Akteure, wussten oft nicht mal was DevOps oder UI/UX konkret bedeutet.
Ich habe so viele verschiedene Welten kennengelernt von Agentur, über Firma und Selbstständigkeit. Es gab so viele Facepalm-Situationen. BIn so glücklich wie ich jetzt arbeiten kann. Deine Interpretation und dein Erlebnis ist so typisch, aber es gibt so viele Versionen davon. Danke dir für deine Zusammenfassung, ist echt super.
Den Schluss der Geschichte fand ich merkwürdig. Gab es denn niemanden, der diese Transformation begleitet und aktiv angestoßen hat? Ein reines Commitment reicht wahrscheinlich nicht, wenn garkeine Expertise in der Firma besteht wie ein besserer Zustand in der Praxis aussehen würde. Oder gab es diese Begleitung aber jeder änderungsversuch ist praktisch fehlgeschlagen und man gab auf? Ich hab gute Erfahrung damit gemacht solche Änderungen von unten her einzuführen. Also die entwickler raufen sich zusammen und gestalten den prozess selbst und helfen gegenseitig aus bis sich neue Arbeitsweisen ergeben. Wenn man nur drauf wartet dass Management was umstrukturiert wirds zäh.
Stecke jetzt auch in so einem Projekt. Alle haben gekündigt, es gab keine Übergabe und ich soll es retten. Gelernt wurde aus den Fehlern aber nichts und es wird jetzt bei mir Druck gemacht. Da kommt man schon ins grübeln...
Ich bin Team Team. Da bin ich ja froh anscheinend zu den 10% der Firmen zu gehören, bei denen das einigermaßen läuft. Die Rollen sind alle klar und verteilt, wir haben people Manager, Tester (gut, könnten mehr sein, aber es ist wirklich nicht so leicht, Tester zu finden), POs, Architekten. Wenn ein refactoring sinnvoll erscheint, wird’s gemacht. … würde auch nicht sagen, dass es besonders stressig zugeht. … support dürfte gerne bisschen weniger sein, aber da wird auch gerade eine team für aufgebaut.
Hey, dann wirst Du mir bestimmt zustimmen, wenn ich sage das die Arbeitsqualität in solchen Team um Lichtjahre besser ist, als in solchen problematischen Teams/Gruppen wie in dem Video geschildert... :D Gruß David
@@DavidTielke mir fehlt ehrlich gesagt der Vergleich, da das abgesehen von meiner Zeit als WiMi an der Uni mein erster Arbeitgeber ist. Aber ich kann mir gut vorstellen, dass es ohne den effort kaum möglich ist, nachhaltig Software zu entwickeln. Angesichts dessen, dass in fast jeder Stellenausschreibung irgendwas von agil usw. steht (und Kern dessen ist ja u.a. die Rollenverteilung), wundert es mich aber schon, dass viele Firmen das dann anscheinend gar nicht machen 😅
Das klappt nur mit Entwicklern, die sich selbst zurücknehmen können. In der Lage zu sein, etwas zu tun, aber es zu lassen, ist äußerst schwierig. Gerade wenn die Firma angeblich "Engagement " erwartet.
Ich habe das Glück gehabt, nie wirklich darunter gelitten zu haben. Selbst in dem ersten Team gab es genügend agile Struktur und Prozessverbesserung. Heute arbeite ich in einem Geflecht aus Tribes, Squads, etc. mit etwa 100 anderen Entwicklern und wirklich jede erdenkliche Rolle ist besetzt. Fühlt sich sehr gut an 🎉
Ich bin an meiner ehemaligen Uni, wo ich meinen Bachelor gemacht hab, in ein Softwareentwicklungs Team gerutscht. Es gibt zwei Personen/Entwickler, die den Quellcode geschrieben haben und alles kennen. Wenn die mal nicht mehr da sind, müssen sich Entwickler hinsetzen und erst mal das ganze Projekt oder große Bestandteile davon verstehen. Die beiden machen aktuell Implementierung, Testen und das Bereitstellen. Da es aber ne Uni ist und wir keinen Umsatz machen müssen, ist das irgendwie okay. Ich hab als studentische Hilfskraft 100% Home Office und kann mir meine Zeit einteilen, wie ich will. Ich muss nur auf meine 36 Stunden im Monat kommen. Seit neuestem machen wir jetzt Scrum mit nem 1 monatigen Sprint, was auch ganz gut funktioniert. Wir sind tatsächlich auch nur zu viert aktuell, also eine sehr überschaubare Gruppe. Alles in allem schon ein bisschen chaotisch aber es ist noch in Ordnung, grade eben weil wir keinen finanziellen Druck haben, oder zumindest aktuell keinen spürbaren. Wenn wir wirtschaftlich orientiert wären, will ich mir nicht vorstellen, wie anstrengend der Entwicklungsprozess wäre 😅
Hey, am Ende kannst Du auch in solchen Projekten, welche am Umsatz gar nicht beteiligt sind, entscheidende Fehler machen. Der Kernpunkt ist ja, das Eure Software für irgendetwas wichtiges eingesetzt wird. Sei es um Prozesse zu unterstützen, Forschungsgelder einzustreichen oder was auch immer. Wenn ihr jetzt so eine Situation habt, gibt es da halt einige Risiken die man in dem Kontext auf dem Plan haben muss. Gruß David
@@DavidTielke Ja, teilweise wird das auch aktuell angegangen. Die Einführung von Scrum sollte uns organisierter und produktiver machen. Dafür wurden auch zwei Entwickler die letzten Monate abgestellt, die sich darüber Gedanken machen sollten, wie man Scrum umsetzt. Dementsprechend wenig haben die in der Zeit entwickelt. Auch das Dokumentieren soll verbessert werden, damit sich neue Entwickler schneller einlesen können. Hauptproblem ist halt, dass wir keine neuen Entwickler bekommen, damit die beiden Entwickler, die alles kennen, nach und nach an Verantwortung verlieren. Da kann man nur am Institut werben, aber wenn niemand will, will niemand 😁
Kleiner Tipp für die Zukunft: Nicht in Rollen denken, sondern in Skills. Jedes Team sollte die passenden Skills haben, um die vielfältigen fachlichen als auch technischen Anforderungen abzudecken um hierfür auch gemeinschaftlich die Verantwortung übernehmen zu können - ganz unabhängig von irgendwelchen Rollen. Das versteht auch das Management und erleichtert zudem noch die Suche nach passender Unterstützung ;-)
Hey, ja das ist dieser agile Wunschgedanke von selbstorganisierenden Team. Das mag in manchen "Skills" (wie Du sie nennst) funktionieren, in vielen aber definitiv nicht. Architektur, Anforderungen, People sind die ersten die mir einfallen, das kann ein Team definitiv nicht gemeinschaftlich verantworten. Oft fallen Fehler hierbei nur sehr spät auf, in der Architektur beispielsweise und deshalb scheint es erstmal zu funktionieren. Gruß David
@@DavidTielke Gerade die Architektur ist keine Blackbox die paralell zur funktionalen Umsetzung geschieht, sondern ist fest in den Entwicklungszyklus integriert. Moderne Technologien ermöglichen mit vertretbarem Aufwand Änderungen am Fundament, so dass auch hier Fehler früh auffallen und ausgebessert werden können. Keine Entwicklung sollte einem Selbstzweck dienen, sondern Nutzen stiften (egal ob fachlich oder technisch). Nur Wissen löst die genannten Probleme, wenn dieses noch fest in einem Team verankert ist, kann auch die Verantwortung hierfür übernommen werden. Nicht nur theoretisch, sondern auch ganz praktisch :-)
Als ich dann etwas dagegen gemacht hatte und dabei sehr viel Fortschritt gezeigt hatte, wurde mir eine Zustimmung auf eine passiv aggressive Art verweigert aber ich durfte einfach so weitermachen. Hab einen passenden Moment genutzt um innerhalb von Tagen zu verschwinden.
Nach über 5 Jahren Softwareentwicklung in der Automobilindustrie kann ich nur absolut bestätigen was du sagst. Bin heilfroh, den Absprung geschafft zu haben. Hätte nicht gedacht, dass man einen Laden so schlecht managen kann.
Ich mache momentan die Umschulung zum Fachinformatiker in der Anwendungsentwicklung und bin gerade im Praktikum und darf mir mein Projekt aus dem nichts herbeizaubern. Ich soll/muss alle Rollen selbst übernehmen außer die Abnahme durch meinen Vorgesetzten. In der Firma würden die Projekte auch so laufen, wenn man später fest angestellt ist. Ich hatte ja eigentlich die Hoffnung, dass es in anderen Firmen besser läuft. 😅😂
ChatGPT (version GPT-4) ist dein Freund. Nicht zum blind erstellen, sondern als Betreuungsersatz. Müsstest dich aber 1-2 Tage mit Prompt Engineering und den Limitierungen auseinandersetzen. Lohnt sich aber. Viel Glück und Erfolg!
Ich habe 3 Jahre in der Entwicklung einer SaaS gearbeitet, alles was du beschrieben hast wurde so auch missachtet. Das Business Modell hat von vornherein nicht gestimmt. Es gab kein PO, keine richtige Vision, keine Scrum Master... Ect. Im Endeffekt würde das Produkt aufgrund geringer Nachfrage eingestampft. 3 Jahren Nerven und Überstunden für nichts. Habe dann natürlich gekündigt. Wie alle anderen auch. Problem ist das viele Unternehmer denken die können das alles wissen und einschätzen, leider fehl am Platz.
Was waren das bitte für 9 Software-Entwickler? Alles Juniors? Denn dass nicht einer schon mal zu seinem Vorgesetzten gegangen ist um zu erklären, dass es nun mal einen technischen Lead braucht, der alles zusammenhält und koordiniert, das finde ich erstaunlich. In meiner letzten Firma war ich Lead-Developer, aber hatte wieder das Problem, dass mir der Gruppenleiter, also mein Vorgesetzter immer in Dinge reinredete, die ihn nichts angingen. Ich habe das Know-How, aber wurde seitens des Vorgesetzen "bekämpft", aber nicht aus Bosheit, sondern aus purem Aktivismus. Denn sonst hätte man vielleicht bemerkt, dass bestimmte Positionen im Unternehmen keinen Mehrwert für das Unternehmen haben und gestrichen hätten werden könnten.
Klingt wie ein typisches Ergebnis einer agilen Transformation oder Scrum-Implementierung. Es gibt aber einen gemeinsamen Nenner: zu wenige Leute mit technischem Hintergrund im Management. Sag, was du willst, aber alle wirklich erfolgreichen Unternehmen mit niedriger Fluktuation bei den Entwicklern haben Leute im oberen Management, die selbst Entwickler waren und dann in kaufmännische Rollen gewechselt sind. Jedes Mal, wenn ich in einem Unternehmen gearbeitet habe, das auf kurzfristigen Vertrieb und Marketing fokussiert war, entwickelte sich die Situation genau so, wie du es beschrieben hast. Es ist auch verrückt, dass Unternehmen mit Kernsoftwareprodukten oft nur etwa 20 % der Mitarbeitenden im technischen Bereich haben, während der Rest in mittleren Management-, Marketing- oder Vertriebsrollen arbeitet - und Entwickler wie code monkeys behandelt werden.
Interessant, ich habe von 2013 bis 2017 in einer Firma gearbeitet, die ähnliche Herausforderungen erlebt hat. Leider hatte diese Firma Schwierigkeiten, das richtige Personal im Bereich Programmierung zu finden, was zu weiteren Problemen führte. Besonders im Jahr 2016 kam es zu Spannungen zwischen den Abteilungen Marketing/Vertrieb und Entwicklung. Rückblickend habe ich ein besseres Verständnis dafür entwickelt, warum diese Situationen entstanden sind. Kurz gesagt, es ist wichtig, dass neue Teammitglieder, unabhängig von ihrem Hintergrund oder persönlichen Stil, gut in das bestehende Teamgefüge passen. Es ist entscheidend, dass die Unternehmensleitung darauf achtet, um solche Konflikte zu vermeiden
Die Übersicht bei 7:15 finde ich enorm hilfreich um einfach mal zu verstehen, für was die ganzen Bezeichnungen in Stellenbeschreibungen für Softwareentwickler steht. Bei mir stand da bisher immer ein riesiges Fragezeichen, weil ich es gar nicht differenzieren konnte. Als Normalsterblicher, der sonst noch nicht wirklich mit dieser Materie in Berührung gekommen ist, bin ich da wohl auch nicht alleine. :D
Wer seine Firma auf kurzfristigen Umsatz ausrichtet, bekommt Umsatz eben auch kurzfristig. Aber nicht länger. Entweder stellt er sein Unternehmenskonzept um, oder muss zum Seriengründer werden und rechtzeitig vor dem Desaster verkaufen.
Uiuiui, das ist das worst case scenario. Die Verantwortlichen haben sich nicht damit beschäftigt wie man gesund wächst. Im Grunde haben die ne Bugwelle von Versäumnissen im Produkt, in der Organisation und in den Prozessen aufgebaut. Die Entwickler wurden verheizt und allen Problemen ohne Struktur komplett ausgesetzt. Es ist schwer zu beurteilen ob jeder da gekündigt hätte. Für mich hat das Kreuz immer 2 Balken, vereinfacht gesagt: Manager, die die Strukturfehler nicht sehen (wollen, können), und Entwickler, die zu spät lernen wie man nein sagt, und damit notwendige Diskussionen anstossen. Unternehmenskultur spielt auch eine riesige Rolle. Super Video, ich teile alle dargestellten Problemansichten. Das passiert nicht nur in Startups. Auch alte Unternehmen tappen in die Falle, dort manifestiert sich das Problem oft schleichender, daher auch eher abwendbar.
Ich bin an einem Communityprojekt dran und tatsächlich ist der Fall sehr ähnlich was bei deinem Kunden der Fall ist. Man hat zwar Gedanken über die Architektur gemacht, aber es fehlt an Vision und auch die Rollenverteilung. Es ist zum Glück überwiegend nur Javascript. Aber ich erkenne keine konkret verwendete Version. Wahrscheinlich ist in der Entwicklungsteam/-gruppe nicht bekannt, dass bei JS ECMA 4, 5, 6 usw. gibt. Zudem trägt eine Person zu viele Rollen, sodass es dazu führt, dass einige Aufgaben nicht richtig bewältigt werden können.
Hey, das ist bei Communityprojekten nicht anders, da gelten dieselben Gesetze. Aber hier ist die Orga meist eher dezentral und deshalb ist das Thematisieren und Entscheiden hier meist schwieriger. Gruß David
Gut! Läßt sich eins zu eins auf die Situation im deutschen Schulsystem übertragen. Jeder soll alles machen, keiner macht irgend etwas gut. Rollen/Verantwortlichkeiten werden erst gar nicht definiert. Prozesse sind zufällig. Qualitätsmanagement ist als Begriff unbekannt.
Dieses ganze Land ist auf Verwaltung nach militärischen Strukturen aufgebaut. Der ganze Dreck mit agilen Systemen und Co ist eine Utopie die an der Wirklichkeit vorbei geht und nur auf Zeit funktioniert. Wir sehen es halt überall, von Unternehmen bis zu staatlichen Stellen... Unflexible Dummheit und auch der größte Depp über dir lässt das Kartenhaus kippen... Genau das passiert nicht nur in diesem Land und nur an Orten, wo man neue Wege geht, weils geknallt hat, verändert sich auch was... Die Herrschaft der Doofen, die der Vernunft im Weg stehen, werden wir nicht mehr beenden.
Ich bin nicht in der Softwareentwicklung tätig, aber das Thema passt schon sehr gut auf meinen Bereich. Sowohl das Thema der korrekten Rollenverteilung (inkl. Auswahl der dafür fähigen Mitarbeitenden) als auch die klar Regelung von Verantwortlichkeiten, ist oftmals vom Unternehmen nicht sauber und klar Umgesetz. Das führt zu Problemen (es sind ab einem gewissen Punkt keine "Herausforderungen" mehr). Insbesondere, wenn nur auf die Kosten geblickt wird, Personal an allen Enden reduziert wird und jeder dauerhaft über der Belastungsgrenze arbeitet. Dann noch unklare Aufgaben, Rollen und fehlende Entscheidungskompetenzen bei (Line) Managern und nach einer gewissen Zeit stürzt das Kartenhaus zusammen.
Bis auf den Feel-Good Manager haben wir alle Positionen besetzt und es funktioniert bei uns recht gut. Die Unzufriedenheit bei den Kollegen stellt sich ein, weil die Abteilung sehr viel verdient und bei den Kollegen zu wenig ankommt.
Es stimmt zu 100%. Wenn Rollen dann auch nicht nach Fachkenntnisse und Fähigkeiten sondern nach dem nach der Nase reden Prinzip besetzt werden, geht alles zu 100% schief.
Wir haben keinen Architekt, Process Owner, Feelgood Manager, Support macht auch jeder und nur ein halben DevOps. Ist genau so gestartet wie hier beschrieben - mit einem Entwickler (frisch von der Uni noch keine wirklich Ahnung was er tut). Dadurch sind viele der wichtigsten Komponenten kompletter murks, wurden aber so extrem oft schon benutzt, das die App zu abhängig von diesen Komponenten ist als das man sie einfach refactoren könnte. Das beste ist: Der Wunsch des Teams ist sich MEHR anstatt weniger in eine Gruppe weiterzuentwickeln (also jeder soll in ein paar Bereichen tätig sein). Das ganze läuft noch weil der Entwickler, der das ganze Projekt gestartet hat noch im Team ist und 70% der gesamten Tickets abwickelt. Falls der mal geht kann die Firma die App vergessen.
was mich brennend interessieren würde: wenn ein entwickler jahrelang mit komplett veralteter technologie und komplett veralteten prozessen gearbeitet hat -> wie schwer gestaltet sich der jobwechsel? bedenkt man die schnelllebigkeit unserer branche, würde ich aus dem bauch heraus sagen, dass man unheimlich an marktwert verliert.
Bei uns gibt es keine QA. Das sollen die Entwickler grundsätzlich übernehmen, da gute Entwickler keine QA benötigen. Das ist tatsächlich genau das, was uns gesagt wird, täglich.
Nicht meine Branche aber sehr interessant. Das sehr stark auf irgendwelche Kennzahlen geachtet wird ohne das große und ganze im Blick zu haben gibt's denke ich Grundsätzlich überall 😅
Ersteinmal sind wir kein Softwareunternehmen, allerdings entwickeln sehr viele Mitarbeiter. Der Betrieb ist ein streng hierarchisches System, mit Manager die von Softwareentwicklung keine Ahnung haben. Irgendwann hat mal das Management beschlossen agil zu arbeiten, aber die agilen Werte werden nicht gelebt. Ein typischer Fehler ist, dass man Entwickler verbietet selbst zu testen, dafür gibt es ja ein Testteam. Die Entwickler wollen und müssen schnell Erfolge zeigen, deshalb fangen diese mit der Entwicklung an - obwohl es noch viele Anforderungslücken gibt. Das Problem ist häufig auch der Kunde. Da fehlt häufig die Bereitschaft aktiv am Entwicklungsprozess teilzunehmen. Die Kunden haben Angst davor, selbst Entscheidungen zu treffen und zögern extrem bei konkreten Fragen. Die ProductOwner raten deshalb mehr als dass sie etwas erfragen, und die entwickelten Teile sind praktisch nie zu Ende, weil man häufig Monate nach Beendigung von Softwareteilen bestehende Anforderungen anders interpretiert. Offiziell arbeiten wir agil aber in Wirklichkeit ist es das Gegenteil.
Es ist aber, wenn ich das richtig zwischen den Zeilen gelesen habe, eher für "kleinere" Unternehmen gemeint. Also das Konstrukt Team vs. Gruppe. Es gibt ja, gerade bei größeren Unternehmen, auch oft die Konstellation, dass es mehrere Teams gibt, die jeweils ein Produkt oder mehrere Produkte betreuen, oder auch sogar mehrere Teams für ein Produkt. Danke für das Video und die gute Herleitung!
Oft ist es zu viel unqualifiziertes Personal mit wenig Berufs- und/oder Technologieerfahrung. Diese schaffen es nicht Prozesse im Team zu etablieren, geschweige denn nach oben zu kommunizieren was eigentlich benötigt wird und wo der Fokus liegen sollte. Die Probleme sind gar nicht mal den Leuten selbst anzulasten. Vielmehr der Einstellung des Unternehmens gegenüber der Anstellung geeigneten Personals. Warum auch einen erfahrenen High Performer mit Blick auf das Wesentliche, leider aber "unrealistischen Gehaltsvorstellungen" einstellen, wenn es für das gleiche Geld zwei Mitarbeiter gibt, die die Arbeit rechnerisch doppelt so schnell erledigen. Mindestens genauso wichtig ist wie bereits im Video gut aufgezeigt die Übertragung von Rollen und Verantwortlichkeiten. Letzteres wird - oft genug erlebt - aufgrund von falsch verstandener Fehlerkultur im Unternehmen nicht gelebt. Das heißt Fehler werden nicht aufgearbeitet, niemand ist verantwortlich und es gibt kein wertvolles Lesson Learned.
Ein Arbeit für die Consulting Firmen ;) Change Management betreiben, Anforderung von der Kunde mit der Umsetzbaren vergleiche und reduzieren, und richtige Ergebnis nach Scrum pro Sprint liefern, klar in so einem komplexen System ohne Test is schwierig alle Anforderungen zu erfüllen, aber zumindest man hätte darauf eingegangen und verlangt und das Management hätte es verstanden, zwar die wären nicht zufrieden , das es so viel Arbeit , aber zumindest es wäre die richtige Entscheidung.
Ich denke nicht dass das oberste der Softwareentwicklung ist, viel Umsatz zu generieren. Das oberste Ziel sollte und ist es Bedarf zu befriedigen. So kann man eigentlich seine Ziele nicht aus den Augen verlieren. Umsatz fällt dann nebenbei ab.
Hey, meine Reden, leider sitzen die Prioritäten oft anders verteilt. ABER: wie angesprochen ist es nicht immer der Umsatz, sondern oft auch fehlendes Wissen. Das ist leider genau so ein kritisches Thema wie die falschen Prioritäten. Gruß David
Hallo David, meine Erfahrung bei großen Unternehmen mit allen besetzten Rollen ist auch nicht anders. Es liegt alleine nicht die Fehlbesetzung. Der Punkt ist nicht die Fehlbesetzung, sondern die Inkompetenz der Personen in SW-Entwicklung und -Architektur. Ich habe gesehen, wie unerfahrener Produkt Owner ein Team von Softwareentwicklung führte. Ich habe gesehen, wie ein Scrum-Master rumlabert und hauptsache die ganze Meetingreihe moderiert, ohne die Fortschritte nach jedem Sprint zu sachlich erkennen. Genauso, durfte ich auch die unfähigen SW-Entwicklern erleben, die nur beschweren und leeren Versprechen gibt. Das Problem aktuell ist, die Inkompetenz und das Besserwissen ohne die wirkliche Erfolgerfahrung.
Wir entwickeln derzeit eine neue Anwendung um eine alte Access basierte Anwendung zu ersetzen. Auf Basis von React und Typescript, also eine Webanwendung mit allem drum und dran. Diese soll modern und Barrierefrei sein. Es gibt verschiedene Formulare sowie komplexe Fachlogik um Daten zu erfassen und zu bearbeiten. Der Clou, ein Kollege macht mit 20h Anforderungsmanagement und ich bin der einzige Entwickler mit 32h die Woche. Was soll schon schiefgehen.
Hallo David, das ist ein sehr gutes Video. Inhaltlich stimme ich dem voll und ganz zu. Der Kunde hat sich offenbar an euch gewandt, als es schon bereits zu spät war. Nachdem du weg warst, wird er gesagt haben, dass er den Laden eh gleich dicht machen kann, wenn er in den nächsten 8 Jahren 80% der Zeit für Refactorings aufwenden muss, da er das nicht finanzieren kann. Daraufhin haben die Entwickler gekündigt und er kann den Laden nun ebenfalls dicht machen.😄 Ich denke in dem beschriebenen Fall gibt es neben mangelnden Wissen wie so oft noch ein betriebswirtschaftliches Problem. Es wurden Kosten für die im Video genannten nicht besetzten Stellen und auch die Wartungskosten der Software nicht mit einkalkuliert. Für ein Feature, das implementiert wird, kann man gut noch mal 20% an jährlich anfallenden Kosten für Updates, Refactorings, Bugfixing, Betrieb, Support, etc. draufrechnen. Wenn man z.B. ein Feature implementiert, das 5 Personentage kostet, muss man 1 Personentag jährlich aufwenden, um die Software am Leben zu halten. Und da ist die Frage, wie man diese Kosten an den Kunden weitergibt. (Abomodell, Kunde zahlt für Updates, Servicepauschalen, etc.) Man kann in einer Softwarefirma diese Wartungskosten auch relativ lange (z.B. 15 Jahre) nach dem Schneeballprinzip querfinanzieren, in dem man auf einen wachsenden Markt setzt oder die Wartungskosten mit neuen Features finanziert, dessen Implementierung man sich individuell vom Kunden bezahlen lässt. Die Folge ist halt, dass sich die Schlinge über die Jahre immer enger zuzieht und die im Video genannten Probleme immer größer werden. In Firmenbilanzen werden die technischen Schulden sowieso nicht ausgewiesen, genauso wenig stellen die dort aufgeführten immateriellen Vermögenswerte den Aufwand dar, um die Software neu zu entwickeln. Von daher kann sich ein Management jahrelang von vermeintlich guten Umsatzzahlen blenden lassen, obwohl die Firma eigentlich schon längst formal pleite ist, nur eben noch nicht im rechtlichen Sinne. Die eigentlichen Fehler wurden dann vom Management schon viel früher gemacht. Wenn man eine Produktvision hat, sollte man sich auch fragen, ob man das Softwareprodukt an einen ausreichend großen Kundenkreis verkaufen kann und ob dabei genügend hohe Margen erzielt werden können, um es langfristig zu finanzieren. Der Kunde kauft ja letztendlich das Produkt, da er Geld damit sparen will und sich einen Vorteil verspricht. (Wertschöpfung der Software) Steht das investierte Geld, im Vergleich zum gesparten Geld in einem Missverhältnis, wird er das Produkt nicht kaufen. Es gibt auch genügend Geschäftsmodelle, die sich auf dem Markt einfach nicht rentieren.
VB6 , sind die noch auf 32bit windows unterwegs? (Alle hacker dieser welt kichern) Prozesse sind sehr wichtig und wird bei uns auch gemacht. QA fehlt leider, und Produkt fehlt etwas Technik-Kompetenz. Ansonsten hab ich schon öfter mal altes Produkte weggeworfen und neu implementiert (von der Datenbank aufwärts). Erstaunlich was man dabei alles für alten Müll findet, den man garnicht braucht, nur weil ein Coder sich ein neues Buch über Software-Architektur gekauft hatte (Hast du einen Hammer sieht alles wie ein Nagel aus)
Wir haben exakt die beschriebene Gruppensituation. Es geht um ein Softarepaket dessen älteste Komponenten bald 35 Jahre alt sind. Entwickelt wurde in 4 Sprachen und diversen Versionen. Habe selbst mehrere Burnout-Phasen hinter mir, wußte nur lange nicht, dass es Burnout ist. Bin in vielen Bereichen der Einzge, der überhaupt über die nötigen Kenntnisse verfügt. Es gibt keine Strukturen und entwickelt wird nach jeweiligem Gusto. Und auch bei uns wurde zuletzt eher mehr in Marketing investiert. Kündigen ist für mich allerdings nicht so einfach. Strukturschwache Region, alleinerziehend und in der Mobilität eingeschränkt. Das wird natürlich weidlich ausgenutzt.
Dann schaff dir nach und nach eine neue Perspektive um für Firmen im Homeoffice zu arbeiten. Es gibt genug Angebote und du musst ja nicht sofort kündigen. Ich hasse Burn out und hatte das auch schon oft genug. Dachte damals ich bin einfach nur depressiv, aber neee...
Erstmal danke für das tolle Video. Mir fiel aber die Kinnlade runter bei der Aussicht auf 8 Jahre refactoring mit 80% Auslastung darauf. Da dreht sich doch bei jedem Geschäftsmann der Magen um. Ganz schön bitterer Apfel
Kleine Anekdote: als ich in dem Unternehmen, in dem ich derzeit arbeite, angefangen habe, gab es Schulungen. Unter anderem die Schulung "Verschwendung". Da bekam man alle möglichen Dinge erklärt, was denn unnötige Tätigkeiten seien, die die Wertschöpfung mindern.
Und wir wurden gefragt, welche Tätigkeit wir durchführen und ich meine Tätigkeit erklärt habe, bekam ich zu hören, dass ich 100% Verschwendung sei. Das motiviert doch für die nächsten Jahre
Dann stellt sich die Frage, warum du überhaupt angestellt wurdest. Irgendwer muss ja deinen Wert von X € plus Sozialabgaben für lohnenswert für das Unternehmen gesehen haben. ;-)
Eine große Gefahr für Unternehmen ist auch, wenn alle an einem Strang ziehen, aber jeder in eine andere Richtung. Öfters sind Abteilungen ohne Abteilungsleiter deutlich effektiver als Abteilungen mit einem Manager, der nur Sauerstoff verbraucht.
Und hatte man recht, dass deine Tätigkeit unnütz war. Bei uns sind auch zig Leute beschäftigt, welche „wenn morgen nicht mehr da“ keiner bemerken würde.
@@Askunics Aus Sicht gewisser Leute ist es vermutlich Verschwendung, aber ich denke, meine Kollegen denken da anders
@@MarkusBurrer Es gibt schon die unnützen Bullshitjobs, wie Gendergagabeauftragter oder so. Leider hast du nicht geschrieben was du gemacht hast.
@christianhabermann6527 Nichts kann man für $10 kaufen. Du musst einen Antrag stellen (das kostet schon mehr an Arbeitszeit/Lohnkosten!), der muss vom Chef genehmigt werden, der wird dann an den Einkauf weitergegeben, die verbringen zwei Wochen auf der Webseite des Herstellers, und kaufen dann das falsche Produkt, weil sie kein Wort Englisch verstehen.
Ist aber immer noch besser als kostenlose Software. Du musst einen Antrag stellen, der muss vom Chef genehmigt werden, dann gibt's Sicherheitsbedenken ("kostenlose Software ist nichts, kann nichts und ist immer ein Risiko), es gibt ein Risk Assessment, ein Audit, ein Rechtsanwalt wird zur Lizenz-Situation befragt (CC BY-SA 4.0? Rembrandt? Ägypten? Bahnhof?), und irgendwann bekommst Du dann einen Anruf auf Deinem Handy (!), dass man wegen "unklarer Rechtslage" diese frei Software leider nicht einsetzen kann. Und wieso Du nicht an Dein Bürotelefon gehst!
"Äh, ich bin schon seit fünf Jahren bei einer anderen Firma..."
Hallo David, echt ein Wahnsinn. Du erklärst einfach mal schnell in 15 Minuten alle wesentlichen Aspekte eines Softwareentwicklungsprozesses, die selbst größere Unternehmen mit viel Budget und Personaleinsatz weder verstanden noch umgesetzt haben! Vielen Dank dafür!
Wahnsinn! Das ist Eins zu Eins genau meine Erfahrung und war bis zum letzten Monat auch genau meine Situation in dem letzten Unternehmen.
Es wurde der Chefetage so oft gesagt das es nicht mehr geht und das dringend Änderungen nötig sind, wenn man das Unternehmen weiter führen und aufbauen will.
Leider ist absolut nichts passiert und es wurde immer schlimmer, Zeitfristen wurden kürzer, mehr Aufträge mit noch mehr Features und noch mehr Versprechungen gegenüber Kunden die nicht eingehalten werden konnten. Und am Ende von jedem Projekt wurde dann mit dem Finger auf den Developer gezeigt.
Das Ende vom Lied war das auch in diesem Unternehmen, mit mir eingeschlossen, die gesamte Abteilung innerhalb von 2 Monaten gekündigt hat.
Auf jeden Fall Daumen hoch für das super Video, sehr interessant und gut gemacht.
Nur so geht es
Frage: gibt es die Firma noch?
Soweit ich weiß ja, hab mich aber nicht mehr dafür interessiert wie es mit ihr weiterging.
Und zum Punkt Refactoring kann ich nur sagen: es ist das beste was man machen kann. Egal was das Ziel ist. Manchmal erwische ich mich dabei, wie ich fremden Spagetticode 2h lang refakturiere, nur um dann in 30 min die eigentliche Änderung zu programmieren. Refacturing ist einfach eine Grundlage, die unter anderem auch dazu dient, in der Zukunft überhaupt noch Umsatz mit einer alten Idee/Code/Software machen zu können. Wer das nicht wahrhaben will, wird irgendwann immer an ein dead end kommen. Und was beim Refacturing auch nebenbei abfällt, ist manchmal ein Bugfixing, was dann auch die Qualität und die Stabilität des Code erhöht. Auch das wirkt sich indirekt auf den Umsatz aus. Im übrigen wirken sich normalerweise alle Aufgaben auf den Umsatz aus. Selbst wenn ich grad aufm Klo sitze und über einen Lösungsansatz nachdenke.
Ne, nur VISA, MasterCard, die Bank, und PayPal sind direkt für Umsätze verantwortlich. Alle anderen müssen gefeuert werden. 😑
Das schreiben von Tests halte ich noch für wichtig, damit die Funktionalität auch langfristig sichergestellt werden kann. Und Tests schreiben kostet halt Zeit, ist aber aus genanntem Grund wichtig.
@@OpenGL4evergeb das nen DAU der zerpflückt dir deine Software in unter 60s....
Würden Entwickler vorher nachdenken wie einfach Abläufe zu halten sind und Oberflächen nicht überfrachtet werden sollten macht schon mal nen guten Anfang...
Nur heißt es Refactoring factor re ing Bruder. ❤
Brauchst doch nur in den Stellenanzeigen zu gucken, die suchen eine Person die ein ganzes Team ersetzen soll.
Hey,
da ist sehr viel wahres dran und mehr Arbeitserfahrung als der Bewerber Jahre alt ist bitte auch noch.... :P
Gruß David
@@DavidTielke Oder 5 bis 7 Jahre Erfahrung mit einem Framework, was gerade mal halb so alt ist.
Ja, genau... 🤣
@@DavidTielke Aber gleichzeitig soll es ja Fachkräftemangel geben. Beides gleichzeitig geht irgendwie nicht, finde ich.
@@christianknuchel Bei Entwicklern gibt es keinen Fachkräftemangel, nur einen Mangel an billigen Arbeitskräften, die sich ausbeuten lassen.
Es ist heftig wie viele Stellenbeschreibungen nach Senior Software-Engineers suchen und dann ein Einstiegsgehalt eines Fachinformatikers nach abgeschlossener Lehre anbieten
Ich bin 32 Jahre in der Business Software Entwicklung tätig mit 70/30 Schwerpunkt programmieren und Business Analyse. Ihre Darstellung bildet 100% meine Berufserfahrung ab. Auch ihre Ursachen Analyse ist absolut korrekt. Umsatzgeilheit ist der Hauptgrund...Unwissenheit ein wenig auch aber dieser Grund ist ein wesentlich geringerer Anteil. Ich habe das Glück in einem kleinen Scrum Team derzeit ganz gute Prozesse und Rollenaufteilungen zu erleben. Es gibt also Hoffnung für Software Entwicklung, auch in Deutschland 😊. Danke für Ihre klaren Worte.
>"Du bist da, um Tickets abzuarbeiten."
Zusammem mit einer beziehungslastigen Kommunikation, wenig Offenheit für Neues im Entwicklerteam und mangelnde Entwicklungsprozesse, war das ein schwer erträglicher Zustand für mich. Ich war froh gekündigt zu haben
Wenn Tickets bearbeiten heißt Kunden abzzwimmeln und alles verläuft im Sande 100%!!!
Hey,
verstehe ich - deckt sich ja weitestgehend mit der Geschichte bei meinem Kunden.
Gruß David
@@cantkeepitin Bei den Tickets hatte ich sehr oft den Eindruck, dass mehr gehen würde, wenn man den PO aus dem Prozess nimmt. Den den Kunden zufrieden machen ist eigentlich Hauptsache. Grosses Problem war aber die Ansicht von technischen Schulden als non-existent und das kategorisieren von automatischen Tests als unwesentlich. Geschweigedenn die kaum vorhandene Doku bzw. Nutzen der vorhandenen Doku. Ein "Kampf gegen Wind ühlen",
@DavidTielke und die Personen, deren Hauptmotiv auf der Arbeit die Beziehungen waren und nicht die Leistung, haben mir als relativ junger Entwickler gezeigt, dass so eine "fachliche Sackgasse" noch nichts für mich ist.
@@cantkeepitin Ich würde hier "Tickets abzuarbeiten" interpretieren als: "fix den Bug und kümmere Dich sonst um nichts!". Das heißt, der Entwickler zählt nichts, und das wiederum heißt, langfristig sollte er gehen.
Diese Aussage, welche Ihnen da an den Kopf geknallt wurde, ist so unglaublich dumm. Tital wertschätzender Umgang. Es ist schwer zu glauben, dass das die Einstellung von Leuten im Unternehmen sein kann.
07:12 schön dargestellt. Die Rollen Stakeholder, Product Owner und Process Owner waren für mich immer etwas schwer zu verstehen, da bei meinen Arbeitgebern sonst immer jeder jede Rolle hatte - außer Support.
David Ich muss mich bei dir mal bedanken. Dein Content bringt mir und sehr wahrscheinlich vielen anderen Selbstständigen/Entwicklern eine menge Mehrwert. Es gibt ja viele Kanäle, wo man programmieren lernen kann aber dein Kanal zeigt nochmal was dazwischen so alles passiert und wie der ganze Prozess laufen sollte. Danke dir. Mach weiter so. :)
Danke für die Zusammenfassung. Das Thema spricht mir praktisch aus der Seele. Leider wird der Umsatz bevorzugt, als das man die Qualität im Fokus hält und einen Gesunden Umsatz pflegt.
Ich war in einem Team mit genau dieser Situation und es wird dich wenig überraschen, wir sind alle gegangen!
Das Problem war in diesem Fall nicht die Unwissenheit. Die Entwickler wussten sehr gut welche Positionen hätten besetzt werden müssen. Das wurde vom Management allerdings nicht getan. Eigentlich wurde bei keinem Punkt jemals auf das Entwicklerteam gehört. Refactoring war bitter nötig, aber dazu wurde dem Team nie die Zeit gegeben. Stattdessen wurde ein Feature nach dem anderen rausgehauen. Die höheren Dienstgrade lief und dann immer rum, versprachen das Blaue vom Himmel und erzählten den Kunden, wie toll doch alles ist. Die Entwickler konnten dies nur mit Spott, Hohn und Kopfschütteln kommentieren. Genau wie in deinem Fall wurden auch neue Leute eingestellt allerdings nicht für die technische Betreuung oder Entwicklung. Es war der Vertrieb!
Du siehst, deine Geschichte ist nicht so ungewöhnlich und auch das komplette Teams kündigen keine Seltenheit. Ich kann deinem Resümee nur zustimmen: Der Kunde ist selber schuld!
Hey,
ich hatte schon vermutet das es hier schon einigen so ergangen ist. Weißt Du wie es dann bei dem Unternehmen weitergegangen ist?
Gruß David
@@DavidTielke Ich kann dir tatsächlich sagen, was mit dem Unternehmen passiert ist. Erst heute habe ich ein Vertriebsmitarbeiter des Unternehmens getroffen der noch dort arbeitet. Es sind jetzt zwei Jahre her, seit wir weg sind. Zu unserer Verwunderung gibt es das Unternehmen immer noch. Der junge Mann, den wir damals als Azubi eingestellt haben, ist jetzt Leiter der Entwicklung. Wie sagt man so schön, unter den Blinden ist der einäugige König.Mag etwas seltsam klingen, aber er kennt das Produkt immerhin noch am längsten. Vieles von dem ursprünglichen Know-how meiner Kollegen und mir ist natürlich auf Nimmerwiedersehen verschwunden.Den Zeit, irgendetwas gründlich zu dokumentieren, hatten wir natürlich auch nicht.
Das blieb auch im Rest des Unternehmens nicht unbemerkt. Viele Kunden haben gekündigt und auch langjährige Mitarbeiter aus dem Vertrieb sind auf dem Weg aus der Tür oder schon weg. Das ist alles sehr bedauerlich. Wir hatten ein wirklich gutes Team und haben an das Produkt geglaubt. Leider hat man die nötigen Änderungen, die wir immer wieder gefordert haben, nicht durchgeführt. Stattdessen wurde der Druck von oben immer größer. Natürlich gab es immer Floskeln, wie, wir müssen die Qualität verbessern. Aber solche Projekte wurden dann innerhalb weniger Tagen schon immer wieder abgebrochen, weil ein Kunde mit irgendeinem Wunsch kam, den wir dann ganz dringend umsetzen mussten. Dann kam wieder die Phase, wo die Geschäftsleitung sich wunderte, warum das Programm nicht richtig funktioniert.
Im Grunde kam es ganz schnell zu einem regelrechten Exodus. Wenn der erste Entwickler geht, folgen die anderen relativ schnell den keiner will der Letzte sein, der das Licht ausmacht. Es war immer der Zusammenhalt der Kollegen, der uns dort hielt. Nachdem es die nicht mehr gab, hat sich alles sehr schnell in Luft aufgelöst. Es blieben nur die, die den Job dringend brauchten. Das sind dann meistens nicht die besten Entwickler.
Persönlich kann ich sagen, dass es mir, nach dem ich das Unternehmen verlassen habe, auch gesundheitlich viel besser geht. Auch Menschen aus meinem Umfeld haben gemerkt, dass ich ein viel fröhlicher und ausgeglichener Mensch bin. Bei meinem neuen Arbeitgeber gibt es tatsächlich jemand, der sich um das well-being der Mitarbeiter kümmert. Das war für mich ein richtiger Kulturschock. Natürlich zum Guten!
Ich möchte dir übrigens noch sagen, dass ich deine Videos super finde. Leute, die auf RUclips programmieren und Code zeigen gibt es zu genüge. Über das ganze drum herum im Leben eines Entwicklers erfährt man relativ wenig. Es ist prima, dass du dich diesen Themen annimmst.
Hey,
unfassbar - der arme ex-Azubi :D Wie kann man als Unternehmen nur so fahrlässig sein, besonders wenn man ein offensichtlich so gut funktionierendes und harmonisches Team hat. Diesen "Herdentrieb", das wenn einer Kündigt die anderen auch gehen sehe ich leider auch sehr oft, meist in Teams die solche Charakteristiken haben wie dein ehemaliges.
Ja, dieser Teil der "Mentalen-Gesundheit" wird leider auch oft nicht beachtet, das höre ich von Entwicklern nach Ihrem Wechsel immer wieder und auch die Erkenntnis das der Gehaltssprung totale Nebensache geworden ist bei sowas.
Danke für Dein Lob, freut mich sehr das Dir meine Videos gefallen. Würde auch wieder gern mehr zu "praktischeren" Themen wie Architektur, Qualität und Tests machen, aber diese Themen hier schlagen einfach in meinen Projekten immer wieder durch :)
Schön das Du dabei bist!
Gruß David
Ich denke dass Problem ist bei kleinen unternehmen und startups eher ser Fall und verbessert sich mit zunehmen Wachstum im Bestfall. Bei Daimler, Bosch etc. ist sowas weniger ein Problem - da ist jede Stelle doppelt oder dreifach besetzt...
@@mxz2024Bei größeren Unternehmen ist es sehr davon abhängig wie fähig das untere Management wie Gruppenleiter oder Teamleiter sind.
Abteilungsleiter sind oft schon eher "Politiker" als Experten.
Hierdurch kann sich der Gruppenleiter oft aus Problemen heraus reden ohne dass es verifiziert wird.
Also entweder:
Das (ein einfacher Datenabgleich) war technisch hoch komplex.
Oder.
Ich kann nichts dafür, mein Untergebener hat es verbockt.
In beiden Fällen kann der Untergebene schon vorher gewarnt haben.
Womöglich sogar bis zum Abteilungsleiter eskaliert haben.
Oder noch weiter.
Es führt dann nur dazu dass dann auch der Abteilungsleiter dem Gruppenleiter erst recht deckt weil sonst ja der Abteilungsleiter mit verantwortlich ist.
Im Extremfall kann sogar jemand zusätzlich eingestellt werden und noch einige hunderttausend mehr ausgegeben werden um so von dem ursprünglichen Problem abzulenken.
Hatte einmal in einer Chipfertigung beobachten können.
Wafer wurden bearbeitet und dann unzureichend geschützt über Jahre gelagert. Also ohne Schutzatmosphäre oder ähnliches.
Wobei ich finde das beste wäre gewesen diese Chips fertig zu stellen und dann erst zu lagern. Wäre aber wohl zu teuer gewesen.
Anscheinend hatte der Fertigungsplaner das Problem bis zur Werksleitung hoch gemeldet.
Entsprechend hoch war das Interesse andere Schuldige zu finden.
Jedenfalls wurde dann ein Fertigungsplaner gesucht der den Auftrag bekommen sollte alle möglichen alten Anlagen die noch in diversen Prototypen Abteilungen standen in einer (neuen?) Halle wieder zu vereinen und aus diesen inzwischen defekten Wafern komplette Steuergeräte zu produzieren.
Ich schätze bei all den Kosten sollte niemand mehr nach der wahren Ursache suchen. Ob das "funktioniert" hat kann ich nicht sagen.
Auf einen Nenner gebracht,kaputtgespart
Hey,
gut zusammengefasst - wär auch ein tolles TItel für das Video gewesen :D
Gruß David
@@DavidTielkeUnd es wäre auch weniger clickbaity gewesen, was bei so interessanten Themen mMn auch nicht notwendig ist.
Bei Kaputtgespart denke ich sofort an das Straßen- und Schienennetz Deutschlands. Jahrelang nur das Nötigste und nun soll das von jetzt auf gleich alles gefixt werden und möglichst wrnig kosten. Finde den Fehler.
@fairphoneuser9009 - Verstehe Deinen Vorwurf nicht, was bitte ist daran Clickbait? Es geht um einen Fehler den (immo) 90% der Unternehmen machen und der aus meiner Sicht und meiner Erfahrung der größte in der Softwareentwicklung allgemein ist. D.h. der Titel "Größte Fehler in der Softwareentwicklung den viele machen" liefert zu 100% meine Erkenntnis dazu und die Szene aus dem Vorschaubild wird auch geklärt, weil das Team aufgrund des Fehlers gekündigt hat.
@alexanderbehling4680 - Ja, da sind die Ursachen ja ähnlich. Da wurde genutzt, genutzt und genutzt und wenig in die Nachhaltigkeit des Netzes investiert. Genau so ist es auch bei der Softwareentwicklung.
Gruß David
Danke, das ist sehr lehrreich.
Ich, kurz vor dem Ruhestand, habe als Bauer einer Messmaschine Software geschrieben und alle Rollen allein ausgeführt. Der Stakeholder war schon da. Nun wird das Produkt mit ca 3 Jahren Verspätung auf neue Füße gestellt (externe Softwarefirma)
Dass ich kein BournOut hatte grenzt an ein Wunder.
Wow dann bin ich ja froh dass bei uns viele dieser Schlüsselpositionen besetzt sind. Das Einzige, was uns fehlt, ist der Scrum Master, aber in der Zeit wo wir einen hatten, hat diese Person auch quasi gar nix gemacht. Unsere Kommunikation zwischen Product Owner und Entwicklung läuft auch so gut, weil bereits viel Erfahrung da ist. Und so ein Mitarbeiterzufriedenheits-Mensch gibt es bei uns auch nicht, bzw übernehmen unsere Teamleiter diese Aufgabe. Alles in allem bin ich jetzt durch dieses Video extrem dankbar über meine Firma, bei der sehr viel richtig läuft und ich mich als Entwicklerin sehr wohl fühle 😊
Hey,
das ist doch auch eine sehr wichtige Erkenntnis - Glückwunsch!
Gruß David
Braucht ihr verstärkung? ;-)
@@suljocakisic5340 lol... ja klar, immer ^^ (sofern das ernst gemeint war)
Wir sollten hier eine Jobbörse aufmachen :D
Gruß David
hmmm bei uns hocken in den schlüsselpositionen die creme de la creme der "ichkannnichtsausserlabern"
Das Steak bei Stakeholder :'D.. Sehr gutes Video David! Mit der ein oder anderen Aussage hat man sich dann doch "erwischt" gefühlt und man kann dadurch ehernachvollziehen was du meinst :)
Lg
blog.seibert-media.net/wp-content/uploads/2013/06/agile_idrewing_steak_holder.png
Endlich würdigt es mal jemand... :D
Gruß David
@@DavidTielkeDer, der das Steak hält: Grillmaster!!!😂
Ja, in meiner Truppe ist es bedauerlicherweise ähnlich. Mein Team und ich sind damit beschäftigt, eine veraltete Umgebung mit Entwicklung und Wartung am Laufen zu halten. Die neue Umgebung versucht bereits seit etwa 8 Jahren, die Legacy-Anwendung abzulösen. Als Konsequenz wurden uns finanzielle Mittel gestrichen, obwohl wir gleichzeitig zusätzliche Aufgaben aus dem Fachbereich übernehmen sollen. Angesichts dieser Situation überlege ich ernsthaft, im nächsten Jahr den Arbeitsplatz zu wechseln, falls sich nichts ändert.
Unserem Management haben wir die Situation ausführlich geschildert und warten nun darauf, dass neue Mitarbeiter eingestellt werden. Es ist für uns mit nur 3 Mitarbeitern nicht machbar, gleichzeitig neben der Entwicklung auch den Support und das fachliche Wissen aufzubauen. Früher hatten wir 8 Entwickler und 4 Fachkräfte, die uns dabei unterstützt haben.
Hey,
ja geht in eine ähnliche Richtung - leider erlebe ich das auch sehr oft, das bei vermeintlichen Neuentwicklungen plötzlich das alte außer Acht gelassen wird und nur noch mit Halbgas weitergefahren wird - und irgendwie soll das dann funktionieren...
Gruß David
Nicht warten, direkt sich woanders umschauen
Warum nicht jetzt nach einem neuen Arbeitsplatz schauen? Tu dir das nicht noch ein Jahr lang an
Ich empfehle dir so schnell wie möglich das Schiff zu verlassen. Es wird nichts ändern. Ich habe dasselbe schon erlebt. Es wurde nur noch schlimmer. Am Ende habe ich es bereut nicht früher gegangen zu sein.
@@DavidTielkeJa, das kenn ich auch aus meinem jetzigen Unternehmen. Neuentwicklung versucht, viel zu unrealistische Zeitpläne aufgestellt, wo jeder Entwickler gesagt hat, das kann nicht funktionieren. Knapp 2 Jahre später wurde das Projekt eingestellt und bei der Legacy Software sind 2 Jahre Bugs aufgelaufen. Kunden unzufrieden und viele Entwickler sind wegen der Einstellung der Neuentwicklung gegangen.
Das ist auch der Grund, warum ich auch der Entwicklung weg bin. Unfähiges Management und BWLer, die von nix ne Ahnung haben, und davon ausgehen, in der Entwicklung ist alles nur 'ein Knopf drücken, und fertig!' ...
Dein Video zeigt nebenbei sehr schön auf, warum ein Unternehmen sich nicht auf Umsatzsteigerung, sondern auf Gewinnsteigerung konzentrieren sollte.
Das ist gerade bei Software totaler Quatsch, weil du da erst viel investiert und später verdienst.
Amazon hat 10 Jahre keinen Gewinn gemacht.
Ich finde deine Videos und die Themen über die du sprichst unfassbar wertvoll.
Und das Ganze kann auch auf andere Bereiche ausgeweitet werden und beschränkt sich oft nicht nur auf klassische Software Entwicklung. Als Designer in einer Agentur, der in vielen Web-Projekten arbeitet erlebe ich leider oft ähnliche Situationen.
Genau diese Prozedur hatte ich damals bei meine ersten Arbeitgeber... Die Entwickler schreien nach Zeit zum refactoring und Testautomatisierung, aber stattdessen war alles dem Marketing/Vertrieb hörig: Neue Features über alles.
Ich bin sehr froh, dass mein aktueller AG genau das Gegenteil ist, wir wirklich in einem Team arbeiten, wir Zeit haben für Sachen wie technische Schulden, Test- und Deploymentpipelines und die Geschäftsleitung auch aktiv auf die Empfehlungen und Anforderungen der Entwickler reagiert.
Ich komme überhaupt nicht aus der Branche, aber weil Du das Thema so mega gut dargestellt hast bin ich drangeblieben. Sehr gute Analyse, Top Content
Das Gleiche erlebte ich vor einigen Jahren. Dann kam eine Entwicklerin, die sich das ansah und anbot Scrum einzuführen. Damit wurden die Rollen eingeführt und aus der Gruppe ein Team geformt. Danach war das Thema Kündigung unter den Arbeitnehmern vom Tisch.
Als Solo-"Künstler" decke ich quasi alle Rollen allein ab. Aber da meine Kunden im Großen und Ganzen zufrieden sind und meine "Produkte" sauber laufen (in ca.98% der Fälle), kann ich schon etwas besser sehen, warum ich mich permanent ausgebrannt fühle. Vielleicht sollte ich mal Urlaub machen, indem ich endlich eine gechillte Festanstellung in einem wirklich guten Team anfange. Just dreamin'
Das habe ich nach 12 Jahren "Selbständigkeit" genau so gemacht. Ich bereue es nicht. Bei meinem Arbeitgeber wird inzwischen jede der Rollen bekleidet. Gut, wir schuften an einem Monolithen mit einer bescheidenen Architektur und extremer Komplexität aber man kann nicht alles haben. ...und DevOps ist noch nicht ganz am Start. Ich habe die One-Man-Show erst gegen Freelancing getauscht und dann gemerkt wie gut mir wieder regelmäßiger Kontakt mit Menschen tut. Aber ich war auch lange überzeugt, ich wäre kein guter Team Player und könnte es alles besser alleine bieten. Wie gesagt: Ist geil mit Arbeitskollegen und dass man nicht der einzige ist, der die brennende Hütte gerade löschen kann.
@@LarsEchterhoff Die meisten andren Entwickler sind ja genau solche Nerds wie man selber :D
Man könnte fast meinen Du warst bei uns. Aber noch haben nur einzelne Devs gekündigt. Es gibt eine erstaunlich hohe Fluktuation bei neuen Devs (5 Jahre und weniger) am Ende bleiben immer nur die 10+ und entsprechend angestaubt ist auch alles...
"Leider" gibt es einen sehr hohen Wiedererkennungswert in Deinem Video, das erschreckt mich in 2023, da gerade Devs sich mittlerweile den Arbeitgeber aussuchen können und nicht mehr anders herum.
Hey,
so fangen leider die meisten Kommentare hier an :) Ist leider kein so einfaches Thema, das Zitat in einem anderen Kommentare "Der Fisch stinkt vom Kopf" passt wohl auch bei Euch ganz gut :)
Gruß David
Die Frage "Was bei meinem Kunden schief gelaufen [sic] ist" wird leider überhaupt nicht beantwortet. "Nichts ist passiert" und alle Entwickler haben gekündigt ist keine Antwort, sondern nur ein Endergebnis
Aber für mich klingt das so, als habe die Beratung im Wesentlichen daran bestanden zu sagen, "macht mal 'ne Gruppe". Ok ein bisschen mehr wars sicherlich, aber all das schöne Gerede und das Commitment von Management und Kunden helfen herzlich wenig, eingefahrene Gewohnheiten zu ändern.
Mich erinnert das unvermittelt an die Folge, wo Jamie Oliver einer Amerikanerin, die sich und ihre Familie nur mit Fast-Food ernährt, einen Haufen Gemüse in den Kühlschrank stopft und sich dann ein paar Tage später wundert, dass nichts davon gekocht wurde. Um so etwas zu ändern, muss man jeden Tag dran bleiben und es Vorleben. Sprich: die eigentliche Beratung fängt an, wenn der Berater teil des Teams ist (z.B. als Scrum-Master) und auch von der Geschäftsführung die Befugnisse und Möglichkeiten für Änderungen bekommt. So kann man auch langfristig etwas ändern. Aber das erfordert natürlich auch ein erheblich größeres "Commitment" des Beraters zu einem Kunden.
Leider wahr. Wenn das das Ergebnis einer Beratung ist, bin ich über die großen Zahlen auf der Website nicht überrascht. 350 Projekte - da geht kein Commitment.
Deine stimme ist so angenehm, dass ich das Video angeschaut habe während ich was anderes gemacht habe und im Gedanken abgeschweift bin. Jetzt muss ich das Video von vorne schauen :D
Danke David, genau das ist das Problem. Unwissenheit, Verbohrtheit an alte Strukturen festhalten, Desinteresse. Der Fokus ist Umsatz, die Qualität darf nix kosten, weder Zeit noch Geld, ansonsten, wird wiedermal schnell schnell irgendwas irgendwo, implementiert. Die Softwareentropie nimmt seinen Lauf. Das große Heulen kommt später.
Hallo David, tolles Video. Sehr genau auf den Punkt. Ist echt erschreckend wie oft man genau solche Zustände vorfindet. Spannend ist auch: Bei uns findet gerade quasi die Umwandlung vom Team zu Gruppe statt. Um den Umsatz anzukurbeln wird ein funktionierendes Team (5 Leute) auseinander gerissen und innerhalb kürzester Zeit sind 3 neue Softwareprojekte hinzugekommen, die dann jeweils mit 1,5 bis 2 Leuten aus dem Team besetzt wurden. Damit ist ein erfolgreiches Team in 4 strauchelnde "Gruppen" transformiert worden.
Was mir noch aufgefallen ist: Am Anfang sprichst Du von Idee und Vision mit unterschiedlichen Symbolen. Später scheinen die Symbole irgendwie vertauscht. Hatte mich kurz irritiert und ich frage mich ob ich das falsch verstanden habe oder da tatsächlich die Symbole falsch waren. So oder so kommt die Botschaft aber an. Und +1 für die Verwendung von FontAwesome - wenn ich das richtig erkannt hab ;-)
Wenn man täglich inhaltslose Rituale des agilen Arbeitens ausführt kann man sich Vision, Architektur und sogar saubere Implementation sparen. Dann fügt sich auf wunderbare Weise alles ganz von selbst zu einem Superprodukt zusammen. Das ist ja das tolle am Agilen, niemand muss mehr sein Gehrin benutzen, alles ist so einfach. Und ja, meine Hand ist inzwischen in meinem Gesicht festgewachsen.
110% Bestätigung! Mittlerweile ignoriere ich den ganzen agilen-jeden-tag-5-Meetings Scheiß. Bin zwar unten durch, aber wenigstens kann ich in Ruhe arbeiten.
Sorry, aber dann macht ihr agile Softwareentwicklung falsch. Wenn die Meetings ein Selbstzweck sind, dann stimmt was nicht. Im Moment gibt es so eine Gegenbewegung zu agil. Das liegt aber daran, daß die meisten Firmen es schlicht und einfach falsch machen.
@@uran238frdem kann ich nur zustimmen. Agil heißt nicht planlos...
@@uran238fr Deswegen meinte er ja inhaltsleere Rituale. Man kann sie auch sinnvoll füllen und in Frequenz und Dauer reduzieren. Aber manche machen das nicht und das führt dann zu Leuten wie hier, die sich resigniert ausklinken. Bisher war ich fast nur in guten agilen Teams. Nur als agil/lean mal in einem nicht-SW-Entwickler Team eingeführt wurde, endete es in unendlichen Labermeetings ohne Sinn. Das war furchtbar aber ich bin schnell weg von da.
Man braucht nur ne breite Produktpalette und macht viel Werbung, gibt immer dumme Kunden die was kaufen und davon begeistert sind.
Lieber David, vielen Dank für deine Videos! Du sprichst mir bei vielen deiner Themen aus der Seele und ich ertappe mich immer wieder dabei wie ich denke "Jepp, genau so war es in Unternehmen xy" oder "Ja, wäre doch eigentlich mega, wenn auch mal jemand so arbeiten würde.". Insbesondere der Faktor Burnout wird immer wieder komplett übersehen und es wird so lange immer mehr Druck und Verantwortung auf die Entwicklung gelegt, bis die Leute keine Lust mehr haben dauerhaft die Schuldigen zu sein und nie zur Ruhe zu kommen. Man sagt ja "Der Krug geht so lange zum Brunnen bis er bricht."
Wow, vielen Dank für dein Video. Ich bin als Seiten Einsteiger ins DEV Team gekommen. Und so wie du es gezeigt hats habe ich es nie verstanden. Nun weiss ich wie ich meine Arbeit vorbereiten muss das die Kollegen im Team es auch nutzen können. Vielen Dank!!!!🥰😍
Hey,
sehr gerne - schön das es dich weitergebracht hat!
Gruß David
Ich sagte letztens zu meinem Chef, dass wir eine Software-Bastelbude sind. Er stimmte zu. Verbessert hat sich absolut nichts. Prozesse werden aufgebläht und Grundsätzliches, wie bspw.weise ein Qualitätsmanagement existieren faktisch nicht. Ich warte seit über zwei Jahren auf eine stable Release, während ich dev betas auf die Kundensysteme aufspielen muss, um den großen GAU zu verhindern. Hier wird sich kaputt gespart. Das ist auch hauptsächlich der Grund, dass ich nicht an das Produkt und auch nicht mehr an die Firma glaube. Daher werde ich mich in absehbarer Zeit lösen. Ach ja, auf die Gesundheit wird geschissen. Man ist ja selbst schuld, wenn man zu viel arbeitet.
Vor 25 Jahren war Objektorientierung das Allheilmittel, dann kamen SW-Komponenten, Model-driven Development, extreme programming, agile Software-Entwicklung, ...
... aber die Knackpunkte sind noch immer die gleichen - kann das wirklich sein ?
Faszinierend.
Über OOP-Hype habe ich mich schon damals gewundert...
Das ist ein generelles Problem, in allen Unternehmen, dass die Manager keine Ahnung vom Produkt, der Entwicklung und den Details haben und nicht auf diejenigen hören, die es besser wissen.
Ein Hauptgrund dafür ist, dass viele Leute in Management-Positionen oder anderen Führungspositionen Narzissten und/oder Psychopathen sind, sich also für die Besten und Größten halten, die niemals Fehler machen können. Wenn irgendwas nicht läuft, dann ist es niemals ihre Schuld, es sind immer die anderen, Empathie kennen sie nicht und können sich somit eben nicht in andere heineinversetzen und verstehen dann gar nicht, warum gekündigt wird.
Hehe, im Kern durchaus was wahres dran, aber die Aussage so zu pauschalisieren halte ich für nicht richtig. Ich kenne viele sehr gute Führungskräfte, aber natürlich auch sehr schlechte. Das kann man in jedem Fall so nicht sagen :)
Gruß David
@@DavidTielke just to be fair: er sagte viele, nicht alle :)
@@fx-bx8cs Richtig, deshalb ziehen diese Positionen eben soviele Narzissten und Psychopathen an.
@@fx-bx8cs es gibt auch die "berufenen" Führungskräfte. Denen man das quasi angehängt hat. Unter so einem arbeite ich, ein vielseitig kompetenter Mensch, und ein Vorbild.
War aber in Unternehmen, wo deine Aussage auch zutrifft :)
Auch die Besitzer von Unternehmen fühlen sich gerne wie Könige in ihrem Reich.
Ja super Thema, danke das Du das ansprichst. Ich finde man sollte nicht vergessen, dass es auch schon ganz vorne - bei der Idee - zu massiven Problemen kommen kann.
Es gibt einfach Software, die wird nicht benötigt oder die Idee ist einfach schlichtweg schlecht. Das muss ganz früh schon aussortiert werden, sonst reitet man jahrelang ein totes Pferd. Und ich glaube das passiert schon sehr häufig und keiner redet gerne drüber. Ich finde die Value Proposition also welchen Wert die Software tatsächlich erzeugen soll deshalb ein entscheidendes Kriterium, sozusagen die Single Source of Truth für das gesamte Projekt. Wenn das schon nicht passt und es keiner (Management!) merkt, tja gute Nacht. Ich finde wir haben speziell in DE ein massives Problem was die Qualität von (IT) Management angeht: Einfach absurd schlecht was da an vielen Stellen geschieht!
Hey, ja absolut - den Punkt meinte ich mit Vision. Da wird genau die Value Proposition rausgearbeitet. Aber ich habe auch schon in einigen Projekten erlebt, das dort schon erkannt wurde, das die Idee schlecht ist und trotzdem wurde das Projekt gestartet.
Gruß David
Ich denke ein Problem hierbei ist die sogenannte "sunken cost fallacy"; d.h. man möchte ein Projekt oder Produkt. nicht mehr fallen lassen, weil man bereits viel Geld hereingesteckt hat. Das tote Pferd, das man dann reitet, wird dadurch aber nicht lebendig. Besser ein Ende mit Schrecken als Schrecken ohne Ende.
Ich persönlich kenne mich kaum mit Dev Ops und automatisierten Tests aus, daher ist der Trick einfach, das auch wegzulassen und einfach im Wilden Westen zu arbeiten. Ansonsten ist die Aufteilung genau wie du das erklärt hast, kündigen kann ich leider nicht, ich müsste sofort in einen neuen Job starten können und ich werde gefühlt immer weiter abgehängt, weil sich die Lücken langsam auftun :/
Ich glaube das ist ein sehr deutsches Problem, da hier oft die Entscheider davon absolut keine Ahnung haben, weil sie dies selbst nie gemacht haben. War jetzt schon zwei mal in USA und da sieht die Welt ganz anders aus. Bei den Unternehmen wo ich war, wurden Kritierien wie test coverage, code Qualität etc. gemessen, es gab oncall Kalender, Code Reviews etc. Auch wenn das bei weitem nicht perfekt war, hilft es extrem.
Sehr schön zusammengefasst. Ich arbeite für ein Maschinenbauunternehmen, bei dem sich all diese Probleme noch mit zwei weiteren vermischt, erstens nimmt keiner Software ernst (ist eben eine Notwendigkeit, nicht Kerntätigkeit), und zweitens sprechen die Systemingenieure direkt mit den Softwareentwicklern an dem Prozess vorbei, und ich als Product Owner und Architekt (in einigen Projekten) werde dann außen vor gelassen. Die Software sieht dementsprechend aus, ist nicht wartbar, und die Entwicklung dauert länger und wird teurer, als wenn man den Prozess einhalten würde. Aber man hat ja dazwischen immer wieder gespart!
Team, 3 Entwickler, gefühlt hat jeder jede Rolle. Dokumentation pflegen inkl. Handbücher kommt auch noch dazu. Das klappt besser, als es klingt aber ich denke, da wäre viel Potential nach oben.
Hey,
ja diesen Aspekt habe ich nachher herausgeschnitten, weil das Video schon viel zu lang war. Oft funktioniert das auch "irgendwie" und wird als normal angenommen und die Unternehmen haben gar keine Ahnung davon, wie viel besser es laufen könnte!
Gruß David
Manche Probleme treten auch erst bei größeren Teams auf, da die Kommunikation immer schwieriger wird je mehr Personen und Abteilungen involviert sind. Bei einem kleinen Team kann das noch ganz gut ohne festgeschriebene Prozesse gehen.
Ja kleine Teams unter 7 Leute die gut zusammenarbeiten erledigen viel intuitiv richtig. Wobei man bestimmtes besser auskoppeln sollte. Zum Beispiel Tests und Nutzerhansbücher...
Wir haben einen großen Teil der Positionen formell auch nicht besetzt aber. Einige unserer Mitarbeiter haben isaqb Schulungen gemacht und führen die Architektur Ideen und Planungen im Zuge des Sprint plannings aus. Feel good Manager haben wir auch nicht aber der teamlead kümmert sich um uns, er fragt sogar welches Bier wir am liebsten trinken damit der Kühlschrank nicht immer mit dem selben Zeug gefüllt ist. Bugs haben bei uns immer die oberste prio im Sprit und werden immer sofort abgearbeitet. Mind 20-30% gehen regelmäßig für refactoring drauf (zb bei Updates von Bibliotheken, breaking changes, besseres state management usw.). Insgesamt bin ich aber recht zufrieden und fühle mich wohl an dem Produkt zu arbeiten.
Hey,
ob die nun formell besetzt werden oder implizit ist nicht ausschlaggebend, sondern das die Tätigkeit durchgeführt wird. Ob derjenige dazu den Hut auf hat, oder nicht spielt keine Rolle. WENN es aber eine definitive Rolle gibt, kann man alles einfacher kontrollieren und verbessen - das ist der Vorteil. Aber: glückwunsch zu dem Team, alles richtig gemacht :)
Gruß David
Das kommt mir auch alles bekannt vor. Ich vermisse Prozessbeschreibungen und Unit-Tests. Stattdesssen gab es "weiter so" mit weniger Leuten. Jetzt bin ich auf dem Weg raus und bin auf Jobsuche.
Vielen Dank für das sehr informative Video.
Auch ich muss leider sagen, dass ich nur zu gut mit den angesprochenen Themen vertraut bin, da diese größtenteils auf das Unternehmen zutreffen, für das ich seit acht Jahren als Softwareentwickler arbeite (3 davon die Ausbildung). Aber insbesondere bezogen auf die letzten vier Jahre, wo wir einige große Kunden dazugewinnen konnten.
Im Hauptsystem bin ich Architekt (nur für Teilbereiche), Entwickler und DevOps. In einem umfangreichen Zusatzmodul für einen Kunden übernehme ich fast alle Rollen alleine.
Und die seit kurzem diagnostizierte Konsequenz davon: schwere Erschöpfung / Depression aufgrund des enormen Stresses. Und das alles gerade mal 5 Jahre nach Abschluss der Ausbildung.
Ich hoffe, dass es jetzt besser wird, entweder mit dem aktuellen Arbeitgeber, der von den Konsequenzen echt geschockt war, oder einem anderen. Jedenfalls lasse ich meine Gesundheit da nicht mehr drunter leiden.
Bin auch etwas erstaunt darüber, wie viele Kommentare man hier von Personen findet, die mit gleichen / sehr ähnlichen Problemen im Unternehmen zu kämpfen haben.
Sehr schön zusammengefasst.
Deswegen ist es so wichtig das im Vorstand immer jemand sitzt der auch Ahnung von der Softwareentwicklung hat. Damit nicht solche Entscheidungen getroffen werden.
Diese Menschen gibt es leider nicht. Also im Vorstand meine ich.
Sehr interessanter Einblick. War vor 20, 50, Jahren auch in anderen Branchen. Immer wenn der Boom vorbei ist.Tja nun ist das Problem in der IT-Branche. Ständiges Wachstum, durch ständig Veränderungen und maginale Verbesserung. No limits, no border, no respect. Wenn wundert es wenn aus Mitarbeitern erst Personal wurde und dann human ressourcen (HR). Die Siebträgerkaffeemaschine wichtiger die Kantine, Bonis statt Urlaub und Homeoffice statt Feierabendbier mit Kollegen oder Treffen in der Teeküche auf einen Plausch,
13:39 "Haben wir den Scrum Master nicht ist das Projekt zum Scheitern verurteilt". Also ich hab ganz ehrlich noch nie gesehen, dass der Scrum Master irgendwas sinnvolles leistet, fand ich immer Zeitverschwendung.
Hey,
dann hast du bisher nur schlechte Scrum Master gehabt - der sollte normalerweise in jedem Sprint daran arbeiten den Prozess, die Artefakte, die Qualitygates und alles um den Ablauf herum besser zu machen. Die Rolle richtig zu besetzen ist eine der wichtigsten Punkte in der Entwicklung. Was macht Euer Scrum Master die ganze Zeit?
Gruß David
@@DavidTielke Bei uns sind die Scrum Master der verlängerte Arm des Managements um den Entwicklern richtig einzuheizen.
@@AronNimzo Dann haben sie nur den Namen, aber sind es nicht. Dann hat jemand Englisch gelernt und meint: "to scrum" hieße "drängeln".
Ich kenne auch keine sinnvollen Scrummaster. Zumindest nicht als separate Person. Als Rolle kann das jemand nebenbei machen und dann funktioniert auch die Rolle.
Genau meine Erfahrung. Scrum-Master bringen nur etwas wenn sie auch mitprogrammieren. Sie sollen ja den Prozess an sich verbessern und dazu braucht es gestandene Leute die das Team nach Außen vertreten können. Und keine Ja-Sager-Typen deren Kernkompetenz Jira-Tickets sind.
ich arbeite seit 2010 in der software entwicklung und hab viel erlebt, was hier auch angesprochen wird.
interessantwerweise hat sich das stark verbessert seit ich (seit 2021) selbstaendig arbeite und fuer projekte als freelancer dazu geholt werde.
Seit dem arbeite ich nur noch in gut funktionierenden teams. Woran das liegt ist spekulation.
grundsaetzlich bin ich aber froh, die erfahrung in verschiedenen, nicht gut funktionierenden unternehmen gearbeitet zu haben. Am ende bin ich immer vor dem Bunrout abgesprungen, aber ich habe extrem viel gelernt und vor allem verstehe ich was im ganzen passiert und merke auch bei vorstellungsgespraechen schnell ob das projekt laeuft und ob ich da was bewirken kann.
Ich hab eine Zeit lang in einem kleinen Scrum Team ohne Product Owner gearbeitet. Das hat ein Entwickler nebenbei gemacht bzw. irgendwann hat er quasi nix anderes mehr gemacht. Nach einer Zeit hat er dann gekündigt, weil sein Traumjob nunmal Programmierer war (das Coding ist es doch, was wir lieben^^). Dann wurd zum Glück jemand dafür eingestellt, der sich voll drum kümmert. Es gab vernünftige Tickets etc., das ganze Team war zufriedener und produktiver.
Es ist sowieso so absurd, dass Leute die ihren Job am besten machen aus diesem Grund aus diesem Job raus "befördert" werden.
Kann mir durchaus vorstellen, dass er der PO wurde weil er eben der augenscheinlich beste Programmierer war, muss hier genau aber natürlich nicht der Grund sein. Damit verliert man aber den Programmier und bekommt einen semi guten, unzufriedenen PO. Worst of both worlds.
Aber ich sehe es immer mehr, dass es genau so in Betrieben läuft und ich kann es beim besten Willen nicht nachvollziehen. Vor allem wird man oft auch noch besser bezahlt obwohl man einen schlechteren Job macht.
@@TheThursty100 Es mag dir absurd erscheinen, aber genau das ist mir auch passiert. Ich habe immer weniger programmiert, was mich sehr frustriert hatte. Bei einem Bewerbungsgespräch, bei dem ich meinen Wunsch zu wechseln begründen sollte, wurde ich dann gefragt, ob ich überhaupt noch regelmäßig entwickle und das noch könnte. Das war für mich ein Alarmsignal!
@@AtomicKnights Es erscheint mir absurd, dass das der Prozess ist. Du bestätigst mir die Absurdität, ich habe ähnliches durchgemacht und andere aus meinem Team ebenso.
Das Absurde ist nicht, dass ich mir nicht vorstellen kann, dass es passiert, das Absurde ist DASS es passiert. Es ist absurd von den Führungskräften die die Beförderung bzw. die Aufgaben Verteilung so umlegen.
Je besser man ist, desto weniger macht man das worin man gut ist, weil man darin gut ist. Das ist das Absurde und es ist absurd, dass das so weit verbreitet als Gang und gäbe angesehen wird und stattfindet. Das ist der ideale Karriere-Gang.
Peter Prinzip
@@TheThursty100 en.wikipedia.org/wiki/Peter_principle Ich finde (IT) Management (in DE zumindest) einfach grausam schlecht. Die kennen keine best practices, kennen keine moderne SW Entwicklungsprozesse, kennen keine menschlichen Faktoren, haben Digitalisierung nicht verstanden... absurd schlecht. Und an den mythical man month glaube die auch noch alle. Ich höre 5 Tage die Woche soviel Bullshit, das das Wochenende manchmal nicht ausreicht das wieder zu vergessen 😞
Wann erfolgt die Dokumentation? Wann werden die Anforderungen getestet? Wer sagt dem Kunden, dass seine Wünsche nicht erfüllt werden können? Es können zwar alle Wünsche für sich erfüllt werden, aber nicht alle zusammen.
Hey,
- Dokumentation: Meist bei der Erarbeitung durch die Struktur (Epics, Features) und ggf. weitere Dinge, die über die "Definition of Ready" geeregelt werden, ist aber abhängig wie Euer Prozess ist
- Anforderungen Testen: Einmal im Review und ggf. danach in einem Testing-Prozess
- Kunden erklären: Der Product Owner, da er derjenige ist der Bestimmt, was aus fachlicher Sicht in das Projekt kommt
Gruß David
Nichts ist unmöglich. Doku brauchst du erst in 10 Jahren.
Bekommst jetzt doch mal n Abo, nachdem Video letztens mit dem Gehalt nach der Ausbildung war ich echt eher der Meinung "Nicht schon wieder einer, der auch die Sichtweise hat den "Neulingen" eher wenig zu zahlen." Jetzt nach ein paar Videos kann ich einfach nur absolut vieles nachvollziehen, super Content und super Sichtweisen =)
Also was die ganzen Rollen angeht, möchte ich mal kurz aus meiner Erfahrung anregen:
In unserem Team hat die Rollenbesetzung dazu geführt, dass einzelne im Team - ich sage mal - mit Scheuklappen herumgelaufen sind, ihre Rolle als die Entscheidene wahr genommen und verteidigt haben und somit viel Zeit mit unnötigen Diskussionen und Blockaden vertan haben.
Ich habe das dadurch gelöst, dass Rollen schon mal getauscht und/oder flexibel geändert werden konnten.
Das fördert Verständnis, Kommunikation und auch die Stimmung im Team...
Hey,
naja, bei all den Rollen muss man sich auf eine gemeinsame Strategie einigen - ohne die wird es schwierig. Das mit dem vertauschen sehe ich kritisch, da man für einige Rollen schon sehr tiefgreifende Expertise benötigt und die hat bei Weitem nicht jeder.
Gruß David
@@DavidTielke Ja, für effektives Arbeiten ist ein fröhliches Ringelreihen nicht sehr produktiv, aber für die Erweiterung des Horizontes ist ein eigenverantwortlicher Einblick - quasi als Ersatzspieler - für eine begrenzte Zeit sehr hilfreich.
Nebenbei hatte ich die Möglichkeit, die Fähigkeiten der Kollegen in den anderen Fachgebieten besser beurteilen zu können und bei längeren Ausfällen eines Kollegen "besser" zu reagieren. Ich musste ja nicht mehr ins kalte Wasser springen...
Ansonsten hast Du vollkommen Recht, David.
Gruß Andreas
Ich kein Entwickler, bin aber als Netzwerker für das Netz in einem Konzern zuständig, da gibt es viele Parallelen 😅 Da muss man auch mal aufräumen alles glatt ziehen, die Architektur anpassen und nicht immer nur kurzfristig auf Anforderungen reagieren. Sonst passieren ähnliche Dinge wie hier beschrieben.😊
Jepp administration same thing bei den meisten Firmen is das IT immer noch der Blinddarm der Firma die is halt da und tut nur weh wenns ne blinddarmentzündung gibt.
Stimmt genau! Vor allem bei größeren Kunden erlebe ich genau diesen Pattern immer wieder. Oft fehlt beim Kunden schlicht die Einschicht, dass gewisse Fehler, sind sie einmal gemacht worden, nur sehr schwer zu korrigieren sind. Meistens geht das, wie Du auch sagst, einher mit dem Management by Numbers Anti-Pattern.
Das Video müsste jeder Projektmanager sehen.
Ich programmiere Industriemaschinen. Es gibt viele Unterschiede zum klassischen Programmieren, diese Probleme hier sind leider auch größtenteils vertreten.
Ein großer Unterschied ist aber, dass die Vision bereits klar ist, weil die Maschinen im CAD dargestellt werden können.
Es kommt aber leider oft vor, dass ich dann feststelle, dass die Vision mit der geplanten Hardware nicht umsetzbar ist.
Ja, Scrum im Maschinenbau würde mich auch interessieren. Oft werden dort noch wasserfallartige Methoden aus den 80ern verwendet.
Ich bin zwar kein Softwareentwickler, aber man könnte das bei uns quasi auch schon so im übertragenen Sinne anwenden. Wir sind eigentlich ein Team von 7 Staplerfahrer. 2 fürs Abladen, zwei für Auslagerung und drei für Einlagerung. Jetzt sind zwei/ drei Staplerfahrer dauerhaft krank. Einer im Urlaub. Somit ist es natürlich schwierig die Waren ein- und auszulagern. Zumal wir auch wegen arbeitssicherheit enorm viele Anforderungen erhalten haben, wie wir unsere Arbeit zu machen haben. Das kostet viel Zeit. Man gibt zehntausende von Euros aus für Geländer, Ampelanlagen, Beschilderungen und sonstigen Kram. Dabei wird unser Standort spätestens 2026 eh geschlossen. Also was das Betriebsklima angeht, hat sich das dahingehend sehr verändert. Man ist quasi nur noch in einer Gruppe.
Hey,
oh ja, da hast Du recht - sehr gutes Beispiel.
Stelle mir nur gerade die Frage, warum meine Videos einem Staplerfahrer angezeigt werden, der kein Softwareentwicker ist... Komisch. Trotzdem schön das Du da bist und Danke für dein passendes Beispiel!
Gruß David
@@DavidTielke fun fact ich beschäftige mich seit 2020 mit Softwareentwicklung und lerne seit dem auch mit C#. Hab von dir in der Dotnetpro gelesen.
habe zwei Arbeitgeberwechsel gebraucht um jetzt in einem Team zu arbeiten bei denen wirklich jede rolle von einer person belegt ist und scrum wirklich gelebt wird. So schnell werden die mich nicht los. Es ist ein segen, sich als entwickler mal wirklich aufs entwickeln konzentrieren zu können
Herzlich Willkommen in meinem Leben! Das sind genau die Kämpfe die ich täglich austragen muss ein Kampf gegen Windmühlen… Danke David wirklich auf den Punkt gebracht… Ich würde sagen ein typisch deutsches Problem was unter anderem dazu führt, dass gestandene große Softwareunternehmen eben nicht aus Deutschland kommen…
Ich habe selbst vor längerer Zeit in so einem Unternehmen gekündigt. Heute bin ich selbst IT-Berater und kenne dieses Chaos, wenn ich bei einem neuen Kunden mit der Arbeit beginne. Welche Rolle oft auch noch gebraucht wird: Cloud Architect und Cloud Engineer (erste, wenn nicht durch die Architektenrolle abgedeckt). Dazu ist es aufgrund des Fachkräftemangels oft erforderlich, Haupt- und Sekundärrollen zu definieren. Oder Instrumente wie Pair-Programming einzusetzen. Ich helfe selbst auch bei Implementierungen mit. M.M.n. ist wegen dem Fachkräftemangel einfach eine Hands On Mentalität und Lernbereitschaft erforderlich.
ich habe das in meinen wirtschaftsinformatik studium rauf & runter lernen müssen & dachte damals, dass das mega der standard ist & alle firmen so arbeiten. Als ich dann in die Berufswelt eingestiegen bin (als Entwickler) habe ich sofort gemerkt, dass nur ein sehr geringer Bruchteil der Software Branche in diesen Themen Ahnung hat. Selbst gestandene C-Level Akteure, wussten oft nicht mal was DevOps oder UI/UX konkret bedeutet.
Ich habe so viele verschiedene Welten kennengelernt von Agentur, über Firma und Selbstständigkeit. Es gab so viele Facepalm-Situationen. BIn so glücklich wie ich jetzt arbeiten kann. Deine Interpretation und dein Erlebnis ist so typisch, aber es gibt so viele Versionen davon. Danke dir für deine Zusammenfassung, ist echt super.
Den Schluss der Geschichte fand ich merkwürdig.
Gab es denn niemanden, der diese Transformation begleitet und aktiv angestoßen hat?
Ein reines Commitment reicht wahrscheinlich nicht, wenn garkeine Expertise in der Firma besteht wie ein besserer Zustand in der Praxis aussehen würde.
Oder gab es diese Begleitung aber jeder änderungsversuch ist praktisch fehlgeschlagen und man gab auf?
Ich hab gute Erfahrung damit gemacht solche Änderungen von unten her einzuführen. Also die entwickler raufen sich zusammen und gestalten den prozess selbst und helfen gegenseitig aus bis sich neue Arbeitsweisen ergeben.
Wenn man nur drauf wartet dass Management was umstrukturiert wirds zäh.
Stecke jetzt auch in so einem Projekt. Alle haben gekündigt, es gab keine Übergabe und ich soll es retten. Gelernt wurde aus den Fehlern aber nichts und es wird jetzt bei mir Druck gemacht. Da kommt man schon ins grübeln...
Ich bin Team Team. Da bin ich ja froh anscheinend zu den 10% der Firmen zu gehören, bei denen das einigermaßen läuft. Die Rollen sind alle klar und verteilt, wir haben people Manager, Tester (gut, könnten mehr sein, aber es ist wirklich nicht so leicht, Tester zu finden), POs, Architekten. Wenn ein refactoring sinnvoll erscheint, wird’s gemacht. … würde auch nicht sagen, dass es besonders stressig zugeht. … support dürfte gerne bisschen weniger sein, aber da wird auch gerade eine team für aufgebaut.
Hey,
dann wirst Du mir bestimmt zustimmen, wenn ich sage das die Arbeitsqualität in solchen Team um Lichtjahre besser ist, als in solchen problematischen Teams/Gruppen wie in dem Video geschildert... :D
Gruß David
@@DavidTielke mir fehlt ehrlich gesagt der Vergleich, da das abgesehen von meiner Zeit als WiMi an der Uni mein erster Arbeitgeber ist. Aber ich kann mir gut vorstellen, dass es ohne den effort kaum möglich ist, nachhaltig Software zu entwickeln.
Angesichts dessen, dass in fast jeder Stellenausschreibung irgendwas von agil usw. steht (und Kern dessen ist ja u.a. die Rollenverteilung), wundert es mich aber schon, dass viele Firmen das dann anscheinend gar nicht machen 😅
Das klappt nur mit Entwicklern, die sich selbst zurücknehmen können.
In der Lage zu sein, etwas zu tun, aber es zu lassen, ist äußerst schwierig.
Gerade wenn die Firma angeblich "Engagement " erwartet.
Ich habe das Glück gehabt, nie wirklich darunter gelitten zu haben. Selbst in dem ersten Team gab es genügend agile Struktur und Prozessverbesserung. Heute arbeite ich in einem Geflecht aus Tribes, Squads, etc. mit etwa 100 anderen Entwicklern und wirklich jede erdenkliche Rolle ist besetzt. Fühlt sich sehr gut an 🎉
Hä, wasn das fürn Unternehmen? 😂
Ich bin an meiner ehemaligen Uni, wo ich meinen Bachelor gemacht hab, in ein Softwareentwicklungs Team gerutscht. Es gibt zwei Personen/Entwickler, die den Quellcode geschrieben haben und alles kennen. Wenn die mal nicht mehr da sind, müssen sich Entwickler hinsetzen und erst mal das ganze Projekt oder große Bestandteile davon verstehen. Die beiden machen aktuell Implementierung, Testen und das Bereitstellen.
Da es aber ne Uni ist und wir keinen Umsatz machen müssen, ist das irgendwie okay. Ich hab als studentische Hilfskraft 100% Home Office und kann mir meine Zeit einteilen, wie ich will. Ich muss nur auf meine 36 Stunden im Monat kommen. Seit neuestem machen wir jetzt Scrum mit nem 1 monatigen Sprint, was auch ganz gut funktioniert. Wir sind tatsächlich auch nur zu viert aktuell, also eine sehr überschaubare Gruppe. Alles in allem schon ein bisschen chaotisch aber es ist noch in Ordnung, grade eben weil wir keinen finanziellen Druck haben, oder zumindest aktuell keinen spürbaren. Wenn wir wirtschaftlich orientiert wären, will ich mir nicht vorstellen, wie anstrengend der Entwicklungsprozess wäre 😅
Hey,
am Ende kannst Du auch in solchen Projekten, welche am Umsatz gar nicht beteiligt sind, entscheidende Fehler machen. Der Kernpunkt ist ja, das Eure Software für irgendetwas wichtiges eingesetzt wird. Sei es um Prozesse zu unterstützen, Forschungsgelder einzustreichen oder was auch immer. Wenn ihr jetzt so eine Situation habt, gibt es da halt einige Risiken die man in dem Kontext auf dem Plan haben muss.
Gruß David
@@DavidTielke Ja, teilweise wird das auch aktuell angegangen. Die Einführung von Scrum sollte uns organisierter und produktiver machen. Dafür wurden auch zwei Entwickler die letzten Monate abgestellt, die sich darüber Gedanken machen sollten, wie man Scrum umsetzt. Dementsprechend wenig haben die in der Zeit entwickelt. Auch das Dokumentieren soll verbessert werden, damit sich neue Entwickler schneller einlesen können.
Hauptproblem ist halt, dass wir keine neuen Entwickler bekommen, damit die beiden Entwickler, die alles kennen, nach und nach an Verantwortung verlieren. Da kann man nur am Institut werben, aber wenn niemand will, will niemand 😁
Kleiner Tipp für die Zukunft: Nicht in Rollen denken, sondern in Skills. Jedes Team sollte die passenden Skills haben, um die vielfältigen fachlichen als auch technischen Anforderungen abzudecken um hierfür auch gemeinschaftlich die Verantwortung übernehmen zu können - ganz unabhängig von irgendwelchen Rollen. Das versteht auch das Management und erleichtert zudem noch die Suche nach passender Unterstützung ;-)
Hey,
ja das ist dieser agile Wunschgedanke von selbstorganisierenden Team. Das mag in manchen "Skills" (wie Du sie nennst) funktionieren, in vielen aber definitiv nicht. Architektur, Anforderungen, People sind die ersten die mir einfallen, das kann ein Team definitiv nicht gemeinschaftlich verantworten. Oft fallen Fehler hierbei nur sehr spät auf, in der Architektur beispielsweise und deshalb scheint es erstmal zu funktionieren.
Gruß David
@@DavidTielke Gerade die Architektur ist keine Blackbox die paralell zur funktionalen Umsetzung geschieht, sondern ist fest in den Entwicklungszyklus integriert. Moderne Technologien ermöglichen mit vertretbarem Aufwand Änderungen am Fundament, so dass auch hier Fehler früh auffallen und ausgebessert werden können.
Keine Entwicklung sollte einem Selbstzweck dienen, sondern Nutzen stiften (egal ob fachlich oder technisch). Nur Wissen löst die genannten Probleme, wenn dieses noch fest in einem Team verankert ist, kann auch die Verantwortung hierfür übernommen werden. Nicht nur theoretisch, sondern auch ganz praktisch :-)
Als ich dann etwas dagegen gemacht hatte und dabei sehr viel Fortschritt gezeigt hatte, wurde mir eine Zustimmung auf eine passiv aggressive Art verweigert aber ich durfte einfach so weitermachen. Hab einen passenden Moment genutzt um innerhalb von Tagen zu verschwinden.
Sehr gut erklärt, verstehe sogar ich.😊
Ich schreibe auch schon seit Jahrzehnten Programme, bin Autodidakt und mag VB6 und C++, aber nur privat.
Nach über 5 Jahren Softwareentwicklung in der Automobilindustrie kann ich nur absolut bestätigen was du sagst. Bin heilfroh, den Absprung geschafft zu haben. Hätte nicht gedacht, dass man einen Laden so schlecht managen kann.
Ich mache momentan die Umschulung zum Fachinformatiker in der Anwendungsentwicklung und bin gerade im Praktikum und darf mir mein Projekt aus dem nichts herbeizaubern. Ich soll/muss alle Rollen selbst übernehmen außer die Abnahme durch meinen Vorgesetzten. In der Firma würden die Projekte auch so laufen, wenn man später fest angestellt ist. Ich hatte ja eigentlich die Hoffnung, dass es in anderen Firmen besser läuft. 😅😂
ChatGPT (version GPT-4) ist dein Freund. Nicht zum blind erstellen, sondern als Betreuungsersatz. Müsstest dich aber 1-2 Tage mit Prompt Engineering und den Limitierungen auseinandersetzen. Lohnt sich aber. Viel Glück und Erfolg!
Aus irgendeinem Grund habe ich gerade das unstillbare Verlangen, meine Software tiefer zu legen. Ich strebe immer nach Improvemt! Und Tschüss.
Ich habe 3 Jahre in der Entwicklung einer SaaS gearbeitet, alles was du beschrieben hast wurde so auch missachtet. Das Business Modell hat von vornherein nicht gestimmt. Es gab kein PO, keine richtige Vision, keine Scrum Master... Ect. Im Endeffekt würde das Produkt aufgrund geringer Nachfrage eingestampft. 3 Jahren Nerven und Überstunden für nichts. Habe dann natürlich gekündigt. Wie alle anderen auch. Problem ist das viele Unternehmer denken die können das alles wissen und einschätzen, leider fehl am Platz.
Was waren das bitte für 9 Software-Entwickler? Alles Juniors? Denn dass nicht einer schon mal zu seinem Vorgesetzten gegangen ist um zu erklären, dass es nun mal einen technischen Lead braucht, der alles zusammenhält und koordiniert, das finde ich erstaunlich. In meiner letzten Firma war ich Lead-Developer, aber hatte wieder das Problem, dass mir der Gruppenleiter, also mein Vorgesetzter immer in Dinge reinredete, die ihn nichts angingen. Ich habe das Know-How, aber wurde seitens des Vorgesetzen "bekämpft", aber nicht aus Bosheit, sondern aus purem Aktivismus. Denn sonst hätte man vielleicht bemerkt, dass bestimmte Positionen im Unternehmen keinen Mehrwert für das Unternehmen haben und gestrichen hätten werden könnten.
Klingt wie ein typisches Ergebnis einer agilen Transformation oder Scrum-Implementierung. Es gibt aber einen gemeinsamen Nenner: zu wenige Leute mit technischem Hintergrund im Management. Sag, was du willst, aber alle wirklich erfolgreichen Unternehmen mit niedriger Fluktuation bei den Entwicklern haben Leute im oberen Management, die selbst Entwickler waren und dann in kaufmännische Rollen gewechselt sind. Jedes Mal, wenn ich in einem Unternehmen gearbeitet habe, das auf kurzfristigen Vertrieb und Marketing fokussiert war, entwickelte sich die Situation genau so, wie du es beschrieben hast. Es ist auch verrückt, dass Unternehmen mit Kernsoftwareprodukten oft nur etwa 20 % der Mitarbeitenden im technischen Bereich haben, während der Rest in mittleren Management-, Marketing- oder Vertriebsrollen arbeitet - und Entwickler wie code monkeys behandelt werden.
Interessant, ich habe von 2013 bis 2017 in einer Firma gearbeitet, die ähnliche Herausforderungen erlebt hat. Leider hatte diese Firma Schwierigkeiten, das richtige Personal im Bereich Programmierung zu finden, was zu weiteren Problemen führte. Besonders im Jahr 2016 kam es zu Spannungen zwischen den Abteilungen Marketing/Vertrieb und Entwicklung. Rückblickend habe ich ein besseres Verständnis dafür entwickelt, warum diese Situationen entstanden sind. Kurz gesagt, es ist wichtig, dass neue Teammitglieder, unabhängig von ihrem Hintergrund oder persönlichen Stil, gut in das bestehende Teamgefüge passen. Es ist entscheidend, dass die Unternehmensleitung darauf achtet, um solche Konflikte zu vermeiden
Die Übersicht bei 7:15 finde ich enorm hilfreich um einfach mal zu verstehen, für was die ganzen Bezeichnungen in Stellenbeschreibungen für Softwareentwickler steht.
Bei mir stand da bisher immer ein riesiges Fragezeichen, weil ich es gar nicht differenzieren konnte.
Als Normalsterblicher, der sonst noch nicht wirklich mit dieser Materie in Berührung gekommen ist, bin ich da wohl auch nicht alleine. :D
Wer seine Firma auf kurzfristigen Umsatz ausrichtet, bekommt Umsatz eben auch kurzfristig. Aber nicht länger. Entweder stellt er sein Unternehmenskonzept um, oder muss zum Seriengründer werden und rechtzeitig vor dem Desaster verkaufen.
Uiuiui, das ist das worst case scenario. Die Verantwortlichen haben sich nicht damit beschäftigt wie man gesund wächst. Im Grunde haben die ne Bugwelle von Versäumnissen im Produkt, in der Organisation und in den Prozessen aufgebaut. Die Entwickler wurden verheizt und allen Problemen ohne Struktur komplett ausgesetzt.
Es ist schwer zu beurteilen ob jeder da gekündigt hätte. Für mich hat das Kreuz immer 2 Balken, vereinfacht gesagt: Manager, die die Strukturfehler nicht sehen (wollen, können), und Entwickler, die zu spät lernen wie man nein sagt, und damit notwendige Diskussionen anstossen. Unternehmenskultur spielt auch eine riesige Rolle.
Super Video, ich teile alle dargestellten Problemansichten. Das passiert nicht nur in Startups. Auch alte Unternehmen tappen in die Falle, dort manifestiert sich das Problem oft schleichender, daher auch eher abwendbar.
Ich bin an einem Communityprojekt dran und tatsächlich ist der Fall sehr ähnlich was bei deinem Kunden der Fall ist. Man hat zwar Gedanken über die Architektur gemacht, aber es fehlt an Vision und auch die Rollenverteilung. Es ist zum Glück überwiegend nur Javascript. Aber ich erkenne keine konkret verwendete Version. Wahrscheinlich ist in der Entwicklungsteam/-gruppe nicht bekannt, dass bei JS ECMA 4, 5, 6 usw. gibt.
Zudem trägt eine Person zu viele Rollen, sodass es dazu führt, dass einige Aufgaben nicht richtig bewältigt werden können.
Hey,
das ist bei Communityprojekten nicht anders, da gelten dieselben Gesetze. Aber hier ist die Orga meist eher dezentral und deshalb ist das Thematisieren und Entscheiden hier meist schwieriger.
Gruß David
Gut! Läßt sich eins zu eins auf die Situation im deutschen Schulsystem übertragen. Jeder soll alles machen, keiner macht irgend etwas gut. Rollen/Verantwortlichkeiten werden erst gar nicht definiert. Prozesse sind zufällig. Qualitätsmanagement ist als Begriff unbekannt.
Dieses ganze Land ist auf Verwaltung nach militärischen Strukturen aufgebaut. Der ganze Dreck mit agilen Systemen und Co ist eine Utopie die an der Wirklichkeit vorbei geht und nur auf Zeit funktioniert. Wir sehen es halt überall, von Unternehmen bis zu staatlichen Stellen... Unflexible Dummheit und auch der größte Depp über dir lässt das Kartenhaus kippen... Genau das passiert nicht nur in diesem Land und nur an Orten, wo man neue Wege geht, weils geknallt hat, verändert sich auch was... Die Herrschaft der Doofen, die der Vernunft im Weg stehen, werden wir nicht mehr beenden.
Ich bin nicht in der Softwareentwicklung tätig, aber das Thema passt schon sehr gut auf meinen Bereich. Sowohl das Thema der korrekten Rollenverteilung (inkl. Auswahl der dafür fähigen Mitarbeitenden) als auch die klar Regelung von Verantwortlichkeiten, ist oftmals vom Unternehmen nicht sauber und klar Umgesetz. Das führt zu Problemen (es sind ab einem gewissen Punkt keine "Herausforderungen" mehr). Insbesondere, wenn nur auf die Kosten geblickt wird, Personal an allen Enden reduziert wird und jeder dauerhaft über der Belastungsgrenze arbeitet. Dann noch unklare Aufgaben, Rollen und fehlende Entscheidungskompetenzen bei (Line) Managern und nach einer gewissen Zeit stürzt das Kartenhaus zusammen.
Perfekt, klar und verständlich. Danke
Bis auf den Feel-Good Manager haben wir alle Positionen besetzt und es funktioniert bei uns recht gut. Die Unzufriedenheit bei den Kollegen stellt sich ein, weil die Abteilung sehr viel verdient und bei den Kollegen zu wenig ankommt.
Ganz hervorragende Präsentation.
Es stimmt zu 100%. Wenn Rollen dann auch nicht nach Fachkenntnisse und Fähigkeiten sondern nach dem nach der Nase reden Prinzip besetzt werden, geht alles zu 100% schief.
Wir haben keinen Architekt, Process Owner, Feelgood Manager, Support macht auch jeder und nur ein halben DevOps.
Ist genau so gestartet wie hier beschrieben - mit einem Entwickler (frisch von der Uni noch keine wirklich Ahnung was er tut). Dadurch sind viele der wichtigsten Komponenten kompletter murks, wurden aber so extrem oft schon benutzt, das die App zu abhängig von diesen Komponenten ist als das man sie einfach refactoren könnte.
Das beste ist: Der Wunsch des Teams ist sich MEHR anstatt weniger in eine Gruppe weiterzuentwickeln (also jeder soll in ein paar Bereichen tätig sein).
Das ganze läuft noch weil der Entwickler, der das ganze Projekt gestartet hat noch im Team ist und 70% der gesamten Tickets abwickelt. Falls der mal geht kann die Firma die App vergessen.
was mich brennend interessieren würde: wenn ein entwickler jahrelang mit komplett veralteter technologie und komplett veralteten prozessen gearbeitet hat -> wie schwer gestaltet sich der jobwechsel?
bedenkt man die schnelllebigkeit unserer branche, würde ich aus dem bauch heraus sagen, dass man unheimlich an marktwert verliert.
Bei uns gibt es keine QA. Das sollen die Entwickler grundsätzlich übernehmen, da gute Entwickler keine QA benötigen. Das ist tatsächlich genau das, was uns gesagt wird, täglich.
Nicht meine Branche aber sehr interessant. Das sehr stark auf irgendwelche Kennzahlen geachtet wird ohne das große und ganze im Blick zu haben gibt's denke ich Grundsätzlich überall 😅
Ersteinmal sind wir kein Softwareunternehmen, allerdings entwickeln sehr viele Mitarbeiter. Der Betrieb ist ein streng hierarchisches System, mit Manager die von Softwareentwicklung keine Ahnung haben. Irgendwann hat mal das Management beschlossen agil zu arbeiten, aber die agilen Werte werden nicht gelebt. Ein typischer Fehler ist, dass man Entwickler verbietet selbst zu testen, dafür gibt es ja ein Testteam. Die Entwickler wollen und müssen schnell Erfolge zeigen, deshalb fangen diese mit der Entwicklung an - obwohl es noch viele Anforderungslücken gibt. Das Problem ist häufig auch der Kunde. Da fehlt häufig die Bereitschaft aktiv am Entwicklungsprozess teilzunehmen. Die Kunden haben Angst davor, selbst Entscheidungen zu treffen und zögern extrem bei konkreten Fragen. Die ProductOwner raten deshalb mehr als dass sie etwas erfragen, und die entwickelten Teile sind praktisch nie zu Ende, weil man häufig Monate nach Beendigung von Softwareteilen bestehende Anforderungen anders interpretiert. Offiziell arbeiten wir agil aber in Wirklichkeit ist es das Gegenteil.
Es ist aber, wenn ich das richtig zwischen den Zeilen gelesen habe, eher für "kleinere" Unternehmen gemeint. Also das Konstrukt Team vs. Gruppe.
Es gibt ja, gerade bei größeren Unternehmen, auch oft die Konstellation, dass es mehrere Teams gibt, die jeweils ein Produkt oder mehrere Produkte betreuen, oder auch sogar mehrere Teams für ein Produkt.
Danke für das Video und die gute Herleitung!
Oft ist es zu viel unqualifiziertes Personal mit wenig Berufs- und/oder Technologieerfahrung. Diese schaffen es nicht Prozesse im Team zu etablieren, geschweige denn nach oben zu kommunizieren was eigentlich benötigt wird und wo der Fokus liegen sollte.
Die Probleme sind gar nicht mal den Leuten selbst anzulasten. Vielmehr der Einstellung des Unternehmens gegenüber der Anstellung geeigneten Personals. Warum auch einen erfahrenen High Performer mit Blick auf das Wesentliche, leider aber "unrealistischen Gehaltsvorstellungen" einstellen, wenn es für das gleiche Geld zwei Mitarbeiter gibt, die die Arbeit rechnerisch doppelt so schnell erledigen.
Mindestens genauso wichtig ist wie bereits im Video gut aufgezeigt die Übertragung von Rollen und Verantwortlichkeiten. Letzteres wird - oft genug erlebt - aufgrund von falsch verstandener Fehlerkultur im Unternehmen nicht gelebt. Das heißt Fehler werden nicht aufgearbeitet, niemand ist verantwortlich und es gibt kein wertvolles Lesson Learned.
Ein Arbeit für die Consulting Firmen ;) Change Management betreiben, Anforderung von der Kunde mit der Umsetzbaren vergleiche und reduzieren, und richtige Ergebnis nach Scrum pro Sprint liefern, klar in so einem komplexen System ohne Test is schwierig alle Anforderungen zu erfüllen, aber zumindest man hätte darauf eingegangen und verlangt und das Management hätte es verstanden, zwar die wären nicht zufrieden , das es so viel Arbeit , aber zumindest es wäre die richtige Entscheidung.
Ich denke nicht dass das oberste der Softwareentwicklung ist, viel Umsatz zu generieren. Das oberste Ziel sollte und ist es Bedarf zu befriedigen. So kann man eigentlich seine Ziele nicht aus den Augen verlieren. Umsatz fällt dann nebenbei ab.
Hey,
meine Reden, leider sitzen die Prioritäten oft anders verteilt. ABER: wie angesprochen ist es nicht immer der Umsatz, sondern oft auch fehlendes Wissen. Das ist leider genau so ein kritisches Thema wie die falschen Prioritäten.
Gruß David
"Verbessert nicht das Produkt, findet lieber dümmere Kunden"
Habe ich mal gelesen im Buch das Dilbert Prinzip von Adam Scott
Hallo David,
meine Erfahrung bei großen Unternehmen mit allen besetzten Rollen ist auch nicht anders. Es liegt alleine nicht die Fehlbesetzung.
Der Punkt ist nicht die Fehlbesetzung, sondern die Inkompetenz der Personen in SW-Entwicklung und -Architektur. Ich habe gesehen, wie unerfahrener Produkt Owner ein Team von Softwareentwicklung führte. Ich habe gesehen, wie ein Scrum-Master rumlabert und hauptsache die ganze Meetingreihe moderiert, ohne die Fortschritte nach jedem Sprint zu sachlich erkennen. Genauso, durfte ich auch die unfähigen SW-Entwicklern erleben, die nur beschweren und leeren Versprechen gibt. Das Problem aktuell ist, die Inkompetenz und das Besserwissen ohne die wirkliche Erfolgerfahrung.
Der Stakeholder mit dem Steak! Ich brech weg!
Absolut meine Erfahrung, obwohl wir SW nur für unseren eigenen Bedarf entwickeln und betreiben.
Wir entwickeln derzeit eine neue Anwendung um eine alte Access basierte Anwendung zu ersetzen. Auf Basis von React und Typescript, also eine Webanwendung mit allem drum und dran. Diese soll modern und Barrierefrei sein. Es gibt verschiedene Formulare sowie komplexe Fachlogik um Daten zu erfassen und zu bearbeiten. Der Clou, ein Kollege macht mit 20h Anforderungsmanagement und ich bin der einzige Entwickler mit 32h die Woche. Was soll schon schiefgehen.
Hallo David, das ist ein sehr gutes Video. Inhaltlich stimme ich dem voll und ganz zu. Der Kunde hat sich offenbar an euch gewandt, als es schon bereits zu spät war. Nachdem du weg warst, wird er gesagt haben, dass er den Laden eh gleich dicht machen kann, wenn er in den nächsten 8 Jahren 80% der Zeit für Refactorings aufwenden muss, da er das nicht finanzieren kann. Daraufhin haben die Entwickler gekündigt und er kann den Laden nun ebenfalls dicht machen.😄
Ich denke in dem beschriebenen Fall gibt es neben mangelnden Wissen wie so oft noch ein betriebswirtschaftliches Problem. Es wurden Kosten für die im Video genannten nicht besetzten Stellen und auch die Wartungskosten der Software nicht mit einkalkuliert. Für ein Feature, das implementiert wird, kann man gut noch mal 20% an jährlich anfallenden Kosten für Updates, Refactorings, Bugfixing, Betrieb, Support, etc. draufrechnen. Wenn man z.B. ein Feature implementiert, das 5 Personentage kostet, muss man 1 Personentag jährlich aufwenden, um die Software am Leben zu halten. Und da ist die Frage, wie man diese Kosten an den Kunden weitergibt. (Abomodell, Kunde zahlt für Updates, Servicepauschalen, etc.) Man kann in einer Softwarefirma diese Wartungskosten auch relativ lange (z.B. 15 Jahre) nach dem Schneeballprinzip querfinanzieren, in dem man auf einen wachsenden Markt setzt oder die Wartungskosten mit neuen Features finanziert, dessen Implementierung man sich individuell vom Kunden bezahlen lässt. Die Folge ist halt, dass sich die Schlinge über die Jahre immer enger zuzieht und die im Video genannten Probleme immer größer werden. In Firmenbilanzen werden die technischen Schulden sowieso nicht ausgewiesen, genauso wenig stellen die dort aufgeführten immateriellen Vermögenswerte den Aufwand dar, um die Software neu zu entwickeln. Von daher kann sich ein Management jahrelang von vermeintlich guten Umsatzzahlen blenden lassen, obwohl die Firma eigentlich schon längst formal pleite ist, nur eben noch nicht im rechtlichen Sinne.
Die eigentlichen Fehler wurden dann vom Management schon viel früher gemacht. Wenn man eine Produktvision hat, sollte man sich auch fragen, ob man das Softwareprodukt an einen ausreichend großen Kundenkreis verkaufen kann und ob dabei genügend hohe Margen erzielt werden können, um es langfristig zu finanzieren. Der Kunde kauft ja letztendlich das Produkt, da er Geld damit sparen will und sich einen Vorteil verspricht. (Wertschöpfung der Software) Steht das investierte Geld, im Vergleich zum gesparten Geld in einem Missverhältnis, wird er das Produkt nicht kaufen. Es gibt auch genügend Geschäftsmodelle, die sich auf dem Markt einfach nicht rentieren.
VB6 , sind die noch auf 32bit windows unterwegs? (Alle hacker dieser welt kichern)
Prozesse sind sehr wichtig und wird bei uns auch gemacht. QA fehlt leider, und Produkt fehlt etwas Technik-Kompetenz.
Ansonsten hab ich schon öfter mal altes Produkte weggeworfen und neu implementiert (von der Datenbank aufwärts). Erstaunlich was man dabei alles für alten Müll findet, den man garnicht braucht, nur weil ein Coder sich ein neues Buch über Software-Architektur gekauft hatte (Hast du einen Hammer sieht alles wie ein Nagel aus)
Du wärst überrascht in wie vielen Softwareprodukten noch alter VB Code steckt, den bekommt man oft so schnell auch nicht weg... :D
Gruß David
Wir haben exakt die beschriebene Gruppensituation. Es geht um ein Softarepaket dessen älteste Komponenten bald 35 Jahre alt sind. Entwickelt wurde in 4 Sprachen und diversen Versionen. Habe selbst mehrere Burnout-Phasen hinter mir, wußte nur lange nicht, dass es Burnout ist. Bin in vielen Bereichen der Einzge, der überhaupt über die nötigen Kenntnisse verfügt. Es gibt keine Strukturen und entwickelt wird nach jeweiligem Gusto. Und auch bei uns wurde zuletzt eher mehr in Marketing investiert. Kündigen ist für mich allerdings nicht so einfach. Strukturschwache Region, alleinerziehend und in der Mobilität eingeschränkt. Das wird natürlich weidlich ausgenutzt.
Dann schaff dir nach und nach eine neue Perspektive um für Firmen im Homeoffice zu arbeiten. Es gibt genug Angebote und du musst ja nicht sofort kündigen. Ich hasse Burn out und hatte das auch schon oft genug. Dachte damals ich bin einfach nur depressiv, aber neee...
Erstmal danke für das tolle Video. Mir fiel aber die Kinnlade runter bei der Aussicht auf 8 Jahre refactoring mit 80% Auslastung darauf. Da dreht sich doch bei jedem Geschäftsmann der Magen um. Ganz schön bitterer Apfel