75% aller Softwareprojekte scheitern - was Du dagegen unternehmen kannst // deutsch

[@thenativeweb]

Du möchtest das Video an jemanden weiterleiten, die oder der aber lieber liest? Dann findest Du den passenden Artikel zum Video bei Heise Developer: www.heise.de/blog/75-Prozent-aller-Softwareprojekt-scheitern-was-tun-9979648.html

[@toTheMuh]

6:04 - DANKE! Für mich als Software-Entwickler ist es von essenzieller Bedeutung den Kunden, User, Markt und das Produkt zu verstehen. Unternehmen, in denen dies nicht gern gesehen bzw nicht gefördert wird, weil der Entwickler ja nur zum Programmieren da sei, werden für mich direkt uninteressant.

[@marcom.]

Meine persönliche Erfahrung nach 30 Jahren in der Software-Entwicklung: Es fehlt an 1) Fachbereitsleuten, die einem wirklich sagen können, was sie wollen und wie die neue Software das unterstützen soll, und 2) an wirklich guten Software-Entwicklern, die ihren Beruf als seriöse Ingenieurstätigkeit sehen, mitdenken und wissen, was sie tun.

[@3rgoflix]

Fachbereitsleuten, die einem wirklich sagen können, was sie wollen - sollte mal eine Webseite für jemanden aufbauen. Aber was kam von der Person, rein gar nichts, außer ein paar Bilder. Hab das Projekt sein gelassen. Hab keine Lust, solchen Leuten hinter her zu rennen. Am Ende haben sie sich eine WebSeite von jemandem anderes machen lassen. Sah nicht besser aus, wie das, was ich vorhatte. Egal. Abgehakt und weiter machen.

[@saschazapf5232]

Ich arbeitete bis vor kurzem in der Industrie und bekam kunterbunt Aufträge in verschiedensten Abteilungen Prozesse und Daten in neuer Software abzubilden oder neue Daten in alte Software zu integrieren. Ich versuchte mir immer Anfangs möglich viel Zeit für die Fachlichkeiten der Abteilungen zu nehmen und habe mir vom Auftraggeber immer einen möglichst kompetenten Paten gewünschte mit dem ich eben diese Sachen abklären kann. Leider habe ich sehr oft erlebt das man gerne Software haben wollte die alles kann mir aber keiner auch nur einen stabilen, gelebten Prozess einwandfrei erklären konnte. Oft ist es darauf hinaus gelaufen das ich die erste Hälfte des Projekts erstmal die Prozesse aus den Arbeitsanweisungen und Qualitätskontrollplänen heraussuchen und mithilfe des Paten "zum Leben erwecken" damit ich dann die passende Software dafür schreiben konnte bzw. die Eingabe/Ausgabemaske auch den Schritten im Prozess zugehörig schreiben konnte. Das war so ermüdend das ich letzten Endes hingeschmissen hab.

[@deltapi8859]

Dieses Video trifft den Nagel auf den Kopf. All diese Probleme kann ich nach 7 Jahren professioneller Softwareentwicklung bestätigen. Es fasziniert mich auch, wie Tech Worker häufig zu überzeugt und opinionated werden und so an der Sache vorbeireden, aber es ist halt die Norm.

[@rolfspeer5403]

Wir waren einmal zu zweit bei der Fachabteilung und haben uns über die gewünschten Abläufe informiert. Wir fragten, ob die Abläufe immer so sind. 'Ja, klar! Das ist immer so!' Daraufhin packten wir zusammen und waren schon an der Tür, als ein Teilnehmer sagte: '... außer bei Sonderfertigungsaufträgen!' - 'Wie, Sonderfertigungsaufträge?' In diesem Moment zerbröselte unsere komplette Konzeption.

[@SunSailor]

Tatsächlich ein extremes Problem, denn Menschen, die keine Software entwickeln, können sich gar nicht vorstellen, welche Auswirkungen Ausnahmen haben können. In der analogen Denke macht man da nen Vermerkt aufs Papier, interpretiert was anders und schon wird alles gut. Dass auch Ausnahmen funktional abgebildet werden müssen und dies mitunter aufwendiger sein kann, als der Standardworkflow, das verstehen viele echt nicht.

[@stevebula9369]

Du sprichst hier ein Problen an, dass ich bereits seit Jahren predige und mich zum Ausstieg aus dem SW-Consulting mit dem ständigen Wechsel der Branche bewegte..

[@mibeon]

Verschlimmern tut das Ganze, wenn plötzlich Leute aus Fachabteilungen herangezogen werden, die noch nie mit Software zu tun gehabt haben und, weil sie aus den Abteilungen kommen, glaubt man, sie könnten hier die Verantwortung für eine erfolgreiche, fachspezifische Entwicklung übernehmen. So spazieren diese Finanzleute, Personaler stolz durch die Gänge und fühlen sich als Software-Manager. Als wäre das nicht schlimm genug, sind sie absolut davon überzeugt (und machen davon maßig Gebrauch), von einem Tag auf den anderen, da ihre „Ideen“ als Entscheidungen im Zusammenhang mit Software-Entwicklung durchzusetzen. Das Problem ist immer der Mensch in seiner Gier, verfälschten Selbst- und Weltwahrnehmung und seinem Ego. Dieser Wahnsinn ist übrigens nicht nur bei den Software-Projekten zu beobachten.

[@thenativeweb]

Ja, das ist leider auch wahr - das ist dann quasi der Shift in die andere Richtung, wo es zu viel des Guten ist. Am Ende braucht es ein ausbalanciertes und gleichberechtigtes Miteinander, ansonsten funktioniert's nicht. Nur scheint das sehr schwer zu sein …

[@motzky]

Bei uns baut der Fachbereich gern mal einen Prototyp mit Excel und VBA, verteilt das an an dutzend Teams zum Test. Er nennt das dann MVP und möchte später, dass IT etwas ähnliches nachbaut, nur skalierbar und mit Datenschutz und CICD usw. Viel kosten darf es nicht und auch schnell fertig sein plus sich so anfühlen wie die Excel-Lösung. Btw wurde dann gern schon eine externe Agentur beauftragt, die schon mal angefangen hat etwas zu bauen, ganz ohne ITIL und DSGVO und all den anderen Richtlinien, die es bei uns zu beachten gibt.

[@linux912]

Habe ich anders erlebt und war froh gerade in Finanzthemen ( IFRS / HGB ) das mich die Kollegen unterstützten.

[@mibeon]

@@linux912 Sinnvoll unterstützen ist immer willkommen. Zu viel mitmischen und Software-Themen (bis hin zu UI und Funktion) überspannt den Bogen. Bremst man die Menschen höflich aus, geht das zwischenmenschliche Drama los. 🙂

[@3rgoflix]

@@motzky hier würde ich sagen, dann soll die externe Agentur es auch zu ende bringen.

[@realixbase6408]

Die Erklärung in diesem Video ist genau das, was ich auch immer wieder bemerke, aber bisher nicht die hier verwendeten Worte gefunden habe. Oftmals liegt der Fokus auf die technische Umsetzung, aber weniger auf dem fachlichen Kontext, bzw. den Anforderungen. Oft heißt es: "Die Software muss z.B. große Datenmengen verarbeiten können, darf dabei aber nicht viel Speicher benötigen und muss schnell sein, so dass das/die UI/UX nicht leidet.", oder "Es müssen alle möglichen Konfigurationskonstellationen abgedeckt sein!". Das Ergebnis ist dann so, dass sich dann meist nur noch der/die Entwickler/in mit der Software auskennt, weil diese zu kompliziert geworden ist, bzw. der/die Entwickler/in selbst die Dokumentation, mit seinem/ihrem derzeitigen Kenntnisstand, geschrieben hat. Dieses Problem ist aber auch auf andere Bereiche der IT abbildbar.

[@deleonio]

Ich schaue Deine Videos gern und oft mit Skepsis, ABER das Video ist absolute Spitze! DANKE!

[@lurgas404]

Gutes Video! Und gute Argumente. Zugegebener Weise fühlte ich mich ab 12:09 peinlich ertappt. Da werde ich mich künftig mal bewusst beobachten und korrigieren müssen.

[@DJone4one]

Euer Beitrag wurde bei Heise online angezeigt. Ich dachte erst, der Reporter schreibt das, nur jetzt fällt mir auf, der Text ist eins zu eins aus deinem video😅 Das fühlt sich auch bei uns im Unternehmen an, als hätte sich kein softwareentwickler bzw. SAP Berater mit den Jungs aus der Logisitk zusammensetzt, um mal herauszufinden, wie man das eine oder andere haben möchte bzw es effizienter gehen könnte. Da habe ich beim Auslagern für 20 Paletten per Hand (jede einzeln anscannen, kontrollieren ob sie auch gescannt wurde. Mach das mal 200 mal am tag😅), auf eine Excel Tabelle scannen, obwohl nach meinem Kenntnisstand SAP über eigene Scanner Module verfügt. Von 16 Schritten könnte man es dann auf 3 kürzen.

[@korbendallasmultipass1524]

Keep it simple and stupid. Choose the most boring technologies and approaches. Take over responsibility and ignore industry trends. Buy whatever is not part of your core business. Start with a MVP and very small team. Stay away from political topics. Adapt your processes to the business and not the other way around. And most importantly ask yourself: What would you do if it would be your money? That‘s it.

[@dominik4496]

Ich finde es vor allem verrückt wie verbuggt und undurchdacht selbst Software von Größen wie Amazon ist. Beispiel Seller Central und brand registry bei der Verknüpfung von Konten. Oder das man mit der gleichen Handynummer kein Amazon Business Konto eröffnen kann, obwohl es gerade für Geschäftsführer total üblich ist, dass sie ein privates Amazon Konto haben und ein berufliches.

[@ProggingTroll]

Irgendwie bin ich immer in den anderen Projekten. Meistens haben wir fachlich sehr starke Entwickler, Architekten, einen sehr IT nahen Fachbereich, Business Analysten mit Entwicklungserfahrung etc. Das Problem sind dann doch oft technische oder architektonische: Wie schaffen wir es, die Performance zu erhöhen? Wie schneiden wir dem Monolithen in Microservices? Wie betreibe ich eine Kubernetes Plattform? Wer kennt sich mit Stream Processing, Event-Driven Architectures, CQRS, Transactional Outbox, NoSQL, CAP Theorem wirklich im Detail aus und kann qualifizierte Einschätzungen abgeben? Wie schaffe ich es meine Frameworks in der Legacy Anwendung risikoarm zu modernisieren? Überall diese Fragen stolpere ich häufigere als über fachliche, denn diese sind in den meisten Business Anwendungen selten hochkomplex.

[@deltapi8859]

"Software ist kein Selbstzweck" shots have been fired.

[@Oelpfanne]

Mich wundert immer wieder, dass das so wenige erkennen. Es liegt ja eigentl. auf der Hand und ist völlig logisch, aber dennoch sehe ich dieses genannte Problem, dass keiner die fachlichen Prozesse und Anforderungen kennt, immer wieder. Deshalb ist meiner Meinung nach auch immer die wichtigste Frage WARUM. Warum wird etwas so getan, wie es getan wird. Warum wünscht man sich spezielle Dinge. Oft gibt man sich leider mit dem puren WAS zufrieden. Dabei könnte ein WARUM das Problem viel besser lösen.

[@thenativeweb]

Das kann ich nur unterschreiben: Die wichtigste Frage ist die nach dem "Warum". Warum machen wir das alles überhaupt, was ist der Sinn und Zweck, wofür ist das gut? Wer das fragt, kommt so unendlich viel weiter, aber irgendwie wird es für meinen Geschmack viel zu selten gefragt …

[@Bobbel888]

Normal gibt's ein Projektziel und einen -Scope, ausserdem jede Menge Eier-Schaukeln (bei Scrum unter "Selbstorganisation" mystifiziert). Keine der W-Fragen oder generell Konzepte haben daran je etwas geändert. Viel wirksamer in meinem Erfahrungsbereich sind Human Resource Manager, die es zuweilen schaffen, die richtigen Menschen zur richtigen Zeit an den richtigen Platz zu stellen, damit das Richtige getan wird, so wie Gott einen Stanislav Petrov; dann frägt man nicht Warum, sondern es herrscht Freude.

[@ReneHartmann]

Nicht selten ist die Vorstellung die, dass die Fachlichkeit ausschließlich Sache der Fachexperten ist. Die müssten dann den Entwicklern nur genau genug aufschreiben, was die Software tun muss und die setzen das dann einfach um. Große Verwunderung, wenn dabei keine wirklich brauchbare Software herauskommt.

[@PostmanLee]

Wie so oft hat Golo mit dem was er sagt recht und er hat er auch das Wichtigste hervorgehoben, wenn man bedenkt, dass das jetzt nur 15 inhaltsbepackte Minuten waren. Natürlich gibt es noch mehr Faktoren, die (Software-)Projekte scheitern lassen können. Ich gebe ihm außerdem völlig Recht, was das Thema Daten angeht: Klar brauchen Unternehmen heute Daten. Idealerweise "sinnvoll" abgelegt. Aber wie soll man sinnvoll ablegen, wenn der Sinn nicht verstanden ist? Über die Ansätze für dieses Problem hat er auch schon ein paar Tolle Videos hier im Kanal! Stöbern lohnt sich also! Vielen Dank Golo!!

[@joergfoerster8043]

Ich denke, oft wird damit gerechnet, dass der Aufwand zu gering eingeschätzt wurde. Man wird sich wundern, wenn man im Budget geblieben ist. Die Gegebenheiten genau zu erfassen, kostet auch. Dann ist die Aufwandsschätzung möglicherweise näher an der Realität, aber der Gesamtaufwand wird nicht unbedingt geringer.

[@DerTim]

Ich hatte auch mal ein Projekt wo das fachliche Wissen total gefehlt hatte, das Produkt trotzdem irgendwie gut war und! Und das ist das interessante daran: ich hab das Problem auch verstanden. Nur leider 2 Jahre nachdem ich aus dem Projekt raus bin, zufällig, über einen Beitrag vom CCC wo jemand über ein ähnliches Thema gesprochen hat und ein Fachwort, was mir immer nur wörtlich übersetzt wurde, mit Beispielen erklären konnte. :D War btw auch keiner vom Fach, das war ne Recherche, die sie zur Aufklärung machen mussten

[@lobothedark]

Tolles Video, bringt viele Punkte auf den Punkt. Leider bin ich aber auch schon des Öfteren daran gescheitert, wenn dann bei Nachfragen solche Phrasen kommen wie "Entscheiden wir bei der Entwicklung", "Nicht alles Zerdenken", "Muss man nicht definieren, ist ja logisch" und viele Weitere Ausreden. Wo ich dann irgendwann sagen muss, dann bin ich auch nicht mehr so wirklich motiviert, mir die Informationen zu holen. Sondern irgendwann an dem Punkt, dass ich die Firma wechsle, wenn es nicht besser wird. Dabei meinen ich nicht, einfach die Flinte ins Korn zu werfen, ohne es vorher versucht zu haben zu verbessern. Nur hab ich manchmal das Gefühl, was natürlich Subjektiv ist, dass man sich als Leiter einer Firma die Softwarelösungen erstellt, nicht damit auseinander setzten will, wie man Software entwickelt. Dabei können wir als Entwickler natürlich Domainkenntnisse aufbauen, dennoch fehlt in der Regel der intensive Kunden/Anwenderkontakt und wir sind auch in der Branche an sich nicht unterwegs. Beides führt dazu, dass wir natürlich nicht ohne jemanden effizient Arbeiten können, der wirklich weiß was der Need für die bestehenden Kunden ist und weiß wohin sich eine Branche entwickelt. Auch das wird leider zu häufig vermischt. Auf jeden Fall Danke immer für die vielen tollen Videos, die nicht nur neue Denkanstöße sind, sondern auch oft einfach die eigene subjektive Erfahrung bestätigen, dass es nicht nur ein "Ich"-Problem ist.

[@emgalaxy6576]

Die Probleme fangen oft schon damit an dass Fachteams nicht verstehen was Software leisten kann. Das was dann an Anforderungen und Wünschen kommuniziert wird ist dann oft schon unpassend. Für eine echte Produktivitätssteigerung kann es notwendig sein dass auch das Fachteam seine Prozesse anpassen muss. Dies kann zB die Eliminierung von Sonderfällen und Variationen sein, die entweder nicht implementierbar sind weil sie nicht bestimmten Regeln folgen oder aber die Bedienung unnötig kompliziert machen. Der Königsweg ist wenn jede Fachabteilung mindestens einen Mitarbeiter mit Softwareentwicklungshintergrund hat. Kleinere Entwicklungen können dann direkt durch die Abteilung vorgenommen werden und wenn eine größere Entwicklung erforderlich ist, gibt es jemanden der kompetent mit dem Entwicklerteam kommunizieren kann.

[@k1ngarthur87]

Warum können wir alle kein Anforderungsmanagement? Als EntwicklerIn kann man nicht jeden Prozess im Deatil kennen. Wir müssen uns in den Prozess einarbeiten, aber auch die KundInnen müssen liefern und klären, was sie überhaupt erreichen wollen und nicht einfach eine grobe Idee an irgend ein Entwicklungsteam weiterreichen. Meine erfahrung sagt, das Aufbauen des gemeinsames Verständnisses kann auch sehr umfangreich sein und braucht seine Zeit. Die Implementierung ist dann der kleinste Teil. Dabei ist es am spannensten und schönsten einmal in eine neue, völlig unbekannte Welt einzutauchen und dann auch mit der eigenen Software dort etwas verbessern zu können. Schön, dass nicht nur ich das so merke. Vielleicht gibt es doch noch Hoffnung für die Menschheit.

[@dagorgonzoladotco]

Ich hab das 20 Jahre lang gemacht und geliebt. Mit 180 Anschlägen pro Minute konnte ich live mit tippen, und alle Anforderungen erfassen... In meiner letzten Firma ging es wieder einen Schritt zurück und es wurde ein Product Owner eingestellt, der das Produkt "kennt", mehr als Überschriften hatten die Tickets nicht, alles wurde in langatmigen Meetings besprochen. 😅

[@TorianTammas]

Das Problem ist A.Kunden wissen nicht was sie wollen und verstehen nicht das sie eine Bringschuld haben. B. Kunden können keinen klaren Anforderungskatalog formulieren C. Sie erwarten das Rom nicht nur in einem Tag erbaut wird, es soll auch nichts kosten D. Kunden kommen immer mal wieder auch 5 Minuten vor Fertigstellung auf eine neue Idee die man doch mal eben noch implementieren könnte. E. Das ist nicht nur in der Softwareentwicklung so

[@TobiasR-e2q]

Deshalb würde ich verstärkt auf Quereinsteiger setzen, die aus ihren vorherigen Berufen bereits wertvolle Kenntnisse und eine klare Vorstellung der Anforderungen mitbringen. Ich selbst möchte in die Softwareentwicklung wechseln und komme ursprünglich aus dem Handwerk, wo ich bereits auch in einer Führungsrolle tätig bin. Mit 17 Jahren Erfahrung bin ich überzeugt, dass meine Fähigkeiten und mein praktisches Wissen in der Softwarebranche ebenfalls von Nutzen sein können.

[@nilsmach6399]

Ich finde die Vorstellung komisch, dass eine Software gescheitert ist, weil sie nicht in der geschätzten Zeit fertig geworden ist. Es ist doch fast immer ein Problem der Schätzung und seltener eines der Software-Entwicklung. Wenn jemand eine Mondrakete bauen lassen will und dafür zwei Wochen veranschlagt, sagt das Scheitern nichts über die beteiligten Raketenwissenschaftler aus. Das Problem liegt beim Business, das nicht versteht, dass Entwicklungsprojekte im Allgemeinen und Software-Entwicklung im Besonderen nicht gut zu schätzen sind. Und aus den überoptimistischen Deadlines entstehen dann erst die Probleme, wie z. B. dass Entwickler nicht die Zeit haben, sich näher mit der Fachlichkeit auseinanderzusetzen.

[@linux912]

Genau so ist es, ohne Fachlichkeit im Team und das Verständnis, brauch ich keine Codezeile zu Schreiben ..

[@hangar4851]

Es braucht qualifizierte hybride Leute, die aus der Organisationsentwicklung Fachkonzepte und Roh-Spezifikationen schreiben können. Absurd wird es, wenn Auftraggeber versuchen "Fachlichkeit" und "Technik" zu trennen, um dem Systemhaus Idiotenfreiheit zuzusichern. Dann braucht es auch keine Fachkonzepte oder Requirement Engineers. Best case ist ein enges Zusammenspiel von Fachanalyst (hybrid, Schwerpunkt Prozessberatung) und Entwicklungsleiter (hybrid, Schwerpunkt Technik).

[@Monddwarf]

Puh, wie wahr!

[@ErnaSolbergXXX]

This is something i really can agree with and its lacking everywhere. With everything getting bigger and bigger, we as developers are moved further and further away from what we actually solving. This is why i want to leave the role as a software developer. By now its only the money that makes me stay

[@Skoell1983]

Ich plane und entwickle individuelle Lösungen in Python für unsere Kunden, welche unsere Software auf ihre Prozesse anpasst. Hauptgründe warum die Projekte scheitern un absteigender Reihenfolge. 1. Kunde weiß nicht was er eigentlich will. Oft auch, weil eine andere Abteilung das Projekt durchführt als die, die das Problem hat. 2. Kunde unterschreibt blind jedes Design Dokument. Ehrlich, das habe ich bei jedem zweiten Projekt, dass der Kunde dann die Software bekommt und mir dann sagt: ja, so hab ich das ja nicht gemeint. Dann hole ich das Design Dokument hervor und frage ihn ob er das hier gelesen hat und warum er es dann unterschrieben hat. 3. technische Showstopper. Das kann vorkommen, ist aber relativ selten.

[@WolfgangEgger]

Dass die Kunden nicht wissen, was sie wollen ist ganz normal. Kaum jemand kann sich das Ergebnis der Entwicklung vorstellen, so lange er nicht selbst darauf herumgetippt hat. Es war lange die Hauptaufgabe von Entwicklern, herauszukitzeln, was die Anwenderinnen wollen und den Entwicklungsprozess so zu gestalten, dass die Anwenderinnen involviert sind und zeitnah eingreifen können. Aus diesem Grund haben sich ja agile Entwicklungsmethodologien herausgebildet. Die hatten ursprünglich nicht den Zweck, jeden Tag zwei Meetings der Entwicklerinnen untereinander zu erzwingen und eine dicke fette Schicht mittleres Management durchzufüttern.

[@redziy9505]

nix kann ich da machen da es nicht meine projekte sind

[@smilgazolyte6696]

very good topic. to sum up people in charge (sometimes 3 with totally different opinions) have no competence in anything they do and then instead of not distubing the work they do everything ruin it. I have noticed this here in Germany. by the way germans were very unhappy when i told them that straight to the face.

[@tschitschi9811]

Zum Thema empfehle ich das Buch "Die Kunst des perfekten Scheiterns" von Christian Rieck. Aus eigenen Projekterfahrungen kann ich viele der darin enthaltenen Vorschläge nur bestätigen und befürworten. Also nix wie los zum perfekten Scheitern!

[@lucasgrape8576]

Also im weitesten sinn sollte das teil des Informatik studiums sein. Die meisten Punkte wurden bei mir im Modul "Software Engineering" angesprochen, ein paar andere (und noch mehr) bei UX-Design, das war allerdings auch schon optional..

[@anion21]

100% Zustimmung. Leider so oft selbt erlebt...

[@anyaplays7150]

Mal sehen, wann es sich durchsetzt, dass die Leute tatsälich merken, dass Implementierungsdetails nicht so wichtig sind wie die Businesslogik 😄 Viele Grüße von der Dipl.-Kffr (Wirtschaftsinformatik), die keine Probleme mit der Busnisslogik hat und auch nicht mit dem Code dahinter 😄

[@LA-fb9bf]

Naja, tatsächlich ist die Fachlichkeit oftmals nicht klar, weil sie sich erst im Laufe der Zeit vollständig ergibt und sich auch weiterentwickelt. Wem willst denn da die Schuld geben? Eine Glaskugel hat keiner. Dann darf halt auch die Software nur ganz wenig können, nämlich das, was fachlich bereits bekannt ist. Aber so eine kleine Software will wiederum auch keiner akzeptieren…. 🤷‍♂️

[@mac475475]

Die klassische Frage "Warum scheitern Projekte?". Ok, wenn man die Anforderungen nicht verstanden hat oder die Prozesse nicht kennt, wird das schon so sein - aber das kann nicht die Antwort sein. Softwareprojekte mit einfachen Anforderungen und keinen Prozessen scheitern genauso. Die Komplexität steigt mit der Zahl der beteiligten Personen und Komponenten, die auf einen Nenner zu bringen sind. Zudem ist die "Welt" zum Projektstart eine andere als zum Projektende und Erwartungen verschieben sich. Tatsächlich wäre es interessanter zu fragen, warum Aufwandschätzungen für ein erfolgreiches Projekt so schwierig sind.

[@fortuneNext]

Selbst bei meist so gut informierten Kanälen werden falsch zugeordnete Zitate propagiert... armer Einstein! (Trotzdem gutes Video!)

[@Bobbel888]

75% bei den Pfuschern, in meinem Erfahrungsbereich ca. 10%

[@ThomasScholl-z5z]

Der Vergleich mit Excel ist ja mal richtig passend.

[@NeverCodeAlone]

Der Kunde zahlt keine Tests und will das auch nicht 😂

[@DynamicSun]

Die Leute werden oft gleich pampig und fragen mich ob ich eine Dr. Arbeit daraus machen will - Frage mich ob ich jedesmal einen Anwalt mitbringen muss, weil aus Technischen-Fragen - andere werden ...

[@valeridause]

Aha! An Entwickler liegt das Scheitern an einem Projekt nicht! Diese Aussage stimmt nicht. Es ist in jedem gescheiterten Projekt sein Mix. Aber wesentlich wichtiger Faktor - unqualitative Arbeit an jeder Stelle. Davon waren früher eher Management Entscheidungen betroffen. Seit 'Speicher kostet nichts' sind auch viele Entwickler völlig unprofessionell geworden, komplex zu denken und komplexe Probleme zu lösen. Das ist mittlerweile eine Kultur, halb-fertige, halb-getestete usw Software schnell wie möglich zu liefern..das ist Kreis, aus dem kein Ausweg mehr gibt. Es wird nocht schlechter. Deswegen - genießt den heutigen Tag und die Art und Weise. Denn das wird nie mehr geben.

[@freemanch.6720]

Resourcenmanagement ist die Lösung. Weiß doch jeder: 9 Frauen tragen das Kind in nur einem Monat aus 😂