Größte Fehler der Softwareentwicklung den viele machen!
Вставка
- Опубліковано 26 чер 2024
- Softwareentwicklung ist ein komplexer Prozess, der besonders in Teams und in Unternehmen ohne tiefergehendes Wissen im Bereich Programmierung, Softwarearchitektur oder Softwarequalität herausfordernd sein kann. Doch oft liegt das zentrale Problem tiefer: In einem fehlenden grundlegenden Verständnis der Softwareentwicklung selbst. In diesem Video untersuchen wir dieses Problem und seine Ursachen detailliert. Es zeigt sich, dass die Auswirkungen weitreichend und fatal sein können, besonders wenn die Softwareentwicklung im Laufe der Zeit in einem Unternehmen stetig anwächst. Um dies zu veranschaulichen, teile ich ein Beispiel aus meiner eigenen Klientenhistorie. Lasst uns gemeinsam entdecken, welche Fehler gemacht werden können und wie man diese vermeiden kann.
Inhalt
[00:00] Einleitung: Die Softwareentwicklung verstehen
[01:12] Der Startpunkt: Wie die Softwareentwicklung in Unternehmen beginnt
[01:39] Der Evolutionäre Prozess: Wie sich Softwareentwicklung entwickelt
[03:05] Erfolgsgeheimnisse: Was in der Softwareentwicklung unbedingt gemacht werden muss
[05:34] Rollen und Verantwortlichkeiten: Wer macht was in der Softwareentwicklung?
[07:47] Fallstrick vermeiden: Der größte Fehler in der Softwareentwicklung
[15:01] Ein Fallbeispiel: Was bei meinem Kunden schief gelaufen ist
▬ Über diesen Kanal ▬▬▬▬▬▬▬▬▬▬▬▬
Seit vielen Jahren arbeite ich als Consultant, Coach und Trainer für professionelle Softwareentwicklung mit den Schwerpunkten Softwarequalität, Softwarearchitektur sowie Prozessmanagement. Auf meinem Kanal möchte ich Euch mein Wissen und meine langjährige Erfahrung in diesen Bereichen vermitteln - natürlich kostenlos. Dabei versuche ich stets Euch das Wissen so zu vermitteln, dass Ihr damit direkt in der Praxis loslegen könnt und das ganze immer mit guten Portion Humor. Lernen soll ja schließlich Spaß machen :)
▬ Empfohlene Videos ▬▬▬▬▬▬▬▬▬▬▬▬
Wie viel Softwarequalität Ihr braucht - • Architekturen - Von Mo...
Warum Software unwartbar wird - • Warum Software unwartb...
Architektur - Modularisierung - • Architektur - Modulari...
Was ist Architektur - • Was ist Architektur?
Warum Architektur - • Warum Architektur für ...
▬ Wichtige Links ▬▬▬▬▬▬▬▬▬▬▬▬
Abonniere meinen Kanal: / @davidtielke
Alle Videos: / @davidtielke
▬ Social Media ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
► Twitter: / davidtielke
► Xing: www.xing.com/profile/David_Ti...
► LinkedIn: / david-tielke-06140912b
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ - Наука та технологія
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.
DArf ich fragen was genau du machst? Ich habe oft Entwickler gesehen die monatelang etwas gebaut haben das man auch für $10 hätte kaufen und kommerziell nutzen können , totaler Irrsinn. Die arbeiten immer noch da ;)
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.
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!
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. :)
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.
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 UA-cam 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.
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.
>"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.
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...
Perfekt, klar und verständlich. Danke
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
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.
Danke, das ist sehr lehrreich.
Ich, kurz vor dem Ruhestand, habe als Bauer einer Messmaschine Software geschrieben und alle Rollen allein ausgeführt. Der Stakeholder war schon da. Nun wird das Produkt mit ca 3 Jahren Verspätung auf neue Füße gestellt (externe Softwarefirma)
Dass ich kein BournOut hatte grenzt an ein Wunder.
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!' ...
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
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."
Deine stimme ist so angenehm, dass ich das Video angeschaut habe während ich was anderes gemacht habe und im Gedanken abgeschweift bin. Jetzt muss ich das Video von vorne schauen :D
Ganz hervorragende Präsentation.
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 ;-)
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.
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.
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.
Danke für das tolle Video!
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
Dein Video zeigt nebenbei sehr schön auf, warum ein Unternehmen sich nicht auf Umsatzsteigerung, sondern auf Gewinnsteigerung konzentrieren sollte.
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"
Bekommst jetzt doch mal n Abo, nachdem Video letztens mit dem Gehalt nach der Ausbildung war ich echt eher der Meinung "Nicht schon wieder einer, der auch die Sichtweise hat den "Neulingen" eher wenig zu zahlen." Jetzt nach ein paar Videos kann ich einfach nur absolut vieles nachvollziehen, super Content und super Sichtweisen =)
Ich habe so viele verschiedene Welten kennengelernt von Agentur, über Firma und Selbstständigkeit. Es gab so viele Facepalm-Situationen. BIn so glücklich wie ich jetzt arbeiten kann. Deine Interpretation und dein Erlebnis ist so typisch, aber es gibt so viele Versionen davon. Danke dir für deine Zusammenfassung, ist echt super.
Super auf den Punkt gebracht
Sehr gut erklärt, verstehe sogar ich.😊
Ich schreibe auch schon seit Jahrzehnten Programme, bin Autodidakt und mag VB6 und C++, aber nur privat.
Super gut aufbereitet! :)
ich arbeite seit 2010 in der software entwicklung und hab viel erlebt, was hier auch angesprochen wird.
interessantwerweise hat sich das stark verbessert seit ich (seit 2021) selbstaendig arbeite und fuer projekte als freelancer dazu geholt werde.
Seit dem arbeite ich nur noch in gut funktionierenden teams. Woran das liegt ist spekulation.
grundsaetzlich bin ich aber froh, die erfahrung in verschiedenen, nicht gut funktionierenden unternehmen gearbeitet zu haben. Am ende bin ich immer vor dem Bunrout abgesprungen, aber ich habe extrem viel gelernt und vor allem verstehe ich was im ganzen passiert und merke auch bei vorstellungsgespraechen schnell ob das projekt laeuft und ob ich da was bewirken kann.
Ich 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.😊
Was für ein starkes Video 👍👍
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.
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.
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!!!😂
ich habe das in meinen wirtschaftsinformatik studium rauf & runter lernen müssen & dachte damals, dass das mega der standard ist & alle firmen so arbeiten. Als ich dann in die Berufswelt eingestiegen bin (als Entwickler) habe ich sofort gemerkt, dass nur ein sehr geringer Bruchteil der Software Branche in diesen Themen Ahnung hat. Selbst gestandene C-Level Akteure, wussten oft nicht mal was DevOps oder UI/UX konkret bedeutet.
Sehr schön zusammengefasst. Ich arbeite für ein Maschinenbauunternehmen, bei dem sich all diese Probleme noch mit zwei weiteren vermischt, erstens nimmt keiner Software ernst (ist eben eine Notwendigkeit, nicht Kerntätigkeit), und zweitens sprechen die Systemingenieure direkt mit den Softwareentwicklern an dem Prozess vorbei, und ich als Product Owner und Architekt (in einigen Projekten) werde dann außen vor gelassen. Die Software sieht dementsprechend aus, ist nicht wartbar, und die Entwicklung dauert länger und wird teurer, als wenn man den Prozess einhalten würde. Aber man hat ja dazwischen immer wieder gespart!
Herzlich Willkommen in meinem Leben! Das sind genau die Kämpfe die ich täglich austragen muss ein Kampf gegen Windmühlen… Danke David wirklich auf den Punkt gebracht… Ich würde sagen ein typisch deutsches Problem was unter anderem dazu führt, dass gestandene große Softwareunternehmen eben nicht aus Deutschland kommen…
Aus irgendeinem Grund habe ich gerade das unstillbare Verlangen, meine Software tiefer zu legen. Ich strebe immer nach Improvemt! Und Tschüss.
Ja super Thema, danke das Du das ansprichst. Ich finde man sollte nicht vergessen, dass es auch schon ganz vorne - bei der Idee - zu massiven Problemen kommen kann.
Es gibt einfach Software, die wird nicht benötigt oder die Idee ist einfach schlichtweg schlecht. Das muss ganz früh schon aussortiert werden, sonst reitet man jahrelang ein totes Pferd. Und ich glaube das passiert schon sehr häufig und keiner redet gerne drüber. Ich finde die Value Proposition also welchen Wert die Software tatsächlich erzeugen soll deshalb ein entscheidendes Kriterium, sozusagen die Single Source of Truth für das gesamte Projekt. Wenn das schon nicht passt und es keiner (Management!) merkt, tja gute Nacht. Ich finde wir haben speziell in DE ein massives Problem was die Qualität von (IT) Management angeht: Einfach absurd schlecht was da an vielen Stellen geschieht!
Hey, ja absolut - den Punkt meinte ich mit Vision. Da wird genau die Value Proposition rausgearbeitet. Aber ich habe auch schon in einigen Projekten erlebt, das dort schon erkannt wurde, das die Idee schlecht ist und trotzdem wurde das Projekt gestartet.
Gruß David
Ich denke ein Problem hierbei ist die sogenannte "sunken cost fallacy"; d.h. man möchte ein Projekt oder Produkt. nicht mehr fallen lassen, weil man bereits viel Geld hereingesteckt hat. Das tote Pferd, das man dann reitet, wird dadurch aber nicht lebendig. Besser ein Ende mit Schrecken als Schrecken ohne Ende.
Ich 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.
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
Interessant, ich habe von 2013 bis 2017 in einer Firma gearbeitet, die ähnliche Herausforderungen erlebt hat. Leider hatte diese Firma Schwierigkeiten, das richtige Personal im Bereich Programmierung zu finden, was zu weiteren Problemen führte. Besonders im Jahr 2016 kam es zu Spannungen zwischen den Abteilungen Marketing/Vertrieb und Entwicklung. Rückblickend habe ich ein besseres Verständnis dafür entwickelt, warum diese Situationen entstanden sind. Kurz gesagt, es ist wichtig, dass neue Teammitglieder, unabhängig von ihrem Hintergrund oder persönlichen Stil, gut in das bestehende Teamgefüge passen. Es ist entscheidend, dass die Unternehmensleitung darauf achtet, um solche Konflikte zu vermeiden
Uiuiui, das ist das worst case scenario. Die Verantwortlichen haben sich nicht damit beschäftigt wie man gesund wächst. Im Grunde haben die ne Bugwelle von Versäumnissen im Produkt, in der Organisation und in den Prozessen aufgebaut. Die Entwickler wurden verheizt und allen Problemen ohne Struktur komplett ausgesetzt.
Es ist schwer zu beurteilen ob jeder da gekündigt hätte. Für mich hat das Kreuz immer 2 Balken, vereinfacht gesagt: Manager, die die Strukturfehler nicht sehen (wollen, können), und Entwickler, die zu spät lernen wie man nein sagt, und damit notwendige Diskussionen anstossen. Unternehmenskultur spielt auch eine riesige Rolle.
Super Video, ich teile alle dargestellten Problemansichten. Das passiert nicht nur in Startups. Auch alte Unternehmen tappen in die Falle, dort manifestiert sich das Problem oft schleichender, daher auch eher abwendbar.
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
Nach über 5 Jahren Softwareentwicklung in der Automobilindustrie kann ich nur absolut bestätigen was du sagst. Bin heilfroh, den Absprung geschafft zu haben. Hätte nicht gedacht, dass man einen Laden so schlecht managen kann.
Ich 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
Ich habe selbst vor längerer Zeit in so einem Unternehmen gekündigt. Heute bin ich selbst IT-Berater und kenne dieses Chaos, wenn ich bei einem neuen Kunden mit der Arbeit beginne. Welche Rolle oft auch noch gebraucht wird: Cloud Architect und Cloud Engineer (erste, wenn nicht durch die Architektenrolle abgedeckt). Dazu ist es aufgrund des Fachkräftemangels oft erforderlich, Haupt- und Sekundärrollen zu definieren. Oder Instrumente wie Pair-Programming einzusetzen. Ich helfe selbst auch bei Implementierungen mit. M.M.n. ist wegen dem Fachkräftemangel einfach eine Hands On Mentalität und Lernbereitschaft erforderlich.
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
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
Es ist aber, wenn ich das richtig zwischen den Zeilen gelesen habe, eher für "kleinere" Unternehmen gemeint. Also das Konstrukt Team vs. Gruppe.
Es gibt ja, gerade bei größeren Unternehmen, auch oft die Konstellation, dass es mehrere Teams gibt, die jeweils ein Produkt oder mehrere Produkte betreuen, oder auch sogar mehrere Teams für ein Produkt.
Danke für das Video und die gute Herleitung!
Super Video
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 :-)
Die Übersicht bei 7:15 finde ich enorm hilfreich um einfach mal zu verstehen, für was die ganzen Bezeichnungen in Stellenbeschreibungen für Softwareentwickler steht.
Bei mir stand da bisher immer ein riesiges Fragezeichen, weil ich es gar nicht differenzieren konnte.
Als Normalsterblicher, der sonst noch nicht wirklich mit dieser Materie in Berührung gekommen ist, bin ich da wohl auch nicht alleine. :D
Erstmal danke für das tolle Video. Mir fiel aber die Kinnlade runter bei der Aussicht auf 8 Jahre refactoring mit 80% Auslastung darauf. Da dreht sich doch bei jedem Geschäftsmann der Magen um. Ganz schön bitterer Apfel
Wir haben einen großen Teil der Positionen formell auch nicht besetzt aber. Einige unserer Mitarbeiter haben isaqb Schulungen gemacht und führen die Architektur Ideen und Planungen im Zuge des Sprint plannings aus. Feel good Manager haben wir auch nicht aber der teamlead kümmert sich um uns, er fragt sogar welches Bier wir am liebsten trinken damit der Kühlschrank nicht immer mit dem selben Zeug gefüllt ist. Bugs haben bei uns immer die oberste prio im Sprit und werden immer sofort abgearbeitet. Mind 20-30% gehen regelmäßig für refactoring drauf (zb bei Updates von Bibliotheken, breaking changes, besseres state management usw.). Insgesamt bin ich aber recht zufrieden und fühle mich wohl an dem Produkt zu arbeiten.
Hey,
ob die nun formell besetzt werden oder implizit ist nicht ausschlaggebend, sondern das die Tätigkeit durchgeführt wird. Ob derjenige dazu den Hut auf hat, oder nicht spielt keine Rolle. WENN es aber eine definitive Rolle gibt, kann man alles einfacher kontrollieren und verbessen - das ist der Vorteil. Aber: glückwunsch zu dem Team, alles richtig gemacht :)
Gruß David
Das 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.
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.
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.
Nicht meine Branche aber sehr interessant. Das sehr stark auf irgendwelche Kennzahlen geachtet wird ohne das große und ganze im Blick zu haben gibt's denke ich Grundsätzlich überall 😅
Schön dass bei dem Stakeholder ein Steak dabei ist ;D
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.
Ich bin nicht in der Softwareentwicklung tätig, aber das Thema passt schon sehr gut auf meinen Bereich. Sowohl das Thema der korrekten Rollenverteilung (inkl. Auswahl der dafür fähigen Mitarbeitenden) als auch die klar Regelung von Verantwortlichkeiten, ist oftmals vom Unternehmen nicht sauber und klar Umgesetz. Das führt zu Problemen (es sind ab einem gewissen Punkt keine "Herausforderungen" mehr). Insbesondere, wenn nur auf die Kosten geblickt wird, Personal an allen Enden reduziert wird und jeder dauerhaft über der Belastungsgrenze arbeitet. Dann noch unklare Aufgaben, Rollen und fehlende Entscheidungskompetenzen bei (Line) Managern und nach einer gewissen Zeit stürzt das Kartenhaus zusammen.
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 :/
Man könnte annehmen, Du hättest bei uns 1 Jahr gearbeitet. Muss während Corona gewesen sein, da ist man sich vielleicht nicht so oft begegnet..Sehr schöner Beitrag.
"Verbessert nicht das Produkt, findet lieber dümmere Kunden"
Habe ich mal gelesen im Buch das Dilbert Prinzip von Adam Scott
Es stimmt zu 100%. Wenn Rollen dann auch nicht nach Fachkenntnisse und Fähigkeiten sondern nach dem nach der Nase reden Prinzip besetzt werden, geht alles zu 100% schief.
Ich stimme total zu und finde es so richtig gut auf den Punkt gebracht. Aber mir fehlt die Ergänzung aus der anderen Sicht. Denn klar sind die genannten Rollen alle relevant, aber wenn man sie als einzeln besetzt, hat man sehr viele Leute in der Produkt Organisation. Davon ausgegangen und angenommen die Entwickler skalieren mit, entsteht wieder Silo Bildung, da ein Team ja auch nicht zweistellig werden soll. Dann widerum gibt es mehr Absprachen, daraus folgt man ruft nach übergeordneten Rollen. Diese widerum (sollen laut Entwickler) fungieren schnell bestimmend und kritisch. Dem ordnen sich Entwickler unter bzw. Sehen ein, dass es diese demokratische Instanz benötigt (und das ist schon ideal beschrieben). Nun hat man wider weniger Autonome teams mit teilweise interdisziplinär besetzen Stellen, die sich nach Team oder alternativ untergeordnet unterscheiden. Man steht wieder näher an der Anfangssituation.
Nichtsdestotrotz ich denke aktuell ist das extrem eher reine Entwickler teams zu haben und nicht zu viele interdisziplinäre Personen, daher bin ich stark bei Ihnen.
Trotzdem glaube ich aus meinen 10 Jahren agiler Produktmanagement im Software Bereich, dass eine Organisation und Produktentwicklung unverhinderbar asymptotisch ineffizient wird ab einer bestimmten Größe.
Ich plädiere eher, obwohl ich nur bei Konzernen mit Ihren Sub Unternehmen arbeitete, eher die gesamt Struktur im Mittelmaß / Mittelstand zu halten und zumindest um die 30 Prozent interdisziplinäre Rollen in einem Team neben den Entwicklern zu haben, die aber auch je nach Unternehmensanforderungen oder Funktionsweise mehrere Rollen inne haben dürfen (Rollen sind ja eh fließend definierbar). Gar keine dieser Personen im Team ist schlecht, nur Fokus auf je Rolle eine Person kann nicht funktionieren, bei diversen Rollen die man in der Produktentwicklung braucht. Gleiches gilt für das Verhältnis zum vermeintlichen management.
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.
Lol, das Steakholder Icon ist ja grossartig 😂
Ich finde es immer wichtig eine eigene abteilung für ein projekt zu haben die nur für Qualitätsanforderungen zuständig ist
Ein Arbeit für die Consulting Firmen ;) Change Management betreiben, Anforderung von der Kunde mit der Umsetzbaren vergleiche und reduzieren, und richtige Ergebnis nach Scrum pro Sprint liefern, klar in so einem komplexen System ohne Test is schwierig alle Anforderungen zu erfüllen, aber zumindest man hätte darauf eingegangen und verlangt und das Management hätte es verstanden, zwar die wären nicht zufrieden , das es so viel Arbeit , aber zumindest es wäre die richtige Entscheidung.
You nailed it!
Danke :)
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 😅
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.
Zum Glück musste ich nie in einem Unternehmen mit einem solchen Chaos arbeiten. Es gab immer mindestens eigene Abteilungen für Entwicklung (inkl Architekt, usw), Qualitätssicherung (Test) und Support, sowie wurden auch die hier beschriebenen Rollen entsprechend Personen zugewiesen, so dass die hier beschriebenen Probleme nicht auftraten. Trotzdem hat man manchmal Probleme, weil irgendwas "schnell gemacht" werden muss, allerdings weniger in der Entwicklung, eher im Bereich Devops.
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...
Die Prozesse zu bürokratisieren löst die Probleme aber auch nicht. Bei so kleinen Teams die einzelnen Rollen auf nur eine Schulter zu stellen, erscheint mir als ein massiver Fehler. Gerade bei der Architecture eines so großen Projektes sollten unbedingt viele Köpfe beteiligt sein. Einzelperson Architekturen sind bei uns eigentlich fast alle schief gegangen. Und auch beim Testen sollten sich alle beteiligen, denn es erfordert viele verschiede Blickwinkel. Es erstaunlich wie unterschiedlich Software von verschiedenen Menschen genutzt wird. Insbesondere mit unterschiedlichen Background.
Nebenbei scheinen mir die Entwickler hier selbst Schuld zu sein. Man macht klare Ansagen an die Geschäftsleitung und wenn dann die Tests und andere Punkte nicht fertig sind, ist das Feature eben nicht fertig und geht nicht an den Kunden. Und sollte die Geschäftsleitung selber das unfertige Produkt an die Kunden senden, dann macht man danach trotzdem erstmal beim alten Feature fertig, bevor man was neues anfängt. Und wenn die Leitung fragt, warum man nicht fertig ist, kann man doch auf die Vereinbarung verweisen.
Ein solches Refactoring in 8 Jahren durchzuführen erscheint mir auch sehr ambitioniert. Wir sind jetzt schon mindestens 10 Jahre am Refactoring unseres Monolithen, vielleicht 80% geschafft.
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
Der Stakeholder mit dem Steak! Ich brech weg!
Absolut meine Erfahrung, obwohl wir SW nur für unseren eigenen Bedarf entwickeln und betreiben.
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.
So schlimm ist und war es bei mir fast nie, aber einige Punkte treffen natürlich immer zu!
Hey,
"immer" stimmt nicht ganz, habe auch einige Kunden mit einer sehr guten Umsetzung, aber die angesprochenen 90% kommen nicht von ungefähr.
Gruß David
@@DavidTielke Bei mir gab es glaube ich noch keinen Job bei dem nicht mindestens ein Punkt zugetroffen hat.
Das schlimme ist, wenn es eine kritische Rolle ist, hat es fatale Konsequenzen.
Gruß David
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.
Bin quasi alles in einem. 😂 habe letzte Woche deployed und seit geraumer Zeit zwei weitere Entwickler, die aber nicht meine Mitarbeiter sind aber Apps (django) mit meiner Hilfe entwickeln, die ich dann zusammenführen werde. Eine der beiden haben wir nun im großen Ganzen gemerged und joa, es macht spaß aber wenn ich nicht alles überblickt, dann werden Datenbanken in den einzelnen Apps entwickelt, die das große Ganze torpedieren.
Hallo David,
meine Erfahrung bei großen Unternehmen mit allen besetzten Rollen ist auch nicht anders. Es liegt alleine nicht die Fehlbesetzung.
Der Punkt ist nicht die Fehlbesetzung, sondern die Inkompetenz der Personen in SW-Entwicklung und -Architektur. Ich habe gesehen, wie unerfahrener Produkt Owner ein Team von Softwareentwicklung führte. Ich habe gesehen, wie ein Scrum-Master rumlabert und hauptsache die ganze Meetingreihe moderiert, ohne die Fortschritte nach jedem Sprint zu sachlich erkennen. Genauso, durfte ich auch die unfähigen SW-Entwicklern erleben, die nur beschweren und leeren Versprechen gibt. Das Problem aktuell ist, die Inkompetenz und das Besserwissen ohne die wirkliche Erfolgerfahrung.
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!
Wir haben keinen Architekt, Process Owner, Feelgood Manager, Support macht auch jeder und nur ein halben DevOps.
Ist genau so gestartet wie hier beschrieben - mit einem Entwickler (frisch von der Uni noch keine wirklich Ahnung was er tut). Dadurch sind viele der wichtigsten Komponenten kompletter murks, wurden aber so extrem oft schon benutzt, das die App zu abhängig von diesen Komponenten ist als das man sie einfach refactoren könnte.
Das beste ist: Der Wunsch des Teams ist sich MEHR anstatt weniger in eine Gruppe weiterzuentwickeln (also jeder soll in ein paar Bereichen tätig sein).
Das ganze läuft noch weil der Entwickler, der das ganze Projekt gestartet hat noch im Team ist und 70% der gesamten Tickets abwickelt. Falls der mal geht kann die Firma die App vergessen.
Was für Aspekte meiner Meinung nach komplett vergessen/unterschlagen wird
* Rollen und Verantwortlichkeite: Zwei Personen != 200% Leistung, da die beiden Personen ein gemeinsames Verständnis entwickeln müssen und dafür geht Zeit drauf. (nicht zu vergessen Agiles Principles: Business people and developers must work together daily throughout the project. )
* Und das Thema der prozentualen Aufteilung ist auch total unrealistisch (Ideal ist doch nicht alles mit 10%, eine Anforderung die in z.b. 2h erstellt wird, braucht vielleicht 20h fürs coden oder andersrum)
* Ein Aspekt den ich oft sehe, dass Menschen sich völlig überschätzten, man nicht auf erfahrene Kollegen hört. Wenn das Kind dann in den Brunnen gefallen ist, verkrümelt man sich leise und erspart sich neben dem Lerneffekt auch das übernehmen der Verantwortung.
* Und last but not least "Working software is the primary measure of progress." ob man dafür eine Build Pipeline braucht oder nicht steht da nicht drin.
* Der für mich wichtigste Punkt ist "Keep it simple stupid" und zwar durch den kompletten Prozess
* Und mein Lieblingskonzept ist den Entwickler zum Kunden zu schicken oder mal Abends um 22 Uhr noch die DB fixen lassen, nachdem man mit dem letzten Patch alles kaputt gemacht hat.
Klar kann man mit dem Ideal am Ende erfolgreich sein, aber das kostet dann halt auch und muss erwirtschaftet werden. Der für mich spannende Bereich bewegt sich zwischendrin. Wo man mit möglichst wenig Ressourceneinsatz, langfristig möglichst viel Herausholen kann. Das ist übrigens auch das womit Scrum gestartet ist - einem Baukasten von dem man sich nur das herausnimmt was tatsächlich benötigt wird - wie halt im echten Leben ;-) Da ist mir auch noch keiner begegnet der sich die große Hilti kauft nur um ein Bild aufzuhängen...
Und weil der Monolith noch erwähnt wurde, da möchte ich gerne an den Vortrag "Keep it simple? My Ass!" von Dr. Karl-Heinz Wichert erinnern. Microservices sind teuer und ein Monoltih nicht per se schlecht.
Ersteinmal sind wir kein Softwareunternehmen, allerdings entwickeln sehr viele Mitarbeiter. Der Betrieb ist ein streng hierarchisches System, mit Manager die von Softwareentwicklung keine Ahnung haben. Irgendwann hat mal das Management beschlossen agil zu arbeiten, aber die agilen Werte werden nicht gelebt. Ein typischer Fehler ist, dass man Entwickler verbietet selbst zu testen, dafür gibt es ja ein Testteam. Die Entwickler wollen und müssen schnell Erfolge zeigen, deshalb fangen diese mit der Entwicklung an - obwohl es noch viele Anforderungslücken gibt. Das Problem ist häufig auch der Kunde. Da fehlt häufig die Bereitschaft aktiv am Entwicklungsprozess teilzunehmen. Die Kunden haben Angst davor, selbst Entscheidungen zu treffen und zögern extrem bei konkreten Fragen. Die ProductOwner raten deshalb mehr als dass sie etwas erfragen, und die entwickelten Teile sind praktisch nie zu Ende, weil man häufig Monate nach Beendigung von Softwareteilen bestehende Anforderungen anders interpretiert. Offiziell arbeiten wir agil aber in Wirklichkeit ist es das Gegenteil.
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 😁
Ich bin an einem Communityprojekt dran und tatsächlich ist der Fall sehr ähnlich was bei deinem Kunden der Fall ist. Man hat zwar Gedanken über die Architektur gemacht, aber es fehlt an Vision und auch die Rollenverteilung. Es ist zum Glück überwiegend nur Javascript. Aber ich erkenne keine konkret verwendete Version. Wahrscheinlich ist in der Entwicklungsteam/-gruppe nicht bekannt, dass bei JS ECMA 4, 5, 6 usw. gibt.
Zudem trägt eine Person zu viele Rollen, sodass es dazu führt, dass einige Aufgaben nicht richtig bewältigt werden können.
Hey,
das ist bei Communityprojekten nicht anders, da gelten dieselben Gesetze. Aber hier ist die Orga meist eher dezentral und deshalb ist das Thematisieren und Entscheiden hier meist schwieriger.
Gruß David
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.
Bam, Teambatch. In meiner Firma haben auch mehrere innerhalb drei Moante gekündigt. Ich hatte meinen Vertrag auch nicht verlängert, sondern einen anderen Job gefunden und bin auf das neue Team gespannt
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.
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.❤
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
Ich habe bei Infosys Limited gearbeitet, ich habe gekündigt in Dezember und danach am 17 Januar 2023 ich habe kennengelernt 13 andere Kollegen habe gekündigt