Warum Softwareentwickler immer schuld sind

In diesem aufschlussreichen Video tauche ich tief in die komplexe Welt der Softwareentwicklung ein und untersuche, warum Softwareentwickler oft ungerechterweise die Schuld für Probleme tragen, die weit über ihren Kontrollbereich hinausgehen. Durch eine detaillierte Analyse beleuchte ich die systematischen Mängel im Entwicklungsprozess, die zu dieser ungerechtfertigten Schuldzuweisung führen.
Ich beginne mit einem Blick auf die oft übersehenen Aktivitäten im Entwicklungsprozess und wie deren Vernachlässigung zu kritischen Fehlern führen kann, die letztendlich auf die Entwickler zurückfallen. Anschließend diskutiere ich die Problematik der Ausbildung und der Rollenverteilung innerhalb von Projektteams, die dazu führt, dass Erwartungen und Realitäten nicht übereinstimmen.
Ein weiterer Schwerpunkt liegt auf der Qualität der Artefakte, wie Anforderungsdokumente und Architekturpläne. Ich diskutiere, wie die mangelhafte Qualität dieser Elemente den Entwicklungsprozess beeinträchtigt und warum es unfair ist, Entwickler für Mängel verantwortlich zu machen, die ihre Wurzeln in früheren Phasen des Projekts haben.
Durch detaillierte Fallstudien und eine kritische Betrachtung der Industriestandards biete ich Einblicke, die sowohl für Softwareentwickler als auch für Nicht-Techniker von Interesse sind. Mein Ziel ist es, Verständnis und Empathie für die Herausforderungen zu fördern, mit denen Entwickler konfrontiert sind, und Wege aufzuzeigen, wie Teams effektiver zusammenarbeiten können, um diese Herausforderungen zu überwinden.
Begleite mich auf dieser Erkundungsreise, um zu verstehen, warum Softwareentwickler oft zu Unrecht beschuldigt werden, und entdecke, was wir alle tun können, um eine positivere und produktivere Softwareentwicklungsumgebung zu schaffen.
Kapitel
[00:00] Das Problem
[01:22] Das große Ganze verstehen: Ein Blick auf die Softwareentwicklung von oben
[05:06] Häufiger Fehler #1: Fehlerhafte Softwareentwicklungsprozesse
[07:03] Häufiger Fehler #2: Fehlendes Wissen in Schlüsselpositionen
[09:15] Häufiger Fehler #3: Nicht ausreichende Qualität von Artefakten
[11:03] Die Schuldfrage: Warum Softwareentwickler immer im Kreuzfeuer stehen
[12:22] Ein Stück Wahrheit: Warum wir als Entwickler doch nicht ganz unschuldig sind
▬ Ü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
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

[@gzoechi]

Schuld sind immer die, die gearbeitet haben. Diejenigen die nur reden und sabotieren waren noch nie Schuld. Das ist nicht auf Softwareentwicklung beschränkt

[@psymcdad8151]

"Wer noch nie ne' Maschine gecrashed hat hat noch nie an einer Gearbeited." - Aufmunternde Worte für Lehrlinge an CNC-Maschinen, nachdem das Büro sie zur Sau gemacht hat.

[@derRobert-dy5tw]

Ich arbeite seit 24 Jahren als Softwareentwickler. Aber selbst ich könnte nicht genau sagen, wie man ein Projekt ohne Probleme fertigstellt. Was ich aber sicher weiß, ist, wie man ein Projekt zum Scheitern bringt: Man fängt damit an, jemanden einzustellen, der die Arbeit überwacht und die Leitung verwirrt. Dann mischen sich die Chefs direkt ein, bringen ständig neue Ideen, ändern die Pläne und setzen unrealistische Fristen. Das Ergebnis? SCRUM - unser Arbeitsplan - wird nur noch auf dem Papier existieren, der JIRA-Account verwaist. Am Ende haben wir ein gescheitertes Projekt oder ein Produkt, das niemand mag. Kunden sind unglücklich, Entwickler sind gestresst, manche sind so frustriert, dass sie innerlich kündigen. Wie macht man es besser? Nicht alles zu ernst nehmen, als Entwickler auch mal Nein sagen und aufpassen, nicht alles selbst machen zu müssen.

[@DavidTielke]

Hey Robert, da hast Du mit vielen leider vollkommen recht - allerdings solltest du es nach 24 Jahren wissen, wenn Dein Unternehmen mehr Wert darauf gelegt hätte, allen beizubringen wie es geht. Wenn Du als Entwickler das Know How nicht hast, ist die Wahrscheinlichkeit hoch, das auch Euer Projektmanagement, die Product Owner etc. es nicht wirklich haben. Gruß David

[@AndreasDelleske]

Auch Entwickler seit 20 Jahren (in anderem Licht seit 40) und ich habe festgestellt daß man zuerst den Kunden schulen muß dahingehend was realistisch ist, was er übersehen hätte, was man besser sein läßt, was man heute noch nicht angeht aber vorbereitet, wie man erst mal Informationen aus der Firma oder der Benutzung zieht... was Refactoring ist, was die Langzeitfolgen sind, welche Risiken man bewußt angeht, wie wichtig Sicherheit und dennoch Schlankheit ist, daß das Wichtigste erst mal das Datenmodell ist... Und all das am besten bevor man das erste Dokument schreibt, ohne daß man als Verzögerer wahrgenommen wird.

[@Kkubey]

Als Junior darf ich in meiner Firma gerade meine Fristen selbst setzen und habe Mitspracherecht bei den Funktionen die umgesetzt werden bzw. welche Priorität sie haben, das macht mir wieder klar, dass ich am besten dort bleiben sollte.

[@shenlong3879]

Oftmals weiß der Kunde ja selbst nicht was er will. Er hat eine abstrakte Idee und von deinem Sales Team wurde dann irgendwas verkauft. Und dann muss man erstmal Zeit investieren alles zu definieren und das dauert meist auch viel länger beim Kunden als bei einem selbst. Oft werden auch Probleme nicht richtig verstanden und Lösungen entwickelt bevor überhaupt das richtig Problem definiert ist. Daher sage ich auch immer wieder einer der wichtigsten Skills eines Softwareentwicklers, neben dem logischen Denken, ist es Probleme zu verstehen. Das Problem zu verstehen und zu analysieren ist eigentlich sogar wichtiger als eine Lösung zu finden. Denn nur eine auf das Problem angepasste Lösung ist eine wirklich gute Lösung.

[@LupoTosk96]

An meinem alten Arbeitsplatz haben mehrere, inklusive mir, genau wegen dieser Organisation gekündigt. Ein schwerwiegender finanzieller Schaden, weil nun das halbe Team gefehlt hat - und von Kollegen, die noch dort sind, höre ich, dass die Teamleitung aus nichts gelernt hat.

[@user-lq5qo6wg8q]

Immer wenn ich diese Videos sehe, freue ich mich, dass es nicht nur mir so geht. Und dass es doch an meinem Chef und nicht nur an mir lag, dass ich in der Reha gelandet bin.

[@DavidTielke]

Oha, was ist passiert? Burnout?

[@user-lq5qo6wg8q]

@@DavidTielke Ja, Burnout und Depression. Dabei bin ich gar nicht Softwarentwickler an sich, sondern e-Learning Spezialist. Ich hatte immer Angst vor Montagen, weil der Chef am Wochenende wieder gegoogelt oder Nachrichten geguckt hat und dann am Montag 7 Sprachnachrichten auf mich warteteten, in denen er seine Vision änderte, "Input gab" oder Designentscheidungen revidierte von denen er schon beim ersten Entscheiden keine Ahnung hatte, was da alles dran hing.

[@DavidTielke]

Das tut mir sehr leid für dich, gute Besserung! Ja, diese Art von Chef ist fürchterlich, die kenne ich auch. Bist du noch in der Firma?

[@user-lq5qo6wg8q]

@@DavidTielke Vielen Dank! Formal bin ich dort noch angestellt, aber nicht arbeitsfähig. Die Gesundung wird wahrscheinlich auch länger dauern als mein Arbeitsvertrag noch geht. Meine Priorität liegt jetzt erstmal darauf, mit dem gewöhnlichen Alltag wieder zurechtkommen zu können. Und unter anderem auch deine Videos zu diesen Softwareentwicklungsprozessen zu gucken, um im Ansatz zu verstehen, was da eigentlich schief gelaufen ist.

[@DavidTielke]

Freut mich, wenn ich dir dabei helfen kann - viel Erfolg!

[@sVIIDragonfly]

Wie immer hochwertiger Content - ein Genuss zu konsumieren, danke für deine Zeit und das Video!

[@DavidTielke]

Sehr gerne, freut mich das es Dir gefällt! Gruß David

[@AdriaticSun]

David, vielen Dank für das Video. Da ich ähnliche Erfahrungen hatte, kann ich nur bestätigen: Projekte scheitern in vielen Fällen, weil die Vorbereitung für die Entwicklung nicht gut genug ist. Zwischen Produkt Vision und DoR User Stories ist ein sehr langer Weg. Diese Rollen sind sehr oft nur von einer Person besetzt (Stichwort: Bottleneck). Entwicklerteam hat 2 bis 4 Entwickler, 1-2 QA. Auch wenn 2 oder 3 Entwickler Junior sind (bzw. 1-2 Mid / Senior Developers), wir haben noch immer Möglichkeiten zur Korrektur, die nicht so viel Zeit kostet. Wenn ein PM/PO seine Artefakte (User Stories, Features, Epics) in schlechter Qualität liefert, dann übernimmt das Team die Aufgaben von PO (schon mehrmals gesehen). Am Ende haben wir unzählige Probleme und Lieferverspätungen.

[@DavidTielke]

Hey, sehr gerne, schön das Dir das Video gefällt. Perfekt zusammengefasst und ergänzt - genau so erlebe ich es immer wieder :) Gruß David

[@sperl42]

Manchmal hat es auch Vorteile, in einer kleinen Firma zu arbeiten, in der man alleine für das Projekt verantwortlich ist und man im Zweifel noch einmal beim Kunden nachfragen kann, was wirklich gewünscht wird.

[@tobyzieglerrr]

Umso kleiner das Team umso erfolgreicher... ich glaube da ist schon was dran. Natürlich gibt es auch erfolgreiche SW Projekte mit Tausenden MA, aber die riesige Kommunikationskomplexität da in den Griff zu bekommen, da braucht man schon kompetente Leute. Und ja, meine Beobachtung: Es wird sehr sehr hemdsärmlig gearbeitet, mit wenig Fachwissen und selbst Erfahrung wird einfach mißachtet. Lernprozesse nur auf dem Papier usw. Ein kleines, effizientes Team mit 3-5 MA, wenn es gut zusammenarbeitet... unschlagbar IMHO

[@AScribblingTurtle]

Es sei denn, diese kleine Team wird von einem Egoisten ohne jegliches Technisches Verständnis geleitet, der nur die Meinungen zulässt, die er hören will oder verkaufen kann. Dann ist selbst das kleinste Team wenig erfolgreich.

[@MrMocren]

Als angehender Software-Entwickler (bereits FAE Ausbildung hinter mir und jetzt im dualen Studium) bin ich immer super Dankbar für dein Videos! Du sensibilisierst für Themen, über die man sich sonst nie Gedanken machen würde. Ich habe das Gefühl, dass den Mitarbeitern, auch Software-Entwicklern, oft der Blick über "das große Ganze" fehlt und die Ursache für die Probleme noch lange vor der ersten Zeile Code liegt. Und ich bin ein Freund davon das Problem "an der Wurzel zu packen", anstatt die darausfolgenden Symptome zu behandeln. Oft ist man zu sehr im Arbeitsalltag gefangen, sodass man mit den Gedanken bei einem Task ist. Ist das abgearbeitet, kommt der nächste. Dabei hilft es (mir zumindest) ab und zu mal einen Schritt von allem zurück zu gehen und sich nochmal ein Überblick zu verschaffen. Mal kritisch zu hinterfragen, ob das der richtige Weg ist. Die richtige Architektur etc. Aber ja. Es steckt immer der wirtschaftliche Gedanke dahinter. Und wie du schon erwähnt hast, wird leider an den falschen Enden gespart. Aber wäre Software nicht viel zu teuer, wenn man all diese benötigten Stellen besetzen würde? Würden das die Kunden noch kaufen? Im Mittelstand zum Beispiel. Ich bekomme oft mit, dass diese mittleren bis "großen" Kunden einfach nicht bereit sind solche Summen für eine "einfache" Software auf den Tisch zu legen.

[@DavidTielke]

Hey, schön dass dir die Videos weiterhelfen :) Ich denke so viel teurer wird die Software gar nicht, du hast zwar auf der einen Seite mehr Personalkosten aber auf der anderen Seite ein besseres Produkt am Ende. Hat man nur Entwickler gibt es meist viele teure Nacharbeiten und irgendwann wenn man einen großen Monolithen hat, gibt's einen sehr teuren rewrite - da wäre man in Summe mit einer gescheiten Softwareentwicklung günstiger weggekommen. Gruß David

[@askat1085]

Ein sehr gutes Video, dem ich vollständig zustimme! Was mir aber bei vielen Kollegen in der Softwareentwicklung aufgefallen ist, dass nie hinterfragt wird, ob eine Entscheidung so richtig ist. Ich habe vor 5-6 Jahren als Junior in einer großen Firma mit wenig IT Personal angefangen. Da mir immer wichtig ist zu verstehen warum ich an etwas arbeite, wurden die Termine mit dem Product Owner manchmal etwas hitzig, denn diese vehementen Rückfragen waren neu. Aber ich hatte das Gefühl (und auch Feedback) dass sich das Team nach einer Weile daran gewöhnt hat und es auch gut fand, dass diese Fragen gestellt wurden. Manche Tasks wurden dadurch auch zurückgestellt oder umgeschrieben, weil sie nicht ganz passten. Man kann damit in der falschen Firma auf die Nase fliegen, aber für mich ist es extrem wichtig das Ziel zu verstehen. Zumindest aus meiner Erfahrung heraus, können nur die Entwickler (wenn man keinen guten und übers gesamte Projekt eingebunden Architekt hat) teilweise Projekt-/Programmabschnitte gedanklich schon so miteinander verknüpfen, dass eigentlich identische Aufgaben mit unterschiedlichen Datensätzen als solche erkannt werden.

[@DavidTielke]

Hey, genau um dieses Ziel zu verstehen, gibt es ja die Produktvision - hat vermutlich bei Euch gefehlt. Das Problem das die Kollegen eine Entscheidung zu selten hinterfragen ist oftmals aufgestauter Frust, weil die Fehlerkultur im Unternehmen eh nichts ändert oder (mal wieder) einfach fehlendes Wissen um die falschen Entscheidungen überhaupt zu erkennen bzw. hinterfragen zu können. Gruß David

[@askat1085]

@@DavidTielke Das mit dem Frust ist in dem Fall am wahrscheinlichsten, da hier eine externe Firma die Entwickler gestellt hat (ich war der einzige interne) und sie in der Vergangenheit bei Refactoring Wünschen übergangen wurden. Diese Tasks wurden dann in der Einarbeitungszeit meistens mir übers Backlog zugeschanzt, so dass auch ein paar davon abgearbeitet werden konnten.

[@bastianwestphal]

Tolle Erklärung. Danke! Und die Waschmaschiene ist auch oft Schuld an vielen Klamotten-Bugs, wie z.B. fehlende Kapuzenbänder. 🫢

[@DavidTielke]

Sehr gerne! Nein, das hat mir meine kleine Tochter geklaut :)

[@MiniCmaX]

Aber als wissenschaftlich gesichert gilt doch, Waschmaschinen fressen Socken🤡🥴

[@DavidTielke]

Also meine steht auch auf kaputtenbänder... ;)

[@mulaschnick]

Aber grundsätzlich ein sehr geiler Pulli, auch ohne Band.

[@andreasschurz63]

Der UAT wurde vergessen zu erwähnen. Beispiel aus meinem Umfeld: die Entwicklung hat länger gedauert als geplant und mit Beginn der Abnahme knallen immer wieder neue Tickets hoch. Das geht so weit, bis man feststellt, dass die Architektur falsch gewählt wurde. Und das Projekt verzögert sich und verzögert sich. Jeder Bug, der gefixt wurde deckt neue Nachfolge-Bugs auf, die weitere bisher nicht gesehene Bugs nach sich ziehen. Hölle

[@DavidTielke]

Es wurden ganz viele Fehlertypen nicht erwähnt, sonst wäre das Video über Stunden gegangen :) Aber Danke für die Anmerkung: Ja, ist ein großes Problem, das kenne ich auch :)

[@cosmochaosmaker]

Absolut, das ist ein entscheidender Punkt! 👍 Die Verantwortung der Reviewer, insbesondere vor dem Merging von Änderungen und dem automatisierten Testen bestehender Features, ist nicht zu unterschätzen. Eine gründliche Überprüfung in dieser Phase kann viele zukünftige Probleme vermeiden. Ohne diese sorgfältige Prüfung riskieren wir, in einen Zyklus von Fehlern zu geraten, für die letztlich die Entwickler verantwortlich gemacht werden, was weder fair noch produktiv ist. 🙄 Es ist wichtig, dass sowohl Entwickler als auch Reviewer das UAT ernst nehmen und als integralen Bestandteil des Entwicklungsprozesses betrachten. Dies fördert nicht nur die Qualität und Zuverlässigkeit des Produkts, sondern trägt auch dazu bei, ein gegenseitiges Verständnis und Respekt innerhalb des Teams zu schaffen.

[@AScribblingTurtle]

7:00 : Das hab ich grad sowas von gefühlt. Autsch. Bei uns in der Firma (5 Programmiere + 1 Designer + 1 Sekretär + 2 Chefs) sind Produkt Owner, Product Manager und Projekt Manager dieselbe Person. Die Anforderungen ändern sich ständig, je nach dem was besagte person grad unseren Kunden verkaufen möchte. Interesse an der technischen Umsetzung hat besagte Person auch nicht, (Von ein paar verkaufbaren Buzzwords mal abgesehen). "Er ist ja keine Software-Entwickler sonder sieht nur die Sicht der Kunden" ~ um Ihn mal zu zitieren. Sobald dann doch mal was fertig wird, darf man sich hinterher anhören, dass alles viel zu lange gedauert hat und das man ja weniger Umsetzungszeit versprochen hätte. (Auch wenn alle sinnigen Umsetzungszeiten von der Chef-Etage immer mit "Das ist zu Teuer, das bekomme ich nicht verkauft" abgeschmettert werden und man gar keine andere Wahl hatte als irgendwas unsinniges / unmögliches anzugeben, weil die einen ohne Antwort nicht aus dem Büro lassen)

[@armendshala7229]

Vielen Dank.. Tolles Video

[@DavidTielke]

Danke schön, sehr gerne!

[@patrickj.2584]

Das hört sich ja einfach an 😅 Aus dem Maschinenbau kann ich nur sagen, dass wir auch in die Richtung Software entwickeln, aber da kommt noch hinzu - physikalische Prozess verstehen (NC, Fluide, Chemie, etc.) - mechanische/elektrische Konstruktion - Sicherheitsmaßnahmen/-normen (jedes Land unterschiedlich) - andere Normen - etc. Erwartungshaltung ist natürlich immer, dass man in den hinzugekommenen Bereichen auch Ahnung/Durchblick hat und "Nein" sagen kann. Und dann gibt es ganz viele Leute im Maschinenbau, die nicht verstehen, dass es eine Architektur braucht. Das sind die besten 🤣

[@stoernaify]

Freue mich gerade sehr deine slides mal wieder zu sehen. Und richtig gute Videoqualität 👍🏻 Vielen Dank

[@DavidTielke]

Hey Stephan, das freut mich :) Vielen Dank! Gruß David

[@st0ox]

Wie oft ich schon als einfacher Softwareentwickler für Fehler durch schlechtes Management verantwortlich gemacht worden bin ist echt traurig.

[@DavidTielke]

Hey, genau das ist das Problem, das kennen wir (leider) alle nur zu gut. Gruß David

[@st0ox]

@@DavidTielke Das beste war mal als sich die Geschäftsführung über unsere Softwareabteilung beschwert hat, dass wir nicht 100% unserer Arbeitszeit auf Kundenprojekte gebucht haben (obwohl es dazu auch keine Vorgabe gab). Wir hatten halt ca 70% unserer Arbeitszeit auf Tickets gebucht (der Rest waren interne Meetings und was man sonst noch so macht) von denen ca 70% auf Kundenprojekte waren und 30% interne Tickets (wie Techdebt zu fixen der jetzt nicht konkret nur einem Kundenprojekt zuordbar ist). Wir haben eine Software die im Kern mehrere Kunden nutzen aber die auch immer gewisse Anpassungen für die Kunden bekommt. Die GF hatte dann wirklich damit gedroht uns abzumahnen weil die wirklich gedacht haben wir würden unsere Zeit nicht arbeiten. Das war noch vor dem Zeiterfassungsgesetz und wir hatten alle Vertrauensarbeitszeit Verträge. Jetzt buchen wir halt interne Posten random auf irgendeinen Kunden und versuchen wirklich 100% unserer Arbeitszeit zu tracken und auch wiederum auf irgendwelche Kunden zu buchen. Die GF will halt das da am Ende 8h am Tag steht.

[@DavidTielke]

Hey, oh mein Gott - aber leider kenne ich auch solche Diskussionen. Aber da bin ich wieder bei der Aussage im Video, da fehlt einfach Wissen bei der GF zur Softwareentwicklung, weil wenn er das verstanden hätte, würde er nicht darauf bestehen, dass 100% der Zeit auf Kundentickets (also funktionale Anforderungen) gebucht werden. Traurig... Gruß David

[@st0ox]

@@DavidTielke mein Kommentar wurde entfernt aber scheinbar konntest du ihn ja noch lesen.

[@DavidTielke]

Warum wurde der entfernt?!? Hast Du eine Nachricht bekommen? Ich habe gestern schon auf zwei Kommentare geantwortet und als ich es abgeschickt habe, war der Kommentar weg!?

[@markusfeljofsen8345]

Softwareentwickler sind immer schuld, weil sie die wahren Arbeitenden und Wissenden sind. Wer wird in Rufbereitschaft angerufen, wenn Fehler in der Produktion auftauchen? Nicht die Projektleiter, nicht die Abteilungsleiter, nicht die Bereichsleiter. Aber all diese Leute wollen alles immer gleichzeitig und möglichst schnell. Den Betrieb der Systeme und die (Fehl-)Entscheidungen verantworten sie nicht. Die Software Entwickler sollten viel mehr Entscheidungskompetenz haben.

[@MyZeD88]

"Dann sag einfach 'nein'" (und ein 'Ja' zur Agentur für Arbeit) Manche haben halt nicht das Glück Selbständig zu sein.

[@DavidTielke]

Hat wenig mit der Selbstständigkeit zu tun, ich kenne viele Entwickler die genau das machen, nicht selbständig sind und noch immer ihren Job haben. Geht ja am Ende darum, alles besser zu machen.

[@Zatarra48]

Es geht auch angestellt. Im Zweifel heißt "nein" da auch abgeschwächt: Protestieren dass die Umstände ein gutes Projekt unmöglich machen. Entweder wird man gehört oder man hat wenigstens im Nachhinein die Sicherheit nicht verantwortlich gemacht zu werden. In meinem kleinen Unternehmen ist es zu 90% die erste Variante gewesen und es wurde korrigiert. Es ist viel mehr Gift fürs Unternehmen wenn keiner was sagt. Vorrausgesetzt alle haben grundsätzlich das Ziel gute Produkte abliefern zu wollen. Gerade in den Unternehmen dich sich alles außer die Entwickler sparen, gibt es sonst ja auch niemanden der protestieren könnte :D

[@DavidTielke]

Stimme dir vollkommen zu!

[@opodendorf]

Selbständig sein ist doch keine Frage von Glück, sondern eine aktive Entscheidung.

[@DavidTielke]

Guter Punkt und eine Entscheidung die wohl überlegt sein will....

[@JonDoe-ux5gm]

Tolles Video! Welche beiden Stakeholdergruppen wurden bei dem Kunden im Video bei Minute 9 eigentlich noch vergessen?

[@DavidTielke]

Hey, vielen Dank! Das DevOps Team und der Support waren die anderen beiden. Gruß David

[@MiniCmaX]

So ist es eben, Software-Entwickler machen nie das, was sie sollen und wenn, dann machen sie es falsch, sagt der Chef oder der Kunde😂😅😂. Und auf jeden Fall dauert es immer zu lange, egal was sie machen. Wie häufig habe ich gehört:"Das machen wir doch eben einfach mal schnell🤡" Selten einen Spruch gehört in dem aber auch jedes Wort im Widerspruch zu den anderen steht🤣 Mit 'wir' war natürlich nie derjenige gemeint von dem der Spruch kam🥴 Hat mir eine ganze Weile Spaß gemacht, habe es aber aufgegeben nachdem der Spaß den Stress nicht mehr aufwog.

[@DavidTielke]

Oh ja, "das ist doch hat nicht so viel Aufwand" kenne und liebe ich auch sehr - ein Klassiker :)

[@MiniCmaX]

​@@DavidTielkeDer Spruch ist meistens vom Verkäufer/Chef, nicht selten völlig ungetrübt von jeglicher Sachkenntnis bzw. Kenntnis der Auswirkungen🤡🥴

[@DavidTielke]

Absolut, das waren alles mal Profi-Entwickler ;)

[@MiniCmaX]

​@@DavidTielkeIn meiner Zeit kam 4GL auf, Smalltalk u.a., jedoch keine mit einer vernünftigen Anbindung zu relationalen Datenbanken. Eine brauchbare 4GL wurde intern entwickelt, die Ergebnisse der Interviews zur Pflichtenhefterstellung wurden in ein CASE-Tool übertragen. Ich habe mir die Mühe gemacht dieses CASE-Tool auszulesen und in eine Anwendung zu übertragen, die daraus die Beschreibung eines Anwendungsprototypen erzeugte und diese Beschreibung auch ausführen konnte. Wenn die Beschreibung des Anwendungsprototypen hinreichend genau war, dann wurde mit dieser Beschreibung ein Anwendungsgenerator gefüttert. Die Arbeit steckte damit in der CASE-Beschreibung und dem Generator für die 4GL-Anwendung. Fehler wurden damit in ihrer Güte völlig anders, es wurden überwiegend systematische Fehler, deren Ursachen im Generator behoben wurden, vagabundierende Fehler (logische Programmierfehler, Flüchtigkeitsfehler) kamen in der Endanwendung nur noch in den manuell individualisierten Anwendungsbereichen vor, sofern nicht beim Softwaretest aufgefallen. Das war der Teil, der mir am meisten Spaß gemacht hat, die Herausforderung aus Softwareentwicklung weitestgehend in eine Softwareproduktion zu machen. Damit wurde die Dauer bis zur Bereitstellung des ersten Anwendungsprototypen beim Kunden dramatisch verkürzt und die Nähe der Anwendung zur Beschreibung im CASE-Tool nahm mit jeder Verbesserung im Generatorstrang zu. Der Zeitdruck nahm aber nie ab und ich war dann irgendwann raus. Als Entwickler sitzt man immer mindestens zwischen drei Stühlen, Verkäufer/Chef/Kunde und man selbst hat ja auch noch Ansprüche an Arbeit und Freizeit🤡🥴 Ich habe die Anzahl der Stühle auf zwei reduziert und mich selbständig gemacht, immerhin ab 1995 noch 23 Jahre bis zu meiner Rente. Softwareprojekte habe ich danach nur noch sporadisch gemacht als Auftragsarbeit, auch für die alte Firma. Mir hat in meinem Arbeitsleben viel geholfen, dass ich fast immer das tun durfte was mir Spaß machte und ich überwiegend auch noch sehr gut dafür bezahlt wurde. Jetzt komme ich aber auch gut ohne Arbeit und den allfälligen Stress aus.🤣😂🤣

[@ikemkrueger]

"Du bist doch Softwareentwickler, kannst du mir eine App programmieren für XY? Das dauert auch nicht lange."

[@cosmochaosmaker]

Vielen Dank für diesen Beitrag! 👍 Dieses Thema ist leider ein ständiger Begleiter in unserer Branche, und ich stimme allen Punkten zu. Häufig fehlt es Product Ownern (POs) an der nötigen Ausbildung und dem Willen, sich mit Requirements Engineering professionell auseinanderzusetzen. Ideal wäre es, Entwicklungsarbeiten erst dann zu beginnen, wenn alle erforderlichen Informationen vorliegen, damit die Arbeit effektiv und effizient durchgeführt werden kann. Darüber hinaus wird die Rolle des Chief Information Officers (CIO) oft unterschätzt. Ebenso wird übersehen, dass Software- und Prozessentwicklung Teamprozesse sind, die die aktive Beteiligung aller Stakeholder erfordern. Diese Prozesse sollten in erster Linie vom CIO in Abstimmung mit dem Chief Technology Officer (CTO) vorgegeben und durch kontinuierliches Feedback in den ersten Sprint-Groomings und Retrospektiven feinjustiert werden.Das Fehlen von Retrospektiven und eine direkte Entwicklungsbeteiligung des CTO ohne das Verfassen von Tickets oder das Befolgen eines klar definierten Prozesses spiegeln zudem eine problematische Erwartungshaltung und ein Mangel an Prozessverständnis im Management wider.

[@DavidTielke]

Hey, sehr gerne! Perfekte Ergänzung, stimme Dir vollkommen zu - finde den Aspekt mit CIO und CTO sehr interessant, aus der Brille habe ich das noch gar nicht betrachtet. Gruß David

[@cowboyjo_]

Das finde ich ja interessant, wie viel ich aus dem Video auf meinen eigenen Arbeitsalltag ableiten kann. Ich bin selbst kein Softwareentwickler im klassischen Sinn, ich bin SPS Programmierer. Zu meinem Beruf gehören also nur ein paar Teile der klassischen Softwareentwicklung. Die genannten Rollen kenne ich so direkt nicht, jedenfalls nicht unter den Namen. Aber viele Tätigkeiten (oder sogar alle) hinter den Rollen gehören zu meine Projekten auch dazu. Meine Rolle würde ich dem Diagramm hauptsächlich als Architekt und Entwickler beschreiben, bei uns sind diese Rollen praktisch nie getrennt, da dass Entwicklerteam meist zu klein ist (viele Projekte programmiere ich alleine oder zusammen mit einem Entwickler des Kunden). Product Owner mache ich oft auch noch mit, und nicht selten auch den Product Manager. Die Probleme die dabei so entstehen sind aber oftmals genau dass, was du hier angeführt hast: - Ich bekomme eine vage Beschreibungen, was das Ergebnis sein soll und der Fertigstellungstermin ist gestern. - Dann stelle ich konkrete Fragen, was man sich denn genau bei Diesem und Jenen vorstellt (ich mache also selbst schon Produktvision, da der Stakeholder, der gleichzeitig das Projekt leitet, das nicht kann) und bekomme ein "keine Ahnung" als Antwort. - also entwickle ich nach bestem wissen und Gewissen und den vorhandenen Informationen ein Softwaregerüst und ein paar Grundfunktionen und zeige sie danach dem Kunden um zu erfahren, ob er sich das ganze so vorgestellt hat - so bekomme ich dann nach und nach während des Entwicklungsprozesses die Informationen, die ich brauche. -> wenn ich ein gutes Näschen habe und die Kundenwünsche vorhersehen kann, dann bekomme ich eine flexible Software hin, die sich leicht an ändernde Anforderungen des Kunden anpassen lässt, ohne zu komplex zu werden -> gelingt mir das nicht, muss unter hohem Zeiteinsatz, Änderungen durchführen und ganze Teile vom Code verwerfen Eine vernüftige Planungsphase, die jedes Projekt eigentlich benötigt, wird meistens als unnötig empfunden. "Für dieses Projekt ist das zu aufwendig, dass kann man einfach direkt umsetzen" Bei meinem jetzigen Projekt habe ich dann Stopp! gesagt und habe eine Komponentenanalyse der Hardware und einen Prozessablaufplan erstellt, aus dem ich dann einen 6 seitigen Fragenkatalog ableiten konnte, den der Kunde ersteinmal abarbeiten muss!, bevor ich über das Schreiben der nächsten Codezeilen nachdenke. In diesem Projekt hängt einfach zu viel schief, als dass ich die ganzen Fehler und Versäumnisse gerade bügeln könnte. Ich würde mich echt freuen, wenn im Maschinenbau auch langsam mal die Einsicht einziehen würde, dass eine vernünftige Projektplanung essentiell wichtig für eine planbare Umsetzung ist.

[@wjhann4836]

"Produktmanagement, Anforderungsanalyse, Architektur usw" - ich hab die schlimmste Version in einem DAX Unternehmen erlebt: Genau die mittleren Funktionen wurden an Freiberufler ausgegliedert, - einerseits musste ich als Anforderer immer neue Leute einarbeiten - andrerseits hatte die Architektur keine Linie - einer der Freiberufler, lange im Amt hatte sehr gute Visionen, wo die Architektur hin sollte, damit alte Schwächen beseitigt werden - aber er wurde nach ein paar Versionen (er hatte darin immer kleine Teile seiner Vision erfüllt) ausgetauscht, da er nicht auf die Feilscherei des Einkaufs einging (er wollte nicht mal mehr, nur seinen bisherigen Satz).

[@Life4YourGames]

Genau das Problem mit den fehlenden Richtlinien im Frontend haben wir in unserem Projekt auch. Da sind inzwischen 4 Jahre technische Schulden drin. Nicht zuletzt weil man Backend-Developer gezwungen hat, Frontend Code zu schreiben, "weil es dann ja schneller geht" bzw., voran gehen muss. 🤷‍♂️

[@DavidTielke]

Hey, und wer wird bei Euch verantwortlich gemacht? :D Gruß David

[@keyoslive]

Verwandle technische Schulden in Projektschulden!

[@ManuelBTC21]

Deswegen hat es sich (wo möglich) etabliert, möglichst kurze Iterationszyklen zu haben. Wenn man alle 2 Wochen oder gar kontinuierlich einen funktionierenden Stand abliefern kann, dann fällt den Stakeholdern überhaupt erst auf, was sie selbst nicht wussten, was sie nicht kommuniziert haben, was falsch verstanden wurde, welche Anforderungen nicht bedacht wurden, oder einfach als Selbstverständlichkeit angenommen wurden usw. Es vermeidet auch das Phänomen des Wunschkonzerts, da jedem klar ist, dass man in den nächsten zwei Wochen nicht komplett fertig werden kann, wodurch eine Priorisierung stattfindet. Davon abgesehen ist der tatsächlich nötige Entwicklungsaufwand bei größeren Projekten äußert schlecht abschätzbar, was man aber durch den kontinuierlichen Prozess umgeht, da man einfach immer etwas abliefert und der Kunde zahlt nur so lange, bis er zufrieden ist (oder ihm das Geld ausgeht...).

[@wjhann4836]

Alles was Du sagst, ist mir schmerzlich vertraut. Ich wundere mich allerdings immer über Projektmanagement: - Es heißt immer, der Projektmanager soll managen, nicht mit machen. Anders: Er soll im Streitfall das Spielfeld nicht betreten. - Ich hab das so gehalten: A erzeugt ein Dokument (Dein "Artefakt" kommt mir zu sehr von Tomb Raider 😉). Das Dokument - wenn denn nötig, hat auch einen oder einige "Verbraucher", Anwender. Also schaue ich das Dokument offiziell gar nicht an - sondern lasse es mir von den Verbrauchern testieren. Wenn die es akzeptieren, müssen sie damit leben. OK, manchmal hab ich schon einen Anwender gefragt, ob er sich über eine Sache sicher ist, es verstanden zu haben). Leider wurde dieser Gedanke im Unternehmen regelmäßig torpediert, weil die BWLer nur ihr Zaun Denken durchsetzten (ich werf das Dokument über den Zaun, ab da läuft die Uhr für den Nächsten - was auch ziemlicher Quatsch ist).

[@TheCarmacon]

Als ehem. Systemtester und ehem. SW-Entwickler: kann bestätigen, dass die SW-Entwickler IMMER schuld sind :D Und genau deshalb bin ich keines von beidem mehr.

[@LarsPW]

Selbst wenn Rollen wie Product Manager, Product Owner und Project Manager nicht oder nur teilweise besetzt werden, können häufige Kurswechsel - also grundlegende Änderungen der Spezifikation - in einem Projekt ja nicht verborgen bleiben. Ich erlebe es in meinem Betrieb häufig, daß zu spät mit dem Bauen begonnen und vorher Gott weiß was zu lange getrieben wird (Anforderungen definieren zählt leider nicht dazu), m.a.W. nach der Devise verfahren wird: Bauzeit = Zeit bis zum Termin - Palaverzeit, gleich welche Schätzung man angibt. Viele Entwickler denken allerdings auch nicht sonderlich weit und ich möchte mal behaupten, daß Scrum seinen Anteil daran hat.

[@DavidTielke]

Wenn du eine gute Produktvision hast die auch verfolgt wird, sollte das nicht passieren. Ich denke das Problem des nicht mitdenken, haben nicht nur die Entwickler :)

[@MCLAXAP]

Dev: "Wie lange soll der Nachname max. sein dürfen?" PO: ??? Dev: "Ja, dann frag mal nach und noch welchen Zeichensatz, komplett UFT-8?" Sec-Type: "Aber keine Hochkomma zulassen wegen SOLi und die anderen Sachen filtern" 3 Wochen später PO: "minmale Länge 5 Zeichen, max. Länge 50 Zeichen und nur a-zA-Z, ist ja ne interne App und hier reicht das" 3 Monate später Ticket: "Der neue Kollege aus Irland kann sich nicht anmelden, der heißt irgendwie O'Brien oder so" 2 Monate später Ticket: "Die neue Kollegin Xi aus China bekommt immer ne Fehlermeldung" GF: "Sind meine Dev alles blöd, können die überhaupt was? Alle Devs zum Rapport!" Genau so erlebt 😀

[@svenwilkens5617]

Ich sage einfach mal so, wenn der Chef in einer Abstimmung kommt. Entwickler haut in die Tasten und erzeugt Quellcode und du Projektmanager Manage die Kunden, fürs reden und malen hier werdet ihr nicht bezahlt! Da war ich wirklich mal sprachlos und habe mir gefragt, ist das gerade wirklich passiert. Ja ist es

[@tldw8354]

Das wäre doch ein Grund, sich einen anderen Arbeitgeber zu suchen.

[@psymcdad8151]

11:02 Oha... ich hab ne Zeitlang als Nebenjob Software geschrieben. Das war auch nach dem schema "Mach mal..." ...Tjo, Ich mach und bekomm was Lauffähiges und größtenteils Bugfreies hin, und dann muss was geändert werden. "Nur ne' Kleinigkeit"... aber da ich nicht von vornherein wusste das diese "Kleinigkeit" gewünscht war musste ich das komplette Programm einmal auf links drehen. Komplett neuschreiben wär da letzten Endes vermutlich leichter gewesen. Aber weils ja nur ne' Kleinigkeit war muss man ja am Terminplan nix ändern. 5 Tage später mit insgesammt 12 Stunden Schlaf (Wie gesagt: Nebenjob. Ich hatte noch einen Normalen 40-50h/Woche Job als Haupterwerb...) liefer ich etwas ab, das zwar grob den neuen Vorgaben entspricht, aber halt noch verbugt ist ohne ende und keinerlei Exceptionhandling aufweist. Wurde zum glück angenommen, also jetzt noch schönmachen und dann... kommt die nächste Kleinigkeit... Nach 5-6 Monaten war ich komplett durch und hab hingeschmissen. Seitdem Programmier ich nur noch als Hobby, und nur selten was mit mehr als 500 Zeilen.

[@bowlingguy7755]

Die Softwareentwickler sind immer schuld, weil das jener letzte Schritt ist, den die Benutzer letztendlich zu sehen/spüren bekommen. Die "unsichtbaren" Vorgänge vor oder während der Softwareenwicklung werden nicht wahrgenommen.

[@opodendorf]

Alles halb so wild, solange man keine Festpreise macht. Das ist kein Problem der Entwickler, sondern des Vertriebs. Wer "vorne" einspart, zahlt "hinten" drauf.

[@DavidTielke]

Ist weniger eine Frage von Festpreis vs. Leistungsbezogene, als eher eine Frage das Softwareentwicklung so nicht funktioniert :) Aber der letzte Satz drückt es sehr gut aus :)

[@wjhann4836]

"Sag einfach mal NEIN" - das wird doch gerne durch die Zaun Thematik ausgeschlossen 🤧

[@anyaplays7150]

Nach meiner Erfahrung versteckt sich die "Businessabteilung" gerne dahinter, dass die Softwareentwickler/innen das ja alles machen sollen. "Ja, wir brauchen jetzt ne TSE, macht ihr mal" (Bonpflicht, kennt inzwischen jeder ;)). "Ne, nicht nur online, auch eine offline." Aber was das Ding können muss, musste ich bzw. wir dann eben selbst rausfinden. Das ist aber auch nicht das erste Mal und das passiert immer wieder. Es muss halt funktionieren und das wird dann auch erwartet. Und dann wird gefragt, wieso das denn so lange gedauert hat. Ja, haha, warum wohl. Keine Ahnung, wie man das aus den Leuten raus kriegt.

[@JonDoe-ux5gm]

Es wäre ganz toll, wenn Du mal ein Video zu den Rollen in der Grafik erstellen könntest. Nur dann eben inkl. Details zu den anderen Rollen z.B. typische Stakeholder, Zusammensetzung des Entwicklungsteams, UX/UI usw.

[@DavidTielke]

Hey, das ist schon lange auf meinem Zettel, aber das bedarf einiger Vorbereitung und deshalb schiebe ich es immer wieder vor mir her - aber ich hoffe bis zum Sommer ist das Thema soweit durch :) Gruß David

[@wjhann4836]

Ich finde - aus meiner Erfahrung - dass in DE super oft ein Fehler gemacht wird: Die Unternehmen arbeiten wie hinduistische Gemeinschaften mit strengem Kasten Denken. - Die "Guten" "Großen" "Führungskräfte" erstellen die Anforderungen - die unteren Kasten (die mit der SW dann arbeiten) werden NICHT gefragt Meine leidvolle Erfahrung: Sehr viele der Anforderer haben keine Ahnung, wie der Laden läuft, was er braucht - aber die definieren einfach.

[@richardbck1829]

ich sehe keinen deutlichen Unterschied zu anderen technischen Entwicklungsteams

[@user-gi9uh8eu6x]

Immer wenn du solche Probleme ansprichst und erklärst denke ich:" Jo GENAU SO ist es bei uns auch das Problem. " :D Eine Produktvision haben viele bei uns aber einen klaren Plan niemand😅 Aber wie sage ich nein wenn ich zb ein 20 Jahre altes Produkt mit 3 Leuten neu aufsetzen soll aber ALLES so bleiben soll wie im alten System? Egal ob Dinge nicht mehr zeitgemäß sind oder einfach sehr schlecht. Am Ende waren wir als Entwicklung am Ende der Nahrungskette und das Projekt ist nach 2 Jahren gestorben wie wir in den ersten Wochen schon befürchtet haben.

[@DavidTielke]

Hey, guter Punkt - ich argumentiere immer wie in dem Video hier: kzbin.info/www/bejne/bIKoh2qupMxqhLs Wenn ihr etwas neu Entwickeln müsst, muss es irgendwelche Fehler in der Vergangenheit gegeben haben, die zu diesen Resultat geführt haben. Wenn diese Fehler nicht abgestellt werden, kann man so viel Geld und Zeit wie man will in die Hand nehmen, das neue Ergebnis ist immer so schlecht wie das letzte. Deine Geschichte ist (mal wieder) ein perfektes Beispiel - Danke dafür! Gruß David

[@dustmarcus]

Welche Rolle hattest Du dabei?

[@dullyvampir83]

In dem Prozess scheint auch kein Feedback formal vorgesehen zu sein. Das die Entwickler den Leuten in der Pipeline sagen koennen: "Sorry das sind unrealistische Anforderungen, das und das muss geandert werden, sonst machen wir das nicht." Aber das ist wohl in den Hirachien von Unternehmen nicht moeglich.

[@davidmares6053]

gracias

[@DavidTielke]

Sehr gerne!

[@MarkusBurrer]

Bei uns in der Produktion ist es genau anders rum. Es werden immer weniger Leute, die die eigentlichen Produkte fertigen und immer mehr Manager. Ich vergleiche das immer mit einer römischen Galere. Die in der Produktion rudern, die Manager trommeln. Es ist irgendwann egal, wie viele Trommler es gibt, wenn nicht mehr genug rudern

[@MiniCmaX]

😜Und wenn der Chef Wasserski bzw. Porsche fahren will, dann wird eben schneller getrommelt🥴🤡

[@ExtremeTeddy]

Was leider häufig noch viel schlimmer ist, als die von dir beschriebenen Probleme, sind Features bzw. Feature-Suites in den Anwendungen die bereits vollmundig an den Kunden verkauft wurden und dann bereits gestern geliefert werden sollen. Mit dem Zusatz das die eigentlichen Anforderungen weder definiert sind noch die techniche Umsetzbarkeit überhaupt geprüft wurde. Wenn man dann als Dev das ganze falsch einschätzt, was relativ leicht passieren kann, dann verzögert sich ein an sich gut umsetzbares Projekt um Welten. Mir zuletzt passiert bei der Anbindung einer Türklingel Anlage ... das Ding läuft nun zwar, aber der Anbieter hat bereits 3 API Varianten im Umlauf in unseren WOhnanlagen und wir wussten davon auch nichts ... sprich stille Bugs durch fehlende Kommunikation seitens der Partner ist ein weiterer Faktor der einen gerne torpediert...

[@mxz2024]

Menschen suchen meistens die Schuld bei anderen und bei Softwareentwicklern ist es besonders einfach, da sie am Ende der Nahrungskette stehen , unter den Managern

[@DavidTielke]

Thats it!

[@dagochen]

Shit in, Shit out.

[@easypy]

Kommt mir irgendwie bekannt vor :D

[@DavidTielke]

Ich hoffe nicht die Probleme ;)

[@nomanomen4611]

@@DavidTielke Ganz einfach ohne sauberes Fundament und Guten plan baut man kein haus das mus man den BWL lastigen verantwortlichen aber Erklären die haben zu viel Unsinn im Kopf ( komische Kennzahlen und so das verstopft das Gehirn )

[@TheMino1337]

Gibts ne realistische Chance als interessierter Quereinsteiger seine Brötchen mit Softwareentwicklung zu verdienen ? Ich finde immer nur teure Schulungsanbieter, die mir beibringen was ich schon weiss mich aber danach weitervermitteln wollen.

[@DavidTielke]

Klar kannst Du das, aber wofür genau brauchst du einen Schulungsanbieter? Lern eine Sprache/Plattform, mach ein paar private Projekte, Tage etwas zu OpenSource Projekten bei und dann bewirb dich einfach mit den GitHub -Projekten. Bei dem aktuellen Fachkräftemangel bekommst du dann schon was. Gruß David

[@TheMino1337]

@@DavidTielke Guter Fahrplan. Mein nächstes Problem wäre gewesen das ich keinerlei Ideen habe zu eigenen Projekten aber bestehenden OpenSource Projekten etwas beizusteuern hatte ich noch nicht auf dem Schirm. Thx

[@rudigermoller587]

Die ganzen Zwischenrollen führen (weil oft auch nicht kompetent besetzt) am Ende nur zu schlechterem Informationsfluss und vor allem auch ungeeignetem SW Design. Idealerweise übernehmen Entwickler Poduct Owner Rollen. Je weiter die Entwickler von den Stakeholdern entfernt sind, desto schlechter, langsamer und teurer wird das Produkt/Entwicklung

[@aminkharchi166]

Selbst beim Nein-sagen ist der Entwickler am Ende schuld. Weil er es meistens eben nicht sagt. Ergo: der Software-Entwickler ist immer schuld.

[@myopinion1309]

Der Macher ist immer der Schuldige.

[@DavidTielke]

Meistens schon, das stimmt :)

[@tldw8354]

Selbst als Angestellter - der ich nicht bin - würde ich wahrscheinlich auf die Leute da oben zugehen und mit denen ein Gespräch suchen, um zu verstehen, was die genau wollen. Ich würde definitiv nicht einfach nur etwas auf Geheiß programmieren. Selbst wenn man mich dann kündigen würde - es wäre mir absolut egal.

[@vorrnth8734]

Manchmal wi wird man als SW Entwickler auch für Hardwarefehler verantwortlich gemacht. Einfach weil der in der GUI gemeldet wird 🤣. Wenn die Software mit ner Meldung anhält, weil das Filament der Röntgenröhre durch ist, ist das kein Absturz. Das Filament muss wirklich in der Röhre getauscht werden.

[@iamwitchergeraltofrivia9670]

Solange die es fixen hinterher habe ich kein Problem

[@user-cm1mq9gx3z]

Kann ich alles absolut nachvollziehen, aber es fehlt noch eine wichtige Variable: der Anwender. Kaum eine Software, die ich in meinem Unternehmen nutze, ist wirklich Anwenderbezogen. Da fehlen oft die simpelsten features bzw. könnte man durch den Einbau einger weniger, einfachen Features die Software erheblich verbessern. Aber uns fragt ja niemand. Hauptsache, wir zahlen für den Mist. Adobe Acrobat Pro ist da ein richtiger Musterkandidat; das kann vieles, aber kaum etwas wirklich richtig gut. Habe schon oft Feedback dazu abgegeben, wenn ich danach gefragt wurde, aber passiert ist nie was. Im Endfeefekt muss ich wieder 2-3 verschiedene Programme nutzen, um ein einziges Ziel zu erreichen.

[@thygrrr]

Schuld is, wer 2024 noch im Waterfall-Prozess arbeitet.

[@iamwitchergeraltofrivia9670]

Ach ja

[@summersendband]

Kann euch beruhigen. Bald ist dann die AI schuld.

[@onkelbob5469]

ich bin immer schuld. es gibt nur mich in der firma der code schreibt und alles wissen und können muss ...

[@gronkhfp]

Ich wurde letztens blöd angemacht, dass mein Feature zu lange gedauert hat, obwohl das Ticket super konfus gestellt war, das bestehende Feature vom backend bis zum Frontend komplett umgeschrieben wurde und generell die komplette Architektur umgestellt werden musste. Das war weder dem Management noch den Seniordevs bekannt. Zudem wurden den Kunden auch wieder Sachen versprochen, die einfach nicht machbar sind 😊. Achja Testing gibts auch nicht und die awareness dafür ist auch nicht existent

[@DavidTielke]

Klingt genau nach dem angesprochenen Problem, das bei euch nur sehr wenige wirklich Ahnung von Softwareentwicklung haben ;)

[@IT-Entrepreneur]

Irgendwie kommt mir das alles so bekannt vor 😂.

[@DavidTielke]

Das tut mir leid... 😂

[@samtigernotiger3886]

Mal kurz zusammengefasst: Die Entwickler sind schuld, wenn sie nicht die Arbeit aller anderen Beteiligten bewerten und bei schlechter Arbeit nein sagen. Hmm .... Mal abgesehen davon, dass die Entwickler, um diese Zuarbeiten bewerten zu können, Kompetenzen und Informationen brauchen, für die sie weder bezahlt noch eingestellt werden ... Wenn sie dann Nein sagen, werden sie meiner Erfahrung nach, als inkompetent verrufen und sind folglich ebenfalls Schuld daran, dass das Produkt nicht fertig wird. Also mal ohne all das Gebims: Die wesentliche Schuld der Entwickler liegt darin, dass sie ganz am Ende der Kette stehen. Dass sie weisungstechnisch unter all den anderen Instanzen stehen. Das nennt sich klassisch Schuldumkehr! Natürlich ist nicht der Projektmanager schuld, der die Anforderungen verkackt hat, oder der Architekt, der nicht gründlich über die Konsequenzen seiner Entscheidungen nachgedacht hat, Nein, es ist der Entwickler, der den Projektmanager und dem Architekten nicht rechtzeitig erklärt hat, wie diese ihre Arbeit richtig zu machen haben. Tzzzzzzz

[@DavidTielke]

Moin, ja ist wohl etwas falsch angekommen oder du willst es bewusst falsch verstehen - die Entwickler haben nicht die Aufgabe den anderen ihre Arbeit zu erklären, sondern Missstände und Fehler in der Entwicklung aufzuzeigen (Kernpunkt der agilen Softwareentwicklung). Du konstruierst hier eine Schuldumgeht da rein, nicht ich.

[@samtigernotiger3886]

@@DavidTielke Den feinen Unterschied zwischen "anderen ihre Arbeit erklären" und "Missstände und Fehler in der Arbeit anderer aufzeigen" sehe ich in der Praxis nicht. Nicht ich konstruiere etwas, du möchtest deine Aussagen nicht bis zum Ende durchdenken. Konsequent zu Ende gedacht wäre eine Strukturumkehr nötig: Produktmanagement und Softwarearchitektur müssten der Entwicklung untergeordnet sein und von dieser beauftragt werden. Dann könnte die Entwicklung auch Fehler in den Auftragsarbeiten bemängeln und Verbesserungen einfordern. Dass so etwas weit von jeglichen reale existierenden Strukturen entfernt ist, weist du selber.

[@DavidTielke]

@@samtigernotiger3886 Ich denke wir kommen da meinungstechnisch nicht zusammen :)

[@aminkharchi166]

Ich bin seit 25 Jahren in Kundenprojekten (meistens Legacy) Software-Entwickler. Heute weiß ich nur eines: es wird zwar gerne so getan, als ob man meine Meinung wissen will, aber nur so lange sie konform ist. Irgendwann habe ich resigniert und heute weiß ich nur eines: wir sind nur die Code-Monkeys. Es gibt keinen Anhaltspunkt, das wir irgendwie für die paar Kröten uns Stress machen müssen, alle anderen in dem gezeigten Diagramm (Projektmanager, POs usw.) verdienen viel mehr Geld. Dann sollen die auch die Verantwortung übernehmen.

[@matthiaspigerl1158]

Es ist richtig, dass oft Wissen über die verschiedenen Rollen fehlt. Aber es ist gerade bei kleinen Firmen kaum möglich, diese alle mit unterschiedlichen Personen zu besetzen. In meinem aktuellen Projekt: 20 Angestellte in der Firma: Medtech, HW und SW. Medtech = viele Doku, viele Tests, usw. HW Team entwickelt Elektronik u Firmware mit 3 Personen, jeder Mitarbeiter erfüllt 5 Rollen gleichzeitig. SW Team mit 6 Personen ruft ständig nach mehr Dokupersonal, Architekten, ScrumMaster, Software QA, usw das geht eben oft finanziell nicht. Vollkommend einverstanden, dass SW Entwicklung mehr wie coden ist. Aber gar nicht einverstanden, dass manche Entwickler nur coden wollen und für alle anderen Tätigkeiten immer nach exklusiven Personal rufen. Das es länger dauert, bei mehreren Rollen in einer Person ist klar, dass ein Entwickler nicht auch mal dokumentieren kann oder verifizieren oder als Feature owner arbeiten kann, dagegen nicht.

[@rethardotv5874]

Wenn ich ein Team aus hochbezahlten Entwicklern habe, sollte ich erwarten können dass ich denen Anforderungen zuwerfe und nach jedem Sprint zumindest theoretisch was lieferfähiges habe, egal wie schlecht mein requirements Engineering ist. Was in den meisten Projekten schief läuft ist vor allem dass blind entwickelt wird: der Kunde ist nicht einbezogen, es werden viele Sachen angenommen und trotz agiler Entwicklung sind die einzigen stakeholder im review der PO und das Management.

[@aminkharchi166]

Was heißt hochbezahlt? Die meisten Entwickler haben ein normales Gehalt. Gerade Software-Entwickler sind in so einem Komplex wahrscheinlich die nicht hoch bezahlten. Hochbezahlt sind diejenigen, die mit Klemmbrett und Kugelschreiber rumlaufen. Denn allgemein ist der Software-Entwickler nur der Code-Monkey. I

[@user-fd1ru8bt8e]

Warum braucht man Intro heutzutage? 😅

[@DavidTielke]

Weil ich es cool finde 😂

[@ralfwarnat9257]

warum bekommt David weniger Likes als Kommentare?

[@EshmesVid]

Quatsch, Schuld ist immer der ,der viel macht. Und das Arbeitsleben besteht daraus dafür zu sorgen das andere mehr machen wie du.

[@garymuller9771]

Du widersprichst dir im Intro selbst

[@DavidTielke]

Interessant

[@mia30vh]

die Schuld und eure Sünden gebt Jesus Christus

[@christianbaer2897]

Fehler Nummer 4: Man hält sich an einen solchen Prozess und wundert sich dann, dass das alles nicht funktioniert. Der aufgemalte Prozess ist ein klassischer Wasserfallprozess und die funktionieren erfahrungsgemäß einfach nicht. Selbst wenn man alle diese Rollen gut besetzt und einen tollen Projektplan, eine gute Architektur und eine klare Produktvision hat, hat man ein Problem. Es braucht ja trotzdem Zeit. Zeit in der sich die Welt weiterdreht und -bewegt. Zeit in der die Ideen nicht validiert werden. Allein die Frage "Was machen die SW-Entwickler die ganze Zeit" zeigt mir, dass es keine kurzen regelmäßigen Feedbackzyklen gibt und sich niemand (oder nur wenige) Zwischenstände angucken. Natürlich kann man Module entwickeln und einzeln abarbeiten und zusammenfügen. Nutzt halt nur nix, wenn das fertige Produkt dann doch nicht auf die Realität passt, weil niemand mal mit den Leuten geredet hat, die die Software dann nutzen müssen. Lösung: Agile Softwareentwicklung. Damit meine ich sicher nicht Scrum oder sowas wie SAFe. Schmeißt Jira weg, nehmt Zettel (meinetwegen auch digital mit Miro), baut euch ne vernünftige CI-Pipeline (CD nur für Fortgeschrittene) und seht zu, dass ihr die Software nach jedem Änderungsschritt in die Hände der tatsächlichen Anwender bekommt. Redet einfach ständig drüber was gerade nicht klappt und wartet nicht 2 Wochen auf eine Retro, auf die sowieso niemand Bock hat, weil sich da ein Scrum-Master oder "Agile-Coach" vorne hinstellt und als erstes sagt "Wenn ihr den Sprint also Gemüse bezeichnen müsstet, was wäre er dann." (Auch hier gilt: Ein Coach muss Ahnung davon haben was und wen er da coacht. Ein Agile-Coach der nicht coden kann, kann nur sehr sehr begrenzt helfen)

[@DavidTielke]

Hey, das gezeigte ist eine Prozessdefinition, wo genau siehst Du da einen klassischen Wasserfallprozess? Ob ich diesen Prozess statisch oder agil ausführe ist doch gar nicht ersichtlich und für das Beispiel hier im Video und die angesprochenen Probleme komplett irrelevant? Agilität siehst Du nicht an einer Prozessdefinition, sondern an seiner Ausführung und der Einhaltung der agilen Werte und Prinzipien. Sehr schöne heile agile Welt die du da beschreibst, bin in der Theorie komplett bei dir (habe ja zwei mal im Video gesagt, dass in der Prozessdefinition noch einiges fehlt, z.B. das von dir angesprochene Devops). Es gibt auch Projekte wo es schlicht noch keine Anwender/Kunden gibt. Es gibt Projekte wo die Zieldefinition ziemlich klar ist, die natürlich unterwegs agil ggf. angepasst werden kann. Es gibt Projekte wo man einfach ein Preisschild dran hängen muss. Klar muss man ständig über Probleme reden, dafür gibt es Impediments im Daily. Wenn Ihr so eine langweilige Retro macht, habt ihr einfach einen schlechten Scrum Master / Process Owner. Der agile Coach sollte Ahnung von Softwareentwicklung haben, aber nicht zwingend programmieren können. Der Scrum Master muss definitiv nicht programmieren können, der ist für den Prozess zuständig und da sind andere Dinge wichtig. Das ist ja so, als wenn man sagt der Product Owner muss programmieren können. Das besagte Team entwickelt mit Scrum (2 Teams a 5 Personen, einem Product Owner und einem Scrum Master), ordentliche Dailies, ordentliche Retrospektive - am Ende war das Problem das man gemeint hat, agile Softwareentwicklung löst alles auf magische Art und Weise (und Du scheinst diese Ansicht ja zu teilen) und natürlich die Transparenz und Kommunikation außerhalb der Softwareentwicklung - so einfach ist die Softwareentwicklung dann doch nicht. Gruß David

[@christianbaer2897]

@@DavidTielke Wo ich den Wasserfall sehe? Im Bild. Jemand hat eine Idee, daraus wird ein Plan gemacht und die Entwickler setzen den dann um. Das ist Wasserfall. Agile Softwareentwicklung löst mit Sicherheit nichts von allein und magisch ist das auch nicht. Hinzu kommt, dass Scrum alles mögliche ist, aber eben keine agile Softwareentwicklung. Ob Coaches das beherrschen sollten was sie versuchen zu verbessern, halte ich nicht für diskussionswürdig. Wenn der Scrum Master für den Prozess verantwortlich ist ohne zu verstehen wie Entwickler arbeiten, weil er es selbst nie gemacht hat, sind keine großartigen Ergebnisse zu erwarten. Dass ein agile Coach nicht programmieren muss ist ungefähr so, als wenn ein Fußballtrainer nicht dribbeln kann. Er muss ja nur den Trainingsprozess managen, oder wie? Das funktioniert nicht. Nicht umsonst gibt es im spitzenfußball extra Torwarttrainer, weil der Mannschaftstrainer das nicht kann.

[@christianbaer2897]

@@DavidTielke Und wenn es noch keine Anwender gibt, für wen wird die Software geschrieben und warum?

[@DavidTielke]

@@christianbaer2897 In dem Bild siehst Du Aktivitäten, die Artefakte durch Rollen erzeugen und eine Darstellung worauf die sich auswirken. Ob die gesamte Vision erst erzeugt wird, dann die Anforderungen, dann der Plan und dann der Code (das wäre Wasserfall) ist doch gar nicht dargestellt?!? Ich verstehe nicht wie du ohne eine dynamische Darstellung eines Prozesses (wer macht was, wann) eine Beurteilung machen kannst, das etwas wasserfallartig abläuft? Du machst Annahmen darüber, das verstehe ich, aber in keinem Satz im Video wird das so beschrieben wie du es interpretierst?

[@DavidTielke]

@@christianbaer2897 Wie im Video gesagt, Vorgaben von der Geschäftsführung für das Zielprodukt.