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. :)
@@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
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..."
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 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.
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.
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.
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."
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.
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 :/
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 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.
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.
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 🎉
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 :-)
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.
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.
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.
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.
My life. Aber sowas von. Zum Glück arbeite ich nicht länger für meine bisherigen Arbeitgeber, die allesamt genau Ihren geschilderten Kunden geklont haben.
Kleiner Witz am Rande - in der Coronazeit wurden eine Vielzahl an VPN Loesungen etabliert. Bei einem Kunden wurde ein externer Dienstleister damit beauftragt dieses VPN einzurichten: Kostenpunkt 11.000 Euro netto fuer die Einrichtung und monatlich 12.000 Euro Betrieb. Es fiel auf, als wir nur 0,5 MBit/s an Leistung erhielten und gesagt bekamen dies sei bei dem Preis die einzige garantierte Leistung und ja auch noch andere Kunden das VPN nutzen wuerden. Bei den Entwicklerlaptops wurde natuerlich gespart - so 500 Euro Schrott - das gab dann Aerger, bis der Chef mal fuer die Gruppe 2.000 Euro Laptops gekauft hatte. Fazit: Im Jahr wurden ca 132.000 Euro zum Fenster rausgeworfen. Die Laptops haben pro Jahr nur 15.000 Euro an Mehrkosten verursacht. Letztendlich ist es eben gutes Marketing und Ausnutzung von Unwissenheit, mit dem Geschaefte gemacht wird.
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.
Im Konzern hat man schon den Idealfall. Ich arbeite bei einem großen Automobilhersteller und da haben wir jede Rolle ausgefüllt. Aber ja, kommt nicht überall vor :D
Diese Umsatzbesessenheit nervt mich schon lange. Legte man den Fokus wieder mehr darauf, ein ordentliches Produkt abzuliefern, würde sich vieles von alleine erledigen. Eigentlich ist es auch Profitbesessenheit.
Ich glaube ein Problem ist, wenn man sagt "80% refactoring für acht Jahre", das ist für den Kunden schwer zum schlucken, denn für Kunden heißt entweder fünffache Teamgröße (versucht, 40 neue Entwickler einfach so zu finden) oder auf 80% des Umsatzes verzichten, was auch für den Kunden das Aus bedeutet hätte. Das hat wahrscheinlich dazu geführt, das der Kunde das Paket als ganzes abgelehnt hat, inklusiv alle anderen nicht so teueren Veränderungen. Persönlich war ich noch nie in einem Projekt, das man wirklich 80% Refactoring gebraucht hätte, egal wie schlimm, und perspektivisch würde nie langfristig nie mehr als 50% der Entwicklungszeit "Refactoring" einstecken, man verliert sonst die Perspektive. Und "acht Jahre langes refactoring", das man kann wirklich nicht wissen, wie lange man für ein Refactoring braucht. Ob ein "konservativerer" Vorschlag eher angenommen wäre, und ausreichend gewesen wäre, um die Entwickler zu behalten, kann man nie wissen. Auf jeden Fall ist ein Software Unternehmen mit zehn Entwicklern und 55 "andere" total falsch aufgestellt. Aber: Es ist herrst auch nicht in jedem Unternehmen so ein Chaos, das ist nicht der Standard in Deutschland, ich habe in viele Unternehmen gearbeitet, wo es wesentlich entspannter ist.
es werden unzählige Unternehmen so 'geführt' - der Markt bereinigt so etwas. Insolvenz! Aber bis dahin: Angestellte nicht so dolle, Management hat Haus abbezahlt 🤓 so isses, was es und wird es immer sein
Umsatz ist gut, Gewinn ist besser. Man müsste mal beleuchten, wie die Situation aus betriebswirtschaftlicher Sicht gesehen wird. Funktionierenden Code neu zu schreiben bringt kurzfristig keinen erkennbaren Vorteil, kann aber auf Dauer die Weiterentwicklung bremsen.
Komme aus dem Handwerk und bei uns auch echt der Brüller von oben. Viel Arbeit, kaum Leute und dann wurde wieder ein neuer Außendienstmitarbeiter eingestellt, weil ja so wenig Arbeit.
Schön umrissen. Aber ein paar Sachen fehlen. Es gibt ja nicht nur die Rollern in der Software-Entwicklung, sondern auch die "menschlichen" Rollen im Team. Also z.B. nach Meredith Belbin. Und, wenn man dann nach diesen Rollen Erfinder, Beobachter und Perfektionist ist, also alles auch eher nicht Umsatz optimierend, dann hat man schon von daher Probleme. Ein anderes Problem kam mit der Erwähnung von VB 6.0 zur Sprache: Tote Pferde. Das Wissen, bzw. die Business Logik steckt im Code und kann nur sehr schwer vom "toten Pferd" auf ein junges Pferd portiert werden und darum werden tote Pferde geritten und geritten. Man könnte nach dem Ende fast aller Märchen sagen ... und, wenn sie nicht gestorben sind, dann werden sie heute noch geritten. ... Aber erkenne den Widerspruch. Was ich damit sagen will ist, dass man nicht zum frühest möglichen Zeitpunkt umsteigt, sondern zum Letzt möglichen oder diesen gar verpasst. Dabei ist klar, je früher desto Kosten günstiger.
Fakt ist aber, dass ohne VB6-Anwendungen ein nicht unerheblicher Teil unserer gesamten IT-Welt zusammenbrechen würde. Nicht ohne Grund hat Microsoft den Runtime-Support bis zum "Lebensende" von Windows 11 verlängert. Und, JA, auch ich habe das Problem, dass bei jeder Erweiterung von bestehender Software mein Hinweis darauf, dass es sinnfrei ist, an der alten Technologie weiter rumzuschrauben, überhört wird, weil die Umsetzung in einer aktuelleren Technologie zeit- und somit meist auch kostenaufwendiger wäre. Also reitet man den alten Gaul weiter - stellt ihm bestenfalls für kleinere Problemlösungen das ein oder andere "Pony" zu Seite. Ein Projekt (Produkt), dass teils über Jahrzehnte gewachsen ist, schreibt man nun mal nicht von heute auf morgen neu - nicht mal partiell. Und schon gar nicht mit Entwicklern, die deutlich näher an der Rente als an der Ausbildungszeit stehen.
Ich kenne das zu gut, das Management spart an der falschen Stelle - wird nicht gemacht weil zu viel Aufwand. Dabei sind die Opportunitätskosten immens und das mag auch an der Unwissenheit über gute Entwicklungsprozesse liegen... die Softwareentwicklung wird wohl oft unterschätzt und als leicht hingenommen oder sich nicht ausreichend qualifiziert oder beraten. Oder man hört halt nicht auf den Berater und dann sind die Entwickler wie hier auch weg
Hey, ja absolut - das Problem des "Unterschätzen" ist leider wirklich gewaltig und solches Wissen bei Entscheidern anzusiedeln ist halt auch nicht einfach, weil es da ja sooo viel wichtigere Dinge gibt. Gruß David
Also ich weiß nicht so recht, aber ich finde die Entwicklung heute wesentlich komplexer als früher. Wenn ich heute die gleiche Software von vor 15 Jahren mit den heutigen Techniken und dem gleichen Funktionsumfang noch neu entwickeln müsste, würde ich die Software nicht fertig bekommen und wäre pleite. Zu viel Infrastruktur Komplexität, zu viel JS Library Komplexität, die vielen UI Frameworks, microservice Orchestrierung, kostenpflichtige cloud tools etc. etc. Ja, man veraltet technisch, aber ich könnte locker alle Anforderungen in der halben Zeit umsetzen und der Kunde wäre glücklich. Vielleicht kann man auch Technologien überspringen (siehe Java EJBs) und auf eine bessere Sau im Dorf warten. 😂
Ich war mal in einem Startup als Mitgründer und ich war der einzige Entwickler für das Produkt neben zwei BWLern die meinten sie seien die großen Macher und würden so hart arbeiten (aber haben sich geweigert ihren gemeinsamen Kalender offenzulegen um das nachzuweisen) und einer der BWLer meinte er braucht als CEO mindestens 51% Firmenanteile..😅 Das war der Moment wo ich ausgestiegen bin und der CEO meinte dann alles wäre seine Idee gewesen und der ganze Code den ich als Prototyp geschrieben habe gehöre ihm und er hätte einen Doktoranden am Start der mich ersetzen könnte..🤣 Ich hätte zu gern gesehn wie der angebliche Doktorand meinen sicherheitskritischen real-time C-code weiterentwickelt, aber seltsamerweise hat sich das Startup dann einfach aufgelößt..🤔
Das Management schafft sich seine eigenen Stellen mit dem ganzen agil-scrum-UML-Gaga und die Entwickler müssen den Rest erledigen. Ich habe meine Projekte *allein* und ohne diesen ganzen Unfug programmiert. Benutzerfreundliches Frontend, Backend/Datenbanken. Geht komischerweise... Achja, und funktionieren tut meine Software auch noch, weil ich *immer* erst teste und Fehler ausmerze, statt neue Features reinzuballern.
Junge Junge Junge, das mit dem gescheiten Verpacken von Wissen hast du aber voll raus. Ich wollte mir das Video eigentlich als Hintergrundrauschem beim Essen anschalten. Jetzt ist mein Essen kalt und ich hab Bock dir weiter zuzuhören.❤
Klingt teilweise sehr vertraut, auch, dass Entwickler dann irgendwann das weite suchen. Oder um es mal zu Zitieren mit einer Aussage einer Mail welche ich mal von einer Geschäftsführung erhalten habe: "Du verbrennst da mein Geld! MEINS ! ! !"
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)
Meiner Erfahrung nach bringt ein "Refactoring" bei einer sehr komplexen, vielschichtigen Anwendung mit verschiedenen Technologieplattformen gar nichts bzw. ist unmöglich! Der bessere Ansatz ist eine komplette Neuentwicklung. Das bisherige Team macht nur noch Bugfixes und absolut notwendige Implementierungen an der alten Software. Wer irgendwie verfügbar ist, unterstützt das neue Team, welches die neue Software entwickelt. Das neue Team konzentriert sich dabei nur auf die neue Software, natürlich unter Anleitung und ggf. Mitwirkung der erfahrenen Entwickler aus dem alten Projekt. Das auf 8 Jahre auslzulegen ist auch realitätsfern, 3 Jahre sollte ein realistisches Ziel sein, mit ersten Prototypen nach einem Jahr und teilweise schon verwendbaren bzw. funktionalen Ständen nach dem zweiten. Natürlich muss klar kommuniziert werden, dass an der alten Software nur noch das Nötigste gemacht wird. Im Dialog mit Kunden können zum Ausgleich aber in der neuen Software bereits stark nachgefragte Features implementiert werden. Das kann z.B. auch einfach eine deutliche Performance-Verbesserung bei bestimmten Modulen sein, die man bisher nicht auf dem Schirm hatte, etwa weil der Kunde viel größere Datenmengen hat und erst dann ernsthafte Probleme auftreten. Erkennbarer Fortschritt, etwa in Form von kleinen Demonstrationen oder Präsentation einen besseren Benutzoberfläche, idealerweise basierend auf Feedback von Anwender, können sich während der Zeit der Neuentwicklung dabei sehr positiv auf die Geduld des Kunden auswirken. Die Kosten für ein solches Projekt müssen natürlich kalkuliert werden und sind nicht zu unterschätzen, es sollte mit wenigstens 50% Aufstockung der Entwicklungskapazität kaluliert werden. Wenn die Mittel aber prinzipiell verfügbar sind, dann ist die Kündigung eines ganzen Entwicklerteams aber zu 99% nicht auf fehlende Rollenbesetzungen, sondern auf menschliche Konflikte zurückzuführen, denn technische und organistatorische Probleme sind i.d.R. lösbar. Fehlt es aber an gegenseitigem Respekt, gibt es Kompetenzgerangel oder werden Entscheidungen aus emotionalen statt rationalen Gründen getroffen, dann ist eine Eskalation unvermeidlich. P.S. Das alte und das neue Team stehen natürlich nicht in Konkurenz zu einander, viel mehr findet ein fachlicher Wissenstransfer vom alten an das neuen Team statt und das neue Team bringt zwingend Experise für die anvisierte Technologieplattform mit. Nach Ende des Projekts werden dann beide Teams zusammengeführt. Meist scheiden dabei planmäßig aus beiden Teams Mitglieder aus, etwa weil ältere Mitarbeiter in Rente gehen und jüngere Mitarbeiter nach den 3 Jahren etwas anderes tun wollen. Somit sollte das am Ende auch passen und die Entwicklungskapazität wieder reduziert werden können.
Wenn ein Unternehmen im Jahr 2024 noch keine einfache CI-Pipeline hat, dann soll es einfach untergehen. Das ist doch mit aktuellen Tools innerhalb weniger Tage zumindest in Grundzügen erledigt.
@@FilmfanOliver1992 Sofern man nicht so völlig am Ende ist, dass die Alternativen in Richtung Psychatrie gehen, sucht man sich erst einen neuen Job und kündigt dann den alten. Das bedeutet natürlich auch, dass der alte AG keine Möglichkeit zum Nachverhandeln hat. Der AN hat ja schon beim neuen AG unterschrieben.
Wäre da das VB6 nicht, würde ich glatt sagen, in der Firma hab ich vor ein paar Jahren mal gearbeitet. Vielleicht weiß ich aber auch einfach nichts von diesem uralten VB6-Kern, ich hab's da nur ein Jahr ausgehalten.
Hey, ich kenne die Mitarbeiterhistorie recht gut, ich vermute Du warst nicht dabei... :D Der VB6 Code ist auch recht offensichtlich, es sei denn Du hast Frontend gemacht :D Gruß David
Ich kann die Entwickler verstehen, aber auch die Geschäftführung. Rollen zu besetzen kostet Geld, es ist eine Investition die sich auf lange Zeit auszahlt. Die auf den ersten Blick als eine Geldverschwendung aussieht. Und ich denke, die Geschäftsführung hat sich gedacht, das dauert uns zu lange, bis es besser wird und sind zu dem alten Muster zurück gekehrt
Aus meiner Erfahrung ist sehr viel Unwissenheit. Es ist ja der natürliche Prozess, dass man erstmal etwas entwickelt und verkauft. Aber spätestens mit deiner Beauftragung zählt das Argument ja nicht mehr. Ich arbeite in der Anlagenautomation und dort wird quasi nur Implementierung, deployment und Support gemacht. Die Anforderung ist ein Schaltplan und ein Fließbild 😂 und "Anlage muss laufen". Fortbildung ist aus meiner Sicht der erste Schritt in die richtige Richtung. Aber aus Management Sicht ist es ja nicht notwendig solange alles "läuft". Es mindert ja nur den Gewinn
@@DavidTielke naja, wenn es genug Entwickler gibt, dass diese ihr Aufgabenspektrum erweitern können und trotzdem die Entwicklung nicht vernachlässigen müssen, geht es ja auch gut - wird eben leider oft nicht gemacht, wie du im Video auch gut beschreibst :)
Mangel an billigen Arbeitskräften die sich ausbeuten lassen! Man soll Senior sein, aber bitte nur das Einstiegsgehalt eines Fachinformatikers verlangen... Wenn nicht müssen die anderen Mitarbeiter halt mehr Arbeit leisten und bekommen natürlich keinen Bonus oder Gehaltserhöhung.
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...
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
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!
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
>"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.
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.
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.
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.
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.
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.
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.
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!' ...
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
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.
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.
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...
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.
Wenn 9 gehen und 50 davon abhängig sind läuft eindeutig etwas falsch, vielleicht hätte lieber mehr Entwickler als Feel Good und Marketing leute einstellen sollen. Also so ein gedusel wie einen Feel Good Manager würde ich eher als Grund sehen für schwach sinn, gerade im Bereich People erleben wir ein Over Managment, und irgendwann wird auch dem dümmsten Entwickler klar das solche Leute nicht nur auf die Nerven gehen sondern einem die kosten auch noch quasi direkt vom Gehalt abgezogen werden. Das sind doch nur Menschen die von Technik keine Ahnung haben und von dem Werten leben wollen die andere erschaffen.
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.
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!!!!🥰😍
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.
Hey Christopher, guter Punkt, ich habe es mit zu den Anforderungen / Support gezählt, aber hätte man auch getrennt erwähnen können. Danke für das Feedback! Gruß David
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 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.
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.
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 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
Du hast den Begriff der Idee und der Vision in der Mitte des Viedos vertauscht... am Anfang stand noch die Vision am start des Prozesses, später dann Idee. ;)
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.
Prinzipiell bin ich bei dir, aber eine Blaupause für den Erfolg ist eine Teambildung mit Rollenbesetzung nicht. Ich nenne es mal Legacy, also Software, die im Grunde auch nach /dev/null verschoben werden könnte und immense Entwicklungskosten hatte. Natürlich möchte der Shareholder die Wahrheit nicht hören und das Management stellt alles immer auch als machbar dar. Hohe Fluktuation der "Indianer", festhalten an wirren Strukturen, da ein notwendiges Refactoring dem Shareholder nicht zugemutet werden kann. Und das Management, das eben Management ist, und nunmal keine Eier die Wahrheit auf den Tisch zu legen. Das was Entwickler sagen muss man ja nicht ganz so ernst nehmen. Ich selbst hätte fast mal gekündigt, da ich in ein solches (in Shareholder feuchten Träumen süßes) Produkt zwangsversetzt wurde. Die Firma ging rechtzeitig pleite, wurde aufgekauft, ich wanderte zurück in mein altes Team, und alles war wieder gut. :)
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.
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!
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,
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.
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 😞
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 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
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 😁
![[Limbus Company - Teaser] Season5 - Oblivion](http://i.ytimg.com/vi/8anKuEeZLeI/mqdefault.jpg)
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. :)
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
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..."
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"
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.
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.
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.
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.
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."
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.
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 :/
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 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.
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.
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? 😂
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 :-)
Schön dass bei dem Stakeholder ein Steak dabei ist ;D
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.
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.
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.
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.
My life. Aber sowas von. Zum Glück arbeite ich nicht länger für meine bisherigen Arbeitgeber, die allesamt genau Ihren geschilderten Kunden geklont haben.
Kleiner Witz am Rande - in der Coronazeit wurden eine Vielzahl an VPN Loesungen etabliert. Bei einem Kunden wurde ein externer Dienstleister damit beauftragt dieses VPN einzurichten: Kostenpunkt 11.000 Euro netto fuer die Einrichtung und monatlich 12.000 Euro Betrieb. Es fiel auf, als wir nur 0,5 MBit/s an Leistung erhielten und gesagt bekamen dies sei bei dem Preis die einzige garantierte Leistung und ja auch noch andere Kunden das VPN nutzen wuerden. Bei den Entwicklerlaptops wurde natuerlich gespart - so 500 Euro Schrott - das gab dann Aerger, bis der Chef mal fuer die Gruppe 2.000 Euro Laptops gekauft hatte.
Fazit: Im Jahr wurden ca 132.000 Euro zum Fenster rausgeworfen. Die Laptops haben pro Jahr nur 15.000 Euro an Mehrkosten verursacht.
Letztendlich ist es eben gutes Marketing und Ausnutzung von Unwissenheit, mit dem Geschaefte gemacht wird.
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.
Der Stakeholder mit dem Steak! Ich brech weg!
Absolut meine Erfahrung, obwohl wir SW nur für unseren eigenen Bedarf entwickeln und betreiben.
Im Konzern hat man schon den Idealfall. Ich arbeite bei einem großen Automobilhersteller und da haben wir jede Rolle ausgefüllt. Aber ja, kommt nicht überall vor :D
Diese Umsatzbesessenheit nervt mich schon lange. Legte man den Fokus wieder mehr darauf, ein ordentliches Produkt abzuliefern, würde sich vieles von alleine erledigen. Eigentlich ist es auch Profitbesessenheit.
Ich glaube ein Problem ist, wenn man sagt "80% refactoring für acht Jahre", das ist für den Kunden schwer zum schlucken, denn für Kunden heißt entweder fünffache Teamgröße (versucht, 40 neue Entwickler einfach so zu finden) oder auf 80% des Umsatzes verzichten, was auch für den Kunden das Aus bedeutet hätte. Das hat wahrscheinlich dazu geführt, das der Kunde das Paket als ganzes abgelehnt hat, inklusiv alle anderen nicht so teueren Veränderungen.
Persönlich war ich noch nie in einem Projekt, das man wirklich 80% Refactoring gebraucht hätte, egal wie schlimm, und perspektivisch würde nie langfristig nie mehr als 50% der Entwicklungszeit "Refactoring" einstecken, man verliert sonst die Perspektive. Und "acht Jahre langes refactoring", das man kann wirklich nicht wissen, wie lange man für ein Refactoring braucht. Ob ein "konservativerer" Vorschlag eher angenommen wäre, und ausreichend gewesen wäre, um die Entwickler zu behalten, kann man nie wissen. Auf jeden Fall ist ein Software Unternehmen mit zehn Entwicklern und 55 "andere" total falsch aufgestellt.
Aber: Es ist herrst auch nicht in jedem Unternehmen so ein Chaos, das ist nicht der Standard in Deutschland, ich habe in viele Unternehmen gearbeitet, wo es wesentlich entspannter ist.
Ich denke, es war gemeint, dass innerhalb von 8 Jahren 80% der bestehenden Software refactored wird. Das wäre machbar. Man muss es aber anfangen.
Ich finde es immer wichtig eine eigene abteilung für ein projekt zu haben die nur für Qualitätsanforderungen zuständig ist
es werden unzählige Unternehmen so 'geführt' - der Markt bereinigt so etwas. Insolvenz! Aber bis dahin: Angestellte nicht so dolle, Management hat Haus abbezahlt 🤓 so isses, was es und wird es immer sein
Umsatz ist gut, Gewinn ist besser. Man müsste mal beleuchten, wie die Situation aus betriebswirtschaftlicher Sicht gesehen wird. Funktionierenden Code neu zu schreiben bringt kurzfristig keinen erkennbaren Vorteil, kann aber auf Dauer die Weiterentwicklung bremsen.
Ich gucke nur noch in Open Source Projekte rein. Da erledigen sich viele Probleme die das Proprietäre mit sich bringt zwangsläufig von selbst.
Hey,
das kommt darauf an, gibt auch einige Tätigkeiten (Architektur beispielsweise) die da auch relevant sind.
Gruß David
Komme aus dem Handwerk und bei uns auch echt der Brüller von oben. Viel Arbeit, kaum Leute und dann wurde wieder ein neuer Außendienstmitarbeiter eingestellt, weil ja so wenig Arbeit.
Schön umrissen. Aber ein paar Sachen fehlen. Es gibt ja nicht nur die Rollern in der Software-Entwicklung, sondern auch die "menschlichen" Rollen im Team. Also z.B. nach Meredith Belbin. Und, wenn man dann nach diesen Rollen Erfinder, Beobachter und Perfektionist ist, also alles auch eher nicht Umsatz optimierend, dann hat man schon von daher Probleme.
Ein anderes Problem kam mit der Erwähnung von VB 6.0 zur Sprache: Tote Pferde. Das Wissen, bzw. die Business Logik steckt im Code und kann nur sehr schwer vom "toten Pferd" auf ein junges Pferd portiert werden und darum werden tote Pferde geritten und geritten. Man könnte nach dem Ende fast aller Märchen sagen ... und, wenn sie nicht gestorben sind, dann werden sie heute noch geritten. ... Aber erkenne den Widerspruch. Was ich damit sagen will ist, dass man nicht zum frühest möglichen Zeitpunkt umsteigt, sondern zum Letzt möglichen oder diesen gar verpasst. Dabei ist klar, je früher desto Kosten günstiger.
Fakt ist aber, dass ohne VB6-Anwendungen ein nicht unerheblicher Teil unserer gesamten IT-Welt zusammenbrechen würde. Nicht ohne Grund hat Microsoft den Runtime-Support bis zum "Lebensende" von Windows 11 verlängert. Und, JA, auch ich habe das Problem, dass bei jeder Erweiterung von bestehender Software mein Hinweis darauf, dass es sinnfrei ist, an der alten Technologie weiter rumzuschrauben, überhört wird, weil die Umsetzung in einer aktuelleren Technologie zeit- und somit meist auch kostenaufwendiger wäre. Also reitet man den alten Gaul weiter - stellt ihm bestenfalls für kleinere Problemlösungen das ein oder andere "Pony" zu Seite.
Ein Projekt (Produkt), dass teils über Jahrzehnte gewachsen ist, schreibt man nun mal nicht von heute auf morgen neu - nicht mal partiell. Und schon gar nicht mit Entwicklern, die deutlich näher an der Rente als an der Ausbildungszeit stehen.
Ich kenne das zu gut, das Management spart an der falschen Stelle - wird nicht gemacht weil zu viel Aufwand. Dabei sind die Opportunitätskosten immens und das mag auch an der Unwissenheit über gute Entwicklungsprozesse liegen... die Softwareentwicklung wird wohl oft unterschätzt und als leicht hingenommen oder sich nicht ausreichend qualifiziert oder beraten. Oder man hört halt nicht auf den Berater und dann sind die Entwickler wie hier auch weg
Hey,
ja absolut - das Problem des "Unterschätzen" ist leider wirklich gewaltig und solches Wissen bei Entscheidern anzusiedeln ist halt auch nicht einfach, weil es da ja sooo viel wichtigere Dinge gibt.
Gruß David
HA! Jemand der das Wort Opportunitätskosten in den Mund nimmt, sollte sofort eine Lohnerhöhung bekommen!
Also ich weiß nicht so recht, aber ich finde die Entwicklung heute wesentlich komplexer als früher. Wenn ich heute die gleiche Software von vor 15 Jahren mit den heutigen Techniken und dem gleichen Funktionsumfang noch neu entwickeln müsste, würde ich die Software nicht fertig bekommen und wäre pleite. Zu viel Infrastruktur Komplexität, zu viel JS Library Komplexität, die vielen UI Frameworks, microservice Orchestrierung, kostenpflichtige cloud tools etc. etc. Ja, man veraltet technisch, aber ich könnte locker alle Anforderungen in der halben Zeit umsetzen und der Kunde wäre glücklich. Vielleicht kann man auch Technologien überspringen (siehe Java EJBs) und auf eine bessere Sau im Dorf warten. 😂
Ich war mal in einem Startup als Mitgründer und ich war der einzige Entwickler für das Produkt neben zwei BWLern die meinten sie seien die großen Macher und würden so hart arbeiten (aber haben sich geweigert ihren gemeinsamen Kalender offenzulegen um das nachzuweisen) und einer der BWLer meinte er braucht als CEO mindestens 51% Firmenanteile..😅
Das war der Moment wo ich ausgestiegen bin und der CEO meinte dann alles wäre seine Idee gewesen und der ganze Code den ich als Prototyp geschrieben habe gehöre ihm und er hätte einen Doktoranden am Start der mich ersetzen könnte..🤣
Ich hätte zu gern gesehn wie der angebliche Doktorand meinen sicherheitskritischen real-time C-code weiterentwickelt, aber seltsamerweise hat sich das Startup dann einfach aufgelößt..🤔
RIchtig so, nicht ausbeuten lassen als DEV. Wir müssen immer die Scheiße von den anderen ausbaden aber der Lob landet dann oft woanders...
Das Management schafft sich seine eigenen Stellen mit dem ganzen agil-scrum-UML-Gaga und die Entwickler müssen den Rest erledigen. Ich habe meine Projekte *allein* und ohne diesen ganzen Unfug programmiert. Benutzerfreundliches Frontend, Backend/Datenbanken. Geht komischerweise...
Achja, und funktionieren tut meine Software auch noch, weil ich *immer* erst teste und Fehler ausmerze, statt neue Features reinzuballern.
Leider gibt es genau diese Probleme nicht nur in der Softwareentwicklung.
Was für ein starkes Video 👍👍
Junge Junge Junge, das mit dem gescheiten Verpacken von Wissen hast du aber voll raus.
Ich wollte mir das Video eigentlich als Hintergrundrauschem beim Essen anschalten.
Jetzt ist mein Essen kalt und ich hab Bock dir weiter zuzuhören.❤
Klingt teilweise sehr vertraut, auch, dass Entwickler dann irgendwann das weite suchen.
Oder um es mal zu Zitieren mit einer Aussage einer Mail welche ich mal von einer Geschäftsführung erhalten habe: "Du verbrennst da mein Geld! MEINS ! ! !"
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
Meiner Erfahrung nach bringt ein "Refactoring" bei einer sehr komplexen, vielschichtigen Anwendung mit verschiedenen Technologieplattformen gar nichts bzw. ist unmöglich! Der bessere Ansatz ist eine komplette Neuentwicklung. Das bisherige Team macht nur noch Bugfixes und absolut notwendige Implementierungen an der alten Software. Wer irgendwie verfügbar ist, unterstützt das neue Team, welches die neue Software entwickelt. Das neue Team konzentriert sich dabei nur auf die neue Software, natürlich unter Anleitung und ggf. Mitwirkung der erfahrenen Entwickler aus dem alten Projekt. Das auf 8 Jahre auslzulegen ist auch realitätsfern, 3 Jahre sollte ein realistisches Ziel sein, mit ersten Prototypen nach einem Jahr und teilweise schon verwendbaren bzw. funktionalen Ständen nach dem zweiten. Natürlich muss klar kommuniziert werden, dass an der alten Software nur noch das Nötigste gemacht wird. Im Dialog mit Kunden können zum Ausgleich aber in der neuen Software bereits stark nachgefragte Features implementiert werden. Das kann z.B. auch einfach eine deutliche Performance-Verbesserung bei bestimmten Modulen sein, die man bisher nicht auf dem Schirm hatte, etwa weil der Kunde viel größere Datenmengen hat und erst dann ernsthafte Probleme auftreten. Erkennbarer Fortschritt, etwa in Form von kleinen Demonstrationen oder Präsentation einen besseren Benutzoberfläche, idealerweise basierend auf Feedback von Anwender, können sich während der Zeit der Neuentwicklung dabei sehr positiv auf die Geduld des Kunden auswirken. Die Kosten für ein solches Projekt müssen natürlich kalkuliert werden und sind nicht zu unterschätzen, es sollte mit wenigstens 50% Aufstockung der Entwicklungskapazität kaluliert werden. Wenn die Mittel aber prinzipiell verfügbar sind, dann ist die Kündigung eines ganzen Entwicklerteams aber zu 99% nicht auf fehlende Rollenbesetzungen, sondern auf menschliche Konflikte zurückzuführen, denn technische und organistatorische Probleme sind i.d.R. lösbar. Fehlt es aber an gegenseitigem Respekt, gibt es Kompetenzgerangel oder werden Entscheidungen aus emotionalen statt rationalen Gründen getroffen, dann ist eine Eskalation unvermeidlich.
P.S. Das alte und das neue Team stehen natürlich nicht in Konkurenz zu einander, viel mehr findet ein fachlicher Wissenstransfer vom alten an das neuen Team statt und das neue Team bringt zwingend Experise für die anvisierte Technologieplattform mit. Nach Ende des Projekts werden dann beide Teams zusammengeführt. Meist scheiden dabei planmäßig aus beiden Teams Mitglieder aus, etwa weil ältere Mitarbeiter in Rente gehen und jüngere Mitarbeiter nach den 3 Jahren etwas anderes tun wollen. Somit sollte das am Ende auch passen und die Entwicklungskapazität wieder reduziert werden können.
Wenn ein Unternehmen im Jahr 2024 noch keine einfache CI-Pipeline hat, dann soll es einfach untergehen. Das ist doch mit aktuellen Tools innerhalb weniger Tage zumindest in Grundzügen erledigt.
Kündigen ist nur gut wenn auch was neues hat. Sonst bekommt man ein Problem mit dem Jobcenter
Hey,
ja das ist richtig, war aber hier schon alles erledigt :)
Gruß David
@@DavidTielke Die Sanktionen bei Job-kündigung können hart sein.
@@FilmfanOliver1992 Sofern man nicht so völlig am Ende ist, dass die Alternativen in Richtung Psychatrie gehen, sucht man sich erst einen neuen Job und kündigt dann den alten. Das bedeutet natürlich auch, dass der alte AG keine Möglichkeit zum Nachverhandeln hat. Der AN hat ja schon beim neuen AG unterschrieben.
Wäre da das VB6 nicht, würde ich glatt sagen, in der Firma hab ich vor ein paar Jahren mal gearbeitet.
Vielleicht weiß ich aber auch einfach nichts von diesem uralten VB6-Kern, ich hab's da nur ein Jahr ausgehalten.
Hey,
ich kenne die Mitarbeiterhistorie recht gut, ich vermute Du warst nicht dabei... :D Der VB6 Code ist auch recht offensichtlich, es sei denn Du hast Frontend gemacht :D
Gruß David
Ich kann die Entwickler verstehen, aber auch die Geschäftführung. Rollen zu besetzen kostet Geld, es ist eine Investition die sich auf lange Zeit auszahlt. Die auf den ersten Blick als eine Geldverschwendung aussieht. Und ich denke, die Geschäftsführung hat sich gedacht, das dauert uns zu lange, bis es besser wird und sind zu dem alten Muster zurück gekehrt
Aus meiner Erfahrung ist sehr viel Unwissenheit. Es ist ja der natürliche Prozess, dass man erstmal etwas entwickelt und verkauft. Aber spätestens mit deiner Beauftragung zählt das Argument ja nicht mehr. Ich arbeite in der Anlagenautomation und dort wird quasi nur Implementierung, deployment und Support gemacht. Die Anforderung ist ein Schaltplan und ein Fließbild 😂 und "Anlage muss laufen". Fortbildung ist aus meiner Sicht der erste Schritt in die richtige Richtung. Aber aus Management Sicht ist es ja nicht notwendig solange alles "läuft". Es mindert ja nur den Gewinn
ich glaube bei so einer Software hilft kein Refactoring mehr. Killen und neu bauen LOL
"Wir arbeiten dran". Bedeuetet ich besetze mindestens 3 der benötigten Rollen selbst...
Ein Entwickler sollte keinen Support anbieten müssen.
In Kurzform: gesunder Menschenverstand und vieles läuft schon rund
witzigerweise kaufen sich Unternehmen dann Support und DevOps wieder ein. I mean, ich werd mich da sicher nicht beschweren, dass sie das tun 😁
Hey,
das ist ja noch die gute Variante, die noch schlechtere ist es alles auf die Entwickler abzuwälzen :)
Gruß David
@@DavidTielke naja, wenn es genug Entwickler gibt, dass diese ihr Aufgabenspektrum erweitern können und trotzdem die Entwicklung nicht vernachlässigen müssen, geht es ja auch gut - wird eben leider oft nicht gemacht, wie du im Video auch gut beschreibst :)
Fachkräftemangel???? Oder zu hohe Anforderungen der Firmen????
Mangel an billigen Arbeitskräften die sich ausbeuten lassen! Man soll Senior sein, aber bitte nur das Einstiegsgehalt eines Fachinformatikers verlangen... Wenn nicht müssen die anderen Mitarbeiter halt mehr Arbeit leisten und bekommen natürlich keinen Bonus oder Gehaltserhöhung.
@@DanielM.-mq4rm Bitte Hochqualifiziert und gleichzeitig jung. Einarbeitung gibt es nicht ....
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. ❤
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
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!
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!!!😂
>"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.
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.
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
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.
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.
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.
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.
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!' ...
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
Scrum ist auch nur für Kontrollfreaks. Wie hat man früher blos tolle Sachen programmieren können?
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.
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.
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 die rollen schon besetzt, aber die personen sind dem nicht gewachsen.
Hey,
die Situation kenne ich auch - nur jemandem einen Titel geben reicht leider nicht aus :)
Gruß David
Das ganze Team hat gekündigt? Da hat wohl jemand den Obstkorb nicht wieder aufgefüllt...😅
Der kicker war kaputt
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.
Wenn 9 gehen und 50 davon abhängig sind läuft eindeutig etwas falsch, vielleicht hätte lieber mehr Entwickler als Feel Good und Marketing leute einstellen sollen.
Also so ein gedusel wie einen Feel Good Manager würde ich eher als Grund sehen für schwach sinn,
gerade im Bereich People erleben wir ein Over Managment, und irgendwann wird auch dem dümmsten Entwickler klar das solche Leute nicht nur auf die Nerven gehen sondern einem die kosten auch noch quasi direkt vom Gehalt abgezogen werden.
Das sind doch nur Menschen die von Technik keine Ahnung haben und von dem Werten leben wollen die andere erschaffen.
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...
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
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.
Mir fehlt in der Liste der Dinge, die getan werden müssen, ein wichtiger Punkt: Die Dokumentation des Produkts. Jemand muss die schreiben.
Hey Christopher,
guter Punkt, ich habe es mit zu den Anforderungen / Support gezählt, aber hätte man auch getrennt erwähnen können. Danke für das Feedback!
Gruß David
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 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.
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.
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 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
Du hast den Begriff der Idee und der Vision in der Mitte des Viedos vertauscht... am Anfang stand noch die Vision am start des Prozesses, später dann Idee. ;)
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.
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
Prinzipiell bin ich bei dir, aber eine Blaupause für den Erfolg ist eine Teambildung mit Rollenbesetzung nicht.
Ich nenne es mal Legacy, also Software, die im Grunde auch nach /dev/null verschoben werden könnte und immense Entwicklungskosten hatte. Natürlich möchte der Shareholder die Wahrheit nicht hören und das Management stellt alles immer auch als machbar dar.
Hohe Fluktuation der "Indianer", festhalten an wirren Strukturen, da ein notwendiges Refactoring dem Shareholder nicht zugemutet werden kann. Und das Management, das eben Management ist, und nunmal keine Eier die Wahrheit auf den Tisch zu legen. Das was Entwickler sagen muss man ja nicht ganz so ernst nehmen.
Ich selbst hätte fast mal gekündigt, da ich in ein solches (in Shareholder feuchten Träumen süßes) Produkt zwangsversetzt wurde. Die Firma ging rechtzeitig pleite, wurde aufgekauft, ich wanderte zurück in mein altes Team, und alles war wieder gut. :)
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.
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!
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,
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.
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 😞
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...
8 Jahre für Refactoring bei 20% Kappa für neue Features und das in einem 55 Personenbetreib?! Was soll denn das bitte für ein Produkt sein?
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.
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 😁