All posts tagged: agile

Skillbyte Podcast #39: 10 Lektionen, die wir in 40+ Jahren Softwareentwicklung gelernt haben (Teil 1)

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: 10 Lektionen, die wir in 40+ Jahren Softwareentwicklung gelernt

// Inhalt //
01:20 – 1. Lektion: Halte die Komplexität in IT-Projekten so niedrig wie möglich
08:24 – 2. Lektion: Der beste Code ist einfacher Code.
14:44 – 3. Lektion: Gutes Projektmanagement ist wichtiger als das Vorgehensmodell
22:36 – 4. Lektion: Es ist sehr wichtig eine verantwortliche Person zu bennen
25:07 – 5. Lektion: Katastrophen werden passieren – stelle dich darauf ein!

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Also das Gefühl, wenn du so ein Ding gelöst hast. Das ist. Ich weiß es nicht. Ich kann nicht sagen, es ist besser als beim Sex. Aber es ist halt klar, den noch viele ein bisschen Aufregung und Spannung. Endorphine werden ausgeschüttet und wenn es dann gelöst, dass man das Adrenalin weg ist, dann fühlt sich einfach nur so hey, quasi.

Herzlich Willkommen zum Skill bald Podcast Nr. 39 10 Lektionen, die wir in mehr als 40 Jahren Softwareentwicklung gelernt haben. Teil 1 Abonniert unseren Podcast für mehr spannende Themen aus dem Technologie Umfeld er Entscheider oder die Fachkraft seid. Wenn ihr Hörer Fragen auf der Prisoner habt, sendet uns gerne eine E-Mail an Podcasts. Geh weiter. Bewertet diese Episode gerne mit 5 Sternen und wir uns immer bei Weiterempfehlung an Freunde und Kollegen und schaut auch bei der Skill BYD Jopp Seite vorbei. Ich bin hier heute wieder mit Malaysia.

Hallo Malaysia. Hallo Boris, grüß dich.

Freut mich, dass du da bist und dass wir heute aus deinem ganzen Erfahrungsschatz schöpfen können. Ich hoffe, da bin ich ganz sicher. Ich springe einfach mal mit der ersten Lektion rein und illustrer kurz das Problem und dann können wir gemeinsam darüber sprechen. Die erste Lektion ist Halte die Komplexität in Projekten so niedrig wie möglich. Was bedeutet das genau? Das Problem besteht darin, dass häufig in Projekten alle möglichen Werkzeuge verwendet werden Libraries, alte wie neue. Daraus entsteht eine sehr, sehr hohe Komplexität und ein Wartungsaufwand.

Weil natürlich jede Library dies irgendwann mal ins Projekt geschafft hat, muss mitgeschleppt, gewartet werden, weiterentwickelt werden. Gegebenenfalls. Wenn Sicherheitslücken auftreten, müssen die gefixt werden, was zu einem sehr großen Aufwand bei Versions Upgrades führt. Denn all diese Inhalte, die einmal ins Projekt gekommen sind, die laboris, müssen mitgezogen werden.

Das wird insbesondere dann kritisch, wenn man Komponenten verwendet hat, die aus dem Support raus sind, also die einfach nicht mehr gepflegt werden, weil es sich beispielsweise um eine veraltete Technologie handelt. Ich bin sicher, da kannst du auch eine ganze Menge zu sagen. Leider ja. wÃchentlich wir aber bei dem Lieblingsthema Scrum, wo die Verantwortung ja quasi dem Team obliegt und das Management diesen Prozess komplett vertraut. Nämlich, dass das Team sich selber organisiert. Dass das Team, bevor sie neue Tools und Technologien einführt, sich einig ist.

Ich muss jedem Mensch mit tatsächlichen Augen öffnen sein. Dem ist nicht so. In jedem Projekt, wo ich war, wo das so mal rigoros gelebt worden ist, haben Entwickler Tools Frameworks eingeführt, wie sie wollten. Natürlich, der Entwickler will dazulernen. Das ist auch völlig legitim. Er will mit neuen Technologien spielen. Aber leider hat halt der Entwickler, gerade jüngere Entwickler, nicht dieses Bewusstsein, dass das ja auch später jemand betreiben muss. Jemand muss das verstehen, der, der nach ihm kommt oder wie auch immer.

Das heißt, diese Betriebs Komponente, diese Langfristigkeit hat er leider nicht im Auge, sondern in dem Moment hatte erst mal nur seinen eigenen Vorteil oder seinen eigenen Spieltrieb nachgegeben und das fällt dem Projekt hinterher auf die Füße. Das sind nicht nur Tools. Also es gibt Projekte, wo ich erlebt habe, dass auf ihr für verschiedene Test Frameworks eingeführt worden sind. Im schlimmsten Fall hätte einer nicht mehr erkannt was das sollte und baute sein eigenes Ding. Machen hat seins drüber gestülpt.

Schwuppdiwupp hast du diese 400 Frameworks drin und es ist einfach nur noch Kraut und Rüben. Und das mal der ganzen Komplexität, die jedes Buch für sich mitbringt. Security Patches, Versions Upgrade, was du erwähnt hast und so weiter und so fort. Oder es wurde entschieden. Okay, Kafka ist es cool in aller Munde. Lass uns Kafka, nutze dem Projekt. Dann wurde das einfach eingeführt, dass das jemand betreiben muss, dass da zu einem Kafka viel mehr gehört als in Docker Run.

Das wird halt ausgeblendet. Aber nachher muss die Software drauf laufen. Und wenn dann tatsächlich Probleme auftauchen, blickt keiner durch. Eine schlimmsten Fall ist der, der das einführt. Hat 3, 4, 5, 6 Monate später weg und dann läuft das Ding halt irgendwo.

Ich bin auch auf jeden Fall dafür, dass man so eine Art Architektur Verantwortlichen hat im Team, der die Langfristigkeit der Anwendung im Blick hat, der den Application Lifecycle kennt, also dem bewusst ist Wenn das hier ein Erfolg ist, dann muss das noch 5 Jahre erstens weiterentwickelt werden und dann gepflegt werden und irgendwann ist die heiße Entwicklungsphase vorbei. Dann geht es in den Betrieb und der ist eben nicht mehr so von neuen Werkzeugen geprägt, sondern da kommt es darauf an, dass die Werkzeuge, die man hat, möglichst lange eben supported werden.

Und oftmals kristallisiert sich in einem Team ja schon so jemand raus. Das Problem ist, wenn der formal nicht die Macht bekommen hat. Da kann man gleich noch zu Neiman Lektion zu sagen Okay, so machen wir das. Oder auch die Frage zu stellen Wenn da eine neue Technologie eingeführt wird, was bringt uns das, was kostet uns das? Also ich sehe auch die Lösung dieses Problems darin, dass man als guter Entwickler tendenziell mit möglichst wenig Abhängigkeiten auskommen sollte ein Testing Framework und dann ein möglichst branchenübliche, was halt wahrscheinlich noch lange Unterstützung findet.

Bewährte Tool Scheines einsetzen. Nicht unbedingt das neueste und heißeste, sondern etwas, was es. Einige Jahre gibt und was eine gewisse Verbreitung erfahren hat, dass man halt auch Infos zum Internet findet. Aber dennoch, ich meine, das muss uns ja auch klar sein. Einen gewissen Prozentsatz an neuen Technologien muss man in jedem Projekt einsetzen, sonst würde man ja stehenbleiben. Absolut.

Mir geht es auch weniger so, dass man sie hinterher betreiben kann. Es ist ein Punkt für sich. Ja, aber das größere Problem sich in der Komplexität. Ja, du hast ein System und dieses System hat ne gewisse Entropie. Und jedes Tool, jedes Framework, jedes Stück, was du dazu nimmst, erhöht die Entropie. Das heißt, das System wird komplexer und ihr komplexes wird es. Mehr Manpower Bausumme um das am Laufen zu halten.

Da kann ich wirklich auch aus meiner Historie sprechen in einem Projekt, das es noch gar nicht so lange her. Dann werden auch ich glaube zwei oder drei verschiedene Test Frameworks benutzt, das einem brauch Not und p.m. Als Abhängigkeit, damit es funktioniert. Das andere ist von Java STANDARD Framework und da sieht man richtig die verschiedenen Altersstufen des Projektes, wann mal was Neues probiert wurde. Und das führt dazu, dass irgendwann einer sagt Boah, wir müssen das alles neu machen, weil keiner mehr durchsteigen.

Also halte die Komplexität niedrig. Weniger Komplexität ist meiner Ansicht nach ein Genie Streich. Also jemand, der darauf achtet, da hat man schon so viel gewonnen. Weniger Komplexität heißt weniger Bugs, weniger Probleme, weniger Sicherheitslücken und generell ein besseres Software Verständnis von dem entwickelten Artefakt. Ein Aufschwung aus dieser Lektion hört man z.B. in der Skill BYD Podcast Episode Nr. 18, warum IT-Projekte so teuer sind. Die Komplexität führt nämlich dazu, dass die Preise irgendwann explodieren oder der Aufwand explodiert.

Also für mich bedeutet professionelle Softwareentwicklung auch nicht, jedem Trend ungefragt hinterherzulaufen, sondern primär eine konsistente Architektur anzustreben und Neuerungen gezielt einzubauen. Ich hab mal gelesen, dass man pro Projekt 15 bis 25 prozent an neuen Komponenten einsetzen kann, wo man hofft, dass die möglichst lange gewartet werden. Das wäre dann so ein guter Wert.

Es ist schwierig, das so in Prozenten auszudrücken. Ich glaube, jedes Projekt ist sehr spezifisch. Bei dem einen bedarf es mehr an neuer Technologie. Keine Ahnung. Wenn du sagst, ich möchte jetzt auf Echtzeit Streaming gehen, dann kommt halt nur ein oder zwei Tunes in Frage. Will sagen, es ist finde ich schwer nachzuvollziehen, so Prozentzahlen zu sagen. Drittel der Komponenten sollten neu sein. Also jetzt rein subjektiv. Aus meiner Erfahrung kann ich jetzt nicht an irgendwelche Zahlen festmachen.

Es ist immer individuell.

Das stimmt. Und wichtig wäre noch darauf zu achten, dass wenn man so eine Komponente einsetzt, sondern eine neue Technologie einsetzt, dass es eine saubere Schnittstelle gibt. Wenn du jetzt sagst Echtzeit Streaming, dann gibt’s ja irgendwie ein Interface, um diese Streaming Komponente anzusprechen, dass das halt sauber ist, dass man das nötigenfalls mal wechseln kann. Das sehe ich genauso. Also neue Tools können ausprobiert werden und jeder von uns hat natürlich den Drang, das zu tun und möglichst viele Sachen neu auszuprobieren.

Aber in einem professionellen Projekt muss man das abwägen, ob das wirklich immer sinnvoll ist. Die zweite Lektion stößt ja ein bisschen ins gleiche Horn. Der beste Code ist einfacher Code. Das ist meiner Ansicht nach auch ein Problem, wenn man die Entwickler sich selber überlässt. Also dieses Prinzip do not repeat yourself.

Die R ui, das kennt sie ja bestimmt auch. Das wird ins Extreme verkehrt. Also da werden Konfigurationen über Bilder Patterns gebaut und verschiedene Dinge, wo ein einfaches Textteil gereicht hätte. Ja, weil man diese Konfiguration nur einmal sozusagen einliest und dann nicht mehr braucht. Da werden Konstrukte aufgesetzt, die wahnsinnig komplex sind für eine einfache Sache. Und man guckt mehr darauf, ne Funktion nur wirklich einmal zu implementieren, statt dass man sagt Okay, is of reading ist hier wichtig.

So eine flache Konfigurationsdatei, auch wenn sich da irgendwie einen Wert doppelt. Ja, also Server für Datenbank und Server für sagen wir mal E-Mail ist jetzt vielleicht der gleiche, dann steht zweimal der gleiche Wert da drin, dass man trotzdem die beiden Werte einfach reinschreibt, anstelle dass man die Konfiguration dann wiederverwendet.

Also ich würde tatsächlich auch Einfachheit über Dry favorisieren, wenn es hart auf hart kommt. Sich entscheiden müsse ich mich persönlich immer wiederholen, als das Ganze kompliziert zu machen.

Würde ich auch so sehen. Also es gibt natürlich für jedes Pattern die Entwicklungspfad, dann haben natürlich ein Sinn. Ich möchte hier überhaupt nicht gegen Patterns wettern, aber ich habe es schon gesehen. Statt einer einfachen for-Schleife wurde ein komplexes Producer Consumer Pattern implementiert. Wurde dann irgendwie zehn Werte von irgendeinem Dienst consumers wurden, wo man denkt ja okay, die zehn Werte jetzt auch einfach als Liste übergeben können, da hätte jeder verstanden, was du willst. Und so muss man das erst ausgraben.

Man muss ja sagen, die Idee Unterstüzung ist ja auch tatsächlich so weit, dass sie auch q blöcke wär, wenn du sie wiederholst erkennt das sei es. Sowas lässt sich schneller auffinden, weil Dojo BDO Set kommt er dann zum Tragen, wenn du Code verändern willst? Und muss irgendeine Änderung reinnehmen, dass du seine Stelle machst und an der anderen Stelle vergisst. Hast du ein Bad drin? Sowas lässt die Idee dann schon erkennen, dass das die Unterstützungs entsprechend da.

Das spricht dann für mich auch eher dafür, dass sich das System mir einfacher halte oder mein Boot, als es zwingend unter allen Umständen auf Teufel komm raus diesem Prinzip gerecht werden muss. Genau.

Also ich glaube ein gutes Beispiel für Dohna Creepy yourself wird z.B. die Berechnung der Mehrwertsteuer, die aktuell bei 16 prozent statt bei 19 prozent liegt. Wenn das natürlich komplett durchs Programm verstreut ist, wird es sehr aufwendig, alle Stellen zu erwischen. Da will man natürlich eine Methode haben, die dann überall aufgerufen wird.

Aber gerade bei Configuration Klassen oder Klassen, die so Rest Calls aufrufen oder so. Da kann man sich dann doch sehr Fahrkünste an Was mir zu diesem Thema sofort einfällt ist eher so diese wie sich verschachteln Stream Map Filter Konstrukte über mehrere Zeilen gehen. Das ist für mich ja. Man mag sich dann hip vorkommen, weil man tolle neue Features benutzt hat, die in anderen Programmiersprachen schon länger da sind. Und es mag shiny sein, aber kann man argumentieren wie man will?

Es macht den Code schwer lesbar und das ist es mir definitiv nicht wert. Dann hab ich lieber drei Bout Blöcke, was man einfach lesen kann wie ein Buch statt sich da so einzudecken. Weil es ist ja so, du hast ja eine anonyme Funktion hinter der anderen. Diese Ketten, die aus dieser JavaScript Server Seuche herkommt. Und du musst ja wenn du das bitte folgen willst mit dem Kopf, dann musst du ja quasi ins Deck bilden. Der Rekursive ist und das strengt mich so an und Leute, das hat nix mit meinem Alter zu tun, sondern das ist einfach Mist.

Das fällt jedem schwer, als wenn ich das quasi in einfachen Zeilen hab.

Ja dieser Landa Notation, die verführt halt dazu, dass man immer ach und man filtert das. Achja und dann sortiert man es noch. Achja und dann macht man noch das Ding und dann dies und dann jenes und dann entsteht so eine Kaskade. Und in der Sekunde wo man da drinne ist ist das toll, weil man einfach da so runter schreiben kann. Aber ich hab auch schon mal eine lange Landa Funktion in zwei oder drei Blöcke aufgeteilt, weil ich einfach dann so ein Zwischenergebnis haben wollte und sage Okay, das ist die gefilterte Liste beim nächsten Mal.

Okay, das ist jetzt das tilgte Liste. Okay, das nächste Mal, da sind die gefundenen Treffer drin oder so. Sodass man dir dann eben folgen kann, wenn das irgendeiner mal anfassen muss.

Das ist also sehr richtig gesagt. In dem Moment, wo du selber dich quasi diesem Kontext aufgebaut hast und drin bist, dann lässt sich das relativ einfach runterschreiben. Aber der nächste muss ja auch da rein und der übernächste.

Also meine Regel ist, wenn der Quellcode nicht direkt auch von den Junior Entwicklungs Kollegen verstanden werden kann, was da passiert ist, dann ist er zu kompliziert. Punkt. Also klar, dass man mal ein Pattern erklären muss oder dass man sagen muss Oh, hier hab ich eine neue Funktion benutzt, dies in der neuen Version gibt. Das verstehe ich aber da Verschachtelung Stephen und irgendwelche wilden typisierten.

Ja genau das ist das nächste Ding.

Funktionen, die sich dann selber aufrufen. Ja, dann wird’s ein bisschen zu wild und man muss sagen hör mal, was machen wir eigentlich? Weil meistens mag man ja nur Daten irgendwie aufeinander, wenn man programmiert und arbeitet. Nicht immer Spaceshuttle, Steuerung und auch die Map letztlich nur Daten, auch sehr beliebt.

So typisierte Methoden Rückgabewert mit Wildcards und auch sehr Nies nicht.

Also nochmal Patterns haben natürlich ihren Sinn, aber man muss immer gucken ist das hier die richtige Hammerl Größe für das richtige Problem? Ich glaube das ist ganz wichtig.

Man muss einfach auch an andere denken, die dann kommen, vielleicht nicht nur den Skill Level haben.

Ich habe auch festgestellt, die besten Entwickler wenn eine Lösung entwickelt haben, dann hören die nicht auf und committen das einfach, sondern die lesen das dann nochmal von oben nach unten durch und vereinfachen auch komplizierte Funktionen. Also es gibt diesen Spruch Jeder Schwachkopf kann Dinge kompliziert machen, aber es braucht ein Genie um Dinge einfach zu machen. Und die gehen wirklich nochmal diese extra Runde, dass sie sagen Okay, jetzt hab ich zwar eine Lösung, die funktioniert. Aber was mache ich hier eigentlich nochmal?

Okay, das ist ein Zwischenschritt, der logisch. Das ist ein Zwischenschritt des logisch und zergliedern. Das entweder in einzelne Methoden oder einfach in logische Blöcke. Manchmal recha das Einführen von Leerzeile schon, weil du kennst ja bestimmt zu klickst in einer Datei auf nach so ne Wall of Text 300 Zeilen ohne eine Leerzeile dazwischen. Da denkt man schon Boah, was ist hier passiert? Da ist es wichtig, dass man auch diese logischen gedanklichen Schritte dann eben voneinander absetzt und dann möglichst ein einfachen Fluss hinbekommt.

Da kommen wir zur dritten Lektion und da bin ich ganz sicher, wirst du ganz viel zu sagen können. Die dritte Lektion Gutes Projektmanagement ist wichtiger als das Vorgehens Modell.

Was meinst du damit mit Vorgehens Modell? Das Vorgehens Modell könnte das agile Vorgehens Modell sein. V Modell x t Wasserfall Modell ganz klassisch oder irgendeinen meißtens wenn die Vorgehens Modelle ja nicht in Reinform ausgeführt, sondern es entsteht so eine mehr köpfige Hydra, die sich an allen Vorgehens Modellen irgendwie bedient und dann ein neues Monster erschafft. Nachdem das Team dann arbeitet nein, es soll gar nicht so negativ sein. Also natürlich gibt’s kein Vorgehens Modell in Reihenfolge. Es muss auch immer zur Firma und zum Projekt passen.

Aber ich glaube, nach den Jahren kann man schon sagen, dass man gutes Projektmanagement von schlechtem Projektmanagement unterscheiden kann.

Aber Moriz Projektmanagement gibt’s doch gar nicht mehr. Ist doch alles agil.

Ja, auch ein Kilis Projektmanagement ist ja Projektmanagement. Was ich festgestellt habe ist Es gibt so Projektmanagement, das sich so im Unternehmen entwickelt hat und was dann so implizit durchgeführt wird oder was du von oben aufgestört wird. Agil wäre z.B. ein Beispiel für Da kommt eine Entscheidung und das wird häufig von oben aufge stülpt. Ja, wir haben das jetzt gehört. Wir machen es jetzt alle. Aber diese von oben aufgestellten Modelle scheitern oft an der Realität. Also das agile Paradigma wird ausgerufen, es wird ein Sprint geplant, die Leute fangen an zu arbeiten und nach zwei Tagen kommt jemand rein und sagt Nee, das ist aber jetzt ganz wichtig.

Dann sagt man Ja, schreibs ins Backlog. Gucken wir uns zwei Wochen an So, und jetzt hasst der Lackmustest. Gelingt das jetzt? Oder sagt jemand Ja, Moment. Ich bin aber der Geschäftsführer. Ich will das jetzt sofort. Und so sterben dann die guten agilen Ansätze dann auch ein. Also die verwässern so nach und nach. Ich will das gar nicht so negativ klingen lassen, aber dann landet man meistens bei irgend so einer Zwischenform. Also um Priorisierung von oben.

Notfälle passieren. Naja, Hacker-Angriff, Sicherheitsprobleme. Das Leben bewegt sich ja auch. Es ist ja auch nicht so stark, dass es sich in ein Modell quetschen lässt. Schlüsselpersonen geht. Neue Mitarbeiter kommen, die noch keine Vorkenntnisse haben. Jemand wird krank. All das kann während der Projekte geschehen und es gibt keinen Plan, der alle Eventualitäten abdecken kann. Das ist die Realität. Wie löst man das gut?

Grundsätzlich ist es ja bei dem agilen Vorgehen. Es ist eigentlich eine Wohltat für die bisherige Softwareentwicklung gewesen. Gar keine Frage. Wir alle oder nicht alle? Vielleicht die? Die jüngeren Zuhörer nicht. Dieses Modell, das man sich vorher im Prinzip schon qualmende Ingenieuren, die Anforderungen genau holen musste, niederschreiben musste und abschätzen musste oder Modell Werkvertrag gemacht. Das hat alles nicht funktioniert. Insofern ist agil schon super. Aber ich glaube, dieses so völlig rigorose Agilität, wie das Agile Manifest sagt oder was daraus geworden ist, sag ich mal, das ist totaler Humbug.

Du kannst keinem Management erklären. Pass mal auf. Wir können dir nicht sagen, was es kostet. Wir können dir nicht sagen, wann es fertig wird. Wo hast du sowieso nichts zu melden, außer die Kohle da hinzulegen? Das funktioniert einfach nicht. Selbst wenn das Management von großen Firmen sagt Ja, wir führen das jetzt ein und egal was wir machen, ist agil, agil, agil. Trotzdem fragen sie immer nach Wann ist es fertig? Was kostet das?

Trotzdem wird Projektmanagement nicht mehr gemacht. Man merkt, dass Sie nicht loslassen können. Klar. Ich meine das selbst ich als Softwareentwickler dieses Modell ja mitgemacht hat und sehr froh ist, dass es das auch gibt, sagt. Das ist totaler Quatsch. Entwickler können machen was sie wollen. Hin und her. Das funktioniert einfach nicht. Deswegen vermischt sich das im Moment. Klar, wenn du nur diese Menschen sind, Firmen und Coaches und so weiter. Die verdienen ihr Geld damit, dieses Modell einzuführen.

Aber aus der Praxis, so wie ich es erlebe, entsteht irgendwie eine Mischform. Dadurch aber, dass diese Mischformen links beschrieben ist, vermisse ich das Alte mit dem Neuen. Und da kommen ganz komische Konstrukte raus. Mein Punkt ist jetzt gar nicht mal so finanziell und Management und Zeit, Berechnungen usw. Also auch das werden mit Sicherheit 99 prozent der Zuhörer zustimmen. Irgendwie schleicht es sich ein, dass die Komplexität Punkte plötzlich in Tagen weiter kommuniziert werden. Aber mein Punkt ist rein technisch im Moment.

Und dass sich diese Architektur Thema, dieses Setzen eines Rahmens, in dem man sich frei bewegen kann und nicht einfach blind vertrauen und sagen, dass die Macht es schon. Ah, braucht das Team einen Rahmen. Es fühlt sich wohler. Der Entwickler fühlt sich wohler, wenn ein Rahmen, in dem er sich bewegen kann, im Grunde wie ein Bauplan auf der Baustelle.

Na, da baut ja auch nicht einfach jeder drauflos, wie er lustig ist, sondern es gibt einen großen Plan und das so muss das am Ende zusammenpassen.

Genau, du gehst ja auch nicht, wenn du ein Haus bauen willst und schmeiß irgendwie schon haben wir kein Geld ins Gesicht und sagt so guck mal wir das OP’s aufbaut. Nee, du gehst mal schon denken als erstes. Genauso ist das mit der Softwareentwicklung. Es ist auch sehr schwer, wenn du als Dienstleister, was wir hier sind Verträge machen wollen. Weil wenn ich dem Kunden komme, sagt Ja. Wir arbeiten zwar als verlängerte Werkbank, das ist unser Modell, das nach timen Material.

Aber wenn wir Projekte machen und ich sage agil, dann kommen genau diese Fragen. Und wenn ich dem sage, jetzt mal nichts zu sagen, wir machen das und du kannst nur sagen Stopp nach allen 14 Fahnenmeer und Sprint Review hast. Mit dieser Zeit kannst du das Projekt stoppen. Toll. Deswegen entstehen diese Mischformen und auch Verträge. Was wir machen ist dann kein Dienstleistungs Vertrag, kein Werkvertrag, sondern agiler Vertrag. Also dieses Konstrukt gibt’s tatsächlich, wo man gewisse Rahmen festsetzt.

Ich hoffe, das wird noch ein bisschen dauern, bis das, was ich jetzt gerade sage, den Unternehmen auch tatsächlich bewusst wird und man erkennt. Rein so agil, wie es Groom oder diese Coaches einem propagieren, so geht’s einfach nicht. Das wird früher oder später kommen, spätestens wenn dann Projekte zeitlich und finanziell aus dem Ruder laufen. Wenn man sich wieder fragen warum, wieso, weshalb? Und dann, wenn das Argument auf den Tisch kommt, dann überlegt man sich etwas Neues.

Also das beste Projektmanagement, was ich erlebt habe. Es hat total problemorientiert. Das guckt wo sind die Stolpersteine oder was steht uns im Weg, was steht unserem Erfolg in weg und kümmert sich darum? Also es räumt im Grunde einfach nur Hürden aus dem Weg und lässt dem Team schon viel Autonomie. Aber kommuniziert die Ziele immer sehr klar. Also da wollen wir hin, da wollen wir hin. Da wollen wir hin und alles, was da im Weg steht. Probleme müssen gelöst werden.

Leute müssen überzeugt werden und darum kümmert sich das Projektmanagement. Und auf der anderen Seite schützt ist das Team, das das Team in Ruhe arbeiten kann und nicht in endlosen Meetings Runden verhaftet wird, um alle Stakeholder, die es irgendwie geben könnte, abzuholen. Das sind die effektivsten Projekte, in denen ich bisher gearbeitet habe, wo man einfach gesagt hat Okay, wir räumen alle Probleme aus dem Weg. Ihr könnt in Ruhe arbeiten, natürlich alle zwei Wochen oder je nach Sprint Ende wird gezeigt, woran ihr gearbeitet habt.

Und dann sagt der Kunde, wohin es als nächstes geht. Natürlich gibt’s so einen groben großen Plan, was man erreichen möchte. Mit den Schlüssel Features. Aber das war sehr zielorientiert und die Projekte, die ich so gemacht habe, waren sehr erfolgreich. Vielleicht können wir hier auch festhalten. Also das ist so mein Fazit aus dem Punkt gutes Projektmanagement. Wenn Projekte scheitern. Ich hab das noch nie erlebt, dass ein Projekt, eine Technologie scheitert, weil irgendwas nicht gegangen wäre oder so vielleicht.

Bei Raumfahrtunternehmen ist das so. Aber ganz oft sind es menschliche Faktoren, Firmenpolitik oder einfach nicht gut durchgeführtes Projektmanagement, wo dann hinterher das ganze Team demotiviert war. Das sind so die Gründe, warum Projekte scheitern.

Meiner Ansicht nach ja, ist schon so. Aber ich hatte auch. Also muss ich wirklich hervorheben einige Projekte, die wirklich super erfolgreich waren, wo gutes Projektmanagement stattgefunden hat, wo dem Team der Rücken gestärkt wurde und alle Probleme organisatorischer Art eben aus dem Weg geräumt wurden. Also super klasse gelaufen, muss ich wirklich sagen. So ein bisschen in die dritte Lektion Gutes Projektmanagement spielt die vierte Lektion hinein, würde ich sagen. Die ist nämlich Es ist sehr wichtig, eine verantwortliche Person zu benennen.

Was ist das Problem? Also das kennst du bestimmt auch bei Retro oder auch so werden Missstände benannt, was vielleicht nicht so toll ist, was man besser machen kann. Dann gibt’s eine Diskussion im Plenum, da spricht man darüber und dann wird darum gebeten, meistens von höherer Stelle, dass sich darum gekümmert wird, ohne explizit eine Person zu benennen. Vielleicht wird sogar noch ein Ticket erstellt im Backlog. So, und das wars. Und bitte kümmert euch darum.

Heißt für mich Keiner kümmert sich darum. Gerade wenn das ein heißes Thema ist. In erfolgreichen Projekten, so ist es meine Erfahrung, wird eine verantwortliche Person benannt, wenn das Thema wichtig ist. Wenn ein Thema nicht wichtig ist, dann wird keine Person benannt, aber dann braucht man es auch nicht aufschreiben. Und diese Person ist dann dafür verantwortlich, dass dieses Thema weiterverfolgt ist und hat dann die Themenführerschaft da drüber und kümmert sich auch. Und das ist gar kein Fingerprint Ding, das man sagt Okay, du kümmerst dich jetzt darum.

Sondern jeder hat ein paar Themen, für die er verantwortlich ist. Dadurch entfällt diese ganze Fragerei, wenn irgendwie Probleme in einen gewissen Themenkomplex fallen. Man weiß sofort Aha, Person X oder Epsilon ist dafür verantwortlich. Brauch halt nicht weiter zu fragen, hat sofort einen Ansprechpartner. Auf der anderen Seite hab ich ja selber drei Themen, für die ich verantwortlich bin, sodass da auch kein Ungleichgewicht entsteht. Ich weiß nicht, wie hast du das erlebt? Also auch da ist ja das Team kümmert sich.

Also wenn wir es beim Business-Modell Scrum bleiben, heißt es ja, das Team ist eigenverantwortlich und wenn ich eine gute Durchmischung hab von jüngeren und erfahrenen Entwicklern, dann erfolgt quasi alles im Team. Und die sollen sich selber organisieren. Faktisch aber auch jetzt organisatorisch, innerhalb. Selbst wenn man das Modell macht und man im Team Dinge bespricht, ist es ganz wichtig für jedes Thema Verantwortliche zu benennen. Das ist ja dieses Prinzip. Ja, das hat eine andere schon mal vielleicht gehört.

Ja, wenn du in einer Menschengruppe unterwegs bist und irgendeiner hat einen Herzinfarkt, wenn du sagst Kann jemand mal einen Arzt rufen, macht es am Ende keiner, weil sich jeder von anderen verlässt. Aber wenn du dann jemanden anguckst und sagst, kannst du einen Arzt rufen, dann ist die Wahrscheinlichkeit viel größer, dass derjenige oder vielleicht wenn du dir selber bis überlebt.

Genauso ist es in IT-Projekte vielleicht nicht weniger dramatisch. Man braucht vielleicht nicht so oft ein Arzt, wobei das auch vorkommen kann. Je nach Katastrophen Lage. Ja. Oh mein Gott, ich seh gerade das war ja ein wundervoller Übergang. Die fünfte Lektion Katastrophen werd passieren, stell dich drauf ein. Da können wir jetzt ja mal wirklich von ein paar Katastrophen erzählen, die wir bisher erlebt haben. Ich fange mal von meiner allerersten Katastrophe an, da war ich noch Student und hab.

Eine Webseite betreut und hub zu einem gewissen Zeitpunkt des Vormittags Club zehn oder elf Uhr morgens ein Update gemacht. Dieser Webseite und die Webseite gehört einen riesigen Dax-Konzern habe das Update eingespielt. Okay, und auf die Webseite und drücke 5 aus passiert gar nichts. Und das Rad dreht sich und das Rad dreht sich und das Rad dreht sich. Ich drück nochmal 5! Das Rad dreht sich, das Rad dreht sich. Man geht auf Google um zu gucken. Hat der Rechner kein Internet oder sowas.

Alles funktioniert. ernÃhren, Webseiten funktionieren. Nochmal zurück auf die eine Webseite Rad dreht sich das Rad dreht sich, kommt keine Webseite. Da wurde mir heiß, kalt, heiß, kalt in schneller Folge mich aufgestanden und zu meinem Manager gegangen und hab gesagt Hammerl, ich habe gerade in D dein Schild an die Webseite lädt nicht mehr und er macht seinen Browser auf, geht auf die Webseite und das Rad dreht sich. Das Rad dreht sich und das Rad dreht sich.

Das war so wie im Trance, muss ich wirklich sagen. Ich war total. Oh mein Gott, was soll ich machen? Und dann griff er zum Telefon, auch relativ hektisch dann und hat wild rum telefoniert. Wahrscheinlich hat es nur 10 Minuten gedauert, aber für mich gefühlt ne Ewigkeit. Und dann hat der Kunde angerufen und gesagt, dass er gerade eine Wartung von diesem Server macht, wo ich gerade drauf wie Pleul hatte. Ich war also gar nicht schuld.

Es lag gar nicht an meinem Release, sondern der Kunde selber hatte den Server neu gestartet und dann auch noch in andere Firmen auf diesem Server drauf. Also es war quasi eine kurze Downtime von paar Minuten, wo ich nichts konnte, weil ich einfach nicht wusste, dass da jetzt durchgestartet wird oder so. Das heißt, am Ende war ich nicht schuld, aber das will ich nie vergessen. Das war für mich eine Katastrophe und das wäre auch für die kleine Firma, für die ich damals gearbeitet habe, eine Katastrophe gewesen.

Am Ende des Tages ist alles gut ausgegangen, aber das weiß ich noch ganz genau. Das war so die erste Feuerprobe. Und ich bin sicher, jeder Entwickler kennt diesen Moment und kann von anderen Situationen erzählen, wo dieses Heiß kalt Gefühl aufgekommen ist. Also was ist die Lektion hier? Trotz aller Vorbereitung wird es irgendwann zur Katastrophe kommen. Downtime ganzer Produktionssystem durch Softwarefehler oder Datenbank Updates schlecht reproduzierbare Bugs. Ich weiß, wir haben mal in einem Projekt zusammen gearbeitet, da es alle sechs Wochen ein komplettes Rack ausgefallen.

Das inklusive braucht ein BIOS Update oder so. Aber wahnsinnig aufwendig zu reproduzieren. Und jedes Mal wenn der Fehler aufgetreten ist, ist das ganze System abgestürzt, sodass ein riesen Impact hatte. Datenverlust, Hardware, Defekte alles schon dagewesen. Betrug, Hacking, Diebstahl, DDoS also das wird passieren, da muss man darauf vorbereitet sein. Was war deine Katastrophe in jüngster Vergangenheit oder die größte, die du je erlebt hast?

Also ganz ehrlich, ich kann nicht sagen, es war jetzt eine große Katastrophe hier oder da. Der ganz normale Wahnsinn. Solche Ausfälle hier, da. Oh Gott, unser Gitt baut nicht und oh Gott, unsere Produktion Server ist down. Das ist eigentlich Normalität, dass das kommt. Ich muss ganz ehrlich sagen, es ist nichts dabei, was mich geschockt hätte. Ja so! Gerade wo ich angefangen hatte. Und so dachte ich Jo, hier in IT-Systemen.

Alles Ingenieure und komplexe Systeme. Wenn das läuft, dann läuft und da passiert nix. Wurde erst in ein, zwei Mal Sucks, du bist hier abwanderten. Also das ist wie Hartmut weißt. Klar werde ich nie vergessen. Irgendwie bei der großen Systemhaus am Anfang, wo wir Mailserver betreut haben für Kanal so 20000 Leute und die konnten keine Mails verschicken. Da ist gezittert und bibbert. Aber es kam danach noch schlimmere Dinge hinterher.

Wenn das Problem gelöst ist, kann man darüber lachen. Aber in dem Moment, wenn man nicht weiß, woran es liegt.

Es ist schon also das Gefühl, wenn du sunde gelöst, dass das ist. Ich weiß es nicht. Ich kann nicht sagen, es ist besser als beim Sex.

Aber okay, ja, ich weiß, was es so weit kommt sich vor wie Superman.

Ja, auf jeden Fall. Es ist halt klar die Endorphine, ein bisschen Aufregung und Spannung, Endorphine werden ausgeschüttet und wenn es dann gelöst und das andere Adrenalin weg ist, da fühlt sich einfach nur so Hey Vasile, das Widersprüchliche hier an der Lektion ist ja, dass die Unternehmen oder gerade auch Großunternehmen einen unglaublichen Aufwand betreiben, dass es eben nicht dazu kommt.

Also viele Back ups, redundante Systeme, 24/7 Support. Und trotzdem Irgendwann bist du fällig. Irgendwann passiert die Katastrophe. Ich weiß nicht. Gerade wenn man ein System schnell weiterentwickelt. Irgendwo ist ein Fehler drin, den keiner bedacht hat. Ob es ein Schaltjahr ist, das hatte ich auch mal bei einem System. Da fehlte der letzte Tag, weil das Jahr 366 Tage hatte statt 365. Das war nicht bedacht worden. So konnte am letzten Tag keine Buchung erfolgen.

Das sind alles so Dinge, die können passieren und das Wichtige ist, damit zu rechnen. Ich finde, daran erkennt man immer so supergut den Unterschied zwischen Junior Developer und Senior Development, weil da passiert das, was du beschrieben hast. Die einen haben die Hornhaut, die anderen haben die noch nicht. Pferde Junior Developer ist so wie ich damals schweißnass gebadet. Völlig paralysiert und weiß nicht, was er machen soll, und der Senior Developer zieht die Handschuhe an und greift ins Feuer.

So ungefähr. Bleibt ruhig. Okay, das Kind ist jetzt im Brunnen gefallen. Welche Optionen haben wir? Was können wir machen? Was man die letzten Schritte, die du getan hast? Welchen Impact hat das im Grunde? Wie gehen wir jetzt vor? Natürlich zügig, aber diszipliniert wird an einer Lösung gearbeitet.

Und das ist auch sozusagen die Lösung dieser Katastrophe. Das ist auch ganz wichtig, dass das Management mitspielt. Task Force zusammenstellen, alles stehen und liegen lassen und sich um das Problem kümmern. Den Rücken dieser Task Force freihalten. Ja, vielleicht alle paar Stunden mal den Status abfragen, damit man das entsprechend kommunizieren kann. Richtung Vorstand oder Kunden, den Fortschritt und das aktuellen Problem Status Monitoren. Was kann man machen? Wo befinden wir uns und wirklich sehen, dass das Team die volle Konzentration auf das Problem werfen kann und nicht gestört wird?

Kein Telefon und so weiter. Also außer zur Problemlösung dann erlaubt und auch dem Team dann die nötigen Ressourcen, also Experten z.B., die sich mit einer Technologie ganz besonders gut auskennen, die dann eben Hilfestellung geben können, in kritischen Situationen zur Verfügung stellen. Und Annas Team muss man einfach sagen Bleib dran, ihr müsst durchhalten. Es gibt ein tolles Zitat von Winston Churchill. Das fällt mir in diesem Zusammenhang immer wieder ein If you going to hell, keep going.

Also nicht stehenbleiben, weitermachen, dranbleiben, das Terrier gehen, auspacken und einfach weiter daran arbeiten, bis das Problem gelöst ist. Und unterwegs Schadens Minimierung betreiben. Natürlich.

Aber ich kann es immer noch nicht glauben. Du hast keine Katastrophe erlebt.

Nee, ich überlege echt die ganze Zeit. Aber wie gesagt, es ist halt relativ Katastrofe.

Also ich weiß, dass wir schon in Projekten gearbeitet haben, wo Leute panisch über den Flur gelaufen sind, weil die Webseite offline war. Wenn das dich nicht aus der Reserve gelockt hat, dann hast du auf jeden Fall mehr Hornhaut als ich.

Die Sache ist eine Sache der Perspektive. Willst du brauchst einen kühlen Kopf bewahrt.

Ich weiß, einmal ist ein Manager aus dem Urlaub zurückgekommen, hat sein Notebook eingesteckt, dann auf dem Notebook lief noch irgendwas Server Komponente vom Produktiv System, die in der Entwicklung dann noch gestartet war und dann klappt das Notebook auf. Und dadurch, dass er eine Zeitlang im Urlaub war, zieht das Notebook alle Events von Zeitpunkt. Ich gehe jetzt in Urlaub bis Zeitpunkt. Ich bin wieder da. Nach dem Produktionssystem und blockiert das ganze Produktionssystem stundenlang und keiner wusste, woran es liegt, weil keine Änderung erfolgt ist, außer dass dieser Mensch aus dem Urlaub zurückgekommen ist, was man ja auch erst nicht weiß.

Das war auch eine heiße Phase, diesen verkehrssicher auf Rädern, weil sie rausgefunden haben, da haben nicht wir geschwitzt, da hat er dann geschwitzt, aber das weiß man dann erst nicht.

Es sind einfach so Sachen. Technologie ist manchmal wunderbar wie Magie und manchmal auch sehr einfach. Und sehr dumme Fehler passieren. Das muss man auch sagen. Na ja, ich freue mich, mit dir im zweiten Teil über die Lektionen 6 bis 10 zu sprechen, nachdem wir jetzt die Lektionen 1 bis 5 durchgegangen sind.

Ja, sehr gerne freue ich mich auch. Bis dahin ganz schön nochmal überlegen, ob wir noch ähnliche Katastrophen erleiden wollen.

Genau da greifen wir den Faden wieder auf und machen noch so einen Marsyas Katastrophen Blog am Anfang. Sehr schön bin ich gespannt, wo die die meiste Hornhaut gewachsen ist. Wenn unsere Zuschauer Fragen haben oder Feedback zur aktuellen Podcast Episode, können Sie uns eine E-Mail schreiben an Podcasts. Geh weiter. Wir freuen uns immer über Bewertung oder Weiterempfehlung des Podcasts an eure Freunde und Kollegen. Schaut darauf, dass Gilbert Jopp Seite vorbei. Wenn ihr mehr spannende Technologie Themen lesen möchtet, schaut auch auf der Skjelbred Website Slash Blog vorbei und abonniert natürlich unseren Podcast.

Ja, es war wie immer eine Freude. Ich wünsche noch einen schönen Abend.

Bis dahin.

Maurice KnoppSkillbyte Podcast #39: 10 Lektionen, die wir in 40+ Jahren Softwareentwicklung gelernt haben (Teil 1)
Mehr

Skillbyte Podcast #18: Warum sind IT Projekte so teuer?!

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Warum sind IT Projekte so teuer?!

// Inhalt //
00:36 – Was sind die Kostentreiber in IT Projekten?
01:07 – Problem: Wasserfall bei unklarer Route
04:54 – Problem: Kein klares Zielbild
07:47 – Verbesserungsvorschlag: Klares Zielbild – Was leistet die ideale Zielsoftware?
08:22 – Problem: Entwickler dürfen beliebige Technologien einsetzen
10:27 – Verbesserungsvorschlag: Systemarchitekt gibt Architektur vor, geringere Komplexität
12:21 – Verbesserungsvorschlag: strenge Sprint Zielkontrolle und offene Fehlerkultur
13:15 – Problem: Projekte werden mit Zieltermin statt Ziel-Funktionsumfang begonnen
14:07 – Verbesserungsvorschlag: nur wirklich wichtige Kernfunktionen festlegen
14:38 – Problem: Agile Movement
16:47 – Verbesserungsvorschlag: offene Sprint Reviews & Verantwortungsübernahme
17:25 – Verbesserungsvorschlag: Übertrage klare Verantwortungen!
18:54 – Problem: unklare Kommunikation
19:16 – Problem: Alle Konflikte im Team vermeiden wollen
20:40 – Problem u. Lösung: Die Fachseite muss ansprechbar sein
22:15 – Probleme im technischen Bereich
23:21 – Verbesserungsvorschlag: Neue Technologien und Projekte erst nach Rücksprache nutzen
24:26 – Problem: Integration von Altsystemen
26:24 – Unsere Faustregeln für erfolgreiche IT Projekte
31:14 – Faustregeln für Aufwandsschätzung

Wir empfehlen zu dem Thema auch die Podcast Episode #9: Bull’s Eye Software Development – Einfach und fokussiert auf Unternehmensziele
https://soundcloud.com/skillbyte/podcast-9-bulls-eye-software-development-einfach-und-fokussiert-auf-unternehmensziele

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Herzlich willkommen zum skillbyte Podcast Nummer 18. Warum sind IT-Projekte so teuer? Ich freue mich herzlich, die Zuhörer willkommen zu heißen. Vor der heutigen Ausgabe. Ich bin heute wieder mit Masala. Hallo Masa!

Hi, wenn euch der Podcast gefällt, abonniert ihn gerne oder lasst uns einen Daumen hoch oder ein leichter, wenn ihr Zuhörer Fragen habt, schreibt uns eine E-Mail an Podcast. Elbseite beginnen in der nächsten Episode darauf ein, und wir freuen uns immer über Bewertungen, positive Bewertungen und auch negative Bewertungen. Oder mit konstruktiver Kritik. Damit wir wissen, was wir besser machen können. Was sind die Kostentreiber in Projekten? Soll uns heute beschäftigen. Ich bin mir ganz sicher, dass wir beide dazu einiges zu sagen haben.

Oh ja, oh ja.

Ein leibliches Thema, das aber auch unsere Zielgruppe interessiert, um herauszufinden, wo das Geld hingeht oder warum IT-Projekte wir jetzt nicht sagen, wie Bauprojekte ja doch relativ oft das Budget überschreiten und deutlich überschreiten und auch den Zeitplan deutlich überschreiten. Wenn es um die Fertigstellung geht was glaubst du, ist denn Nr.1 Grund? Ich habe eine Theorie, aber ich würde sie gerne von dir zuerst hören.

Also Nr. 1 Grundwort Projekte, die teuer sind? Ja, genau. Klassischerweise wurden Projekte erstellt im Sinne eines Wasserfalls Modells.

Das heißt, man hat sehr lange bevor das Projekt überhaupt los war. Ich spreche von Projekten.

Genau um die geht es auch heute sehr lange, sich eingeschlossen. Ich sage mal Stellen, Fachabteilungen, Kämmerlein hat sehr viel die Prozesse durchgesprochen und was man genau will und wie das alles aussehen soll. Und dann ging es darum Okay, das muss das jemand erstellen. Und dafür braucht man Grays Wollen wissen, was uns das kostet. Damit ich ein paar kaufmännische Zahlen drüber legen kann. Was bringt uns das? Und so weiter und so fort. Und dieses Pflichtenheft hat aber sehr schwierig, diesen zu formulieren, weil man sehr genau eigentlich schon im Vorfeld wissen musste, was man genau braucht.

Also die Glaskugel. Man muss in die Zukunft schauen, in die Glaskugel schauen, genau, genau das.

Ich habe öfters ein solchen Pflichtenheft mitgewirkt, und das war immer ein riesen Akt, sehr schwierig zu erstellen, und am Ende hat es auch nichts gebracht. Dann hat eine Firma einen Preis abgegeben, die diese Ausschreibung bekommen hat. Natürlich haben Sie Ihrem entsprechend prozentualen Aufschlag drauf geschlagen. Sicherheit oder Risiko? Marge Und das Problem ist, dass, wenn es dann mit der Entwicklung losgeht und man irgendwann ein Ergebnis präsentiert bekommt oder vielleicht Meilensteine präsentiert bekommt, dann stellt man fest Welche Prozesse im Unternehmen sind wirklich sehr komplex?

Und man durchschaut nicht alles sofort oder kann alles manifestieren. Und man bekommt dann erst mit, wenn man diesen Aufschlag hat, damit interagiert, dass man das ein oder andere doch anders gerne gehabt hätte, oder? Es hat die Entwicklung so lange gedauert, dass der Prozess sich geändert hat. Aber die Firma hatte ja schon Preis dafür abgegeben. Man sagt, dass das diese Wasserfall Modelle immer zu 80 prozent Autoteilen und ordos Budget war. Mit gutem Grund.

Das heißt, erst bei der Umsetzung hat man dann Fragestellungen aufgeworfen, oder die sind dann entstanden, die man im Grunde nicht abgestellt hat, weil man dann erst festgestellt, dass es so und so und ganz, ganz genau gab.

Es ist auch immer ein Konfliktpunkt zwischen Dienstleister und dem Auftraggeber. Was ist jetzt eine änderung? Und können wir das noch rein nehmen? Und dann hat sich das wieder nach hinten verschoben. Von der Zeit wurde immer teurer, und deswegen sind oder waren IT-Projekte teuer und sind aus dem Ruder gelaufen.

Beide Seiten sind unglücklich. Der Anbieter versucht, dem Kunden alles auszureden, damit er ja keine Mehrarbeit leisten muss, nach dem originalen Vorkasse zu bleiben oder Budgets bleiben. Und der Kunde möchte natürlich so viel wie möglich an änderungen unterbringen, ohne das Budget zu erhöhen. Dann hat man diesen Konflikt ein bisschen länger ausgeruht.

Da sprechen wir ja jetzt in der nächsten Stunde ein bisschen drüber. Aber das hab ich jetzt gebraucht, um dir zu antworten und zu sagen, warum die Projekte teuer werden. Ich glaube, weil man im Vorfeld nicht weiß, was man will, und deswegen ändert sich das permanent. Dinge kommen dazu, Dinge fallen weg. Deswegen wird es teuer.

Du hast jetzt auch organisatorische Fallstricke angesprochen, weil häufig. Ich habe das ein bisschen für mich aufgeteilt. Meiner Ansicht nach gibt es organisatorische Gründe für Budget, überschreitungen und technische Gründe. Und ich glaube auch, dass die organisatorischen mit Abstand einen größeren Anteil am Budget überschreitung haben. Aus vielerlei Gründen. Jedes IT-Projekt ist ja ein Stück weit, oder was man dann umsetzt, ist ja ein Stück weit ein individual Projekt, weil sonst kaufe ich eine standardlösung installiert und bin fertig.

Und bei individual Lösungen, das ist wie das muss man sich vorstellen, wie wenn der Architekt ein Haus plant und. Das ist immer genau dann auf den USGS zugeschnitten und auch beim Hausbau. Jeder, der mal ein Haus gebaut hat, der weiß, dass da ganz schön viele Eventualitäten dazukommen können, und der Preis, der auf dem ersten Angebot steht, ganz, ganz selten der Preis ist, den man letztlich auch bezahlt. Ich bin immer verblüfft, weil bei der Architektur verstehen, dass die Leute sofort.

Aber bei der Software, weil das so etwas Abstraktes ist, kommen die Leute oft auf die Idee. Ich sage mal Kurz vor Fertigstellung wollen sie noch ein Stockwerk mehr und den Balkon auf die andere Seite versetzt haben.

Gute Metapher. Und wundern sich dann, warum das warum die Projektkosten explodieren. Bei einem Hausbau ist völlig klar, dass ich so eine weitreichende änderungen, die ich durch schaue oder die ich ja sehen kann, anfassen kann. Warum auf einmal, da die Kosten aus mir laufen? Also ich würde sagen, das ist schon angesprochen der Nr.1 Grund, warum IT-Projekte teurer werden, ist erstens eine ungenaue ziel. Beschreibung und mehrere unterschiedliche Vorstellungen der Stakeholder. Die sagen das Gleiche. Aber der eine meint das, der andere meint das ja.

Es muss ein System gebaut werden, was unser altes System ablöst. Der einer sieht nur seinen Prozess. Der zweite Mensch im Projektteam sieht zwar andere Prozesse von der, die das als System leistet, von denen der erste gar nichts weiß. Dann wird aus so einer wabernden Vorstellung wird ganz, ganz schnell, weil es schnell gehen muss, ein IT-Projekt aus dem Boden gestampft in Folge 9 oder Episode 9. Das Gebiet podcaster mal drüber gesprochen, kein Business Value Software Development gemacht, sondern es wird nicht geguckt.

Was sind denn die Prozesse, die werthaltig sind? Was ist wirklich das, was unser Unternehmen voranbringt oder unsere Prozesse vorwärts bringt, womit wir Geld verdienen, sondern da wird so eine Wünsch dir was Kiste aufgemacht. Und um alle zu befriedigen, darf jeder da sein Wunsch Zettelchen einwerfen, und du hast einen riesigen Wust, aber keine oder seltene, genaue ziel. Beschreibung, dann ist das Ziel für die Entwickler, und für die Konzeption ist einfach nicht klar. Also eine ganz genau ziel.

Beschreibung. Was müssen wir machen? Und was soll das fertige System leisten? Auch meinetwegen auf einem abstrakten Niveau. Das ist extrem wichtig, meiner Meinung nach ein bisschen verschlimmert. Noch wird das Ganze durch dieses agile Paradigma. Ja, wir legen erst mal los. Wir müssen uns jetzt gar keine Gedanken machen, sondern wir fangen an zu entwickeln. Und unterwegs treffen wir das dann noch so.. Ja, das ist richtig, wenn man ein Ziel Bild hat und das unterwegs nachschärfen.

Aber ich kann nicht anfangen, ein Softwareprodukte zu bauen oder ein Haus zu bauen, was als Gartenlaube gedacht ist, und dann unterwegs auf Bürogebäude umschwenken oder so. Ohne das die Kosten völlig aus dem Ruder laufen. Auch hier Software ist abstrakta ist das nicht so sichtbar. Bei der Baustelle würde das jeder sofort verstehen. Und also ganz klar. Problem Nummer eins Ungenaue Beschreibung, würde ich sagen. Aber wir wollen ja nicht nur schimpfen, sondern auch Tipps zur Verbesserung geben.

Meiner Ansicht nach lohnt es sich auch, wenn man agil unterwegs ist, sich im Vorhinein Gedanken zu machen und viele Gedanken darauf zu verwenden. Wie sieht denn die ideale ziel. Software aus? Welche Funktionen übernimmt sie? Welche Daten verarbeitet sie? Wie ist der grobe Fluss der Daten durch das System? Meiner Ansicht nach lohnt sich jede Planung Stunde, die man vorher investiert, 20 fach hinten raus, weil man einfach viele Sachen, die man nicht braucht, komplett weglassen kann und eine genaue Planung dahinter hilft, viel unnützen Code eben nicht zu schreiben, weil man von vornherein da klar ist, dass ein Thema aufgrund dieser Problematiken, die wir am Anfang besprochen haben, ist ja überhaupt das Agile und Scrum entstanden.

Da ist es irgendwie der nächste Pferdefuß. Was ich jetzt sage, mal in Entwicklungsteam so der agilen entwicklungsteams so mitbekomme, ist das ein bisschen vergleichbar mit dem Föderalismus. Was wir, was wir in Deutschland haben? Man versucht irgendwie, alle Entwickler in so eine Rolle zu zwingen oder gewisse Freiheiten oder gewisse maximale Freiheiten zu geben. Und das müssen einfach IT-Leiter und deutsche Unternehmen verstehen. Das Entwickler Spiel Kinder Entwickler spielen gerne mit modernen Technologien. Sie wollen mit modernen Technologien spielen, damit sie etwas dazulernen, damit sie wie das auf ihrem Zivi gut macht.

Entwickler werden mich jetzt wahrscheinlich hassen, aber das ist halt eine gewisse Technik.

Spielerei kann man ja niemand abstreiten. Das man macht ja jeder Mensch auch.

Ich denke ja genauso absolut in Ordnung, aber es muss zielgerichtet sein, es muss zielgerichtet sein.

Und aus Unternehmer Sicht muss man da halt ein bisschen vorsichtiger damit umgehen, was dann passiert ist. Und das ist jetzt nicht Theorie, sondern tagtäglich in vielen Projekten, so dass ein unheimlicher Wildwuchs von Technologien in einem Projekt entsteht, weil jeder mit irgendwas experimentieren will, das in Produktion wandert Entwickler übermorgen oder der Externe, was auch immer in einem Jahr wieder weg ist. So wächst das System um Frameworks und Leichen, die nicht dokumentiere. Und dann hast du ein Wildwuchs, dessen du nicht mehr Herr wirst.

Worauf ich hinaus will, ist Komplexität. Das ist so etwas wie System, Entropie. Und je höher die Entropie ist, umso mehr Chaos entsteht. Das ist eins zu eins widerspiegelt auf die Software-Entwicklung. Welt Du wirst der Komplexität nicht mehr Herr, und du kannst Entwickler nicht gleichberechtigt nun sagen So euch mal eine schöne Welt aus, setzt alles ein, was ihr möchtet. Meines Erachtens ist meine persönliche Meinung. Brauchst du immer. Das gab es früher immer Architekten in Projekten, der erfahren.

war, viele Projekte gemacht hat und die Architektur ein bisschen vorgegeben hat, ein bisschen darauf geachtet hat, was ein scheinbar umsetzen, was ein Wir setzen, was ein bisschen darauf geachtet hat, die Komplexität niedrig zu halten, manage skalierbar zu halten. Und wenn du das mal gemeinschaftlich in die Hände von vielen gibst, dann passiert genau das, was im Föderalismus passiert. Jeder kocht sein eigenes Süppchen, und jeder hat mitzureden. Und dann entsteht Chaos.

Das kann ich mir meines Erachtens im Unternehmens Context nicht erlauben, da es zu Recht die IT-Mitarbeiter, das sind auch irgendwo Wissenschaftler. Und wenn man Wissenschaftler da hat jeder so ein Bild vor Augen einfach in ihrem Labor einsperrt und sagt Macht irgendwas, da passieren viele Dinge. Aber gegebenenfalls gerät das Ziel aus den Augen. Genau. Also auch hier Ziel, Fokussierung. Und ich bin auch absolut dafür, dass es im. Oft sagt man in Scrum Teams Alle sind gleichberechtigt.

Ich denke auch, dass die erfahrenen Mitglieder auf jeden Fall so ein Drahtgitter Modell für die Architektur vorgeben sollten. Das hat einfach den Hintergrund, dass man a kennt sich damit aus jahrelanger Erfahrung und b ist das auch wieder so eine ziel. Fokussierung, eben nicht jedes Framework mitzunehmen und sich einfach an Standards zu orientieren, weil die Entwickler denken Ui, hier gibt’s ja neue Technologie, das kann ich benutzen, und das macht mir vielleicht etwas einfacher. Was Sie aber nicht sehen, ist der Maintenance auch dran?

Jemand, der vielleicht nach mir kommt, der muss sich auch damit beschäftigen, der muss das lesen. Er muss verstehen, was ich da gemacht habe und so weiter und so fort. Und das zieht halt dann einen ganzen Rattenschwanz nach sich. Und ich würde auch sein. Komplexität ist auf jeden Fall ein Feind für Projekte, Laufzeiten, was auch wieder damit zu tun hat. Genaue Ziele, Beschreibung auch architektonisch, technisch. Eine genaue Beschreibung ist auf jeden Fall Wert voll.

Wir wollen ja immer sagen, was man noch besser machen kann, und nicht uns einfach nur beschweren, sondern auch Input geben. Für die Zuhörer. Wie kann man das machen? Ich bin auch ganz knallhart dafür, dass man, wenn man Sprints macht, dass man danach eine strenge, ziel. Kontrolle hat, also wirklich sagt. Wie viel hat jemand geschafft? Klare Kommunikation. Ist das ausreichend? Kann man das besser machen? Auch unpopuläre Ansagen machen, um zu sagen Okay, das Framework kann man benutzt.

Das hat sich nicht als werthaltig herausgestellt. Wir probieren jetzt was anderes Probleme, Verbesserungspotenzial, offen ansprechen, aber dann dem Team auch helfen, diese Probleme lösen zu können. Also entweder durch Weiterbildung in einer bestimmten Technologie, durch modernere Hardware oder durch Ansprechpartner, die sich dann um das Problem kümmern und dann eben auch die Verbesserungen im nächsten Sprint, übernächsten Sprint und so weiter dann eben zu prüfen. Ich glaube, das hilft schon mir dann noch. Ich muss nochmal auf dieses Ziel Bildteil, diese ungenau ziel.

Beschreibung und das glaube ich, kennt jetzt jeder IT-Berater oder auch die Entwickler. Projekte werden oftmals gestartet mit der Frage Wann können wir live gehen? Die erste Frage ist Wann ist das fertig? Sozusagen. Anstatt zu fragen Welche Funktionen brauchen wir denn? Und das ist meiner Ansicht nach auch ein großer Problem. Punkt, dass man sagt Wann ist es denn fertig? Das kann ich auch verstehen aus busens Sicht. Aber jetzt muss man sich mal vorstellen, wenn man ein Haus kaufen will, und man geht zum zu so einem Immobilienberater, und der sagt Alles klar.

Wunderbar, dass Sie ein Haus kaufen wollen. Setzen Sie sich. Was sind denn Ihre Fragen? Die erste Frage wäre Wann kann ich einziehen? Na, dann wird auch der Berater sagen Ja, Moment, soll ein Haus sein oder eine Wohnung? Wo soll Design? Wie viel Budget haben Sie? Wollen Sie einen Garten? Wollen Sie eine Garage und so weiter und so fort? Und genau das muss man auch bei einem Software Projekt machen, das man erstmal fragt Was sind denn die wirklich wichtigen Funktionen?

Das mdep sozusagen mit dem Produkt, was erfüllt sein muss, um dann zu gucken, wenn man diesen funktions Korb hat. Okey, wie lange brauchen wir denn dafür? Und nochmal Wenn man diesen funktions Korb hat, wenn man glaubt, was alles wichtig ist, wirklich bei jedem Ding nochmal nachfragen? Ist das wirklich wirklich wirklich wirklich wichtig für die erste Version?

Oder können wir das hinterher auch machen? Können wir das hinterher machen, also wirklich den kleinen inkrementelle dann vorgehen? Das halte ich auch noch für ganz, ganz wichtig.

Passt zu dem, was noch gesagt, dass er, was auch immer, sehr witzig ist, wenn dieses Thema stramm und agil, warum man das macht, damit Projekte nicht mehr schief gehen. Unternehmen meinen, wenn Sie eine Firma anstellen, die Scrum einführt, ist das Thema gegessen.

Das Thema Nr.1 Verspätungen oder Projekt Fernzug gibt es nicht mehr. Wird ja verkauft das Agilität oder Egil oder digitale Transformation was wird die Lösung aller Probleme? Die ist dann meinen Vorstände. Na ja, gut, dann beauftrage ich halt so eine Firma, die bei mir agil einführt. Und dann finden ganz tolle Workshops und Spiele und Spaß um dieses Thema statt. Das Wichtigste Meinen Augen ist das Management oberster Ebene, aber auch in mittlerer Ebene das Thema verinnerlicht. Was das bedeutet, dass Meincke dahinter verstehe?

Ich habe ich noch kein Projekt erlebt, wo man zwar gesagt hat Ja, wir fahren. Wir fahren jetzt agil, machen agil, alles total super. Und was kostet das denn? Und dann fangen Sie an, diese Story von dieser Komplexität Abschätzungen plötzlich in Montale umzurechnen, weil diese beiden Welten sind dann noch da, sowohl die alte, und das wird dann versucht. Das ist total witzig.

Das ist auch schwierig, weil die anderen natürlich alte Business Welt oder die andere Business Welt, die ist natürlich total Termin getrieben. Wann ist sie fertig? Wann kann ich, was ich mache? Die werden ja von ihren Kunden auch wieder gefragt. Und wenn der Kunde sagt Ja, wenn wir 300 Story Points abgearbeitet haben, drängt sich natürlich die Frage auf Was heißt das jetzt? Dieser Wechsel, dieser Mentalitätswechsel hin zu Komplexität? Begg Von Zeit ist natürlich auch schwierig, aber deshalb halte ich es nochmal.

Ich stelle es noch mal raus für ganz wichtig, dass man sich mit der Kern notwendigen Funktionalität beschäftigt und sagt Okay, das machen wir erstmal und haben das innerhalb von nicht mein Gropp kann man es ja schon abschätzen 2 3 Monaten realisiert. Und die ganzen Sonderfunktionen? Die bauen wir dann danach dran. Und dann kann man jede Woche oder alle zwei Wochen je nach Spendende kann man den Fortschritt sozusagen dann eben kundtun, dass es auch noch eine Verbesserungsmöglichkeiten, die ich jedem empfehle, sind offene springend Reviews mit kurzem Projekt Intro, das man nach einem Sprint.

Die Entwickler, die Projektmanager, stellen vor, was in diesem Sprint erarbeitet wurde. Dass diese Runden offen sind. Im Grunde kann da jeder aus dem Unternehmen hinkommen, der möchte oder von Kundenseite auch der möchte. Dadurch entsteht so eine Art Verantwortlichkeit des Teams gegenüber der geleisteten Arbeit, und ich halte das für sehr, sehr wichtig. Verantwortlichkeit ist sehr, sehr wichtig. Und die Entwickler stellen kurz vor, woran sie gearbeitet haben, welche Fortschritte sie erzielt haben, und stehen danach auch für Rückfragen zur Verfügung.

Aber das zwingt die Entwickler, Verantwortung für die eigenen Module zu übernehmen. Unklare Verantwortlichkeiten ist auch ein ganz, ganz großer Killer und Kostentreiber. Du kennst das wahrscheinlich auch riesige Meeting runden, um alle abzuholen mir im Betrieb. Paar Wochen später fällt eine Komponente aus, und es ist völlig unklar Wer kümmert sich jetzt darum nicht? Wessen Fehler ist das? Sondern wer kümmert sich darum, dass das jetzt behoben wird? A Und das ist vor allen Dingen nicht wieder Auftritt.

B Der Monitor bestimmte Größen, ob das speicherplatzes Server, auslastungen, Netzwerkkarte ausgefallen und so weiter. Gibt es eine Checkliste für die Inbetriebnahme von Komponenten? Diesen übergang von Entwicklung zu verantwortlichem Betrieb, gerade wenn man schon Prozesse darauf ab gebildet werden, die dann produktiv sind, dass wirklich Leute zu benennen oder Teams zu benennen, die sich dann organisieren müssen. Das ist super wichtig. Bei sehr oft ist es so Eine Komponente fällt aus, irgendwie wird das. Dann wieder wird der Patient wieder beatmet und wird wieder an den Start gebracht.

Und danach laufen wieder alle zu ihrem Platz. Und die Aufregung im Hühnerstall legt sich wieder. Aber es ist nicht klar definiert. Wer ist denn jetzt verantwortlich, wenn das nächste Mal passiert? Und welche Größe kann ich monitoren, damit ich im Idealfall vorher schon weiß, dass es wieder sich andeutet und es gar nicht erst passiert? Das finde ich ganz wichtig und würde ich auch als Verbesserung anführen, Verantwortlichkeit den Entwicklern zu übertragen oder auch dem Team, was für den Betrieb verantwortlich ist.

Ein weiterer Punkt ist die unklare Kommunikation innerhalb von Projekt. Anforderungen, also Verstecken hinter Abkürzungen, werden nicht erklärt, alte Prozesse werden nicht hinterfragt. Halte ich auch für ein Riesending, wenn man jeden Prozess Formalin digitalisiert, mal hinterfragt Brauche ich den überhaupt noch? Oder macht er in der Form Sinn? Es zahlt auch wieder auf dieses klare Ziel ein. Kann ich auch sehr, sehr viel Aufwand sparen. Dann habe ich noch einen Punkt. Das ist mir aufgefallen, dass es da unterschiedliche Befindlichkeiten in Unternehmen gibt.

Und zwar gibt es Projektmanager, die scheuen den Konflikt nicht. Für die ist wirklich der Output wichtig. Also ist das Modul fertig. Ist es nicht fertig? Es gibt Probleme. OK. Dann bitte guckt, dass das gelöst wird. Und ok, du möchtest Technologie benutzen. Ich gebe aber Technologie BE vor, benutze Technologie BE, weil ich das vorgegeben habe. Das ist erstmal ein bisschen brutal, aber es gibt auch Struktur. Andere Projektmanager wiederum, die wollen diesen Konflikt gar nicht.

Die sind eher defensiv und sagen Nein, machst du das, wenn du das für richtig hältst, und ihr seid die Techniker, und ihr müsst das entscheiden. Und dadurch wird halt diese komplette Verantwortung. Von der Software Austellung wird quasi auf die Entwickler abgeladen. Ist ja bequem. Meiner Ansicht nach kann das nicht funktionieren, weil du dann wieder diese Insellösungen schaffst und jeder in seinem eigenen Saft schmort. Anstelle von Gemeinschaftsgefühl entsteht das allein einer Komponente Arbeiten. Man muss schon gewisse Richtlinien einhalten und Rahmenbedingungen einhalten, damit die Einzelkomponenten zusammen auch funktionieren können.

Da erwarte ich von einem Projektmanager, dass er auch in Konflikt gehen kann und sagen kann Nein, das muss jetzt, muss jetzt zusammen funktionieren, und dann müsst ihr halt müsst euch die Sache nochmal angucken. Wenn das jetzt noch nicht funktioniert und das ist deine Verantwortlichkeit für dieses Modul dafür zu sorgen, dass das funktioniert. Also bitte, setzt das jetzt auch um?

Apropos Projektmanager Wenn man heutzutage werden ja fast alle Projekte nur noch agil und so gemacht. Also Thema, Projektmanager und Zuständigkeiten. Und die Methodik sieht ja vor, dass du ein Produkt oder hast, der quasi von der Fachabteilung oder Kundenseite gestellt wird. Und der steht Rede und Antwort für all die Fragen, die man als Entwickler so hat bezüglich Anforderungen, bezüglich Vorgehensweise. Und auch das hab ich des öfteren erlebt, dass eigentlich auch so einer gar nicht richtig benannt ist, im Unternehmen oder im Tagesgeschäft so eingefangen ist, dass er den Sache nicht hinterherkommen.

Das habe ich schon ganz oft erlebt. Dass Entwickler sich da darüber beschweren, dass diese Zuständigkeit oder die Ernsthaftigkeit dieser Rolle nicht gegeben ist, weil diese Person, dieser Projektmanager, der hat wahrscheinlich schon drei Projekte für das Neue noch obendrauf.

Und jetzt muss er auf so vielen verschiedenen Hochzeiten tanzen, dass er im Grunde nur noch die die Bälle weg schlagen kann, ohne da wirklich tief einzutauchen. Okay, also die nicht Verfügbarkeit der fachleiter würde ich ja, aber genau das wäre ja jetzt auch gar nicht so schlimm, wenn wiederum das Ziel Bild klar beschrieben wäre.

Und oft ist es ja so, dass sich das Ziel dann eben entwickelt während der Umsetzung. Und dann muss natürlich die fachleiter verfügbar sein oder der Ansprechpartner verfügbar sein. Es geht ja nicht beides. Ich kann nicht bei der ziel. Beschreibung sparen und dann noch unterwegs bei der Kommunikation sparen, sondern ein tot., heißt es. So schön muss man sterben. Das waren ja jetzt sehr, sehr viele organisatorische Punkte, die wir angesprochen haben und wo wir auch Verbesserungsmöglichkeiten aufgezeigt haben.

Was siehst du denn im technischen Bereich? Wirklich harte technische Probleme, die dazu führen können, dass Projekte teurer werden oder dass Projekt Laufzeit stark ansteigt, hatte ich schon am Anfang so?

Das ist für mich Thema Nummer eins ist Komplexität. Dieses Mal agile Vorgehen ohne Architekt, das Dinge tut und irgendwo von der Bundeswehr ist. Das gehört zwar irgendwo zu Fehlerkultur dazu, dass man agil lernt. Aber wenn man eine Position im Projekt besetzen würde durch einen erfahrenen Architekten, könnte man sich halt viel Zeit, ärGer und Kosten ersparen.

Und der wäre dann auch verantwortlich. Man würde verantworten müssen, auf Hygiene achtet und all diese Dinge, dass das Projekt in gewissen Bahnen frei laufen kann, also nicht einschränkend von oben vorgehen, wie es früher gewesen ist, wo, bis Festnahmen und variabel nahm, alles vorgegeben wurde? Das ist Quatsch. Aber die Schranken dafür setzen, innerhalb derer ich mich frei bewegen.

Das sind die Fronten. Technologien, das ist die Gentechnologie, die zum Festen genaus. Und ja, auch wenn unter oder während des Projektes eine neuere Version rauskommt, benutzen wir erst mal die alte weiter, weil wir wissen, dass die stabil ist. Und das Upgrade auf die neue Version ist dann sozusagen ein Teilprojekt, wenn wir das wollen. Aber sonst benutzen halt erst mal die Alte weiter und machen das dann danach. Hohe Komplexität. Ich sehe das genau wie Du ist auf jeden Fall ein Killer.

Auch der Wechsel von Technologien während der Laufzeit halte ich für einen Killer wahrscheinlich. Im Frontend lässt sich das je nach Projekt Laufzeit gar nicht immer vermeiden. Aber dass man innerhalb eines Projektes Teilprojekte hat, wo man grundlegende Sachen umstellt und dann alle wieder sich neu eindecken müssen. Zumindest ich finde das ziemlich anstrengend, weil du du entwickelst, so eine Karte von einer Software Anwendung in deinem Kopf. Und wenn das andauernd umgestoßen wird und du dich komplett wieder neu einarbeiten musst, das es irgendwann blickt keiner mehr durch.

Und dann gibt sich auch keiner mehr Mühe, weil jeder weiß, wo in drei Monaten sowieso wieder alles anders aus. Von daher verliere ich jetzt. Hier gebe ich mir gar nicht so viel Mühe mehr, um das ordentlich zu machen. Ein weiterer technischer Fallstrick? Das weiß ich gar nicht. Ob das nicht doch vielleicht eher organisatorischer Natur ist, ist die Integration von Systemen. Da geht es häufig darum, dass alle Systeme noch angebunden werden müssen oder Daten migriert werden müssen.

Und das ist meiner Erfahrung nach auch nimmt das sehr, sehr viel Zeit in Anspruch, dass man das alte System dann irgendwie so beatmen, dass man die Daten in den neuen Topf dann eben mit übertragen kann. Das ist auch ein Punkt, lässt sich nicht immer verhindern. Aber das alte System ist meist schlecht dokumentiert, und es wird auch nicht immer. Und Leute, was es damit auf sich hat und wie das genau funktioniert, sodass man da viel trial and error hat.

Und was zieht es natürlich in die Länge, wenn man herumprobieren muss. Auch hier wieder würde ich sehen, um die Technologie oder um die Komplexität beherrschbar zu halten. Möglichst wenig erst einmal umsetzen, aber dann generell die Komponenten erweiterbar gestalten. Durch diese Micro Service Architekturen haben wir jetzt den Vorteil, dass wir diese harte Verdrahtung oft nicht mehr so extrem haben, wie das früher der Fall war. Aber auch hier und das kommt eigentlich diesem modularen Entwicklungs Ansatz schon entgegen, das man dann nach und nach weitere Komponenten nachrüsten kann oder Komponenten mit mehr Funktionen ausstatten kann, um dynamisch diese Software Landschaft hochzuziehen.

Früher hat man Software entwickelt wie ein Weihnachtsgeschenk. Man hat sich was gewünscht, dann hat man ja gewartet. Mal kam irgendjemand, der hat das Paket ausgepackt und Tadao da ist. Es ist dann wie das Geschenk der Tante.

Das kann gut sein, das muss nicht gut sein. Genau, oder? Heute ist es mehr so, dass Software entwickelt wird wie so eine Pflanze man Pflanzensamen in den Topf gießt, Wasser drauf, und die wächst so langsam nach oben. Und wenn sie krumm wächst, dann kann man auch die Pflanze an so einen Stab binden, sodass sie wieder in die richtige Richtung wächst. Nach einem Jahr hat man dann auch eine große Blume, die man aber quasi kontinuierlich begleitet hat und die Wachs Richtung beeinflusst hat.

Jetzt muss man sich einfach gewöhnen, dass es so ist. Hast du welche Faustregeln für IT-Projekte, um es besser zu machen? Also, wenn du ein Projekt aufsetzt, hast jetzt auch schon oft gemacht. Was sind die Fragen, die du dir stellst, um zu sagen Okay, ich möchte jetzt. Ich möchte auf gar keinen Fall, dass es ausufert. Sondern es soll natürlich ein erfolgreiches Projekt werden.

Ich versuche mich immer, dass das Projekt immer aus Sicht aus der Brille des Kunden zu sehen. Das. Ich würde gerne immer das Business verstehen oder den Newski hinter den einzelnen Features und eigentlich der gesamten Software. Wenn es mal Domänen, fremde oder fremde Projekte für mich sind, wo ich keine Erfahrung habe, lese ich mich sogar in diese Thematik hinein, damit ich einfach das Würdigen verstehe. Die Kunden oder die Projektleiter oder wie auch immer, die sprechen halt in ihrem Jargon.

Und das heißt Kommunikation oder Missverständnisse sind eigentlich auch ein riesen Faktor, warum Dinge in die falsche Richtung laufen. Deswegen nehme ich mir auch Zeit. Und in ersten Workshops versuche ich, das eigentlich auch sehr erfolgreich rüberzubringen, das ich mir erst mal Zeit nehmen möchte. Das Business natürlich nicht in voller Komplexität, aber ich sage mal, die Grundbegriffe und Grundbesitzes regeln und die Dynamik dieses Geschäftsmodells verstehen will. Bevor ich anfange, in irgendwas in Richtung Technik zu sprechen, weil ich will was Fundiertes haben.

Ich will das, weil gerade am Anfang, wenn du das ist wie Mathe, wenn du die Basics nicht verstehst, dann wird es hinterher immer schlimmer und immer schwieriger. Und so ist das in einem Projekt, auch wenn du dir angewöhnt, die gleiche Sprache wie der Kunde zu sprechen, das Projekt aus seinen Augen zu sehen und ernsthaft versucht, das Problem zu verstehen. Dann werden wir ganz andere Lösungen einfallen und am besten beraten und entsprechend auch am besten das Projekt Setup machen.

Du kannst daraus dann ableiten Wo haben wir Schwächen, wo aber Stärken? Was brauche ich für Rollen? Was muss ich besetzen? Aber ich versuche immer, alles zu umgehen, wo es heißt So, jetzt machen. Da ist das agile Team, legt einfach los und beachtlich inzwischen ein bisschen drauf und notfalls auch grüne Projekte nicht an. Wenn ich merke, das Verständnis ist nicht da, und da fangen irgendwie zwölf man wild auf, irgendwas rum zu prügeln oder verlieren sich ein Spielchen und Maskottchen, Schneiderei fürs Team oder Team Name?

So ein Quatsch. Das sind für mich keine ernsthaften Projekte, und da nehme ich mich auch raus.

Da ist das Projekt im Grunde schon von Beginn an verloren.

Was heißt verloren? Wenn die lang genug Geld rein schmeißen, wird es mit Sicherheit irgendwann irgendwas Vorzeigbares haben. Aber irgendwann geht es auch dem Kunden dann auch die Augen auf, wo man? Warum gibt es dann noch nichts? Und man Warum ist es so teuer wie jetzt? Vectoring? Wie? Und irgendwann fragen Sie sich Was stimmt da nicht? Und ich möchte halt nicht Teil eines solchen Teams sein. Für mich ist Softwareentwicklung immer noch eine Ingenieurskunst. Ich gehe das mal aus meiner Sicht sehr professionell an, und ich möchte irgendwas lösen und keinen Wellness-Urlaub für Entwickler durchmachen.

Das wäre dann so eine Art Du sprichst direkt auf eine Faustregel an, die ich für mich formuliert habe. Ist das die Frage? Habe ich die richtigen Leute, um dieses Projekt durchzuführen? Haben Sie schon mal ähnliche Projekte erfolgreich durchgeführt? Das ist ganz, ganz wichtig. Gerade kleinere Kunden, die orientieren sich bei Anforderungen dann oft an Silicon Valley Unternehmen und sagen Ja, bei Facebook geht das doch auch so und so, bei Google geht das doch auch so. Aber die.

Dass wir hier Multi Milliarden Dollar Unternehmen haben, die nur aus Software-Entwicklern der höchsten Güteklasse wenn ich das so sagen darf bestehen und die das natürlich einfach machen können. Und das ist vielleicht nicht bei jedem anderen Unternehmen der Fall. Da muss man sich fragen Habe ich die richtige Mannschaft, um sowas auch stemmen zu können? Dann auch eine Frage, die ich den Kunden jetzt nicht so direkt stelle ins Gesicht stelle, weil sie nichts schockieren würde, aber die ich mir dann schon selber stelle, um die Sinnhaftigkeit eines Projektes abschätzen zu können, ist Lohnt sich das Projekt für diese Firma, für diesen Kunden, auch wenn es doppelt so teuer wäre.

Und wenn es doppelt so lange dauern würde, weil man dann die Antwort ja ist, dann weißt du, dass du einen Transformationsprozess mit begleitet, der für das Unternehmen im Grunde alternativlos ist. Und dann ist seitens vom Vorstand auch oft das Commitment da, dass man auch bei Widrigkeiten das Projekt fortführt und nicht das so nicht essenzielles Projekt ist. Was dann immer gefährdet ist, das finde ich immer ziemlich schade. So, bei den Projekten arbeite ich auch nicht so gerne mit, weil ich immer das Gefühl haben Siemens.

Warum mache ich das? Warum? Wenn das nicht wirklich wichtig ist, warum setze ich meine Arbeitskraft ein? Und noch eine Faustregel, die ich aber mehr für mich postuliert habe, aber die ganz oft ganz gut hinhaut, ist, dass ich Schätzungen von Entwicklern das kennst du bestimmt auch es gibt. Es gibt unterschiedliche Schätz Typen, es gibt den Entwickler Typ A. Alles kein Problem. Da kann man irgendein Problem skizzieren, der schätzt Na, das hab ich in einem halben Tag gelöst.

Nach einer Woche sitzt da immer noch dran, weil auf einmal sich da doch unabwendbar keimten ergeben haben. Und witzigerweise sitzt dieser Entwickler oft immer eine Woche an Problemen, die er von halben Tag abgeschätzt hat. Das sind diese überaus optimistischen Entwickler. Abschätzungen. Dann gibt es das aber auch in die andere Richtung. Oh, da muss ich eine Farbe ändern. Da muss ich den Button hin machen, und das dauert bestimmt drei Wochen, damit Sie dann nach zwei Tagen fertig haben und sich sozusagen auf die Schulter klopfen können, dass Sie das viel schneller umgesetzt haben.

Und dann Mittelweg zu finden, das ist eine Kunst. Sag ich wirklich, mein Glauben abschätzen ist so einfach, aber das ist wirklich eine Kunst. Ich habe mir angewöhnt, bei Ich sage mal einigermaßen so gemittelte Schätzungen immer noch den Faktor 30 Prozent drauf zu schlagen. Wenn jemand 100 Tage abgeschätzt hat, rechne ich mit 13 Tagen Faktor 1,3 und lande oft ganz im Mittel. Natürlich lande damit oft ganz guten Treffer. Also, es gibt natürlich Aufgaben, die dauern nur die Hälfte der Zeit.

Dann gibt es Aufgaben, die liegen etwas drüber. Und dann? Das passiert oft. Es gibt Aufgaben, an die keiner gedacht, und die brauchen auch nochmal Zeit. So stehen gar nicht auf dem Zettel. Die tauchen unterwegs auf und verschlingen auch ein bisschen Zeit. Und da ist dieser 30 Prozent Sicherheitspuffer dann oft sehr wertvoll, dass man den für diese Aufgaben verwenden kann. Sehr oft hat man in der Aktie mit absolut profanen Problemen zu tun. Die Architektur ist alles da, die Schnittstellen können kommunizieren, und das Ganze konzeptionell Schwierige ist abgearbeitet.

Und dann braucht man zwei Tage, um den richtigen Datenbank Treiber mit der Datenbank zu verknüpfen, weil irgendwie Error 436 fliegt und keiner weiß, warum. Und dafür brauchst du dann zwei Tage, um das herauszufinden, wie man dieses Problem löst. Und das schätzt natürlich keiner ab.

Also, ich habe mal in kein Projekt gesehen Zeitbudget für unvorhersehbare, verrückte Fehlermeldungen. Drei Tage müsste man eigentlich, müsste man eigentlich immer einplanen, weil das passiert überall. Aber habe ich bisher noch nicht gesehen. Ich weiß nicht, wie es dir da geht.

Nee, das stimmt. Wenn ich aber eine Abschätzungen abgebe, ist es meistens so, dass ich sage mal also ich mache mir ein Excel Datei, schreibe die ganzen Features rein und mache dann drei Spalten, eine Spalte und eins ist der Schnitt.

Dieser klassische Trichter, dieser Trichter genau. Und zum Schluss dann tatsächlich diese 30 Prozent drauf. Für Unvorhergesehenes.

Das ist, so STANDARD, die 30 Prozent drauf, vom Schnitt oder vom Schnitt. Also wenn ein Geschätzter fünf Tage ist, fünf Tage, zehn Tage zwischen siebeneinhalb und da dann nochmal 30 Prozent drauf.

Heißt Eigentlich musst du nur abschätzen, was es bestenfalls und was. Den Zeitaufwand für den besten und den schlechtesten Fall und alles andere ergibt sich dann rechnen? Nee, super. Also ich hoffe, wir haben unseren Zuhörern eindringlich vermitteln können, wie wir glauben, dass man IT-Projekte schneller, besser und vor allem günstiger über die Bühne bringen kann. Also ich möchte nochmal die klare Ziel Beschreibung hier ansprechen, die ich für ganz wichtig halte und die Verteilung von Verantwortlichkeiten. Und ich denke, es ist im Sinne von allen, also sowohl den Unternehmen, die Kosten sparen, den Projektleiters die weniger Runden drehen, und den Entwicklern, die weniger Code schreiben, der am Ende nicht verwendet wird oder schlimmstenfalls in der Mülltonne landet.

Wenn wir lernen, zielorientierter Software zu entwickeln, indem. Möchte ich auch noch einmal auf die Episode IX des SKL bei Podcasts hinweisen? Wulz Development Ich glaube, die ist auch super interessant, wenn man sich für das Thema zielgerichtete Entwicklung interessiert. Ja, ich möchte mich ganz herzlich bedanken für die Session heute. Es war wie immer ein Fest. Danke, liebe Zuhörer. Wenn euch der Podcast gefallen hat, schickt uns gerne Feedback an Podcasts, abonniert den Podcast oder lasst uns eine fünf Sterne Bewertung in ihr weitere Infos aus dem technischen åland von Sky haben möchtet.

Schaut gerne auf Skill bei Slash Blog vorbei. Ich wünsche noch einen schönen Tag. Danke gut, du auch.

Maurice KnoppSkillbyte Podcast #18: Warum sind IT Projekte so teuer?!
Mehr