Tools

Skillbyte Podcast #45: Das Spring Boot Framework

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

In diesem Podcast geht es um das Thema: Das Spring Boot Framework

// Inhalt //
02:35 – Was ist Spring Boot?
03:26 – Erfahrungsbericht: Spring Boot Anwendungsentwicklung
14:43 – Spring Boot Paradigma: Convention over Configuration
15:16 – Lohnt sich der Einsatz von Spring Boot? Lernkurve?
16:39 – Ein kleiner Vergleich mit der Pyhton Welt
18:16 – Features von Spring Boot
22:31 – Spring initilizr auf start.spring.io
23:45 – Spring Support von IntelliJ IDEA
26:41 – Spring Boot Banner
27:44 – Dokumentation der Spring Boot Anwendung
29:00 – Fallstricke & Tipps
33:02 – Fazit: Ist Spring Boot empfehlenswert?

Show Notes:

Podcast #29: Die Zwölf Faktoren des Cloud Native Development (Teil 1)
-> https://soundcloud.com/skillbyte/podcast-29-die-zwolf-faktoren-des-cloud-native-development-teil-1

Podcast #30: Die Zwölf Faktoren des Cloud Native Development (Teil 2)
-> https://soundcloud.com/skillbyte/podcast-30-die-zwolf-faktoren-des-cloud-native-development-teil-2

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

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Ich denke auch, dass sich das als Blaupause und Grundlage für die voll regelrecht für Java Anwendungsentwicklung nehmen würde, weil die meisten Anforderungen aus Umgebungen kommen, wo man das eben gut umsetzen kann. Ich meine missis in den letzten Jahren nichts untergekommen, wo man jetzt auf einen klassischen ein Maschienen Server oder einen großen Mainframe irgendwas hätte entwickeln müssen, sondern man kommt eben immer eigentlich gerade wenn es Java sein soll in diese Microservices Richtung bzw. kann seine Anwendung zum Lösen eines Problems so designen, dass sie auch sinnvoll so umzusetzen ist.

Und dann ist Spring Boot wirklich ein Top Tool.

Herzlich willkommen zu unserer Skill bei Podcast Episode Nummer fünfundvierzig Das Spring Boot Framework abonniert unseren Kanal für mehr spannende Themen aus dem Technologie Umfeld. Wenn ihr die Entscheider oder die Fachkraft seid, wenn ihr eine höhrer Frage habt im Verlauf der Episode sendet uns gerne eine E-Mail an Podcast Skill Bild.de:. Wir freuen uns immer über Bewertungen und weitere Empfehlungen dieses Podcasts an eure Freunde und Kollegen, die sich ebenfalls für diese Themen interessieren.

Wenn ihr aktuell in der IT-Branche auf Jobsuche seid, schaut auch auf Skill weite Isles Jobs vorbei. Ich bin heute hier mit den beiden Skill BYD Data Ingenieurs Oliver und Andreas.

Hallo ihr zwei Callboys. Schön wieder dabei zu sein. Hallo Moritz Fela, endlich mal dabei zu sein.

Oli kennen ja schon einige Zuhörer, Andreas. Für dich ist es heute ein Novum. Aber ich freue mich wirklich, euch beide dabei zu haben, weil ihr euch sehr intensiv jetzt in dem letzten halben Jahr bzw. kann man so sagen die zweite Jahreshälfte 2000 und 20 mit dem Spring Boot Framework beschäftigt habt und auch eine recht komplexe Anwendung darauf entwickelt hat.

Genau. Wir haben als Projekt. Ich glaube, so ab August letzten Jahres bis Ende des Kalenderjahres genau haben wir eine Spring gut basierte Anwendung für den Kunden gebaut, was für uns ein völlig neuer Text steckt. Zu dem Zeitpunkt war uns aber die Möglichkeit gegeben hat, da sehr, sehr schnell production ready zu werden und eine Anwendung zu haben, mit der wir sehr schnell weiterentwickeln und testen können. Das war eine ziemlich coole Sache. Da kann Andreas aber auch noch was zu sagen, weil auch für den war das glaube ich ein neuer Einstieg.

Ja, genau. Also für mich war das eigentlich alles Komplettem, weil sowohl Java als auch Bimbos und bin tatsächlich erstaunlich schnell reingegangen. Das hat mich auch ein bisschen überrascht. Sobald man sich einmal an die Annotationen gewöhnt hat, ist man eigentlich sofort dran.

Genau das ist ja auch das Kernziel des Spring Boot Frameworks. Vielleicht kennt der ein oder andere Zuhörer ist noch nicht so oder kann auch nicht genau was damit anfangen. Deshalb würde ich kurz sagen, dass es sich um einen Quell offenes Framework für die Java Plattform handelt, welches meist genutzt wird, um eben Webanwendung zu implementieren, Microservices zu implementieren. Und das Ziel dieses Frameworks ist es eben möglichst schnell komplett Laufwege Anwendung erzeugen zu können, weil die default Einstellung der Konfiguration im Grunde sinnvoll sind.

Das ist der Anspruch, den dieses Projekt hat. Und wie das so ist z.B. beim Schachner im Menace to learn alive to Master, so ist das auch ein bisschen bei Spring Boot gestartet ist man sehr schnell, kann dann aber die Anwendung nach und nach um weitere Komponenten erweitern und eine sehr komplexe Anwendung bauen, was er ja auch gemacht hat.

Auf die genauen Inhalte müssen wir ja jetzt gar nicht eingehen, aber die Anwendung sollte als System von mehreren kleinen Microservices ineinander greifen. Wir brauchten unter anderem einen einfach zu nutzen. Das Web frommt und wir brauchten den eigentlichen Controller dahinter. Wir brauchten eine Datenbank Anbindung. Wir mussten die Möglichkeit haben, Daten im lokalen Dateisystem zu paar sistieren und und und. Das waren viele einzelne Komponenten, die wir dann entsprechend damit strukturieren konnten. Und das hat dem Ganzen wirklich einen hervorragenden Rahmen gegeben, wo man dann die Arbeit auch de facto gut aufteilen konnte, um eben das Ganze schön gekapselt zu haben.

Das hatte auch ganz viele Aspekte von der Pull-Faktor App, über die wir ja schon mal zusammen gesprochen haben, wie wir das dann Gebaute nachher auch die PEUT haben.

Andreas War das für dich? Hattest du das Gefühl, dass man es gut aufteilen kann und dass du dann so einzelne Häppchen abarbeiten konntest?

Ja, das ging eigentlich Duterte als ich zu dem Projekt dazugekommenen, was aber nur zwei Wochen war, nachdem Oliver auch damit angefangen hat, war quasi schon ein bisschen ein Grundgerüst da und werden dann aber recht schnell gemerkt. Wir brauchen jetzt noch zusätzliche Rest API Endpunkte von quasi zusätzliche Microservices. Und da hat es mich überrascht, wie einfach es war, da dann zusätzliche Sachen zu schreiben. Dann hat man einfach einen zusätzlichen Controller hochgefahren und dem Endpunkte gegeben und die konnten unabhängig voneinander dann bearbeiten.

Das hat einfach sofort funktioniert.

Das Gute ist halt bei dem Spring Framework und Spring Boot ist ja letztlich nur eine Geschmacksrichtung des großen vollumfänglichen Spring Frameworks, dass man diese Inversion of Control eben nutzen kann. Also Andreas hat es eben schon angesprochen per Annotation. Also Edin Denkakt oder Auto wiederholt sich dann die einzelnen Komponenten in die Klasse durch den Container oder durch das Framework Injektor lassen kann. Das deutsche Wort wäre glaub ich verdrahten lassen kann und dann eben diese Komponente vollumfänglich zu nutzen. Habt ihr das so Komponenten Weise aufgeteilt?

Die Arbeit oder jeder hat so ein bisschen Überblick über den gesamten Code gehabt.

Das werden glaub ich beide einen ganz guten Überblick über alles. Aber gut, wenn man zu zweit arbeitet, dann teilt man sich schon ein bisschen die Arbeit auf und Alianza ein bisschen mehr Erfahrung mit Docker Containern schon an denen, die. Deswegen hat er sich da mehr darum gekümmert und ein bisschen mehr um die Rest API selber, dann würde ich auch genau so unterschreiben und es war wirklich praktisch, dass man die ganzen Dependency es, die man ansonsten berücksichtigen müsste, dass man diese ganzen Weg gekapselt module dann sich einfach über dieses Auto via O-Ring direkter reinholen kann.

Da kann man vielleicht später nochmal kurz drüber sprechen, aber so angeteasert. Das hat es für uns dann eben auch super gemacht, das ganze mit Unit Test Abdeckung nachher zu versehen. Also diese modularer Bauweise, die hat uns da das Leben in vielerlei Hinsicht vereinfacht.

D. h. ihr habt dann wirklich Komponente für Komponente g Unit testet im Rahmen der Zeit, die wir zur Verfügung hatten.

Ja, also die war von Anfang an begrenzt. Das waren die letzten paar Wochen im Projekt Scope. Und wir haben mit den Kern Komponenten, die für den Betrieb nötig waren, entsprechend angefangen und haben entsprechend dann doch noch ein sehr akzeptables Level an Test Abdeckung für die ganze Applikation geschafft. Am Ende ja. Und das haben wir genauso gemacht.

Er war auch ein bisschen überrascht, dass wir dann doch noch so eine hohe Testa Abdeckung hingekriegt haben, weil dadurch das ganze zeitlich limitiert war. Haben wir jetzt nicht Testpiloten Development von Anfang an gemacht, da vor allem auch vieles zum Anfang noch nicht klar war, wie es am Ende aussehen würde, aber zumindest Järvi alle gesagt hat. Die Kernidee Teile der App und mit der nachträglich ziemlich einfach noch mit Tests versehen.

Das heißt, die Anwendung wurde zuerst entwickelt. Ich glaube, das kann man sagen. Es handelte sich um eine Brücke, einen Exporteur und einen Importeur von zwei verschiedenen Systemen, der einfach Daten transformiert hat zwischen diesen Systemen. So, und da waren wahrscheinlich die Schnittstellen nicht ganz klar und es hat sich erst im Verlaufe des Projektes herausgestellt und dann am Ende, als die Schnittstellen klar waren und die schon bespielt werden konnten. Habt ihr das dann nochmal getestet? Richtig. Also das Ganze war, wenn man es drastisch formuliert, wirklich als One-Shot Anwendung konzipiert.

Man hätte das natürlich dadurch, dass sowohl das Quelle als auch das Zielsystem weitverbreitet sind in der Branche, in der der aktuelle Kunde da unterwegs ist. Aber die Systeme waren jeweils so spezifiziert und an die Bedürfnisse des Kunden angepasst, dass es viel mehr Aufwand gewesen wäre, das deutlich generischer zu machen, um es als Produkt dann auszuarbeiten, sodass wir da wirklich eine maßgeschneiderte, schnell entwickelte Lösung gebaut haben.

K Perfekt. Jetzt habt ihr diese Anwendung gebaut. Wenn ich das richtig verstanden habe, Oliver, du hast dich so ein bisschen um die Pakete gekümmert. Docker Den Betrieb oder die DevOps Komponente. Andreas Du hast vielleicht etwas mehr an der Anwendungs Logik gearbeitet. Hattet ihr das Gefühl, dass euch springender Gut unterstützt, also dass ihr euch wirklich auf eure Kernthemen konzentrieren könnt Infrastruktur oder Anwendungs Logik? Oder hattet ihr oft das Gefühl oh ich schreib hier Boiler Pleite Code um die x te Datenbank Verbindung aufzumachen oder sowas?

Das muss doch einfacher gehen.

Er sei ein bisschen hatte ich schon den Eindruck, dass man ein bisschen Boiler Plaid Code schreibt. Gleichzeitig hatte ich aber auch den Eindruck, dass es weniger ist als meine Java sonst machen müsste. Da ich wohl noch nicht so Java Erfahrung hatte, war mir bewusst, dass ich da mehr bei der Palette Code schreiben muss, als z.B. ein Payton war. Das hat sich dadurch ein bisschen in Grenzen gehalten.

Hast du ein Beispiel für Boiler Plaid er gut alle Geta an CETA hat man einen Partner z.B. einfach nicht. In Ada kann man vieles umgehen in der Stelle.

Für mich hats massiv Code gespart. Du hast das Stichwort Datenbank Anbindung gerade genannt. Da ist durch JPY zu den technischen Feinheiten kannst du vielleicht gleich noch kurz etwas sagen ist uns extrem viel Arbeit abgenommen worden. Also da bringt Spring Boot von Hause aus die Möglichkeit mit, das sehr elegant zu nutzen, in dem nicht nur einfach die Gredenko sieals und die Konnektivität Informationen zu einer Datenbank übergeben werden, sondern man hat auch über vordefinierte Funktionen hat man die Möglichkeit, die Tabellen selber direkt anzulegen.

Also die Schemata. Das wird alles von Springflut über sehr viele einzelne Komponenten ermöglicht, ohne viel Aufwand an der Datenbank selber betreiben zu müssen. Das ist wirklich schön gemacht.

Ja, das stimmt. Also ein sehr komplexes Datenbank Schema, wie wir dann letztendlich doch eigentlich hatten, halte ich glaube ich hier. Wenn ich die hätte selber schreiben müssen ich in der Zeit hinbekommen. Auf jeden Fall.

Vor allem wenn man noch die SQL Schnittstelle selber in irgendeiner Form hätte bauen oder mit kleine SQL Code hätte bedienen müssen. Und da nimmt einem JPC dann eben schon extrem viel Arbeit ab. Und das hat dann auch def abseitig viel gespart, weil man einfach die Datenbank zur Verfügung gestellt hat, die Konfiguration in JPL mit ein paar Zeilen schnell gemacht hat und dann lief das. Das muss man einfach dazusagen. Das war wirklich einfach die JPL. Hier steht ja für die java persistent api die eben genau.

Für. Daten bank. anbindungen. Da ist. Oder persistenz. Schicht anbindungen da ist. Und das schöne hier ist. Dass man im grunde. Das es gerade gesagt. Diese tabellen relationen. Oder das datenbank schema. Das kann man einmal anlegen. Und jpl kümmert sich dann darum. Je nach dem ob du eine postgresql datenbank hast. Maisie. Soldaten. Bank. Oracle. Datenbank. Den. Richtigen exkl. Dialekt nenne ich es mal zu generieren, so dass das konkrete Backend dann eben unterstützt wird.

Und das macht natürlich auf Migration sehr einfacher. Der eine Kunde setzt die Datenbank Technologie ein, der andere Kunde setzt die Datenbank Technologie ein. Da möchte man kein Wenn du Login haben, sondern die JPL benutzt, läuft es überall oder auf allen Datenbank Plattform, die eben JPY Unterstützung erfahren, was die meisten sein dürfen.

Ja, das Thema Parketts hierum hast du eben angesprochen. Hass hat für mich auch nochmal leicht gemacht. Das war dann die Zusammenarbeit von Spring bzw. Spring gut und eben Maven als Paket Manager dies mir extrem leicht gemacht hat. Die Anwendung dann einfacher dem Docker Container zu betreiben, also sowohl schon für Entwicklungs Zwecke wirklich jeder auf seinem Entwickler Laptop was auch praktisch war war. In Docker waren wir dann eben auch völlig unabhängig davon, weil ich habe es offene Meek gemacht Andreas glaube ich auf einem Linux System.

Das lief dann alles sofort und auch der Roll outs beim Kunden war dadurch viel einfacher, weil der Ebene Container Umgebung zur Verfügung gestellt hat und wir dann nur noch da rein diplomen mussten und dann eben mit dessen, der vom Team geklärt wurde, wie dann der Betrieb abläuft. Aber dadurch, dass wir eben die Pakete hierum über Maven und Spring buht dann eben hatten und das ganze schon im Docker Container betriebsbereit zur Verfügung stellen konnten. Sehr einfach war das ein Kinderspiel und schnell gemacht.

Das war echt toll. Da habt ihr direkt eine Stärke von Spring Boot voll ausgespielt in Kombination mit Docker, weil ich sag euch das früher war das nicht so, dass man eine Java Anwendung direkt ausführen konnte oder es war ganz ungewöhnlich, sondern es gab einen sogenannten Application Server an Tomcat aus dem freien Bereich oder auch verschiedene proprietäre Produkte. Von RedHat hieß es z.B. J. Bors und das war ein sehr schwergewichtige Server, die also teilweise mehrere Minuten benötigt haben um zu starten.

Und da wurde dann die Anwendung alzu war fail oder eher fail wurde die Anwendung rein die bloed und rein geladen und die wurde dann auf diesem Server ausgeführt. Das ist natürlich heute in der kybernetisch Umgebung Microservices Umgebung ist das überhaupt nicht praktikabel, dass man da einen Server hat, der sehr viele Ressourcen braucht und der mehrere Minuten zum Starten braucht, sondern da möchte man eine kleine ausführbare Code Einheit haben, die ihre dedizierte Aufgabe übernimmt. Und da bietet sich natürlich das selbst laufende Spring Boot Programm an oder die selbst laufende Applikation ist es ja ein derFall was man direkt starten kann.

Wir haben in dem Zusammenhang genau das bekommen, nämlich ein Zerfall, was schon alle Dependency es enthielt. Man musste da keine Libraries mehr installieren und gar nichts. Man konnte mit einem minimalistischen Docker Image anfangen. Es musste nur Java installiert sein. Dann hat man das ja ausgeführt. Wenn man wollte noch ein paar Laufzeit Parameter mitgegeben und dann lief die Anwendung und die ethical schon eben diese Webserver Komponente. Zum Beispiel wenn ich mich erinnere an meiner Anfangszeit in dem Projekt, wo ich noch nicht so vertraut war.

Damit hab ich noch einen extra Docker Container hochgefahren, wo ich in Engine X Webserver drin betrieben habe, damit ich diese Rest API überhaupt irgendwie ansprechen konnte. Und irgendwann haben wir dann verstanden, dass Springflut das schon von Hause aus mitbringt. Aber da hat Andreas viel mehr mitarbeitet als ich.

Ja, da kam dann aber nochmal die zweite Erkenntnis. Also erstmal wie obligat gesagt hat, des Rest Framework selber. Aber man habe dann festgestellt, dass es ja wirklich war, seinen kompletten Webserver der auf Heilberufe mitliefert. Wir hatten dann nämlich doch nochmal eine Endings dazu, die Plots, um einfach statisch ein paar Fails für das Frontend können und das fand ein selber und dann feststellte Wir können das einfach direkt staatlich mit einbinden. Wir nennen einfach einen Ordner Public und dann passiert alles automatisch.

Das war dann nochmal so ein Aha-Erlebnis.

Das ist diese Opinio Nahtod Konfiguration. Also bring but leg dir schon so die Fold Ordner an oder bzw. die kannst du anlegen, wo dann Settings drin liegen können für die Anwendung oder eben statische HTML Falz, wo man sich dann nicht weiter kümmern muss, wenn man sich an diese die Fold Konfiguration hält. Man kann auch alles konfigurieren, aber das Ziel von Spring Boot ist es zu sagen Hammer, wir geben dir einen vernünftigen Grundstock auf dem kannst du aufsetzen und du kannst alles konfigurieren.

Aber so wie wir es dir liefern, ist es erst einmal in Ordnung für die meisten Anwendungen. Also könnt ihr bestätigen Spring Boot hat euch fÃr eure Entwicklung doch ordentlich unter die Arme gegriffen. Ihr seid schnell zu Rande gekommen, habt wenig kämpfen müssen. Leute, die um die Millennium Wende Java entwickelt haben, die kennen noch, wie schwerfällig das alles war. Habt euch gut in der STANDARD Konfiguration zurecht gefunden und wenn ihr Zusatz Komponenten eingebaut habt. Ich weiß jetzt nicht ob ihr den Spring Logger benutzt habt oder wahrscheinlich die Spring Datenbank Anbindung und so, dann war das wahrscheinlich mit 20.

Mal googeln. Bildung ist natürlich hier die Website, die sofort auf ploppt, war das relativ schnell eingebunden. Ja, würde ich genau so unterschreiben. Es war zunächst mal intuitiv ziemlich viel verständlich, muss ich sagen. Nun muss ich dazu gestehen, dass ich zumindest Java schon mal vorher gemacht hatte und auch Maven vorher schon mal gesehen hatte. Das hat mir die Grundlage ein bisschen bereitet, aber nachdem ich dann in die einzelnen Sachen besser reingekommen war, lief das sehr schnell.

Die Lernkurve war sehr steil und auch einfachste Internet-Recherche. Meistens kann man eben bei Bildung raus, hat da schon geholfen, weils eben auch so viel genutzt wird und so viele Leute sich damit beschäftigen und damit arbeiten.

Für mich war da die Lernkurve noch ein bisschen Tayler, weil ich hatte tatsächlich vorher noch keine einzige Zeile Java Code geschrieben. Aber selbst damit war das ohne Probleme machen. Also mit den Web Ressourcen kann man dann schnell zu Rande Andreas. Gibt es denn in der Python Welt ein mit Spring Boot vergleichbares Framework? Also was ähnliche Features anbietet oder was die vielleicht immer wieder aufgefallen ist, dass du gedacht hast oh stimmt, das ist so wie bei Falcon oder so.. Also mir geht es ganz häufig so Wenn ich mich in einer Welt relativ gut auskenne und dann mich in neue Themen einarbeitet, dann stelle ich fest Ah, okay.

Die NPD ist eine neue Form von Maven oder Gretl oder dass man quasi diese queer Referenzen herstellen kann.

Ich würde sagen, es gibt nicht so ein monolithischer Ding, was es alles kann. Ein bisschen. Also es gibt gute Respawn Frameworks, dem Rass ähnlich komfortabel auch eine Rest API aufziehen kann. Aber dann muss man halt nochmal einen Webserver dazu machen, was man zwar auch leicht geht, aber es halt erst ein anderes Projekt. Dependency Injection ist nochmal komplett anders. Man braucht es einmal in Payton nicht ganz so viel, da man in der Laufzeit natürlich viel austauschen kann.

Dynamisch auch, aber wenn man es wirklich vollständig benutzen will, dann muss man zu anderen Paketen gehen. Also es gibt nichts, was das alles miteinander verbindet und einem von Anfang an was funktionierendes gibt. Man muss das ein bisschen zusammensuchen, mehr und auch Entscheidungen treffen, welches man dann von mehreren Möglichkeiten wählt. Swing gibt’s ja auch Alternativen.

Genau, aber Spring Boot muss man schon sagen. Ich will nicht vom de facto STANDARD sprechen, aber das ist für Berat, also Rapid Application Development in der Java Welt so über die letzten Jahre ist das ein sehr, sehr großer Player geworden und man startet meistens damit, dass ganz viele große Applikationen, die man kennt, bestehen ja heutzutage aus vielen, vielen kleinen Microservices. Und diese Microservices, die die Arbeit im Hintergrund verrichten, die sind sehr oft mit Springflut geschrieben.

Welche Features von Spring Boot habt ihr denn verwendet? Also wir haben eben schon über ETT Auto Wired gesprochen. Andreas hatte die Notationen erwähnt. Das ist natürlich das Ding, oder? Diese Inversion of Control ist das Konzept, mit dem Spring damals bekannt wurde, Anfang der 2000er Jahre, dass man eben nicht mehr New Klassisch schreibt und damit eine harte Kopplung hat, sondern man sich über ET Auto Wired z.B. einen Logger in Jack tat, eine Datenbank in Jack That oder ein Transaction Manager in Jack That und dieser Transaktion Manager ist quasi entkoppelt davon, solang der ein gewisses Interface implementiert.

Bleiben wir mal beim Logger ist es egal, ob das ein Festplatten Logger ist, ein Screen Logger, ein Netzwerk Logger oder ein Logger auf einem ganz anderen Medium. Ein na Logger, der einfach nur alle Log Zeilen wegschmeißt oder ein Rauchzeichen lagert. Zur Not. Das Konzept ist ja ganz zentral und ich denke, das hat euch auch relativ früh. Habt ihr das bemerkt?

Ja also die Cernko Komponente für uns war, würde ich jetzt für mich sagen das Auto, wir O-Ring, dass man eben nicht jedes mal neue Instanzen von Klassen erzeugen muss, sondern wirklich diese Benes hat. Und wir haben die auch meistens eben als Singleton benutzt. Das war wirklich etwas, wo wir uns dann auch sukzessive beim Design der Anwendungen Gedanken drum gemacht haben. Also wir haben dann wirklich versucht, wo wir eigentlich zuerst intuitiv gesagt hätten Okay, wir brauchen mehrere Instanzen davon von der gleichen Klasse, dann haben wir trotzdem versucht, unser Design Pattern so umzubauen, auch gedanklich, dass wir eben diese Singleton Auto Viri Funktionalität benutzen können.

Und es hat uns halt auch beim Testing dann begleitet. Entsprechend ja eben das Logging. Andreas Was kann ich mir, wie haben wir das gemacht? Haben wir das von Spring genutzt?

Das Logging ist es auch per Annotation. Das war der SL vor J. Logger lassen hab der Franz Spring Boot selber ist oder?

Meistens sind das externe Libraries, die du einfach in Jackets. Beim Logging kippt es mehrere Standards. Es gibt Lock vor J, dann in CV. JJ Logger. Da gibt’s noch zwei, drei andere. Ich benutze den, der in der Anwendung schon drin ist, weil ich da kaum Unterschiede feststelle oder zumindest mit allen leben kann.

Sagen wir so. Was mir noch einfällt, das ist relativ gegen Ende gekommen, als es darum ging, die Anwendung beim Kunden in den Container Cluster. Zwar Masons zu Diplomen ging es darum, wie wir Health Checks unserer Anwendung im Betrieb machen können. Und weil das vom Dev OPs Team des Kunden angefragt wurde, wie man sicherstellen kann, dass die Anwendung auch vernünftig läuft und ich meine, da hättest bring uns die Funktionalität intrinsisch zur Verfügung gestellt. No Matrix Ja, genau, dass wir da nicht noch selber Health Brookes verschreiben mussten mit dedizierten Endpunkten in der API.

Genau. Wenn ihr das Micro Service Profil benutzt habt, haben wir glaube ich Letz endlich nämlich nicht.

Aber wir haben dann letztendlich die eigenen Endpunkte geschrieben gehabt und dann festgestellt, dass es bringt uns eigentlich frei Haus geliefert hätte. Aber da war es in dem Fall schon zu spät. Das lag dann eher daran, dass wir uns nicht genug damit auskannten. Okay, gut.

Aber das heißt im Grunde jetzt wisst ihr, dass es das gibt. Beim nächsten Service könnte man sich diese STANDARD Matrix also hier RAM verbraucht CPU Jukic, Disk Space könnte man sich auch sparen, sondern einfach die vordefinierten nutzen und die dann eben entsprechend erweitern. Wenn man das braucht.

Ja, was Oleh mir auch gesagt hat. Wir hatten dann ganz viele Klassen mit Autoritären, was am Ende darauf hinausgelaufen, dass wir ganz viele einzelne Klassen hatten, die quasi ein Objekt aus der einen Umgebung der neuen Umgebung übersetzen konnte. Und all diese Übersetzer waren dann letztendlich Singleton Wins, die dann an einer entsprechenden Stelle, wo sie benötigt wurden, einfach nur initiiert worden.

Genauso macht man es auch auch. Ich nehme an, als sie dann die einzelnen Komponenten getestet habt, dann injektor dir dann einfach Mock Objekte statt der realen Instanzen um dann die Kernfunktion einer Klasse zu testen. Richtig, genau so haben wir es dann gemacht.

Genau das war immer der Punkt. Wir haben versucht, das, was wir als Bian eben dann Jack Thot haben, vorher getestet zu haben, um es dann eben an einer anderen Stelle als fertigen Mock benutzen zu können.

Habt ihr bei Projektstart ich glaube es gab schon im Template Oleh Wanne. Ihr habt nicht den Spring Finisher Leisure, also auf Startpunkt Spring dort AIO gibt es den, den habt ihr nicht benutzen müssen, oder?

Nee, tatsächlich nicht. Da hatte ein Kollege schon was vorbereitet, um so eine grobe Projekt Struktur auch mal in Form von Place holder Klassen angelegt und eine grobe Funktionalität war auch schon gegeben. Also ich glaube man hat die Möglichkeit eine Liste zu migrieren oder Objekte einzulesen aus einem Testfall. Und es gab schon eine Anbindung an eine Postkarte oder Mail SQL Datenbank. Genau das war so unser Startpunkt zu dem Zeitpunkt und entsprechend gab es dann eben auch schon ein POM Fall mit dem ganzen Maven Setup A okay war.

Es gibt auch Startpunkt Spring Punkt Видео gibt es diesen Spring in leiser und da kann man dann sagen ich möchte eine Springflut Anwendung schreiben mit Datenbank Zugriff mit Maven oder Greendale Build System und man klickt so ein paar Sachen zusammen und am Ende fällt ein Zipfel raus, was quasi so die Basis Anwendung mit den getroffenen Einstellungen schon enthält. Quasi dieses schlachte schnell und kümmert sich um die Anwendungs Logik auf die Spitze getrieben. Jetzt habt ihr beide ja intelligent Diaa benutzt. Für das Projekt hat euch die Idee gut unterstützt.

Bei Spring Boot Anwendungen ist der Support dafür reif.

Der Support der war super. Tatsächlich. So war von den Socken. Wie einfach es doch ist, damit all die Sachen, die man sonst sehr manuell nachschauen muss in Variablennamen merken und dann ins Java natürlicher nach ner typisierte Sprache, d. h. das kommt noch dazu. All das. Da nimmt es einem ziemlich viel Arbeit ab.

Und auch die Kenntnis der Fidi über die Projekt Struktur. Also was kann ich überhaupt per Auto via O-Ring einbinden? Also was hab ich zur Verfügung? Oder wenn ich jetzt gerade nochmal an das Pom fail zurückdenke. Wenn ich da versuche in Versions takk von etwas einzubinden, was in der Form so nicht existiert, werde ich darauf hingewiesen oder dass ich das dann erst runterladen muss, damit es zur Verfügung steht. Für mich jetzt lokal all solche Sachen, um die man sich ansonsten zu einem späteren Zeitpunkt Gedanken machen müsste, um dann wieder zurückzugehen, um es zu fixen.

Das war schon klasse und natürlich die Möglichkeit, selbst in Module reinspringen zu können, die man nicht selber geschrieben hat, sondern die aus externen Libraries stammen und im Zweifelsfall dann eben de kompilierte Code vor sich zu haben. Was aber immer noch besser ist, als nicht zu wissen, was passiert.

Ja, das stimmt. Du hast Andreas hat eben auch gesagt die Gather und Zeta. Das stimmt, dass man die schreiben muss, das ist schon. Da entsteht diese riesen Text Tapete. Ich mache mal mit ALD einfügen generiere ich die einfach und habt ihr dann für alle Properties. Deshalb stört mich das gar nicht so sehr. Obwohl das eigentlich natürlich schöner geht, hat Andreas vollkommen recht. Was ich bei der Springflut Unterstützung ganz klasse finde ist Du kriegst ja dieses Blättchen, dieses Ahornblatt oder so wird dann angezeigt und dann siehst du die einzelnen Pins, dann kannst du bei den Autor via Pins kannst du so dadurch springen oder er schlägt dir dann schon die Methoden der Pins vor, wenn du da unten arbeitest.

Meistens läuft es da so hinaus. Du was hat deine Klasse, die die Anwendungs Logik enthält und du? Historiker Klassen, die dir halt zuarbeiten, also z.B. Du hast deine Anwendungs Logik und hast ein Database Worker, der Objekte aus der Datenbank holt, Objekte in die Datenbank speichert usw.. Kannst du die dann sehr einfach in deine aktuelle Klasse rein? Metten?

Ja, die Funktionalität hab ich zumindest auch hin und wieder mal benutzt. Was mir noch als Randnotiz positiv im Gedächtnis geblieben ist, ist die Tatsache, dass sehr intuitive Nomenklatur vorgeschlagen wird von der Idee. Also wenn ich das schreibe oder was haben möchte an möglicherweise vordefinierten Strukturen innerhalb meiner Klasse, dann ist die Nomenklatur entsprechend schon an das angepasst, was die tun soll. In dem Zusammenhang wies für mich jetzt gerade notwendig ist, auch wenn dann das schon mal sehr lange Methoden Namen bei rauskommen.

Aber es ist sehr gut. Human Redtube möchte ich mal sagen, was die Idee da einem vorschlägt. Also sie unterstützt da auch schon den menschlich intuitiven Zugang sehr.

Habt ihr eigentlich? Fällt mir gerade ein, bei Convention over Configuration habt ihr auch ein eigenes Banner erzeugt vor einer Anwendung.

Ja, ich hab das sogar in zwei erzeigt.

Wäre ja, ich hab zwischendurch mal gewechselt. Das ist richtig. Am Anfang habe ich ein Corporate Identity ähnliches Banner aus Asti Artzt da hinzugefügt. Genau Asgard Generatoren gibt’s ja genug online frei verfügbar und danach hab ich mir ein Zitat aus einem Musikstück, was ich sehr schätze da eingebaut, was in den Zusammenhang von dieser ganzen Worker Struktur ganz gut reinpasst. Richtig, das war so ein bisschen Selbstverwirklichung, muss ich zugeben. Aber ja. Haben wir gemacht.

Vielleicht für unsere Zuhörer. Kurz. Es gibt eine Band TX t, die kann man auch auf einem standardisierten Pfad ablegen. Und wenn die Anwendung gestartet wird, wird automatisch diese Textdatei quasi ins Lock Fail übertragen. Also normalerweise steht an Spring Boot Version 5.1 Delete, aber man kann das halt mit seiner eigenen SII Banner Punkt txt überschreiben. Was immer ganz interessant ist, was die Leute sich da ausdenken, weil das so ein Freitagnachmittag Task ist. Habt ihr denn auch die einzelnen Methoden dokumentieren müssen oder viel Dokumentation schreiben müssen?

Hat euch das bringt Boot irgendwie unterstützt?

Also da gibt es ja Bild Targets Chewie Java Doc die Dokumentation extrahieren. Da gibt es auch so Spring Boot Plug-Ins das ist alles ein bisschen schöner aussieht. Da purzelt dann diese Java STANDARD Dokumentation raus. Ich weiß nicht, ob das in dem Projekt gefordert war.

Das war nicht in Förderturm manuell dokumentiert, was zu dokumentieren war. Aber zwischendurch hatte ich mir tatsächlich auch diese automatischen Tools angeschaut. Die sind teils sehr umfangreich im Sinne von, dass sie natürlich automatisch alles dokumentieren, was in dem Fall einfach mehr war, als wir brauchten. Dann hätte man sich da dann nur die Teile rausziehen müssen, die man braucht. Von daher war es quasi. Es hat einem zu viel schon gegeben, mehr als von den Verbrauchter.

Zumindest war das mein Eindruck, was aber definitiv am Projekt Scope lag. Das war einfach nicht immer Anforderungsprofil der Aufgabe enthalten. Da ging es mehr um eine Übersicht Dokumentation und weniger in die Tiefe einzelner Methoden rein Dokumentation zu schreiben nach dem Festlegen vorgelegten Schema, sodass wir dann da eher eine Markdown Read Me geschrieben haben, die auch eher kurz ausgefallen ist und auf die Punkte eingegangen ist, die wirklich nötig waren. Deswegen konnten wir das Feature nicht nutzen. Sinnvoll.

Gab es denn bei dem Projekt irgendwie Fallstricke, die mit Spring Boot zusammenhängen, wo ihr sagen würdet Oh, wenn ich das nochmal machen würde, da hab ich viel Zeit gelassen, das würde ich anders machen. Also so Tipps, die im Grunde euch selber geben würdet, wenn ihr das Projekt nochmal durchführen würdet.

Ich weiß nicht, ob ich sie anders machen würde, aber auf jeden Fall Fallstricke, über die man wegkommen muss. Schon an seinem bisschen. Vor allem wann etwas ein Singleton Objekt ist und wann es kein Singleton Objekt mehr ist bzw. wenn du mal kein Singleton Objekt haben willst, musst du einfach ein bisschen mehr Arbeit machen oder muss überlegen ob du es wirklich nicht Singleton brauchst oder haben Singleton nicht auch ausreicht, weil einige Teile der Anwendung Wandern nachher ermutigt werdet. Da musste man dann ganz genau nachdenken, dass man da jetzt nicht dem Singleton irgendwie einen State verleiht, der dann von zwei setzt, sich gegenseitig überschreibt oder solche Dinge.

Da kann man perfekt wie Pattern einzelne Instanzen pro Thread Instance Ihren oder eben das ist ja fast schon dein generische Inversion of Control Anwendungs Design. Was du beschreibst.

Genau. Aber da fehlt ein bisschen die Zeit, dann auch für irgendwann. Aber ich würde sagen, dass das der wichtigste Punkt war, weil das einfach ein Konzept ist, was keiner von uns beiden zu dem Zeitpunkt wirklich angewandt hatte. Mal im Alltag, in der Programmierung und wenn man sich damit mal ein bisschen intensiver auseinandergesetzt hat, vielleicht auch auf einer theoretischen Ebene und an einfachen Beispielen angefangen, dann erleichtert das den Einstieg vor allem ins Design von so einer Anwendung, weil wenn man ständig wieder drei Schritte zurückgehen muss, um dann den Ansatz für eine Problemlösung doch nochmal komplett auf links zu drehen, weil man eben genau bei dieser Inversion of Control irgendwie das konzeptionell dann doch nicht richtig gemacht hat für den eigenen Anwendungsfall Gespartes schon.

Zeit, wenn man da einfach von vornherein das bei seinem Design Pattern berücksichtigt, als sie die Anwendung designt habt. Ich meine, wir haben eben schon kurz drüber gesprochen, habt ihr genug Beispiele für Spring gut Problem im Internet gefunden, also Bildung. Die Seite haben wir erwähnt und auch sonst bei Stack Overflow hattet ihr Immi Probleme für euern Fall was zu finden oder war das eigentlich immer gut? Wie würdet ihr die Dokumentation Situation einschätzen?

Ich würde sagen, Bildung war da sehr umfangreich. Es kam ein paar Mal vor, dass ich nach dem hin. Das reicht mir jetzt nicht nochmal einen halben Tag auf die Suche im Internet gegangen, nur um dann am Ende beim gleichen Bildung Artikel wieder zu landen und zu sehen. Okay, eigentlich stimmt es ja doch, was hier steht. Und wenn man es richtig liest und einen mit ein bisschen Abstand nochmal liest, dann steht da eigentlich alles drin.

Ich glaube, bei sehr spezifischen Problemen kommt es dann wie eigentlich immer ein bisschen aufwändiger werden zu recherchieren. So grundsätzlich war das Vorhandensein von Documentation ja schon gut ausgeprägt, aber ich erinnere mich, dass wir bei dem Thema Parallelisierung und dann eben Multi Reading unserer Anwendung doch die eine oder andere technische Hürde hatten, die ein bisschen schwieriger zu überwinden war, sowohl vom Design als auch von der technischen Umsetzung nachher, was dann auch ein bisschen mehr Recherche und Refactoring bei uns dann eben auch nötig gemacht hat.

Aber das sind dann schon sehr spezifisch die Themen der parallele Entwicklung oder?

Neben läufige Entwicklung ist natürlich immer noch ein Komplexität Stufe höher, einfach weil man eine ganze Menge bedenken muss, damit das auch funktioniert.

Ich hatte noch einen zweiten Fallstrick. Vielleicht hat mir eben am Anfang schon über das dpa gesprochen und wie Einfaches zu sagen gemacht hat, die Datenbank aufzubauen. Man hat dann aber am Ende schon gemerkt, wenn man relativ komplexe Abhängigkeiten mit mehreren von Civey, Strands und auch Manitoba Bennie Relationships. Irgendwann kommt man dann halt auch da ans Ende dieses Modells und kommt dann halt an Stellen, wo es dann noch mal her sich herausstellt. Okay, wenn ich das jetzt aber von der Seite aufziehe, funktioniert es perfekt und von der anderen Seite generiert es mir dann halt ganz ineffizienten ASCII Code.

Da muss man dann halt ein bisschen aufpassen, wenn man da angelangt ist.

Also einfach ein bisschen Augen offenhalten und vielleicht nicht nur eine Doku Stelle im Internet aufsuchen, sondern 2 3, um dann eben das für sich passende da rauszusuchen.

Genau da braucht ein bisschen mehr Recherche und muss sagen ein bisschen auch selber mehr ausprobieren, was dann da der beste Ansatzes würde.

Dir den Spring Boot als Plattform weiter empfehlen oder nochmal verwenden, wenn ihr eine weitere Java Anwendung in sagen wir mal im Kybernetisch Cluster betreiben wollen würdet oder auch einfach so auf dem Server betreiben wollen würdet.

Auf jeden Fall. Also ich würd mit nichts anderem anfangen wollen in Java.

Ich denke auch, dass sich das als Blaupause und Grundlage für, ja als die Fall regelrecht für Java Anwendungsentwicklung nehmen würde, weil die meisten Anforderungen aus Umgebungen kommen, wo man das eben gut umsetzen kann. Ich meine missis in den letzten Jahren nichts untergekommen, wo man jetzt auf einen klassischen ein Maschienen Server oder einen großen Mainframe irgendwas hätte entwickeln müssen, sondern man kommt eben immer eigentlich gerade wenn es Java sein soll in diese Microservices Richtung bzw. kann seine Anwendung zum Lösen eines Problems so Design, dass sie auch sinnvoll so umzusetzen ist.

Und dann ist Spring Boot wirklich ein Top Tool würde ich jetzt sagen. Und das ist doch glaube ich für den Einstieg gut. Also wenn man sagt, man kann bisschen programmieren, man kann objektorientierte programmieren, dann steigt man in Java ein, dann kann man mit Spring Boot auch sehr zufriedenstellend schnell ein Ergebnis erzielen, was wirklich Produktions reif. Innerhalb kurzer Zeit ist das eine tolle Sache.

Da kommt glaube ich dieses Opinio Native was du meintest Magix gut durch es. Es hat halt an vielen Stellen einfach sinnvoller die Falz und außer wenn du weißt, dass das unbedingt anders haben willst, ist halt anders. Aber der Default ist erstmal sinnvoll.

Ja genau. Also diese Opinio native Settings spielen eine Rolle. Deshalb läuft die Anwendung sofort, weil man im Grunde alles hat, was eine Anwendung benötigt. Der Webserver oder der Tomcat in dem Fall ist eingebaut, Matrix sind eingebaut, Health Checks sind eingebaut. Externe Konfiguration, also das Laden von Settings aus Properties. Falls wenn man zum Beispiel einen Dart Mac anbinden möchte und da ein Username Passwort und Connection String hinterlegen muss, ist dabei. Also ja, es funktioniert direkt und man kann dann anpassen, was man braucht.

Ich fand euer Beispiel sehr schön, weil ihr eigentlich ein Micros Service der Daten Transformationen hauptsächlich Macht implementiert habe, dann aber gesehen hat. Oh wir müssen noch irgendwie eine Web Komponente nachrüsten, weil wir statische Dateien aus liefern möchten oder Web Dateien ausliefern möchten. Ist das wirklich für eine Web Oberfläche gedacht gewesen, als wo jemand auf diesen Service springt und im Browser etwas machen kann? Oder war das einfach nur um Dateien auszulagern, die für diese Transformation notwendig sind?

Das war tatsächlich dann eine Oberfläche. Einfach weil sonst der Zustand der App ein bisschen schwierig zu monitoren waren. Brauchten wir da etwas, um den Überblick der dem Garzón in dem Fall zu behalten? Einfach weil ja da mehrere Zehntausend. Datenpunkte migriert werden mussten und das durch verschiedene Snakes durch. Erstmal exportiert werden musste, im neuen System importiert. Nebenbei noch Sachen hochgeladen werden mussten und da den Überblick zu behalten. Damals hat man ja im Frontend für gebastelt. Okay.

Und das Frontend ist nur für euch gewesen. Oder guckt der Kunde das auch an, wenn er diese Software einsetzt?

Das war jetzt in dem Fall für uns mehr als die Person, die dann die eigentliche Migration macht. Was in dem Fall ein Kollege von uns ist. Also nicht ganz für uns selber, aber der Kunde benutzt es in dem Fall nicht.

Er könnte es aber benutzen, wenn er wollte. Wenn die Anwendung in unserem Fall, auf dem wir entwickelt haben und er unser Benchmark Punkt war Björn ist gerade gesagt, ein paar 10 000 Datenpunkte, um die es ging, da war die Laufzeit für den kompletten Migrations Prozess im Bereich von Stunden. Das ist was, was man theoretisch morgens starten. Und wenn man es Büro verlässt, ist die Anwendung fertig betreiben kann.

Nicht nur theoretisch, sondern praktisch, ja sogar richtig.

Das wird sich dann hoffentlich bald zeigen. Aber es gab auch den Use Case. Ein bisschen mehr in der Zukunft, dass wir über mehrere 100 000 Datenpunkte vergleichbare Einzel Größe reden. Und dann würde die Anwendung halt schon deutlich länger laufen und man möchte vielleicht aktives Monitoring davon haben. Und das wäre eben darüber möglich gewesen, dass man dann eben mal reinschaut, wie es gerade der Stand der Dinge.

Und insbesondere hat dieses Webforen dann letztendlich nichts anderes getan, als gewisse Endpunkte unserer App anzusprechen. Und mit diesen Endpunkten hätte man dann auch ein beliebiges anderes Monitoring aufziehen können.

Na okay, ater sind die nachgerüstet von Matrix, die ihr eingebaut hat.

Unter anderem genau Azawad. Einige Standards, Sachen wie ihr Herzschlag und Memory Konsumption. Aber dann halt auch einfach wie viele sind schon prozessiert?

Wie viele sind in den unterschiedlichen Stages der Migration solche Sachen? Den letzten Fallstrick hatte ich noch als beiten Entwickler. Man muss sich an die Annotationen gewöhnen, dass sie einfach was ganz anderes sind als Payton Annotationen. Wenn man damit dem momentanen Modell sich einmal umgedacht hat, dann funktioniert es. Also das ist halt wirklich nur Annotation. Sind also zusätzliche Informationen, die dann irgendwie interpretiert wird, nicht Code, der ausgeführt wird.

Die Annotationen gibt es auch in neueren Pfeifen Versionen, zum Beispiel bei den Data Classes und ich hatte das so verstanden, dass die was ähnliches machen wie auch in der Java Welt oder ich hab sie so benutzt.

Sie sehen ähnlich aus, aber letztendlich sind sie nichts anderes als Haja oder Functions. Also die Funktionen als Argumente nehmen und dir deine modifizierte Funktion zurückgeben. Während Java Annotationen ja eigentlich nur ein Hinweis an ein Paket sind, jetzt irgend eine Magie zu verführen, aber nicht an den Annotation selber gekoppelt ist. Klar, man kann Annotation auch selber schreiben, aber es ist schon so, dass die Annotation so eine Art Auszeichnung sind, um die nachfolgende Funktion oder so eben zu Parameter visieren oder das nachfolgende Objekt genau innehabe.

Das eigentlich paar Interesieren passiert in Java soweit ich es verstanden hab, ja nochmal einfach anders. Also irgendetwas anderes nimmt dir Annotation und macht dann etwas damit Sphären in Python. Es ist die Annotation selber, die etwas macht.

Genau das Spring Framework werte die Annotationen aus und sagt Ach guck mal, hier ist ein Auto Wired, da muss ich ja diese Biene reinstecken, die ich hier initialisiert hab. Also das kann man vielleicht noch sagen, das Spring Framework geht hin, wenn die Anwendung gestartet wird, guckt das alle Bins also also eine Java Klassen hier als Service definiert habt oder als Controller definiert habt, guckt es an, instanziiert diese Klassen und dann erst guckt es in die einzelnen Klassen rein.

Wo steht dein Auto Wired und stöpseln jetzt diese initialisiert Klassen eben zusammen, damit die Anwendung loslaufen kann? Das passiert sozusagen alles im Vorfeld von dem Framework selber. Wenn ihr Fragen habt oder Feedback, sendet uns gerne eine E-Mail an Podcast Skill bei Tee. Wir freuen uns immer über Bewertungen und wenn ihr den Podcast an Freunde und Kollegen weiterempfehlen, die sich für ähnliche Themen interessieren. Wenn ihr aktuell im IT-Bereich auf Jobsuche seid, schaut gerne auf das G.H. Die Slash Job Seite vorbei.

Weitere spannende Technologien Themen findet ihr auch im Skill Bait Blog. Oli Andreas, ich danke euch ganz herzlich, dass ihr heute Abend meine Gäste wart.

Danke Maurice. Es war mir eine Freude. Ich wünsche euch beiden noch einen schönen Abend. Danke dir auch.

Maurice KnoppSkillbyte Podcast #45: Das Spring Boot Framework
Mehr

Skillbyte Podcast #43: Helm – Der Kubernetes Paketmanager

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

In diesem Podcast geht es um das Thema: Helm – Der Kubernetes Paketmanager

// Inhalt //
01:23 – Definition: Was ist Helm und wie wird es eingesetzt?
04:14 – Einsatzszenarien für Helm Charts
08:03 – Warum benötigt man Helm Charts ?
09:13 – Vorteile von Helm Charts und deren Einsatz
14:32 – Zusammenfassung Vorteile Helm Charts
16:12 – Von Terraform über Kubernetes zu Helm
22:18 – Beispiele: Betrieb hoch-skalierbarer Anwendungen
26:09 – Neue Anwendungen werden Cloud-native entwickelt; selten Migrationen von Bestandssystemen
29:18 – Bestandteile und Funktionen eines Helm Charts
34:25 – Handhabung von Helm auf der Kommandozeile
36:23 – Helm 2 vs Helm 3
37:35 – Flux – CI/CD in Perfektion
41:53 – Fortgeschrittene Deployments: Canary und Blue Green Deployments; Istio

Show notes:

Podcast #25: Kubernetes: Flexibles und leistungsfähiges Rechenzentrum für Unternehmen
https://soundcloud.com/skillbyte/podcast-25-kubernetes-flexibles-und-leistungsfahiges-rechenzentrum-fur-unternehmen

Podcast #36: Terraform – Virtuelles Rechenzentrum mit dem Infrastructure as a Service Werkzeug
https://soundcloud.com/skillbyte/podcast-36-terraform-virtuelles-rechenzentrum-mit-dem-infrastructure-as-a-service-werkzeug

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

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Das Wichtigste zu verstehen ist, dass man mit Helm eigentlich nur kybernetisch Ressourcen verwaltet. D.h. Anstatt dass ich jetzt mit meiner Cubes Btl hingehe und sage create deployment create secret create config map, sag ich einfach nur Haman Stall und im Hintergrund läuft halt genau das. Aber das Schöne an der ganzen Sache ist, dass das alles kybernetisch Native ist. Also im Prinzip kann ich es nicht best practice, aber im Nachhinein kann ich beliebig auch die Ressourcen per Hand wieder editieren.

Ist natürlich nicht empfohlen, weil dazu gibt’s ja Helm. Herzlich Willkommen zum Skill bald Podcast Nr. dreiundvierzig Helm Der Kybernetisch Paket Manager abonniert unseren Podcast für mehr spannende Technologien aus dem Technologie Umfeld, wenn er IT Entscheider oder ity Fachkraft seid. Wenn ihr eine Frage habt im Verlauf der Episode sendet uns gerne eine E-Mail an Podcasts Skill BYD Punkt D Wir freuen uns auch immer über Bewertungen und ganz besonders wichtig für uns sind Weiterempfehlung an eure Freunde und Kollegen, die sich auch für Technologie Themen interessieren.

Wenn ihr aktuell ity Jobs sucht, schaut gerne auch auf das Gebiet Jopp Seite vorbei. Ich bin heute hier mit Julius, einem DevOps Ingenieur von Skill bald und ich freue mich super auf dich. Hallo Julius, hi Maurice. Ja und heute sprechen wir über Helm und das Thema kybernetisch bzw. was Helm genau ist. Und Helm ist eine Technologie. A kann man sagen, die in den letzten 2 3 Jahren doch deutlich an Verbreitung zugenommen hat und ja auch so ein bisschen gehypt es, oder?

Ja, auf jeden Fall. Also das Tool ist ja schon ein bisschen älter. Aber wie du gesagt hast, es ist jetzt in den letzten Jahren hat das enorm zugenommen. Auch. Vor allem wird das viel verwendet. Also eingebettet in andere Systeme, wie z.B. Rangiere oder so. Also das ist auf jeden Fall sehr populär zurzeit genauso.

Entwicklungsgeschichtlich kann man ja sagen, diese Kuba Metis Infrastruktur ist entstanden und die Leute haben begonnen eben ihre Anwendungen in kombiniertes Cluster zu Diplomen, die zu managen und haben dann aber festgestellt okay, so eine Anwendung aus mehreren Microservices im Kybernetisch Cluster, das ist relativ viel Handarbeit, diese zu warten und die einzelnen Komponenten zu aktualisieren. Es wäre doch schön, wenn man so eine Art Paket Manager hätte, wie man das aus z.B. Linux-Distributionen kennt wie APT, get oder Pacman und dieses Konzept auch für kybernetisch Anwendungen, die wie gesagt aus mehreren Microservices bestehen können, verwenden kann.

Das Ziel ist es eben kybernetisch Anwendungen möglichst einfach zu managen, also wie man bei abgeht install Paket Name sagt und Linux Pakete installieren kann. Genauso möchte man das auch in der Kybernetisch Welt haben und natürlich auch genau so einfach mit einem an install. Wofür hast du denn Helm bisher benutzt?

Ja, im Prinzip genau wie du jetzt gerade erwähnt hast. Also der Zustand, dass man eben irgendein fertiges Tool schnell installieren will, gerade auch zu Demo Zwecken oder um mal so ein kleines Proof of Concept zu machen. Wenn man zu einem Kunden fährt, den einfach zeigen will, was möglich ist und wie schnell das alles geht. Da benutzt man gern Helme, weil wie du schon gesagt hast im Linux Umfeld ist das ja auch sehr gängig, dass man da einfach schnell was installiert um es auszuprobieren, weil man sich eben nicht durch irgendeinen Install Wizard durchklicken muss und auch eben nicht viel konfigurieren muss, sondern das eigentlich out of the Box funktioniert.

Also Helm ist wie kybernetisch selbst auch OpenSource richtig. Genau. Ja, das ist ein Open-Source-Projekt, was von der Cloud Native Computing Foundation betreut wird. Und so kann auch jeder im Prinzip da dran mit basteln.

Contribution Ja, das machen ja die großen Cloud Provider. Alle oder die großen alten Namen bringen sich dann natürlich ein, weil sie auch gesehen haben der Trend geht ganz klar eben zum Paket Manager auf Kuba net des Container Anwendungen. Wenn unsere Zuhörer noch mehr zu kybernetisch wissen möchten, empfehlen wir auch gerne unsere Folge Nr. 25 Da geht es intensiv um das Thema Kybernetisch, um komplexe kombiniertes Anwendungen eben betreiben zu können oder installieren, deinstallieren, abzugrasen zu können. Wie genau macht man das denn mit Helm?

Stell dir einfach mal vor, wir haben entweder Ein und Promos Rechenzentrum oder ein Cloud kybernetisch Cluster hochgefahren. Ist ja egal, ob der jetzt bei einem der großen Cloud Provider läuft oder im eigenen Rechenzentrum. Und ich möchte die Helm Technologie einsetzen. Wie würde ich da denn jetzt dran gehen?

Ja. Also grundsätzlich gibt’s ja dann erstmal die Frage Möchte ich das jetzt für meine spezielle Anwendung, die ich zum vielleicht auch selbst entwickel machen oder für eine Anwendung, die eben noch nicht im Heim Repository mit drin ist? Oder eben so eine typische STANDARD Anwendung? Das weiß ich an Engine X Server oder typisch sind auch ein Monitoring primitives oder sonst was mit allen möglichen Abhängigkeiten. Im letzteren Fall würde man dann halt wirklich gucken, in welchem Repository das drin ist. Meistens sind die auch in den STANDARD Repositories drinnen.

Da gab’s jetzt plötzlich viel Umstrukturierung. Aber die großen Sachen, die sind eigentlich immer zu finden. Und dann würde man ähnlich wie beim Paket Manager tatsächlich einfach sagen Heim ins Daul den Release Namen. Also da kann ich selbst an einen Namen vergeben, der dann unique in meinem Cluster halt erscheint und dann eben der Name des Pakets. Im Prinzip also im Heim Umfeld nennt man das Helmut Shard. Und ja, man kann da beliebig dann auch Variablen in dem Shard verändern und anpassen.

Aber im. SIB reicht ein einfaches Heim in Stall, den Release Namen und das Shard, was ich installieren will und dann läuft das eigentlich schon von selbst alles an, mit allen Abhängigkeiten und einem möglichen.

Das heißt, ich konfigurierte Helm benutze ich von der Kommandozeile Karl gegen den kubanisches Cluster, gegen den ich es benutzen möchte. Ob on primus oder in der Cloud.

Richtig, genau genauso siehts aus. Und es gibt schon Repositories an die Helm Charts enthalten für STANDARD Komponenten wie z.B. Webserver, Engine X oder Datenbanken. Wobei Datenbanken in kubanisches Clustern ist immer so eine Sache, aber für fertige Komponenten und da kann ich meine eigene Software, die vielleicht ein Webserver braucht ne, wenn es Microservices ist, kann ich sozusagen darauf basieren lassen, oder?

Ja, das ist eben der Vorteil. Ähnlich wie beim Paket Manager wieder, dass sich eben Abhängigkeiten auch in meiner eigenen Anwendung einfach reinziehen kann. Und wie du schon gesagt hast, das ganze Management von Abhängigkeiten. Das passiert alles klein seitig und im Prinzip werden dann einfach ganz normal die Sachen nach und nach in kybernetisch Cluster installiert von Hän und ich muss mir da gar nicht viel Gedanken machen.

Also Helm geht dann hin, lädt die einzelnen @Helmut Charts die ich als Abhängigkeiten markierter. Bleiben wir mal beim Webserver runter, lädt die Docker Images runter Diplome die dem kybernetisch Cluster und sieh zu, dass alle Komponenten ordentlich starten. Und ja, die beschriebenen Wolli ums gemault teeth werden die Ports die angegeben werden freigeschaltet sind verschiedene krit. Dunkels gesetzt werden. Also als variablen Beispiel, sodass nach und nach die Anwendungen wirklich wie ausgepackt aus einem Paket in dem kybernetisch Cluster lauffähig gemacht wird.

Genau ungefähr so ist es natürlich schon noch so, dass Kuba Annettes sich um Sachen kümmert, wie jetzt die Container runterzuladen und so weiter. Das wichtigste zu verstehen ist, dass man mit Helm eigentlich nur kybernetisch Ressourcen verwaltet. D.h. Anstatt dass ich jetzt mit meiner Cubes Ctrl hingehe und sage create deployment create secret create config map, sag ich einfach nur ha’m. Im Stall und im Hintergrund läuft halt genau das. Aber das Schöne an der ganzen Sache ist, dass das alles kybernetisch Native ist.

Also im Prinzip kann ich es nicht best practice. Aber im Nachhinein kann ich beliebig auch die Ressourcen per Hand wieder editieren. Ist natürlich nicht empfohlen, weil dazu gibt’s ja Helm.

Das ist ja genau der Punkt, dass man eben nicht Anwendungen händisch installieren möchte. Das würde ja auch funktionieren. Und dass man dann hinterher sagt Okay, die Anwendung läuft. Ich habe drei Tage dafür gebraucht. Welche Befehle hab ich denn sozusagen abgesetzt, um die Anwendung zu installieren und daraus mir ein Script mache, sondern das genau soll ja Helm machen. Man beschreibt in diesem Helm schade, dass es eine Jamel Datei beschreibt man quasi die Abhängigkeiten und den Zustand der App und Helm sieht einfach zu, dass dieser Zustand hergestellt wird und führt die dazu notwendigen Kommandos aus.

Genau, ja.

Also das ist wie du schon gesagt hast, in DE klarer, tiefer Ansatz, typischer Orchestrierung. Use case also ich sag halt was ich haben will und Heyl guckt was hab ich und was muss ich tun, damit ich den Zustand erreiche? Also da haben wir noch gar nicht drüber gesprochen. Auch Sachen wie Updates und so weiter können von Heyme auch direkt behandelt werden. Und PAME vergleicht halt einfach nur Ist und soll und guckt dann, dass die Aktion ausgeführt werden, die nötig sind.

Ja, das ist ja auch wie bei einem Linux Paket Manager. Na da kann man ja auch die Updates direkt über dem Paket Manager machen und die werden dann eben eingespielt entsprechend.

Genau, ja. Also die Vorteile von HAMCHA sind ganz klar. Wir haben schon von der Jamel Datei gesprochen, dass man diesen Infrastructure Ascot Ansatz noch weiter treibt. Die Jamel Datei ist natürlich einfach eine flache Datei, die man in git Versionierung kann. Man sieht wer welche Änderungen gemacht hat, man hat reproduzierbare Installationen. Ich könnte ja jetzt auch sagen wir ich habe drei kybernetisch cluster test Akzeptanz Umgebung und Produktions Umgebung und könnte dann in schneller Folge ein komplexes Helmi Chat mit vielen Komponenten in allen drei Umgebungen installieren.

Das wäre überhaupt kein Problem. Richtig.

Genau das ist eben auch der Vorteil. Ich hab’s eben schon ein bisschen angerissen. Man kann diese Hemme Charts, die bestehen auch aus Templates. Also diese ganzen kubanisches Ressourcen werden getrampt rated und dazu wird go template im Englischen benutzt. Das heißt, dass ich dann auch abhängig von dem Environment, wo ich mein Deployment mache, auch Variablen setzen kann. Das heißt in Produktion kann ich z.B. sagen, die Praktikas von dem Container, also wie viele Container gleichzeitig für meine Anwendung laufen, ist höher als jetzt in einem Test in Valmont, wo ich halt eben nur kurz Funktionalität durch testen will.

Okay. Das heißt, die Ausfallsicherheit ist dann quasi noch die Umgebung anpassbar, sodass ich pro Umgebung das festlegen kann. Genau.

Also es kommt natürlich aufs hammerhart an. Wenn ich jetzt was vorge Bauteils nehme. Irgendein offiziös. Dann muss ich halt gucken, was ist da g Templates. Also was kann ich durch Variablen ändern? Aber wenn ich jetzt ein eigenes Chart Bauer z.B. für meine Anwendung, die ich jetzt selber entwickelt hab mit allen Abhängigkeiten kann ich beliebig in diesen kybernetisch Ressourcen wie jetzt bei eben schon erwähnt mittels den go templates kann ich dann einfach jeden beliebigen Punkt also ob es jetzt in der Environment variabel ist, obs Memory Limits oder sonst was sind, kann ich alles beliebig als variabel definieren.

Im Template und dann eben in einem separaten Pfeil kann ich dann sagen okay, das sind meine Values, die eben für Produktion sind. Das sind meine Waldis, die für die Testumgebung sind. Und so lässt sich das dann beliebig anpassen auf die Infrastruktur im Beispiel jetzt auch wenn man ein fertiges Chart hat. Das macht das Ganze auch so mächtig. Nicht jeder will sein Monitoring gleich aufsetzen. Der eine hat eben andere Ansprüche, auch an Verfügbarkeit oder auch die viele Daten überhaupt gespeichert werden.

Wenn es jetzt Richtung Valium Claims und so geht und das lässt sich dann halt eben beliebig konfigurieren und das macht das Ganze auch so mächtig. Ja, verstehe.

z.B. in meinem Alltag ist es total sinnvoll, dass man sagt in der Produktions Umgebung hab ich z.B. 50 Ports um die ganze Last abzuwickeln. Also dieser Produktions Anwendungen. Aber in meiner Testumgebung, der teste ja nur ich. Da brauche ich viel weniger Disk Space, kann die kleinen Cloud Instanzen nehmen, das kostet dann weniger Geld wenn man will ja nicht. Vielleicht zum ganzen Cluster nur für die Entwicklung dann Überstunden betreiben und kann das dann eben so konfigurieren, dass das passt.

Und das ist auf der einen Seite viel Last bewältigen kann, im Produktionsbetrieb aber im Development Betrieb dann sehr kostengünstig ist, dass man theoretisch ein paar Dollar am Tag jeder Entwickler seine eigene Umgebung hoch und runterfahren kann mit nur wenigen Maschinen aus dem gleichen Hemsworth heraus.

Genau das kann man auf jeden Fall machen. Wie gesagt, es kommt da immer auf das Template an, was genau jetzt konfigurierbar ist und was nicht. Aber das ist auch das Schöne an diesem ha’m Ansatz, wenn ich jetzt selber einen Chart entwickel. Wir hatten ja schon angesprochen, die Struktur ist so, ich hab da mal einen Chart dort Jamel mein Haupt Jamel Fall, was halt so einen Namen vergibt Version Abhängigkeiten und dann kommt halt ein Template Ordner, indem eben diese ganzen Ressourcen liegen.

Und im Prinzip kann ich erstmal von alleine kybernetisch Ressource ausgehen. Also wenn ich jetzt mir einen Cube Citi alte Skripte mache auf eine Ressource im Jamil Format, dann kriege ich im Prinzip schon die Datei, die kann ich in dem Template Ordner ablegen und dann ist das Ding erstmal gelaufen. Ich kann dann eben im Nachhinein sagen okay, hier steht jetzt Reply CAS 3 drin. Ich möchte das jetzt konfigurierbar machen und dann kann ich eben da ganz einfach das mit dem GO Template in Format teilt.

Ja, Template draus machen und da gibt’s natürlich ganz viel Advanced darf das man halt auch anfangen kann Funktionen zu bauen, die dann von bestimmten Sachen wie jetzt welchen Get Lab Branch ich das jetzt baue und so weiter die Variablen anpassen. Aber das ist alles advanced. Das Schöne ist, dass man halt wirklich so step by step das Ganze aufbauen kann.

Das heißt, man kann sehr schnell starten, weil man es einfach verstehen kann. Aber die Erweiterungen Möglichkeiten sind mannigfaltig, sodass man auch komplexe Enterprise Anwendungen im @Helmut Charts verpacken kann.

Genau hier also für jeden der kybernetisch benutzt, ist das eigentlich überhaupt kein Problem Helmuts zu bauen, weil man eben immer bei den Intels Ressourcen anfängt und dann eben bestimmte Sachen konfigurierbar macht.

Das heißt mit Helm Charts sind im Grunde diese Dateien gemeint, die eben diese Orchestrierung beschreiben.

Ja, also das ist ein bisschen verwirrend, weil das Startort Jamel ist ein Fail, was zu einem Heyme Chart gehört. Aber genau wie du sagst das ganze Paket. Also die Templates, das Valerius Free und das Chart dort Jamel, also die Beschreibung von dem ganzen Chart, das ganze Paket, das Wandel, das nennt man eben Chart.

Okay, verstehe. Das heißt, wenn wir nochmal die Vorteile von Helmi Charts zusammenfassen, was bringt mir deren Verwendung? Dann kann man schon sagen erstmal bündelt es die Anwendungs Informationen. Also welche Dienste brauche ich, welche Williams brauche ich, welche Ports brauche ich? Die sind da ja alle beschrieben und einfach erweiterbar. Also wenn man ein weiteres Molden brauch, kann ich das einfach da eintragen und es würde dann hinzugefügt. Änderungen durch die Git Versionierung keit können einfach nachverfolgt werden und es gibt bereits eine große Bibliothek von vorhandenen Pane Charts, die ich entweder inkludieren kann oder als Basis für eigene Entwicklung nutzen kann.

Ja genau. Was vielleicht noch ganz interessant zu wissen ist. Wir haben ja schon gesagt, Heyme macht eben diesen ist Säufer gleich und das gantzer Kommando. In diesem Fall wäre das dann Häme Upgrade. Das ist eidam potent, also idR impotent im Deutschen. Das bedeutet, ich kann das Kommando so oft ich will absetzen und es ändert eigentlich nichts, außer dass jetzt die Release Noma hoch gezählt wird im Cluster. Aber abgesehen davon läuft meine Applikation. Ohne angefasst weiter.

Wenn ich jetzt keine Änderungen gemacht habe und das ist natürlich eine super Grundlage für Scripting, dann also, wenn ich das jetzt in der Pipeline packe oder so, kann das halt dann super einfach immer abgesetzt werden, weil das sich eben selbst darum kümmert, die nötigen Schritte durchzuführen.

Naja, okay, verstehe. Das heißt, wenn zwei Maschinen fehlen und du setzt Upgrade ab, dann Start. Der hat die zwei Maschinen. Und wenn das gleiche Kommando eine Minute später nochmal abgesetzt würde, würde einfach gar nichts passieren, weil er erkennt Ah, der Zustand, wie ich ihn beschrieben habe im HAMCHA. Das ist der Zustand, der auch im Cluster vorliegt. Das heißt, ich muss nichts machen. Genau. Wir haben in Episode Nr. sechsunddreißig über Terraforming gesprochen.

Das nutzt ganz ähnliche Mechanismen, um die Basis Infrastruktur, also z.B. diesen Kybernetisch Cluster aus der Taufe zu heben. Auf einer Cloud Lösung oder einer vorhandenen Infrastruktur und das ist natürlich in Kombination mit Kobanê des und Helmut Scharz kann man sozusagen von den Maschinen über den Cluster bis hin zur Anwendung eine komplette Basis Infrastruktur aus der Taufe heben mit dem Infrastructure as a Service Ansatz.

Das ist vielleicht noch ganz interessant, wo du jetzt Terraforming erwähnst. Viele Leute bringen das ja durcheinander. Terraforming hän Antriebe. Wo ist jetzt hier die Abgrenzung eigentlich? Und wie du schon gesagt hast, Terraforming ist halt eher Infrastructure Xcode. Also da hole ich mir dann irgendwie einen Cluster aus dem stampfe ich mir aus dem Boden und im hellen Bereich. Da ist man dann halt eher so bei den Applikationen, Middleware und sowas wie du gesagt hast. Terraforming hält ja auch für Zustand.

Bei Terraforming ist es so, dass der Kleinen seitig gehalten wird in dem Pfeil. Dieses Fall kann ich auch angucken und bearbeiten. Bei Helm ist es so, dass sich das ist auch abhängig von der Version. Da hat sich auch viel getan von der Version 2 zu 3, aber im Prinzip werden die ganzen Informationen im Cluster gehalten. Bei der neuen Version Version 3, da werden die Informationen in dem Namespace gehalten, wo auch mein Release läuft, also die Applikation, die ich installiert hab.

Und das hat eben den Vorteil, dass dann auch so Sachen wie jetzt Rol based Access Control von kybernetisch aus direkt umgesetzt werden. Also dass der Benutzer, der dazu berechtigt ist, das Deployment zu ändern oder überhaupt was zu Diplomen die Möglichkeit kriegt, wobei jemand anders, der dann eben nicht die Rolle hat, diese Möglichkeit unterbunden ist.

Also so eine Art Zugriffs Beschränkung mit Hilfe der Aarburg Policy genau Vorjahr bei Hellem 2 war das nicht ganz so einfach.

Das hat super funktioniert, wo Kybernetisch Arbat noch nicht implementiert hat. Weida hatte noch einen Server im Kybernetisch Cluster der laufen musste. Der sogenannte Tilla Server oder Tilla wird er auch einfach nur genannt. Und dieser Tilla hat halt als Server funktioniert für das Ziel n Tool vom Client aus und der hat halt seine ganzen Ressourcen innerhalb seines Namens Spaces abgelegt. Also enorm viel war das in dem Cubes System namespace. Da lief halt der Tilla und der hat dann Config Maps erstellt oben eben seine Ressourcen und seinen Zustand zu halten.

Und jetzt? Neu ist eben bei Hemme 3, dass die Ressourcen in dem Target namens Bake, also da wo ich meine Deployment wirklich mache, abgelegt werden, was eben diesen Vorteil hat, dass man die Arak Funktion von Kybernetisch direkt mit einbindet. Na weil wenn ich jetzt mit meinem Kleintieren gehe und keine Rechte hab, dann kann ich natürlich auch diese config maps gar nicht lesen oder bearbeiten.

Ja, das ist auch Tilla. War ja auch so ein Sicherheitsproblem, weil halt alle Leute, die sozusagen mit dem Tiller sprechen können, auf alle verwalteten Ressourcen Zugriff haben. Und jetzt über die Arbaces kann man das etwas feien Granulat wa steuern? Also man sollte auch für unsere Zuhörer, wenn man heute anfängt, auf jeden Fall mit der Version 3 von Helm beginnen. Genau hier. Ja, das ist vielleicht nochmal, um diesen Zweck klarzumachen. Ich finde das ganz interessant.

Du musst dir einfach vorstellen, oder? Unsere Zuhörer können sich einfach vorstellen, man hat diese laufenden Server einfach im Rechenzentrum, also hunderte oder tausende davon. Mittels Terraforming bündelte ich einige dieser Server zusammen zu einem Kybernetisch Cluster. So und der Cubaner? Das Cluster ist sozusagen ein STANDARD, der ob er jetzt bei Escher läuft, bei Google in der Cloud läuft oder bei AWS Amazon in der Cloud läuft oder irgendwo anders auch im eigenen Rechenzentrum sich mehr oder weniger gleich verhält.

Und auf diesem kybernetisch Cluster oder in diesen kybernetisch Cluster kann ich jetzt mittels Helm meine kybernetisch Anwendungen diplomen. Und wenn man diese drei Werkzeuge zusammennimmt also Terraforming Kybernetisch Helm komme ich relativ weit weg von diesem Vendor Lock in genau.

Ja wie du schon sagst. Also ich meine Kuba Annettes generell ist schon ein richtiger Schritt in die Richtung, dass man halt einfach eine Basis schafft und dann eben man nimmt ja gerne den Begriff Cloud Agnostikern in den Mund, also dass man eigentlich sich nicht wirklich drum kümmern muss, was unterhalb von Kybernetisch läuft, weil man da eben diese fest definierten Standards von Kybernetisch hat, also die Ressourcen und so weiter. Und klar, wenn ich dann ein. Dann bin ich da flexibel.

Also wenn du Helm benutzt, bist du da flexibel und hast quasi den ganzen Steg aus dem Vendor Lock in herausgezogen. Genau hier. Das heißt also, das ist ja wirklich toll, diese drei Komponenten oder softer Komponenten, die auch frei verfügbar sind in Kombination binnen Minuten hab ich quasi aus STANDARD Servern hab ich ein komplettes System aufgesetzt. Ich hab meine Infrastruktur pro Visionär. Ich hab mein kybernetisch klasse laufen plus ich habe meine kubanisches Anwendungen laufen und kann zu Testzwecken ja ganz beliebig diese Infrastruktur binnen Minuten hoch und runter fahren.

Kann Updates einspielen, kann Roll backs durchführen. Das hast du eben schon angesprochen, dass Helmut Shard selber dient. Natürlich auch. Jetzt muss man sagen für Entwickler auch als eine Art Dokumentation der Anwendung, weil ja genau beschrieben ist, was hängt von welchen Komponenten ab, welche Ports kommunizieren miteinander. Alleine das hat ja schon ein Wert, dass man sozusagen eine Anwendungs Dependency Graw generieren kann. Aus dem Hemd Shard. Ich weiß nicht. Gibt es da ein Kommando, dass man es irgendwie visualisieren kann?

Deshalb gute Frage. Das weiß ich tatsächlich gar nicht. Aber wie du schon sagst, das ist ein enormer Vorteil, den ich auch immer wieder gerne kommuniziere. Dass man eben durch das Coden von Schritten, die man durchführen muss, im Prinzip die Dokumentation überflüssig macht und auch damit eigentlich Fehler beseitigt. Wenn jetzt Sachen manuell durchgeführt werden, dann können immer Fehler entstehen. Man muss jemanden da haben, der aktiv zur Seite steht, mit dem Kopf da ist und wenn man das eben einfach automatisiert hat, sowohl mit Tera Form an.

Simple aber auch eben helfen könne einen dieser Fehler nicht so schnell unterlaufen.

Um ein plastisches Beispiel zu geben Stell dir mal vor, du bist verantwortlich für den sagen wir mal für den Server oder für die Helm Anwendung, die hier die Server betreibt, wo jeden Tag 20 Millionen Leute die Liste der Coruña infizierten runterlädt. Also das Beckhams sozusagen verdienender Corona Server. Und du würdest jetzt feststellen oh, die Anwendung wird sehr oft aus den App-Stores geladen. Ich muss irgendwie hoch skalieren. Das wäre eine relativ einfache Änderung. Würdest du das dann im @Helmut Chat mittels Reply CAS ändern oder was genau würdest du da einstellen?

Lustigerweise ist das Coruña App oder Coruña Waren App Server Beispiel eigentlich ziemlich gut, weil man da mehrere Komponenten drin hat. Zum einen Documentation. Wenn ich jetzt meine Heimat Charts publiziere einem Ghetto Chopra Satori Open Source, dann kann jeder sehen was läuft da eigentlich? Wie ist die Infrastruktur aufgesetzt? Wo läuft das Ganze? Und das hilft halt wirklich dann auch bei der Dokumentation, dass der Punkt 1, wie du sagst. Dadurch, dass ich dann mit meinen Templates eben diesen Replika Faktor einfach schnell hochsetzen kann, kann ich dann auch super schnell reagieren auf irgendwelche Anfragen.

Der Anstieg von Anfragen gut kybernetisch macht das natürlich auch schon mittels Autos Gayle. Aber wenn man jetzt in die Richtung geht, dass man mehrere Standorte hat, also eine globale Applikation hat, dann kann ich halt auch wirklich sagen Hey, wir haben jetzt einen neuen Markt irgendwo in Asian Pacific Area, dann kann ich einfach sagen So, da fangen wir jetzt an und da brauche ich jetzt ein Rechenzentrum und da hilft mir halt sowohl Theaterformen für die Infrastruktur, aber auch ha’m, vor allem, weil ich eben meine Applikationen in Minuten ausrollen kann oder eher Sekunden.

Ja, ich glaube auch an ein anderes gutes Beispiel ist, wenn ein ganz verbreiteter Messenger für Mobilfunk, Geräte oder für Smartphones seine Policy, seine Daten Policy ändert und auf einmal die anderen Messenger einen immensen Nutzer Ansturm zu verzeichnen haben. Das wäre auch so eine Situation, die in klassischen Server Umgebungen oh Gott, jetzt muss ich Server bestellen und die Immi mieten. Okay, ich bin in der Cloud, das heißt, ich kann in ein paar Klicks hinzufügen, aber das möchte man eigentlich auch nicht.

Man möchte im Grunde eine Anwendung so resilient implementiert haben, dass sie von selber, wenn sie wächst mehr Server Kapazitäten WIP mit kybernetisch mit Autos galligen automatisch sich beschafft bis zu einem gewissen Schwellwert.

Naja, das ist definitiv ein Vorteil. Ja und das ist dann eben ne kybernetisch Funktion bzw. in Helm selber kann man ja auch darauf Einfluss nehmen. Ja also wenn man zwei Beispiele genannt der Coruña ERP Listen Server und die anmeldest Server für Smartphone Messenger. Das ist natürlich auch eine Unternehmenskunden, die uns zuhören. Interessant wenn sie Nutzer Ansturm haben bei gewissen ich sag mal Black Friday Verkäufen oder Medienberichterstattung zu einem Unternehmen oder wenn Marketingkampagne laufen, wo halt in kurzer Zeit viele Kunden die Angebote nutzen.

Oder ein jüngstes Beispiel aus der vergangenen Woche, wo teilweise Server von Brokern Probleme hatten, weil eben ganz viele Aktien gehandelt werden auf einen Schlag. Da kann man dann gegenhalten.

Auf jeden Fall. Das hilft halt einfach schnell zu reagieren, weil ich eben dann nicht manuell. Irgendwelche Schritte einleiten muss, meinen Experten, der dann vielleicht im Urlaub ist, irgendwie ans Telefon kriegen muss. Sondern ich habe eben einfach die Dokumentation mehr oder weniger da und eben kann ich auch einfach Änderungen vornehmen direkt im Code, muss nicht mal irgendwo groß rum klicken, sondern ich mach das halt wirklich genau an der Stelle, wo ich brauch. Und da es so einfach ist, kann das natürlich auch automatisiert passieren, also direkt vom Computer.

Bevor wir jetzt noch auf weitere Details von Helmut Charts eingehen, würde ich dich noch fragen. Gerne zu deinem Erfahrungsschatz. Und zwar ist es deiner Erfahrung nach so, dass Firmen eher anfangen, neue Anwendungen auf Kuba nettes zu entwickeln und dann auch direkt zu @Helmut Charts zu erstellen? Oder werden auch viele Bestands Anwendungen also vielleicht alte Monolithen, die jetzt noch nicht so dem Mikroskops Paradigma folgen auch in Kuba Annettes Pakete verpackt und dann auch mit Helm Charts ausgerollt? Wie ist da deine Praxiserfahrung?

Also meine Praxiserfahrung ist eigentlich fast immer das gleiche und zwar dieses ganze Klout Thema kommt ja auf die Firmen zu und die wissen auch, dass die da was tun müssen. Die meisten haben kurz vor 12, also da ist das wirklich ein heißes Thema. Und da dann meistens auch relativ viel Funding in der Region dann zur Verfügung gestellt wird, passiert das doch meistens, dass Anwendungen grundsätzlich nochmal neu überdacht werden und dann auch eben der Microservices Ansatz umgesetzt wird, weil man eben, wenn man sowieso alles umzieht.

In diesem alten monolithischen Umfeld hat man natürlich seine großen Anwendungen irgendwo auf dem Server, der von irgendwem mit Hand konfiguriert wurde und wahrscheinlich irgendwo ne ganz dicke Dokumentation auf dem Schreibtisch liegt. Und da jetzt zu sagen Okay, ich hole das jetzt alles in die Cloud, das ist sowieso Arbeit. Und dann überlegen sich die Unternehmen meistens, dass es dann sinnvoller ist, das Ganze sowieso direkt schon um zu design, weil diese großen monolithischen Anwendungen haben ja auch was Skalierung betrifft Probleme.

Die sind meistens auch überhaupt nicht dafür gebaut, Verteil zu laufen. Und diese ganzen Cloud Native Komponenten API, Gate, Boyce und allen möglichen Sachen wären da gar nicht wirklich gut eingebunden. Wobei, wenn man dann nochmal wirklich sich anguckt, was gibt’s heutzutage für Frameworks, was ist der Stand der Dinge, dann kann man da seine Applikationen schön direkt Cloud Native neu designen. Und das ist auch das, was ich zurzeit hauptsächlich beobachte dass der Schritt eben auch direkt gemacht wird und die Applikation neu Design wird.

Man hat ja auch aus seinen Fehlern gelernt. Man weiß, wo sind die Schwachpunkte und manchmal sind das ja wirklich grundlegende Sachen, wo halt die Struktur von dem alten System einfach nicht so richtig passt.

Ja, genau, also das ist auch meine Erfahrung. Die alten Systeme funktionieren ja irgendwie, sonst wären sie ja nicht mehr da. Die lässt man vielleicht noch einfach weiterlaufen und steckt da gar nicht so viel Liebe rein. Aber wenn zukünftige Anwendungen entwickelt werden, benutzt man natürlich die neuen Technologien oder erweitert die alten Technologien um eine Komponente, die dann eben schon in der Cloud läuft. So ist auch meine Erfahrung. Also ich habe auch noch nicht gesehen, dass man Monolithen eins zu eins einpackt und dann in Kybernetisch betreibt.

Das wäre sicher auch dann ungünstig.

Ja, da hat sich einfach sehr viel getan, jetzt auch in der letzten Zeit. Wie einfach Applikationen strukturiert werden und implementiert werden, also gerade Sachen Richtung Datenspeicher und so in der Cloud geht man halt nicht davon aus, dass man immer so lokal seinen Speicher direkt bei der Anwendungs Logik hat, sondern geht da dann eher hin und benutzt externe Komponenten. Es kann ja auch eine skalierbare Datenbank sein, die auch im Cluster läuft. Aber eben dadurch, dass alles fein Granularität strukturiert ist, kann ich eben auch beliebig hoch und runter skalieren, so eben wie die Funktion benutzt werden von der Anwendung.

Lass uns doch nochmal etwas ins Detail gehen und nochmal genau besprechen, wie ein Helm Shard genau zusammengebaut wird oder wie das funktioniert. Möchte uns da kurz mit an die Hand nehmen, um das einfach mal strukturiert nochmal von Anfang bis Ende kurz zusammenzufassen, weil wir haben ja jetzt schon hier und da das Thema mal angeschnitten.

Ja, also das Hemd Shard ist eigentlich ein Wandel aus verschiedenen Dateien. Und die Haupt Datei ist eben dieser Chat dort Jamel, die eben dann einfach nur grunt information über das Chat enthält wie jetzt den Namen Version Abhängigkeiten. Und weiter gehts dann eben mit dem Templates Folder. Das ist so standardisiert der Ordner, der eben diese ganzen kybernetisch Ressourcen beinhaltet. PM nimmt dann einfach alles in dem Ordner und Diplomat das ins Cluster. Das heißt, wenn ich ein Pfeil da drin habe was überhaupt nicht ein Template ist, was einfach nur eine kybernetisch Ressource ist, dann wird hier auch genauso im Cluster ausgerollt.

Dann kann ich natürlich keine Konfiguration Änderungen machen mittels variabel, aber manchmal ist das ja auch gewollt. Dann die des Template Ding selbst. Das funktioniert eben mit diesen Gol Templates und alle goh lang internen Funktionen Template Funktionen sind abgebildet. Also wenn man da in der Sprache schon ein bisschen Erfahrung hat, hilft das natürlich immens. Aber Heimat auch noch weitere. Funktion hinzugefügt, dies dann leicht machen eigentlich alles mögliche zu Templeton, was Person nur Beispiel Funktionen, die man nutzt.

Also ich hab jetzt noch nicht viel mit Go lang gemacht, aber gibt es vielleicht eine funktionierende häufiger nutzt und die dir hierzu direkt einfällt?

Ja, also es gibt verschiedene Möglichkeiten, aber es gibt ja auch bestimmte Anwendungen. Wollen ja auch irgendeinen random character String haben, z.B. um krypto grafische Strukturen zu initialisieren.

Und da könnte man dann jetzt einfach in dem hammerhart sagen Gib mir random alpha numerische Ziffern generieren er ID oder sowas und das ist mein zaehlt für irgendwie eine Verschlüsselung Funktion, oder?

Genau das wäre jetzt ein Beispiel. Ich meine, ähnlich würde es oft auch mit Passwörtern gemacht, die eben nur Admin Passwörter für irgendwelche Datenbanken, die nur innerhalb des Clusters einem Sekrete sein sollen. Und da will man das Passwort ja explizit auch randomisiert haben. Das heißt, dass man halt gar nicht erst irgendwie eine Schwachstelle hat, wo irgendwer das Passwort kennt zu irgendeiner Datenbank, sondern das wird einfach direkt alles innerhalb des Clusters abgespeichert und keiner braucht da Zugang zu genau bei den Templates.

Ist vielleicht noch interessant für die, die da jetzt noch nicht so mächtig sind. Mit der Jamel Syntax ist natürlich empfohlen, das in Jamel zu machen. Das wird ja in vielen anderen Bereichen auch verwendet, weil das eben so schön lesbar ist. Aber für die, die’s Probleme macht Jamil ist ja eine obere Menge von Jason, also jede valide Jason Struktur ist natürlich gleichzeitig eine valide Jamel Struktur. Das erlaubt mir dann auch Jamil zu schreiben und wenn ich mal nicht weiterkommen.

Kurz die Ressource oder die Struktur eben in Jason darzustellen. Das wird ganz normal dann verwendet von Ham wie jedes andere Jamil und ja, funktioniert auch so was dann vielleicht noch interessant ist, ist das Beliefs. Das hatten wir schon ein paarmal ein bisschen angerissen. Hier nochmal explizit das ist eben ein Fall, was einfach Variablen definiert. Alles, was ich in dem Chart konfigurieren kann, kann ich in diesem Various Fall anpassen. Das heißt, ich kann dann eben, wie wir schon vorher gesagt haben, die Replika aus einer Anwendung anpassen und ich kann eben auch verschiedene Valerius Fails für verschiedene in Wassermanns benutzen.

Das heißt, wenn ich jetzt z.B. einen Gegenpol Süd-Korea kann ich auf jedem Bronstein auch ein unterschiedliches Belgiers Fall ablegen. Wenn es jetzt Development ist, was dann in die Test in Valmont geprobt wird, will ich da vielleicht andere Werte, andere Hoch Verfügbarkeit Werte haben als jetzt bei Produktion in Wahrnehmens.

Ich könnte auch Suchtest Nutzernamen da unterbringen. Dann heißt der User auf Test heißt der User minus test und auf in der Produktion wird er ganz weggelassen.

Wo solche Geschichten dafür wäre das welches Faltern da genau das Beliefs Fall ist natürlich auch wenn ich mir jetzt irgendwie von extern eine Ressource rein hole. Wenn ich jetzt z.B. einen Promi fürs Monitoring aufsetze, dann ist das Fall eigentlich die einzige Komponente, die ich mir dann auch selber privat abspeichern muss in meinem Git Repository, wo ich meine Changes Tracker, weil ich im Prinzip mit dem Chat dann direkt gar nichts zu tun habe. Ich passe nur dann Sachen an wie jetzt wie viel Speicher klemme ich, damit eben bestimmte Metriken abgespeichert werden und so weiter.

Und das ist alles was, was ich einfach bei mir in dem Delius enda aber grundsätzlich die Templates des Shard, das fasse ich gar nicht an, weil wenn da dann Änderungen Fixes eingespielt werden, dann werden die halt auch eben mit jedem Upgrade dann automatisch ausgerollt.

Das heißt, ich hab jetzt das Hemd Shard zusammengebaut mit Radius Jamil Templates, TV-Gelder, Charts, Jamil hab das auf der Festplatte oder es ist ne sollte ich lieber sagen. Und wie installiere ich das jetzt? Also ich hab die Anwendung da orchestriert in dem Helm Chart. Und wie schafft die Anwendung es jetzt in den Kybernetisch Cluster?

Also ganz konkret passiert das eigentlich mit Helm in Stowe und dann kann ich dem eben mit Minus ein Wadephul geben und dann gebe ich dem ganzen noch einen Release Namen. Den kann ich mir eigentlich mehr oder weniger aussuchen und dann bestimme ich halt noch welches Chart das ist. Das kann natürlich ein externes sein. Da sage ich dann bei einem Engine X z.B. Vietnam Nami Schrägstrich Engine X, also aus dem Vietnam Repository, dass Engine X Chart und dann wird das direkt installiert.

Also dann werden die Schritte eingeleitet, dass im Prinzip alle Abhängigkeiten und alles installiert werden in dem Cluster. Wenn ich jetzt natürlich das Ganze schon am Laufen hab, dann würde ich nicht mehr ins Stäube nutzen, weil Naniten. Steul schlägt fehl. Ein Stall ist nicht wieder impotent, sondern das Install ist ein mehr oder weniger imperatives Kommando, was halt einfach die Installation vornimmt. Normalerweise benutzt man tatsächlich Helme Upgrade und ich benutze eigentlich am liebsten Helme Upgrade minus AI, was soviel heißt wie machen Upgrade und wenn nichts da ist installierst.

Also dieses Kommando ist sozusagen alles in allem. Das Shard wird installiert, wenn es nicht da ist. Und ja, das ist auch das, was man dann eigentlich in Çiçek Scripte oder. Wo bei Automation einbaut, weil das eben diese idem Potenz hat. Okay, verstehe. Das heißt, man braucht sich im Grunde nur ein Kommando zu merken Upgrade minus ai oder minus y und Trends nicht installiert. Es wird die Anwendung installiert in der Version und wenn sie bereits installiert ist in der gleichen Version wird nichts gemacht, außer das Toyo Release Nummer instrumentiert wird und wenn die Anwendung installiert ist in einer vorherigen Version wird auf die aktuelle Version gab geredet.

Genau. Also es gibt natürlich dann auch Advanced Sachen, also haben unterstützt auch Semantic Versionen. Aber also da kann man dann die Release Nummer entsprechend anpassen. Aber das sind dann Sachen, die relativ Fettwanst sind.

Für jeden der jetzt kurz nach einer Anwendung erstmal die Pointe reicht das auch erstmal so dann die Unterschiede zwischen der Helm Version 2 mit dem Tilla Server, der sozusagen im Kybernetisch Cluster läuft und alle Aktionen durchführt und der Version 3, die mittels Airbag auf die ihr zugewiesenen rechte Bereiche zugreifen kann, um die Aktionen durchzuführen. Da bist du ja schon drauf eingegangen. Wie verbreitet ist Helm denn und lohnt es sich das genauer unter die Lupe zu nehmen? Ich glaube da haben wir fast schon eine Antwort gegeben im Verlaufe des Podcast.

Aber vielleicht fassen das nochmal zusammen.

Ja klar. Also das ist auch wirklich haben wir die Sache ganz am Anfang ja angerissen, dass Helme einfach extrem an Popularität zugenommen hat. Also es ist einfach inzwischen auch Grundlage für viele andere Systeme. Also im Ranga Rangiere ist ein Overlay über ein kybernetisch Cluster und das vereinfacht einfach die Verwaltung von kybernetisch Clustern. Da gibt’s ne schicke Joi, wo man das alles verwalten kann und da gibt’s eben auch einen Katalog.

Also das ist im Prinzip wie so eine App Store voll Kybernetiker und der basiert natürlich auf Helme und andere Bonnard sozusagen unter der Motorhaube im Hintergrund.

Genau da läuft dann natürlich Helm ganz normal und da sind auch die offiziellen Helme Repositories. Dann weiter geht’s ja dann noch, das geht ob’s Tool Flachs, Version 2 und das benutzt auch Helm Charts für Deployment. Also das Richtige ist hier natürlich die Version 2, weil da hat sich ja viel geändert zur Version 1, aber das ist so ein Get up Stuhl, wo man eben seine ganze Infrastruktur und Deployment alles entgeht, Repositories hat und Flachs bildet. Die Brücke zwischen den Geth Repositories und der Infrastruktur also ist guckt einfach aktiv.

Hab ich Änderungen in den Geth Repositories? Wenn ja, dann führt das eben die nötigen Kommandos aus. Also sozusagen das Scripten von Ham Upgrade.

Das finde ich richtig cool, muss ich mal sagen. An der Stelle du hast Watcher auf dein Git Repository yum, der bei Änderungen losgeht und dein kybernetisch cluster Status aktualisiert oder updated. Also das ist schon SII ICD auf höchstem Niveau finde ich persönlich es auf jeden Fall.

Das ist für mich auch so der letzte Schritt, der eigentlich alles zusammen packt. Dann war man hat natürlich das Problem, dass die Akzeptanz von Infrastructure oder auch Konfiguration oder sonst was. Ascot halt immer ein bisschen unterschiedlich ist. Es gibt ja auch gewisse Kollegen, die dann auch doch Änderungen manuell vornehmen. Wenn dann wirklich die Hütte brennt, dann hat man manchmal auch das Gefühl, jetzt hier in den Code zu gehen, das zu ändern, das zu Kometen Commit Message zu schreiben, zu pushen, dann wieder nicht woanders einzuloggen, eine Pipeline zu triggern oder sonst was.

Da haben viele dann irgendwie das Gefühl, wenn dann wirklich mal was los ist, dass das zu lange dauert. Und dann kann es schnell passieren, dass der Zustand, in dem geht Repository und in der Infrastruktur divergieren. Und soweit ich da bin, wird’s wirklich kompliziert. Das Schöne ist beim flachst, dass ich den Benutzern gar nicht mehr die Möglichkeit geben muss, manuell Sachen zu ändern. Bei jeder oder jeder. Der muss hat Zugang zu den Repositories und kann da einfach seine Änderungen machen.

Und das wird dann einfach im Hintergrund automatisch auf die Infrastruktur ausgerollt.

Ich sehe da noch einen ganz anderen Vorteil und zwar bis flux. Ja, so eine Art erweiterter Commit Hook. Das heißt, ich weiß, wenn ich mein Kotaku Mitte und auf Master Merge oder auf einen Release Branch merge, der wird dann automatisch Diplomat. So und das auf Entwickler Seite erzeugt dann eine Art erhöhtes Qualitäts Gefühl. Lass mich das nochmal sagen. Ich glaube auch, dass Flags und die Konsequenz daraus, dass wenn ich etwas Kommittee und auf den Master Branch merge, dass das automatisch Diplomat wird.

Das führt dazu, dass man das Testing noch ernster nimmt und noch mehr Tests schreibt, um einfach zu sagen Okay, wenn ich das jetzt hier committee, kontrolliert das kein Mensch mehr, sondern es wird wirklich produktiv ausgerollt. Wenn man das möchte und so einstellt. Und ja, das ist eigentlich eine gute Sache, dass man im Prinzip dann noch mehr Tests schreibt oder die Tests nochmal gründlicher checkt. Manuel checkt, um zu sagen Das muss ja alles Test Bar sein, sonst kann es sein, dass sich vorne was kaputt mache.

Das hilft auf jeden Fall dabei. Und das hilft natürlich auch der. Die Akzeptanz, also, dass Änderungen dann auch wirklich zur Infrastruktur kommen. Die Zeit ist einfach geringer, weil ich weiß, sobald ich was da rein packe, ich muss niemand Bescheid sagen, ich muss keinem sagen Hey, ich hab hier wieder eine Änderung. Roll das doch mal bitte auf die Infrastruktur aus, sondern das passiert dann einfach. Und das ermöglicht natürlich auch wiederum ganz andere Reaktionen bei den Entwicklern, weil die natürlich ihre Changes instant auf der Infrastruktur haben und einfach die Anwender profitieren ja auch ganz deutlich.

Da ein fertig gestelltes Feature ja schneller ist, in die Produktion schafft und schneller dann auch aktiv genutzt werden kann, von den entweder ein Nutzer da draußen oder den Unternehmens Benutzern. Das möchte man ja auch, dass man die Time to Market würde man im BWL Kontext sagen ich sag mal code to user time möglichst gering hält. Auch als Entwickler ist es ja möglichst erstrebenswert, dass wenn doch noch Probleme oder Rückfragen kommen, dass man die möglichst zeitlich nahe zur Implementierung dann erhält und nicht Monate später, wenn man sich dann nochmal eindecken muss.

Unser Muss. Okay, was war denn jetzt nochmal genau Sachstand da?

Okay Julius, vielen, vielen Dank für die intensiven Einblicke in das Ökosystem von Helm Kybernetisch Terraforming. Es hat mich super gefreut.

Sehr gerne, ja. Mich hat es auch gefreut, dabei zu sein. Vielleicht nochmal einen kleinen TISA am Ende. Was natürlich möglich macht, es in Verbindung mit anderen Tools auch komplexe Deployment Strategien umzusetzen, also z.B. Canary Deployment oder Blue Green Deployment. Bei Canary Deployment würde ich halten Feature erstmal an eine kleine Gruppe von Leuten ausrollen und dann testen wie reagieren die da drauf? Ist die Responses Zeit von dem User? Also wie lange braucht der User durch die Seite zu browsen?

Ist die schneller? Ist die langsamer? Wird das UI plötzlich verwirrend oder wird das eindeutiger für den Benutzer? Und dann kann ich Stück für Stück das halt als Produktions STANDARD haben. Und bei Blue Green ist eben dieser Situation, dass ich im Prinzip meinen Production impliziere und meine neue Version in ein zweites Produktion in Valmont, die Pleuger und dann eben einfach den Traffic komplett von dem einen Production in das andere Router und so halt dann auch ohne irgendeine Art Downtime halt einfach um switchen kann auf eine andere Version und Tools wie jetzt zum Beispiel ist Théo, die helfen mit Helm zusammen ebenso Sachen automatisiert umzusetzen und sowas ist natürlich Next Level.

Also das ist wirklich advanced. Aber das ist auch das, was man wirklich braucht, wenn man Ansprüche an Verfügbarkeit hat und Automatisierungsgrad.

Wenn unsere Zohra eine Frage haben oder Feedback zur aktuellen Episode, freuen wir uns über eine E-Mail an Podcast Skill bei Gilbert. Wir freuen uns immer über Bewertungen des Podcasts und natürlich Weiterempfehlung an eure Freunde und Kollegen. Das ist ganz ganz wichtig, wenn ihr die Podcast Episoden und die Inhalte als wertvoll erachtet. Empfehlt den Podcast gerne an Freunde und Kollegen. Weiter schaut Rolfs Gilbert de Slash Blog vorbei für weitere spannende Technologie Themen. Vielen Dank Julius für die Einblicke in Helm.

Und bis bald.

Bis bald.

Maurice KnoppSkillbyte Podcast #43: Helm – Der Kubernetes Paketmanager
Mehr

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

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 (Teil 2)

// Inhalt //
01:27 – Masiar’s IT Katastrophengeschichte
02:29 – 6. Lektion: Verstehe zuerst das Problem, schreibe dann erst Code für die Lösung
08:18 – 7. Lektion: Frage um Hilfe wenn du nicht weiter kommst (ultimative Superkraft)
11:20 – 8. Lektion: Du wirst immer weiter lernen (müssen)
21:22 – 9. Lektion: Test driven development (TDD) ist ein Mythos
26:34 – 10. Lektion: Alles dauert länger als geplant. Lass dich nicht von willkürlichen Deadlines verrückt machen.

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

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Nein. Prozess. Prozess beim ersten Mal o. citta bibber und um Gottes Willen und die Welt geht unter. So, und dann machst du und tust du. Und dann bist am Wochenende da und nachts bis drei. Und hin und her. So wird es aber trotzdem später, weil irgendetwas passiert ist, wo du keinen Einfluss drauf hast oder merkst. So schlimm war das jetzt doch nicht, weil der der Druck gemacht hat. Der war dann auch entspannt. So, und wenn das ein paarmal passiert, dann zuck sogar wenn Merkel.

Herzlich Willkommen zu unserem Skill bald Podcast Episode Nr. 40 10 Lektionen, die wir in über vierzig Jahren Softwareentwicklung gelernt haben. Teil 2 Abonniert unseren Podcast für mehr spannende Themen aus dem Technologie Umfeld, wenn ihr die Entscheider oder die Fachkraft seid. Wenn ihr Hörer Fragen habt, sendet uns gerne eine E-Mail an Podcast als Skill bei D. Wir freuen uns immer über eine positive Bewertung und wenn ihr den Podcast an Freunde und Kollegen aus dem ähnlichen Arbeitsbereich weiter empfehlt ich bin heute hier wieder mit Mazur zum zweiten Teil.

Hallo Masiar, Hallo Maurice, du bist heute sehr Energized.

Ich bin heute total Energieriese. Ich hatte eine gute Woche und freue mich jetzt mit dir. Wirklich, wirklich. Weil die ersten 5 Lektionen sind schon super angekommen. Da hab ich viele Zuschriften bekommen per WhatsApp und freue mich jetzt mit dir. Lektion 6 bis 10 durchzusprechen voller Energie. Vorher allerdings möchte ich dich fragen Sind dir noch Katastrophen aus deinem Leben eingefallen?

Ganz im Ernst. Ich habe überlegt und überlegt, wie es wirklich nichts eingefallen. Allerdings muss ich sagen, jetzt letztens kam eine GERB für Gravity Kiwi so toll eingerichtet. Was dir berichtet, ob alles in Ordnung ist. Und da kam eine Falschmeldung und damit hat sich das Herz in die Hose gerutscht. Da hatte ich seit langem mal wieder Angst, weil ich unterwegs war und nix machen konnte. Aber es war eine Falschmeldung. Insofern war es wieder gut. Was stand in der Meldung, dass Gravity nicht verfügbar ist?

Also komplett offline? Ja, genau. Ah, okay. Ich dachte jetzt Datenbank kaputt. Hacker haben die Daten geklaut oder so irgendwas Relevantes.

Mir ist nichts passiert in der Richtung nichts passiert. Okay. Erst bauen und Fehlalarm.

Das ist bestimmt meine Aura, die sowieso alles abhält. Deine Aura möchte ich auch haben. Na gut, springen wir zur sechsten Lektion. Vielleicht fällt dir unterwegs noch eine Katastrophe auf, wenn wir durch die Lektionen gehen. Die sechste Lektion ist eine ganz wichtige. Und zwar verstehe zuerst das Problem und schreibe erst dann den Code für die Lösung. Das Problem hierbei ist es oft. Ich bin sicher, das hast du auch gesehen, dass wenn es um Softwareentwicklung geht, springen viele Leute sofort ins Coding.

Die haben die Anforderung gehört. Ach ja, ich weiß schon, was ich machen muss. Achja, da mache ich das so. Da braucht man hier in Cash und das und das und setzen sich sofort an die Tastatur und legen los. Neue Funktionen wenn, dann so iterativ, ganz schnell implementiert und laufend angepasst. Und man merkt erst nach einiger Zeit, dass man das Problem gar nicht korrekt verstanden oder vollumfänglich verstanden hat. Und dann fängt man nochmal von vorne an oder es kommt auf jeden Fall zu einem erheblichen Zeitverlust.

Ich bin sicher, das hast du auch schon gesehen.

Ja, absolut. Ich meine, ich hab mich selber schon mal dabei ertappt. Ich hab mir seit dem das war so in den Anfängen hab ich das so gemacht. Tatsächlich. Aber irgendwann hab ich mir angewöhnt, keine Sequenzer, Diagramme, Urmel, Diagramme und so weiter groß gemacht, sondern einfach auf ein Blatt Papier, so die Komponenten aufgemalt, die Beziehungen aufgemalt. Kann echt auf einem Blatt Papier sein, um einfach mein Kopf zu sortieren und dann steige ich habe auch schon gerne ein.

Mir liegt die Klassennamen auf oberster Ebene, verknüpfe sie, schreibe die ersten Tests Duala Test Driven und das funktioniert ganz gut.

Das ist so, bis ihn der Flow, denn ich habe genau das ist für mich ein ganz klarer Indikator, ob man es mit einem Junior Entwickler oder Senior Entwickler zu tun hat. Ein Senior Entwickler stellt erst einmal sehr viele Fragen und versucht das Problem genau zu verstehen oder die Anforderungen genau zu verstehen und ist halt erst Input fokussiert. Wie geht man das jetzt an? Also du hast es eben schon gesagt. In jungen Jahren geht der Tüftler mit einem durch und man möchte sofort einsteigen und loslegen.

Ich habe so zwei unterschiedliche Pattern, je nachdem ob es um Feature Entwicklung geht oder um Bugfix sing.. Fangen wir mal mit dem Einfacheren an. Das wäre das Bugfix sing.. Das Allerwichtigste beim Bugfix sing. ist, dass man erst einmal den Bug zuverlässig reproduzieren kann, weil erst dann sinnvolle Entwicklung eines Fixes möglich. Meiner Ansicht nach erst, wenn ich weiß, wenn ich hier klicke und da klicke und dann tritt der Fehler auf und das immer wieder machen kann. Erst dann kann ich ja quasi prüfen, ob meine Lösung das Problem wirklich löst.

Ein weiterer Hinweis und ich bin verblüfft, wie viele Leute das nicht machen ist, den Debugger zu verwenden, also wirklich Schritt für Schritt durch das Programm durch zu steppen und sich die Variablen anzugucken. Was passiert hier? Was passiert da gerade, wenn man das Programm selber nicht kennt oder es nicht selber entwickelt hat, dann wird es oft sehr einfach, da einen Fix zu entwickeln, weil man einfach genau sieht Ah, ok, an dieser Stelle muss etwas anderes passieren oder muss etwas weiteres passieren und das könnte man dann implementieren.

Einfach den die Bagger abklemmen und idealerweise wenn man den Bug dann gefixt hat, dann hinterher war man jetzt schon im Thema drin. Noch einen Testa zu schreiben, der prüft, dass der fix funktioniert und dass das Problem eben nicht nochmal auftritt. Das ist meiner Ansicht nach eine professionelle Möglichkeit ans Bugfix hing ranzugehen, um nicht direkt in den Code zu springen. Bei der Feature Entwicklung und da bist du wahrscheinlich bei mir ist es oft so, dass die Anforderungen gar nicht so klar sind.

Also das ist wirklich ganz ganz selten, dass der Projektleiter. Jeder auf einen zukommt und glasklar schon sagt Das soll so sein. Das soll so sein. Das soll so sein. Das soll so sein, sondern ja, wie hat man altes System? Und da lief das so und so und ich möchte das jetzt genau so haben. Nur hier und da, da muss etwas geändert werden. Also das tritt sehr häufig auf. Auch hier das Problem erst einmal voll umfassend verstehen.

Wenn schon Quote da ist. Also wenn z.B. das Feature eine Erweiterung darstellt, erst einmal diesen verstehen, dann ne Lösung Skizze erstellen, genau wie du sagst. Ich versuche mir immer die Eingabe und Ausgabe Daten erst einmal aufzuschreiben. Was geht rein, was soll rauskommen und dann eine Technologie Skizze zu machen. Und im Grunde ist für mich ein Computersystem in Daten Topf mit Code drumherum, also eine Daten Haltung die Transformationen auf diesen Daten durchführt. Und ich glaube, wenn man die Daten und die Transformations Schritte hinreichend genau beschrieben hat, dann wird das Problem mehr oder weniger klar und der Rest folgt fast automatisch.

Oder die Problemlösung folgt fast automatisch. Und bis man soweit ist, hat man sehr viel gelesen, aber noch keinen Code geschrieben oder sehr wenig Code geschrieben. Warum passiert das? Warum springt man sofort in den Code? All das einfacher ist, als sich Gedanken über das Problem zu machen. Das ist oft sehr schwierig. Man muss nachfragen, man hat es nicht genau verstanden. Man muss diese Zeichnung erstellen und direkt zu coden. Das möchte im Grunde jeder. Aber mit zunehmender Reife weiß man, dass das nicht unbedingt das zielführende Vorhaben ist.

Du bist auch motiviert, hast eine Idee im Kopf und setzt sich hin und willst das sofort machen. Also ich muss sagen, wenn ich tatsächlich eine Idee fest im Kopf habe, dann mach ich das auch schon mal hier und da setze ich mich hin und knallt die Klassen einfach rein. Das funktioniert auch ganz gut, aber ich glaube, das kannst du nur machen, wenn du gewissen Erfahrungsschatz mitbringst.

Erstens das und wenn das Problem hinreichend klein ist. Ja, definitiv. Also nicht bei super komplexen Funktionen oder wo sehr viele Transformationen gemacht werden müssen. Genau. Und dann ist es oft auch wichtig, das Problem korrekt zu erfassen oder das ist eigentlich das Wichtigste und dann das Problem zu lösen, anstatt irgendwie fancy mit Architektur Patterns technische Exzellenz zu zeigen. Das sehe ich auch relativ häufig. Dann werden dann einfache Sachen technisch exzellent gelöst, aber das Problem ist gar nicht so richtig verstanden worden.

Da gibt’s ein schönes Zitat und damit möchte ich die sechste Lektion abschließend von Abraham Lincoln Gib mir sechs Stunden einen Baum zu fällen und ich werde die ersten vier Stunden mit dem Schärfen der Axt verbringen.

Als Kind ist es echt schön. Ja, genau.

Ich kenne sogar so eine extreme Version. Da heißt es Gib mir fünf Stunden und 50 Minuten zum Schärfen der Axt, sodass man mit einem Hieb im Prinzip den Baum durchbekommt. Aber was heißt das hier? Ganz klar Desto genauer du das Problem verstehst, desto einfacher wird die Lösung hinterher. Nur man muss halt mehr Zeit mit der gedanklichen Beschäftigung mit dem Problem verbringen statt mit dem eigentlichen Coding. Deshalb ist das so schwierig zu befolgen. Die siebte Lektion ist für mich eine ultimative Superkraft.

Und zwar Frage um Hilfe. Wenn du nicht weiterkommst, wie machst du das?

Wenn ich nicht weiterkomme, muss ich sagen such ich tatsächlich im Internet. Stack Overflow ist definitiv eine Quelle, die mir sehr viel Tipps und Inspiration gibt, aber auch alle Menschen toll sehr Ego im Netz sind. Da werde ich für den speziellen Fall, wo ich nix finde, frage ich ja tatsächlich natürlich auch Kollegen.

Man verbeißt sich oft in Problem oder so geht’s mir manchmal. Du fängst an, alles ist ganz einfach. Dann kommen irgendwie Hindernisse, auf den gelangst du immer tiefer in diesen Kaninchenbau rein. Man probiert unterschiedliche Ansätze und wendet sehr viel Zeit auf. Also dann ist man richtig frustriert und fragt nach zwei Stunden vielleicht einen Kollegen. Und er sagt Ach ja, kenne ich schon. Du musst hier das und das machen. Boah, das hat mich damals drei Tage gekostet, das herauszufinden oder so, wo man so richtig schön per Facepalm dann denkt Oh Mann, da hätte ich mal vorher gefragt.

Das ist aber auch so eine Gratwanderung. Du kannst ja nicht wegen jeder Kleinigkeit den Kollegen fragen. Na weil, dann ist er auch irgendwann genervt. Manchmal, wenn du der Mensch bist, der sich am längsten mit einem Problem beschäftigt hat oder am längsten ein Projekt ist. Es ist einfach unwahrscheinlich, dass die andere weiterhelfen können. Natürlich Google Stack Overflow und alle Quellen benutzen, die man im Internet findet. Das ist das Naheliegendste. Aber hier soll es wirklich darum gehen, den Kollegen zu fragen oder die Kollegen Kolleginnen zu fragen, ob man weiterkommt.

Also ich mache das so, ich probier das erstmal eine halbe Stunde, sag ich mal. Wenn ich an ein Problem komme und wenn ich dann nicht weiterkomme, zwinge ich mich, aufzustehen und jemanden zu fragen oder eben patschert jemanden zu fragen. So um dann einerseits respektvoll mit der Zeit der Kollegen umzugehen, auf der anderen Seite aber auch nicht zu viel Zeit zu verständigen. Und das hat sich bei mir eigentlich als gutes Vorgehen herausgestellt. Aber du fragst nicht so viel, oder?

Nee, hat vielleicht auch ein bisschen mit Persönlichkeit zu tun. Ich versuche lieber selber zu lösen. Keine Ahnung, ist einfach so. Ich kann nicht sagen, warum. Aber ich will den Knoten selber irgendwie aufmachen.

Das hab ich auch, dieses Gefühl. Man hat schon so ein bisschen das Gefühl Ah, wenn ich frage.

Und das ist jetzt vielleicht eine einfache Sache, das geht so ein bisschen in die Berufsehre. Sitzt noch nicht mal irgendwie, aber so ich mache auch nicht gerne welche Superpower Grabbing oder sowas würde ich programmiere, möchte ich irgendwie allein sein. Ich hoffe, das versteht Cat irgendwie, oder ob das jemand nachvollziehen kann.

Ich glaube, das können sehr viele nachvollziehen. Bei mir ist das tendenziell auch so, aber ich hab ne Frustrationstoleranz, die sehr niedrig ist, wenn ich nicht in kurzer Zeit ausreichende Fortschritte mache. Also wenn ich das Gefühl habe, oh, mit jemandem zusammen komme ich schneller voran. Der Zweck heiligt die Mittel sozusagen. Dann setze ich mich auch zu zweit hin. Wenn ich das Gefühl hab, ich komme ja alleine weiter, dann hab ich auch kein Problem, das zu machen.

Aber ich glaube dennoch ab und an um Hilfe zu fragen. Kann einem sehr schnell sehr viel weiterbringen. Zumindest für das Team. Insgesamt ist es besser, als wenn jeder verbissen an seiner eigenen Lösung arbeitet. Die 8 Lektion. Hier geht es um Weiterbildung. Da haben wir ja auch schon in diversesten Episoden drüber gesprochen. Im IT-Sektor wirst du immer weiter lernen müssen. Das Technologie Umfeld ändert sich so schnell. Bestehende Technologien verlieren an Relevanz, neue kommen hinzu, die es noch gar nicht gab, die sehr schnell sehr prominent werden.

Und es wird gefordert, weil man ist ja Technologie Experte, dass man sehr schnell eine Einschätzung liefern kann. Was sind kurzlebige Trends und was sind wirklich längerfristige Entwicklung und was bedeuten diese für das eigene Umfeld? Im Grunde Welche Technologien muss ich lernen und welche kann ich einfach vorbeiziehen lassen? Wie machst du das? Hast du da bestimmte Kanäle, über die du dich informierst, abseits der üblichen wie Heise, Golem usw.?

So um Trends und so weiter mitzubekommen. Tatsächlich einfach im Internet. Heise Golem. Ich habe aber auch diese ich habe mal Subscription eins zu Cloud, Gusi und viele Yumi Kurse. Da schaue ich regelmäßig mal vorbei und gucke, was neue Kurse sind. Speziell ist es aber für die Bereiche Java oder DevOps. Wo ich unterwegs bin, suche ich gezielt danach. Und wenn mir irgendwas interessant erscheint oder mir ein Wort begegnet Technologie, von dem ich noch nicht gehört habe, dann gucke ich mal rein.

Dann suche ich danach explizit. Ich versuche halt immer so ein Level zu erreichen, wo ich verstehe, was das Tool macht. Will mir eins besonders interessant erscheinen, oder? Ich meine, das passt mir sehr gut den Kram. Dann mach ich auch schon mal so ein Tutorial mit, um einfach mitreden zu können, einfach zu wissen, was es ist, was man damit machen kann und so erweitere so nach und nach mein Tool. Schade. Oh dann, je nachdem ich das nächste Mal auf so ein Problem stoße, weiß ich Aha, da gab’s doch mal so ein Tool.

Okay, toss im Grunde diese Sternenkarte schon im Kopf. Und wenn ein neuer Stern auf ploppt, dann guckst du dir den kurz an und kannst ihn dann einordnen.

Ja, das halte ich auch für sehr wichtig. Ich finde, diese längerfristigen Entwicklungen oder diese großen Trends, die erkennt man relativ gut, weil sie auch mehrere Jahre bestehen. Also Cloud wäre z.B. ein Trend, Datenauswertung wäre ein großer Trend. Generell Megatrend ist natürlich Digitalisierung. Wobei tue ich mich schwer, das als Trend zu beschreiben, sondern das ist einfach eine weitere Entwicklungsstufe der Menschheit. Das möchte ich jetzt nicht als Trend verstanden sehen, sondern man kann technologisch einfach Prozesse effizienter abbilden, als man das manuell könnte.

Gerade jetzt mit Heimarbeit wird das offenbar an vielen Stellen, sodass das auf eine weitere Entwicklungsstufe ist. Aber es gibt auch Micro Trends, das sind z.B. Tools im Kobanê, das Umfeld oder im Container Umfeld, die man so ein bisschen im Auge behalten muss. Vielleicht hier als Tipp. Ich weiß nicht. Kennst du jeden Freitag auf dem Heise Newsticker diese Developer News in ein, zwei Sätzen? Du kannst mal auf Heise Slash Developer gehen, da kriegst du nur die für Developer relevanten Artikel angezeigt.

Ist für mich ein Super Life Hack und die ganzen Clickbait Artikel sind dann weg und da gibts es jeden Freitag so ein Digest, wo dann in zwei Sätzen immer dran steht. Das Tool ist und der und der Version entschieden. Das kann jetzt so und so.. Die Software hatte Sicherheitslücken, die wird nicht mehr gepflegt, die ist neu hinzugekommen. So und das sind immer 35 40 Einträge, wo man einfach weiß, was so abgeht. Dieses Symbolbild von dem Artikel ist immer das gleiche.

Daran erkennt man es dann sofort und man hat einfach einen schnellen Überblick. Viele Tools sagen einem auch nichts. Also wenn das sieht so aus dem Automotive Bereich kommt oder irgendein Spezialwerkzeug ist okay, dann hat einem das noch nicht berührt. Aber so hat man so einen Überblick. Und da guck ich dann rein. Wenn jetzt ein Tool schon zum dritten, vierten Mal Erwähnung findet, dann kann ich mir vorstellen Ah, okay, das scheint auf jeden Fall wichtig zu sein, oder?

Da wird häufiger drüber gesprochen, weil die Entwicklung da so rasant ist. Jede Woche eine neue Version ist ja dann schon eindeutig ein guter Tipp. Auf der anderen Seite, also wenn es schon gesagt. Im IT-Bereich wird man immer lernen müssen. Auf der anderen Seite finde ich auch desto mehr Erfahrung man hat, desto weniger Schrecken ein. Diese neuen Technologien, weil man immer wieder feststellt So wirklich, wirklich Neues. Das kommt vor. Aber es ist nicht so häufig, sondern oft erscheinen neue Frameworks oder Libraries.

Und die sind nur ein Aufguss einer bekannten Technologie aus einem anderen Kontext. Und alles war irgendwie schon mal da. Deshalb bin ich dazu übergegangen, mir eher die Konzepte anzuschauen Welches Konzept steckt denn hinter der Blockchain oder einem Paket Manager oder Haskell? Wenn du SQL kannst, da kannst du alle Datenbanken und nicht nur eine bestimmte. Wenn du weißt, wie ein Paket Manager funktioniert, dann kannst mit N.P. Umgehen, mit Maven, mit Neef, geht mit APC, mit Pacman Kapern und wie sie alle heißen.

Und wenn dann jetzt der nächste dazukommt, dann weiß man AOC, dass im Paket Manager DeWitt irgendwie so funktionieren. Ich weiß, was im Paket Manager macht und das ist dann der Achte im Bunde. So ungefähr auch Protokolle. Also ganz früher gab’s den Remote Procedure Call, der ist sogar noch vor meiner Zeit, den kennst du wahrscheinlich noch. Dann kam die Scope Schnittstelle. Heute sind wir bei Rest APIs angekommen. Wer weiß was danach kommt. Hier Proto Buffer oder so.

Bei Frameworks genauso Tools kommen auch andauernd neue hinzu. Na da gibt’s natürlich so mega Tools wie Git. Also Code Warning ist glaube ich schon in den letzten 15 Jahren extrem gepusht worden, wo früher die Leute ihre Dateien irgendwo gesichert haben. Es war ganz grausam und zwischen den einzelnen Ökosystemen, also dort net Java node Python you name it. Wenn irgendwo ein cooles Feature auf ploppt ist meiner Erfahrung wird das sehr oft geklaut.

Sehr gut. Ist ja normal. Ja, ich finde das auch gut. Das ist ja die Schönheit. Ein Open Source. Wenn einer was rausgefunden hat, können alle profitieren. Also wie schließen wir mit dieser Lektion ab oder was ist unser Empfehlung? Ich würde sagen, man muss nicht alles im Detail verstehen, aber man sollte halt die Konzepte verstehen und diese Themen einordnen können. So wie du das eingangs im Prinzip gesagt hast. Du hast diese Sternenkarte und kannst neue Sterne schnell platzieren.

Du versuchst halt zu abstrahieren, soweit wie möglich.

Was ist für dich eine Technologie der letzten Jahre, wo du gedacht hast Okay, das ist ein Megatrend? Mein Gott, da muss ich wirklich viel lernen.

Das ist das Thema Cluster Orchestrierung. Docker Dieses ganze Gebilde. Das war für mich völlig klar, dass ich meine, damals waren mehrere so am Start da visus Marathon, kybernetisch, die waren alle gleich auf. Und interessanterweise, das hab ich auch schon bei einem anderen Podcast erwähnt. Ich hab mich am Anfang komplett gegen diese Docker Technologie gewehrt, als die Kollegen das angesprochen haben. So ein bisschen erklärt hab. Ich fand das halt mega abstrakt. Ich hab das alles gar nicht verstanden wie Leya und wie.

Ich kann da nicht reinschreiben was soll der Scheiß. Nach und nach je mehr die das gemacht und eingeführt haben, umso mehr hab ich verstanden. Mein Gott und dann hat es irgendwann Klick gemacht. Hat euch boah wie geil darunter. War mir klar, das willst du lernen. Ja, da hab ich mich rein gekniet. Das war vor fünf Jahren. Und dieses Universum expandiert wie das richtige Universum, wie es permanent neue Tools erfindet sich neu. Da kommt K3 is leichtgewichtige Scobel net das, was du quasi auf dem Raspberry laufen lassen kannst.

Das explodiert quasi diese Technologie. Und ich liebe es aber auch so dran zu bleiben. Kugel und auch Madhya. Das ist super und find ich klasse. Also diese Technologie war für mich so zu all dem was die letzten Jahre passiert ist mit ein Gamechanger der Wahnsinn.

Nachdem du dich zuerst gewährt hast, wusste ich gar nicht. Hast du gedacht, das ist so kleinteilig?

Und was braucht man mehr als VMS oder genau was bringt da auch so außer jetzt eine riesen Lernkurve? Muss das jetzt sein? Sah ich so halt als Spielerei der Admins an und eigentlich war diese Erfahrung ganz gut, weil wir ich jetzt quasi bei einem Kunden bin. Und du hast meinetwegen so einen alteingesessenen Unix Systemadministrator, der diesem Konzept entsprechend auch nicht aufgeschlossen gegenüber ist. Dann kann ich das super nachvollziehen und weiß dann, wie ich den anderen führen kann. Was so?

Weil du diese Entwicklung selber mitgemacht hast, kannst du sozusagen auf der empathischen Schiene sagen. Ich weiß, die Bedenken hatte ich auch. Aber sieh mal folgendes Ja, da kommen mehrere Sachen zusammen. Mit Docker hattest du so eine erste Abstraktionsebene und Docker alleine bringt ja nicht so viel. Aber in dieser Kombination mit dieser Cluster Technologie und diesem Paradigmenwechsel dieser da wir eine Episode gemacht dieser 12 Faktoren für Cloud Native Apps kannst du ja Anwendungen komplett anders bauen, die dann eben wirklich weltweit skalieren.

Also du kannst mit den großen Gagfah Unternehmen mithalten, vom technischen Standpunkt aus, wenn du diese Software nach diesen Paradigmen entwickelst und diese Gaffer unternehmen haben die sie ja entwickelt. Das ist nicht nur Technologie, sondern auch so ein Mindset plus auch diese Cloud. Denke da kommt alles zusammen. Und das ist eine größere Blase oder ein eigenes Universum, was man nicht so isoliert betrachten kann. Und für dich? Du hast ja mal gesagt, dass du auch früher viel IT Administration gemacht hast.

Also Netzwerk Administration, Linux Administration nehme ich mal an..

Die SEMA Administration oder so Backoffice wirklich, oder?

Ich war Third Level Support einmal und zum zweiten haben wir mit einem anderen Kollegen via Mail und Unix Systeme. Administriert mit send Mail. Ja, das waren noch Zeiten. Okay, da war noch nichts Container visiert. Äh, nicht so wirklich.

Ich kann mich genau erinnern, wo der Kollege ankam mit 20 Disketten und Material. Guck mal, Linux hier, Ledoux da. Das war also damals das Linux System. Putzer und Linux kam gerade erst auf und VM, wer will ich nie faxen? Wir sagte hier Guck mal die Virtualisierung von VM. Wer und wie ich da Disketten reingeschoben hab und damit rumgespielt hab. Und da waren wir auch. Glaube, da könnte was draus werden und diese war so Vollbild geworden ist.

Das stimmt. Also dieses Feld wandelt sich weiter und wie im Universum. Es gibt schnelle Sterne, es gibt langsame Sterne, große Sonnen, die nicht mehr weggehen. Und das kommt in der IT auf jeden Fall mit. Man muss sich weiterbilden in allen 40 Jahren oder in all der Zeit. Dann die neunte Lektion. Ich weiß nicht, ob es schmerzhaft ist oder lustig. Test Griffen Die Welt abmahnt ist ein Mythos, heißt die Lektion. Und was ich damit meine ist Testserver Development, dass man zuerst die Tests schreibt und dann anhand der bestehenden Test da rein die Funktion implementiert.

Das hab ich schon so oft gehört. Bei Kunden und in der Theorie macht das auch Sinn, dass man sich zunächst über alle Grenzfälle einer Anwendung Gedanken macht und das Verhalten genau bestimmt. Und wie soll es denn sein? Wie soll sie sich verhalten, dass man anschließend alle diese Annahmen in Unit oder Integrations Test niederschreibt und dann im Prinzip die Komponente selbst entwickelt und nur noch die Komponente so minimal entwickeln muss, dass alle Tests grün sind, also alle Tests erfolgreich durchlaufen werden.

Und dann hat man sozusagen die minimale Lösung, die alle Tests erfüllt. Das habe ich in der Praxis noch bei keinem Projekt gesehen, wo das wirklich funktioniert hat. Ich freue mich schon über die Zuschriften.

Gerne melden, wenn es bei euch in der Firma funktioniert oder wenn ihr ein Projekt kennt, wo es funktioniert hat. Aber ich habe es einfach noch nicht erlebt. Und ich glaube, das Problem besteht darin, dass die Anforderungen für ein neues Feature oder für eine neue Anwendung oft nicht so messerscharf spezifiziert werden können, dass sich daraus Tests direkt ableiten können. Ist da deine Erfahrung?

Ja, Test am Anfang hat man immer gemeint. Also ganz ehrlich, ich gehörte auch dazu. Tests machen die Sache nur teurer, weil du ungefähr ein Drittel deiner Zeit damit verbringen musst. Wenn du Test Rival entwickelst. Aber je mehr ich in komplexeren Projekten eingestiegen bin, um so mehr ist mir bewusst geworden, wie wichtig doch Tests sind. Und inzwischen gibt’s ja Tests irgendwie. White Box Testing, Blackbox Testing, Tschiche Test Varianten und jedes für sich macht Sinn.

Ja, je mehr, desto besser. Weil so hältst du deine Software wandelbaren, gewitzte, gewisse Sicherheit da auch Änderungen zu machen. Und du hast einfach keine Chance, manuell irgendetwas zu testen, wenn du in irgendeiner Ecke rumschrauben.

Ich glaube, da spielen mehrere Faktoren eine Rolle. Und zum einen verändert sich Software heute schneller als früher, weil sich die Geschäfts Anforderungen schneller ändern. Man ist gewöhnt. Ah, ich muss die Software nur ändern und dann ist die neue Funktion da drin und das funktioniert sofort. So, das ist bis in die Vorstandsetage hoch Geblubber. Und deshalb ist die Erwartung. Ich kann die Software schnell ändern, dann können wir das abfangen gestiegen. Also die Zeiträume bis hin zur Implementierung sind halt kürzer.

Wenn die Zeiträume kürzer sind, heißt das aber auch Development to Market ist kürzer. Und wenn du jetzt keine Tests hast, dann ist das so, als wenn du in schneller Folge beim Domino Day die Dominosteine aufstellen willst und umgeben bist von anderen Dominostein. Die Gefahr, dass du da irgendetwas anderes um stößt, ist gerade in komplexen Systemen riesig. Das heißt, die meisten Projekte, so kenne ich das, verwenden schon automatisierte Tests, meistens Unit Tests für einzelne Funktions Komponenten, die dann von der CCD Pipeline, also Git Lab, Bruna, Maven Tests usw.

angestoßen werden und Schlüssel Komponenten testen. Die IBAN sieht die richtig aus? Stimmen, die Datums Konvertierungen usw. und sofort. Aber eben nicht alles abdecken. Auch RPI Tests gibt es mehr und mehr, die einfach die Funktionsweise von Schnittstellen testen. Aber niemand hat 100 prozent und im Falle des Falles unter Zeitdruck fallen die Tests halt einfach runter. So, das ist meine Erfahrung und definitiv. Das sieht ja auch erstmal niemand.

Also du hast 100 Funktionen, 99 davon sind getestet, eines ungetestet. Jetzt machst du noch 10 Funktionen, noch 10 Funktionen ohne Tests, sodass nur so graduell wird das immer schlimmer. Aber das ist wie Carius. Erst einmal sieht man es nicht. Und irgendwann wird es dann offenbar. Und ich will nicht sagen, dann ist es zu spät. Aber dann muss man es dann doch behandeln. Ich glaube, ein guter Kompromiss ist hier die Kernfunktion, also kritische Sachen, wenn es um Transaktionen geht von Benutzerdaten, also datenschutzrechtlich relevanten Inhalten oder Zahlungsarten.

Das ist super wichtig, dass man das alles ab testet.

Es gibt dabei in jeder Anwendung auch unkritische Bereiche, da muss man sich ganz so genau nehmen. Unit Tests zumindest Völklein Komponenten halte ich für wichtig. Ja, und auf Front in Tests gibt es mehr und mehr und auch desto länger die Software besteht, desto mehr lohnen sich Tests. Gerade wenn viel verändert werden soll, hast du noch einen Tipp, wie man vielleicht dieses Tests Problem besser lösen kann? Also wie machst du das? Wie teilst du dir die Zeit ein für Tests?

Machst du Tests oder nur wenn es gefordert ist? Oder bestehst du darauf?

Nee, also so rigoros oder stringent bin ich nicht. Wenn ich meine, dass eine Interaktion zwischen Komponenten oder einer Komponente selber für mich in gewissem Komplexitätsgrad übersteigt, wo ich meine Oh, wenn es hier eine Änderung gebe, dann könnte es zu Problemen führen. Oder wäre das schön, wenn die anderen Komponenten das das bastel ich mir so im Kopf zusammen. Und wenn das einen gewissen Sprechrolle übersteigt, dann mach ich die Tests auch nicht für jede Klasse und jede Methode, sondern wirklich da, wo ich der Meinung bin, das könnte schwierig werden.

Später für die Worker oder Helper oder Converter oder sowas. Eben genau die sehr oft aufgerufen werden und die so eine Kernfunktion dann bewerkstelligen. Ja, sehe ich auch so. Haben wir schon einen gleitenden Übergang zur zehnten und letzten Lektion. Und davon können alle die Mitarbeiter und IT-Fachkräfte und Projektleiter ein Liedchen singen. Die zehnte Lektion heißt Alles dauert länger als geplant. Lass dich nicht von willkürlichen Deadlines verrückt machen. Das geht eher in Richtung Entwickler. Alles dauert länger als geplant. Wäre vielleicht die richtige Überschrift hier.

Was ist das Problem? Das Problem ist bei Kreativ Arbeit und nichts anderes ist ja die Erstellung von Programmcode. Im Grunde genommen ist ja nicht so, dass man da Mathematik rechnet, sondern eher kreativ sich eine Lösung überlegt und die dann runter codiert oder eine Formsprache bringt. Bei kreativer Arbeit ist es schwierig eine realistische Zeit Abschätzung abzugeben, gerade wenn die Anforderungen nicht klar sind. Zudem gibt es eine Vielzahl von Zeitfresser. Das erlebe ich immer wieder, die niemand auf dem Schirm hat.

Neue Bugs kündigen sich nicht an. Man kriegt einen problematischen Mertz Request von jemand anderem zugewiesen und brauch dafür 2 3 Stunden länger als gedacht. Mitten im Projekt gibt es Bibliothek, Updates oder Sicherheitslücken, die nicht warten können. Diese Bibliothek Updates ziehen Schnittstellen Änderungen nach, die man sofort machen muss. Was sonst funktioniert es nicht mehr? Irgendetwas funktioniert nicht wie beschrieben, kommt auch relativ häufig vor. Ein Kollege muss eingearbeitet werden, ein Kollege fällt aus. Es gibt viele Meetings.

Die Firma hat eine Restrukturierungen. Es wird kommuniziert, was jetzt alles restrukturiert wird und so weiter und so fort.

Und das taucht in keiner Zeit Abschätzung auf. Also ich habe noch bei keiner Sheets Runde gehört. Ja, also eigentlich würde ich sagen, ich brauch Tag, aber wenn wir restrukturiert werden unterwegs sollte ich vielleicht mal 2 Tage einplanen, weil beweiß. Dann bin ich ein Tag mit Meetings zugeschüttet oder so. Ich hatte jetzt letztens eine das hat mich nicht selber betroffen, aber eine Mitarbeiterin, die für ein Promo Video der Firma einen Tag quasi zur Verfügung stehen sollte. So was wird natürlich auch vorher nicht abgeschätzt.

Also was bedeutet das? Es dauert immer länger als du denkst. Sogar wenn du weißt, dass es länger dauert als du denkst. Wie gehst du damit um? Weil da wird ja manchmal schon relativ starker Druck gemacht. Extrem entspannt.

Also da drüber bin ich echt hinaus, um mir Druck machen zu lassen von Projektmanagerin oder Product Owner. Bei den Schätzungen gehe ich so vor, dass ich so eine Excel Liste mache und wir die jeweiligen Features Zeile für Zeile aufschreibe. Und dann mach ich eine Abschätzung für den Best Case, eine Abschätzung für den Worst Case dmit dort den Schnitt und addiere darauf nochmal 30 prozent für Unvorhergesehenes. So und so eine Schätzung gebe ich dann ab. Und wenn es dann länger dauert?

Ich versuche dann halt immer so ein bisschen zu dokumentieren, wenn was dazwischen kommt, was nicht auf dem Schirm war. Einfach um nachher, wenn einer fragt bis eine Liste raus und kann sagen Ja, das und jenes, welches ich habe keine Information bekommen nicht gebraucht habe oder der Kollege Z. Als Ansprechpartner war drei Wochen krank, ohne Vertreter, Regelung und und und, um einfach so ein bisschen sicher zu sein. Ansonsten kann ich es sagen. Wenn es dann noch länger dauert, dann ist es halt so.

Also du hast dieses Lass dich nicht von willkürlichen Deadlines verrückt machen völlig verinnerlicht.

War das bei dir immer so oder ist das ein Prozess?

Nein. Prozess. Prozess beim ersten Mal oh citta bibber und um Gottes Willen. Und die Welt geht unter. So und dann machst du und tust du. Dann bist am Wochenende da und nachts bis drei. Und hin und her wird’s aber trotzdem später, weil irgendwas passiert ist, wo du keinen Einfluss drauf hast oder Bergsee. So schlimm war das jetzt doch nicht, weil der der Druck gemacht hat. Der war dann auch entspannt. So wird das ein paarmal passiert da ja auch.

Was will man machen? Also zuckte du noch mit den ATL dieses Druck machen?

Ich sag mal ein bisschen Druck machen, okay. Aber dieses starke Druck machen? Es ist ja nicht so, dass du am Fließband stehst und jeden Tag in acht Stunden acht Autos Ponti hast. Und wenn du da zehn Stunden stehst, montiert du zehn Autos. Du denkst ja nicht schneller, weil du unter Druck geraten bist. Also. Ich weiß nicht. Bei mir funktioniert das nicht. Ich werde dann eher geblockt oder so. Wenn ich weiß Oh du Dexia, die schneller.

Ja, das ist ja sozusagen die Denke, da trödelt jemand, die mach ich jetzt.

Beine Nee, das kommt so aus der Industrialisierung und den setze ich unter Druck.

Und dann konzentriert er sich besser oder bleibt eher an der Sache dran. Das funktioniert bei Creativ Arbeit ja nicht. Also wenn ich einem Künstler sage mach schneller! Dann wirft er den Farbeimer gegen die Staffelei und dann kann er auch nicht sagen Ich bin fertig. Also vielleicht kann er das sagen, aber dann ist das Kunstwerk nicht gut. Und das sieht man leider auch mancher Software an, dass sie unter großem Zeitdruck entstanden ist.

Ich habe aber auch das Gefühl, Entwickler schätzen tendenziell zu positiv. Ich weiß nicht wieder.

Deine Erfahrung ist das kann ich so nicht sagen. Weiß ich das? Ich würde weder sagen positiv noch mal ist es klar mehr positiv, mal negativ heckt und ein bisschen damit zusammen, wie viel erfahrener oder unerfahrener Kollegen du im Team hast. Also eine generelle Tendenz kann ich glaube ich nicht sehen.

Ich hatte schon mal den Fall, dass Projektmanager bei Schätzungen gedrängt haben und sagen Nee, das ist zuviel, das muss schneller gehen und selber dann die Schätzung visieren oder beeinflussen.

Das auf jeden Fall halte ich für sehr gefährlich, es sei denn, der Projektmanager sagt vorher ganz offen Du, wir müssen unter diesem und jenem Level bleiben, um das Projekt genehmigt zu bekommen. Wenn das dann einmal läuft, dann wird es keiner mehr stoppen, wenn es länger dauert. Das hatte ich auch schon. Dass das so offen kommuniziert wurde, ist natürlich auch grenzwertig, aber das passiert manchmal. Aber klar, wenn das Projekt einmal läuft und man hat es schon 60 Prozent geschafft, dann wird es vielleicht der oberen Etage schwerer fallen zu sagen Na, wir stoppen das jetzt, weil das Budgets aufgebraucht, lass die letzten 20 Prozent weg.

Macht jetzt nochmal 20 Prozent und dann ist out.

Ich habe einmal erlebt, wo ein Produkt oder ein Kollegen so gedrängt hat, wird er das jetzt so so schätzt oder nicht fertig wird, dann gibt’s als mit dem Bonus nix.

Also wenn er es schätzt oder wenn es nicht fertig bekommt in der Zeit nicht oder so grob geschätzt.

Und dann sagte er Ja, es dauert halt so lange oder sagt sie Nee, auf keinen Fall. Dann gibt es wieder Modus. Nix gibt’s alles.

Ich hoffe, sie meint es nicht ernst. Doch ich war dabei.

Wenn’s nur auf die Schätzung ankommt, dann wird immer alles ganz schnell geschätzt.

Echt so, die Softwareentwicklung? Ja, manchmal ist es schon verrückt, meiner Erfahrung nach. Man kann sehr zuverlässige Schätzungen abgeben. Allerdings nur für sehr kleine Projekte oder sehr kleine abgegrenzte Probleme. Wenn die eingesetzten Werkzeuge und der Anwendungsfall sehr genau bekannt ist und man sicher gehen kann, dass man nicht von extern gestört wird. Das sind dann aber kleine Projekte und da weiß ich nicht. Die finden in den Firmen nicht so häufig statt. Meiner Erfahrung nach Bara sind dann nicht so wichtige Themen.

Ist denn in deiner Erfahrung mal ein Projekt vor der veranschlagten Zeit fertig geworden?

Ja doch, auf jeden Fall auch schon erlebt.

Ist zwar extrem selten gewesen, aber da gibt’s definitiv bei SKL bei Tamir einfallende, wo wir supergut im Zeitplan lagen. Oh, das war mega. Aber ansonsten. Ich muss mal überlegen. Na gut, auf der anderen Seite wir sind eine Consulting Firma und wir werden meistens angerufen, wenn in Excel schon eine rote Zelle erscheint.

Ja also diese Feuerwehr Geschichten gibt’s natürlich auch der Druck entsprechend groß ist.

Ja, das waren die 10 Lektionen. Unglaublich. Ich bin auf die nächsten 40 Jahre gespannt oder?

Ich hoffe nicht. Da mache ich so eine Abschluss Folge zur Verrenkung. Dann was ich gelernt habe, wenn unsere Zuhörer Fragen haben zu der aktuellen Episode oder auch so können Sie uns eine E-Mail an Podcasts Gilbert D.

Senden. Wir freuen uns immer über Bewertungen oder wenn ihr den Podcast abonniert. Empfehlt den Podcast auch an eure Freunde und Kollegen weiter und schaut auf der Skill bei D. Slash Jobs Seite vorbei. Weitere spannende Technologie Artikel findet ihr Weißgerber D im Blog Masa Es war wie immer ein pures Vergnügen mit ihr zu sprechen. Danke Rorys, dann wünsche dir noch einen schönen Abend.

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

Skillbyte Podcast #36: Terraform – Virtuelles Rechenzentrum mit dem Infrastructure as a Service (IaaS) Werkzeug

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

In diesem Podcast geht es um das Thema: Terraform – Virtuelles Rechenzentrum mit dem Infrastructure as a Service (IaaS) Werkzeug

// Inhalt //
01:10 – Definition: Was ist Terraform? Was leistet die Software?
06:23 – Software eats Hardware -> Infrastructure as a Service
07:42 – Welches Problem löst Terraform und wie erfolgt der Einsatz?
08:40 – So sieht ein typisches Terraform Projekt aus
11:53 – Der Terraform State – am besten remote in der Cloud
16:18 – Vorteile von Terraform
16:28 – Vorteil: Infrastructure as Code / Versionierbar in GIT
16:48 – Vorteil: Infrastrukturänderungen können sofort getestet werden
17:12 – Vorteil: Integration in CI/CD Pipeline
17:50 – Vorteil: Zentrale Infrastrukturpakete /-module
20:11 – Vorteil: Buildserver kann Terraform ausführen
20:44 – Vorteil: Portierbarkeit zwischen Cloudplattformen
23:22 – Nachteile von Terraform (Funktionsgrenzen, Cloud Limits)
23:30 – Nachteil: keine Einheitliche Benamung bei unterschiedlichen Providern; unvollständige Dokumentation
26:20 – Detaileinrichtung von VMs benötigt weitere Werkezuge (Ansible, Puppet, Chef)
27:48 – Vorteil: Kubernetes Umgebungen können mit Terraform provisioniert werden
28:35 – Nachteil: Proprietäre Cloud Features via Terraform nicht oder später verfügbar
31:48 – Nachteil: Abstraktionsschichten erhöhen immer die Komplexität
32:47 – Vorteile: Infrastruktur versionierbar, kurzfristige Wartezeit auf Ressourcen, Rückgabe nicht verwendeter Ressourcen, große Community
34:17 – Variablen in Terraform Templates für unterschiedliche Umgebungen
35:54 – Terraform Graph: stets aktuelle Dokumentation der Infrastruktur

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

Feedback und Fragen gerne an podcast@skillbyte.de

Maurice KnoppSkillbyte Podcast #36: Terraform – Virtuelles Rechenzentrum mit dem Infrastructure as a Service (IaaS) Werkzeug
Mehr

Skillbyte Podcast #30: Die Zwölf Faktoren des Cloud Native Development (Teil 2)

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

In diesem Podcast geht es um das Thema: Die Zwölf Faktoren des Cloud Native Development (Teil 2)

// Inhalt //
01:16 – Faktor 7: Bindung an Ports / Port binding
06:36 – Faktor 8: Nebenläufigkeit / Concurrency
14:31 – Faktor 9: Einweggebrauch / Disposability
19:34 – Faktor 10: Dev&Prod Vergleichbarkeit / Dev&prod parity
25:05 – Faktor 11: Logs
29:37 – Faktor 12: Administrationsprozesse / Admin processes

Twelve Factor App: https://12factor.net/

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

Feedback und Fragen gerne an podcast@skillbyte.de

Maurice KnoppSkillbyte Podcast #30: Die Zwölf Faktoren des Cloud Native Development (Teil 2)
Mehr

Skillbyte Podcast #29: Die Zwölf Faktoren des Cloud Native Development (Teil 1)

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

In diesem Podcast geht es um das Thema: Die Zwölf Faktoren des Cloud Native Development (Teil 1)

// Inhalt //
06:34 – 5 Leistungsversprechen von 12 Factor Apps
06:44 – Generelles Ziel: Verwednung deklarativer Formate
08:12 – Generelles Ziel: saubere Abgrenzung
08:43 – Generelles Ziel: Gleichartige Umgebungen (Dev, Stage, Prod)
08:55 – Generelles Ziel: Cloud-Deployments
09:00 – Generelles Ziel: Skalierbarkeit
10:56 – Faktor 1: Codebasis / Codebase
15:32 – Faktor 2: Abhängigkeiten / Dependencies
21:03 – Faktor 3: Konfiguration / Configuration
25:47 – Faktor 4: Unterstützende Dienste / Backing Services
29:59 – Faktor 5: Build, release, run
35:47 – Faktor 6: Prozesse / Processes

Twelve Factor App: https://12factor.net/

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

Feedback und Fragen gerne an podcast@skillbyte.de

Maurice KnoppSkillbyte Podcast #29: Die Zwölf Faktoren des Cloud Native Development (Teil 1)
Mehr

Skillbyte Podcast #27: Erfolgreiche (Tech-) Produkte bauen – so geht’s!

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

In diesem Podcast geht es um das Thema: Erfolgreiche (Tech-) Produkte bauen – so geht’s!

// Inhalt //
04:47 – Das Mindset für die erfolgreiche Produktentwicklung
07:02 – Technik ist (leider) nicht alles
09:13 – Fehler wurden gemacht…
11:34 – Technologie ist nicht das größte Problem (wiedermal)
14:10 – Wie entstand das skillbyte Produkt GravityCV?
19:12 – Online und Offline Tools sind Produkte
20:02 – Vorgehen für erfolgreiche Produktentwicklung
21:52 – Der Business Model Canvas
25:06 – Der Unterschied zwischen Produkt und Hobby
26:34 – Fertig ist Fertig
29:04 – Weshalb scheitern Technologie-Projekte?
36:52 – Fuckup Nights – Lernen von Anderen

Der Business Model Canvas: https://canvanizer.com/downloads/business_model_canvas_poster.pdf

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

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Man sieht immer, wenn man erfolgreiche Produkte der Unternehmen sieht, berichten die Medien darüber. Dann hört und liest sich das alles so einfach schön und gut. Aber man hört ja gar nicht von den Millionen anderen, die irgendwie aufgeben und nicht funktionieren. Man kann sich nicht vorstellen, wie viel Arbeit hinter einem Produkt steckt.

Herzlich willkommen zur bei Podcast Episode Nr. 27 erfolgreiche Tech Produkte bauen. So geht’s abonniert unser Kanal für mehr spannende Themen aus dem Technologie Umfeld. Wenn ihr eine Frage habt, schreibt uns gerne eine E-Mail an Podcast und lasst uns eine Bewertung und ein Feedback. Darüber freuen wir uns immer sehr. Ich bin heute wieder mit meinem Stammgast Masiar.

Hallo Masiar, hallo ich, hallo du Evergreen Gast. Heute sprechen wir über Technologie Produkte. Ein super spannendes Thema. Ein absolutes Ja. Ich möchte auch sagen Hauptthema. Viele Publikationen drehen sich ja darum. Man müsste einfach nur eine Idee implementieren, und schon hätte man das Riesen ONLINE Business. Aber wie wir selber aus leidvoller Erfahrung wissen, ist das gar nicht so einfach.

Ja, das ist wohl richtig. Ist ein gewisser Wandel im Gang? Jeder Versuch, diese Mentalität zu bilden. Ich habe auch sehr viel. Ich will jetzt nicht sagen, dass ich Produkte bauen kann. Aber ich habe einfach viele Fehler gemacht, und da bin ich auch gleich ein bisschen was erzählen, was man anderen erspart bleibt.

Genau.

Was mich etwas stört, ist, das in der Literatur dieses Lean Start up Movement führt. Oder ist da federführend, das noch weiter zu pushen, das es so dargestellt wird? Es ist alles total einfach. Du brauchst nur eine Idee Setz dich hin, kote das runter, und schon läuft das Ganze. Und das ist ja beileibe nicht so ne.

Man sieht immer, wenn man erfolgreiche Produkte oder Unternehmen sieht, berichten die Medien darüber, dann hört und liest sich das alles so einfach und schön und gut. Aber man hört ja gar nicht von den Millionen anderen, die irgendwie aufgeben, die nicht funktionieren. Und man kann sich nicht vorstellen, wie viel Arbeit hinter einem Produkt steckt. Absolut.

Da muss man fast immer ein bisschen schmunzeln. Du hattest bestimmt auch schon Gespräche mit Freunden oder Bekannten, die sagen Ja, ich habe eine Idee, aber ich möchte nicht darüber sprechen, weil sonst nimmt sie mir niemand weg. Und dann ich die Idee und jemand anderes wird damit ganz reich. Daran erkennt man die Anfänger, würde ich sagen, weil die meisten Menschen Hammann job. Die meisten Menschen haben auch ein Leben, und es ist nicht so. Wenn jetzt jemand von einer Idee hört, dass man alles stehen und liegen lässt, sein Leben aufgibt und sagt Ja, genau das mache ich jetzt, um die Idee zu stehen und damit erfolgreich zu werden.

Ja, es wurden Ideen übernommen in der Vergangenheit, aber zu einem ganz anderen Zeitpunkt und auch mit einer ganz anderen Zielsetzung. Wenn man schon Unternehmen hat, meistens anzumalen.

Die Idee an sich betrãgt nicht mal 100 Prozent an einem erfolgreichen Produkt. Ich würde sogar einprozent nicht schwitzen. Deswegen ist so eine Idee Mal raushauen muss man gehen, aber es ist nicht so wild.

Oftmals sind die Ideen ja gar nicht so entscheidend. Ich meinen, bleiben wir mal bei WhatsApp ist, das die SMS irgendwann durch einen Messenger auf Datenbasis abgelöst wird und man nicht mehr pro SMS 20 Cent bezahlt. Die visionäre Energie, die dahinter steht, halte ich mal für überschaubar.

Also da ist schon klar, dass sowas kommen wird, genau wie Videochats. Aber die Frage ist ja Wer macht es von den ganzen Playern, die es da draußen gibt, eine Wer schafft das dann am Ende? Und das ist genau, wie du richtig sagst. Execution ist 99 Prozent des Weges. Aber trotzdem finde ich immer. Also egal, wie hanebüchen manche Ideen sind, finde ich es mal klasse, wenn Leute sagen, ich habe eine eigene Idee, und ich verfolge die jetzt neben meinem eigenen Job.

Ich probiere, das irgendwie aufzubauen. Ich habe diesen Traum, das ich von meinem Produkt leben kann, und es gibt auch viele Menschen, die das können. Wir erinnern uns an dieser Stelle, an die Geschichte von Tonfalls Fingers. Ich glaube, das ist unsere Episode Nummer 21, wo der Cris genau beschrieben hat, wie er das gemacht hat und seine Geschichte erzählt hat. Und es funktioniert auch wenn man lange genug dran bleibt und lernfähig ist, aus seinen Fehlern lernen kann und sich immer wieder neu herausfordert, dann klappt das auch irgendwann.

Die Schlüsselkompetenzen wird das Durchhaltevermögen sein.

Genau.

Sich kritisch hinterfragen liefere ich wert. Sind die Nutzer Nutzen, die mein Produkt benutzen, die es gerne? Empfehlen Sie es weiter? Bin ich da auf dem richtigen Weg? Muss ich was ändern? Auch oft ist es ja so, dass man stellt sich in seiner idealen Welt das Produkt vor und sagt A so müsste das sein. Aber wenn man es dann baut, dann stellt man fest Nee, die Nutzer brauchen eigentlich etwas ganz anderes oder ziehen den Wert an einer ganz anderen Stelle des Produktes heraus, als man das selber antizipiert hat.

Und da ist es dann wichtig, auf die Benutzer Bedürfnisse zu reagieren und sich selber hinten anzustellen oder seine eigene Leidenschaft hinten anzustellen und zu sagen OK. Scheinbar. Von den Nutzern lernen, wo der Wert herkommt und muss mich dann dort entsprechend anpassen. Also ganz wichtige Mainz Sache.

Das ist ja auch so, wenn ich mal diese erste Spannung und Freude und Enthusiasmus vorbei ist, wo es dann um Arbeiten geht und auch mal langweilige Dinge durchzuziehen, dann würde ich mich gar nicht von Preisbrecher einer, der braucht immer diesen neuen irgendwas geschafft zu haben, irgendwas gelöst zu haben. Und ich muss mich disziplinierend, dann auch mal dabei blame einbringen bis zum Ende. Weil ich auch ein Taki bin. Ich habe mal eine langweilige Technologie, weil ich das gemeistert haben, weil ich das gelöst haben.

Das ist für mich persönlich die Herausforderung, dranzubleiben.

Du meinst, dem abchecken syndromen von der Schippe zu springen, das man nichts sagt. Oh, das ist was Neues, das ist was Neues und das ist viel besser, sondern dass man sich wirklich einer Idee verschreibt und sagt Entweder werde ich damit erfolgreich, oder ich mache nie was anderes.

Und es ist noch nicht einmal wie das andere viel besser, sondern diese so nah, ein komplexes Problem zu haben und mit neuen Gedanken, neuen Herangehensweisen das zu lösen. Das ist, glaube ich, für mich der Kick. Ich habe mir deshalb so ein Programm nicht gelegen. Bin ich immer wieder quasi Erde, und da muss ich jetzt, wo ich bis zum Ende hin du sagst, ja das Problem lösen.

Du meinst wahrscheinlich das Problem technisch lösen? Definitiv. Technisch ja, aber zu einem Produkt. Ein Produkt ist ja nicht nur eine technische Lösung, sondern auch das Marketing drumherum. Man muss die Leute, die Nutzer finden. Die Nutzer müssen auch, müssen das Produkt entdecken, müssen es nutzen, müssen Feedback geben. Und diese kontinuierliche Verbesserung? Diese Maschine muss man erst ins Laufen bekommen. Das war für mich, muss ich wirklich sagen, auch als Techniker eine sehr, sehr harte Lektion, die ich im Laufe meines Lebens gelernt habe.

Dass ich dachte, die Technologie ist total wichtig, dass die 1A ist und dass es den neuesten Standart erfüllt. Und dann baust du eine Anwendung, die super top aussieht, die neuste Technologie verwendet, und keiner nutzt sie. Hab ich gestern noch von einem Freund, der aber einer beim großen Unternehmen arbeitet, gehört? Sie haben sich jetzt 2020 auf die Fahne geschrieben. Noch in einigen Bereichen wird noch MS-DOS verwendet, das das dann doch mal langsam abgelöst wird.

Also technisch ganz schlimme Dinge, aber die liefern halt Wert. Und das ist das am Ende des Tages, worauf es ankommt. Wenn eine Abrechnung auf Maestros Basis funktioniert, dann ist das ein Wert, und die Technologie ist da zweitrangig. Ob das DOS, Windows, Linux oder wie auch immer ist. Wenn die Firma ihre Abrechnung macht und das irgendwie funktioniert, ist das egal.

Hauptsache, die Abrechnung ist der Wert, dass die gemacht wird und nicht die Technologie, die da drunter steht. Das sieht man als Techniker natürlich oft mit einem traurigen Auge. Auch Software auf Geldautomaten ist oft sehr alt. Aber es funktioniert. Solange der Wert, den die Menschen von dieser Technologie erwarten, gegeben wird, ist alles andere zweitrangig. Erst einmal Das ist hart für mich zu verstehen oder zu akzeptieren.

Aber es ist einfach so, und das haben wir auch bei Chris Tent was Finger Beispiel gehört das immer, wenn er an ein Problem gestoßen ist, ein technologisches Problem gestoßen ist, hat er das gelöst und ist dann weiter vorgegangen. Er hat aber nicht sehr viel Zeit darauf verwendet, von Anfang an so eine Infrastruktur aufzubauen, dass man von vornherein alle möglichen technischen Probleme, die man vielleicht mal hat, von vornherein ausschließt. Aber du hast gesagt, du hast. Also, ich hab natürlich auch ein paar Produkte, die ich gebaut hab, die vielleicht nicht ganz so abgehoben haben, wie ich mir das vorgestellt habe.

Aber du sagst auch, dass einige Lektionen gelernt, vielleicht mal ein paar teilen.

Das darunter liegende Thema ist diese Technik Verliebtheit bei unserem ersten Produkt. Da haben wir an der Software gebaut und umgetan und ein Mutterschiff an Funktionalitäten. Mein Gott, was sage ich gleich doppelt so, und das war für so ein Aerzte brutal. Zum zweiten haben mein Partner und ich haben uns gegenseitig gepeitscht, was das für ein tolles Tool ist die Welt erobern und das gesunde Portion Größenwahn? So will ich mal sagen. Genau das haben wir gemerkt. Dann erst angefangen haben, mit Krankenhäusern zu sprechen.

Und alle haben gesagt Journey Moment brauchen wir. Das sind schon gut ausgelastet da, und das hat uns natürlich komplett runtergezogen. Es hat ja noch nicht lange gedauert, bis uns das so ist. Kann man auch. Weil es so schwierig war, dieses Land zu kommen und dann auch gemerkt hat Die Entwicklung war echt Piepenburg dagegen, sondern das Marketing, das Artnet. Da muss so meint Mitbringen nicht von einem Nein, nicht beeinflussen lassen. Die Erfahrung hat man da halt nicht.

Und deswegen mal das Produkt, wo wir sehr viel Schweiß und Geld reingesteckt haben, ist man eingestellt. Und deswegen kann ich diese Bewegung liegen, die bei Lottmann, dass man vorher Interviews führen soll. Vorher anrufen soll. Habt ihr das Problem? Ist das Problem. Und wenn es so ein Ding geben würde, Butzen und so weiter, haben wir dann halt erst gemerkt, als das Produkt schon war. Und dann haben Sie jetzt auch gedacht Mein Gott, hätten wir das doch gemacht.

Wie viel ärGer wie gut seid, hätten wir uns da gespart? Auf der anderen Seite haben wir natürlich durch diese Erfahrungen aber auch sehr viel an Weisheit in Anführungsstrichen gewonnen. Genau wie man es nicht mal als Tiki fängt man an, eine Lösung zu entwickeln, und entwickelt dann die Lösung immer weiter.

Das ist so der natürliche Weg. Vielleicht wäre es cleverer, oder? Ich bin ganz sicher, dass es cleverer ist. Du machst einfach eine Webseite, wo du drauf beschreibst, was das Produkt kann, und sammelt Interessenten. Also versuchst, Leads einzusammeln dafür und bewirbt diese Seite. Und Kux verstehen die Leute, was ich vorhabe? Wollen Sie das Produkt wieviel bezahlen, die für das Produkt nutzen? Nur gratis würden die auch ein Abo abschließen und, und, und.

Diese ganzen Geschäfts kritischen Fragen, die muss man im Grunde vorher stellen oder viele davon vorstellen. Und erst wenn da hinreichend Interesse ist, dann kann man sich in die Lösung begeben. Genau das ist ganz wichtig bei meinem Tool, was ich über dreieinhalb Jahre gebaut habe, dass dieses Online-Tool für Gemeinschafts Geschenke so ähnlich funktionierte wie Dudeln. Und da war es so, dass wir mit diesem Tool gestartet sind Abstimmung für Gemeinschafts, Geschenke. Das haben die Leute gar nicht so benutzt, sondern sie haben sich eher Geschenkideen gesucht.

Was verschenken denn die anderen? Da hat man so ein Blog da, wo wir Geschenkideen beschrieben haben. Der hat dann immer mehr Traffic gezogen, und irgendwann haben wir festgestellt Okay, das sind die Inhalte auf dem Blog, den die Leute eigentlich wollen. Dann müssen wir diese Inhalte halt besser verpacken oder vermarkten im Sinne von E-Books, im Sinne von später Print Büchern. Und das hat dann gut funktioniert. Man hat quasi aus einem Webstuhl ist dann eine Content Plattform geworden.

Da waren wir gottseidank so was schon so viel Erfahrung, dass wir gesagt haben Okay, wir müssen uns immer irgendwie an den Nutzern ausrichten und nicht hart unsere Idee durchdrücken, sondern einfach schauen. Wo kommt der Wert her für die Leute? Und so hat sich das dann entwickelt. Aber das ist auch eine Position am Mainzer Top-Position, die meiner Ansicht nach sehr wichtig ist, dass man die einem dieses dieser Glaube okey. Ich weiß nichts. Ich muss den Nutzer beobachten Wie nutzt der das Produkt?

Wo kriegt er den Wert her? Was ist ihm wichtig? Welche Probleme hat er? Wie löst die Probleme? Wie kann ich ihm helfen, die Probleme zu lösen, dass man das ins Zentrum stellt? Und wirklich Es ist fast schon eine Floskel, Nutzer zentriert, sein Produkt weiterentwickelt. Aber da kommt es eben wirklich darauf an, dass man nicht sagt Ah, ich weiß, wie das alles funktioniert, und ich baue die perfekte Lösung, sondern was man mit zum Meinzer dran sagt.

Okay, ich mach mal etwas, was ich logisch finde, und beobachtet, wie die Leute damit umgehen, und muss das dann entsprechend anpassen. Genau das war auch ein weiter Weg und auch ein schmerzvoller Weg. Und da wurde auch viel entwickelt, was hinterher weggeschmissen wurde. Das stimmt. Bei Gravity Kiwi das ist ja das Produkt für Kiwis, um Lebensläufe digital abzubilden. Da sollte etwas anders vorgegangen. Da gab es ja schon eine erste Version, mit der Idee evaluiert habt.

Und da habt ihr jetzt ja schon auch super viel gelernt und das eben weiter ausgebaut.

Geht es aber schon länger. Ich habe mit meinen Zivis als Freiberufler permanent Probleme. Das ging mir so auf den Nerv, dass ich dieses Tool so nebenher. Um auch mit neuer Technologie zu experimentieren, habe ich das nun selber programmiert. Ganz einfachen Version habe ich dann einfach mal leid. gestellt und mir nach ein paar Wochen man schon eingesammelt. Hat das dann von einem Programmierer quasi nachbauen lassen mit einer anderen Technologie, weil ich es funktioniert. Leute nutzen das. Anscheinend haben andere das gleiche Problem.

Ich hab das nachbauen lassen mit mehr Features, und das war ungefähr einem Dreivierteljahr leid. Und dann haben wir uns entschlossen Okay, mal größer aufziehen. Viele Leute tragen dies und jenes an und haben auch keine richtige Zeit, um Support zu bieten. Das war ja immerhin ein Hobby Projekt, immer noch. Und dann haben wir irgendwann gesagt So professionell auch diesmal richtig Ressourcen, ein Aufrichtung Marketing und bauen das jetzt mal richtig. Und anders dann auch da wieder mit einer ganz einfachen Version, mit dem Wissen, was woher in der Zeit gesammelt haben, in einer Version umgesetzten Jetzt aktuell quasi Leid und haben dann wirklich beim Design viel Zeit verwendet, um User zu befragen.

Wir haben tatsächlich mit Video User befragt und gleichzeitig aufgezeichnet und hat nun einen Fragenkatalog überlegt und haben gesagt Mach mal versucht, dich mal zu registrieren und gehe mal mit dem Tool, mal aufgezeichnet, wie er damit umgeht, was er Fragen stellt, wie er mit der Maus umgeht und was er Schluss, dann auch einen Fragenkatalog durchgearbeitet. Am Schluss war die Frage Würdest du dafür bezahlt und wie viel, wenn ja, wieviel würdest du bezahlen? Das haben wir dann mit 20 Leuten gemacht.

Entwickler, Projektmanager aus dieser Ecke, diverse Rollen. Auf Basis dessen haben wir das Tun dann quasi rund gemacht im September, in dieser neuen Version. Ich bin gespannt, wie du auch diese lernsituation.

Das ist ja jetzt schon das zweite Release. Habt ihr dann schon einmal auch sehr gründlich dann durchgeführt? Bei dem Tool ist es sehr wichtig, dass die Daten sicher abgespeichert werden und so weiter. Kann man nicht einen Schnellschuss wagen?

Exakt im Moment gerade Test durchgeführt. Wir müssen auch gerade weil die Kollegen sehr stark danach fragen Wie speichert Daten, wo speichert sie die Kunden? Du genau? Wenn da was passiert und das Ding dichtmachen, insofern der Schaden so groß ist, wo man ganz, ganz sichergehen, dass alles gut ist. Ein zweiter Runde von Hackern durch Checken und Verschlüsselungen, alles, was dazugehört. Es gibt Dinge, die kann man nicht so agil machen. Gerade wenn es so geht, muss man schon.

Insgesamt ist es natürlich sehr viel Aufwand. Das ist alles selbst finanziert. Ja, das ist schon seit Jahren mitschwang, und ich hatte jetzt noch im Grunde drei Zielgruppen.

Ihr habt einmal die Entscheider, die das sozusagen als eine Herauslösung benutzen können, um ihr Team zu verwalten oder zu schauen. Welche Skills hat denn mein Team? Wer kann zum Beispiel Französisch sprechen und besitzt die Skills für das neue Projekt? Gefragt ist Die IT-Fachkräfte habt ihr als Zielgruppe, die da ihr Profil einstellen, um ihre Skills zu zeigen, und die Personaler, die gegebenenfalls dann, wenn man es im Freiberufler Kontext einsetzt, diese Profile sichten und dann die entsprechend richtigen Kandidaten dann an die eigenen Kunden weiterleiten.

Die Personalvermittler keinen direkten Kunden sehen, sondern die bekommen von unseren Kunden die Unternehmen und Programmierer, Freiberufler, Designer keine Ahnung. Die schicken diese Links an die Vermittler, und die gucken sich das an oder downloaden. Aber das ist keine zahlende Kundschaft.

Bei uns sind aber auch Stakeholder, die sozusagen in Kontakt mit dem System kommen und das Nutzen bestmöglich nutzen. Damit Sie Ihre Arbeit machen können? Okay, jetzt haben wir schon so ein bisschen darüber gesprochen, jetzt nur ONLINE Tools als tag. Produkt bezeichnet. Es gibt natürlich aber auch interne Werkzeuge, sodass man Kommandozeile, Werkzeuge, Import, Export beschreibt, die im Unternehmen selbst Prozesse vereinfachen. So ein Video encoder. Wer zum Beispiel ein Produkt, was man intern einsetzen könnte, oder eine App zur Reisekosten Erfassung für Großunternehmen, die sie intern verwenden können, Branchenlösungen zur Abrechnungen für irgendwelche ärztekammern oder sowas.

Da gibt es viele Tools, die dann teilweise auch auf den arbeitsplatzrechner und fest installiert werden. Das wären ja auch Produkte, die nichts mit Web zu tun haben, aber die man durchaus entwickeln könnte. Wenn man auf diese Nische geht und das Produkt?

Wie würdest du denn empfehlen vorzugehen, wenn ich ein erfolgreiches Produkt bauen möchte?

Ich würde sofort mit Umfragen starten. Das heißt nicht überlegen, wie ich meine Idee validieren kann. Ein Beispiel ist Ich baue eine Landingpage und tu quasi so, als ob das Produkt schon bestünde. Das heißt seine App oder einfach eine Beschreibung, was auch immer muss mir einfallen lassen. Die Landing Page soll quasi beweisen, dass überhaupt User darauf kommen, dass unser Interesse haben. Bin ich zum Beispiel mit Bestellwert Heising arbeite oder Google. Dass ich überhaupt User darauf ziehen kann, dann würde ich einen Button einbauen, wie zum Beispiel Jetzt registrieren oder jetzt kaufen oder mehr Informationen, je nachdem, was ist.

Und dann würde ich auswerten, wie viele User die Seiten gekommen sind, klicken und würden. Man muss sich natürlich überlegen, weil er schon wissen will, was ich ihm dann gebe. Ehrlichkeit am besten. Ich sage Danke, dass du wolltest wie validieren. Gerade eine Idee. Und dafür, dass du jetzt quasi nicht sofort das Produkt haben kann. Nicht so, dass wir, wenn wir das Produkt bauen, auch einen besonderen Preis einräumen oder einen Gutschein, was auch immer.

Du würdest evaluieren. Auf der Seite steht ja das Leistungsversprechen dieses Werkzeuges, das, das sozusagen auf Interesse stößt und Leute sich da sogar eintragen. Genau oder sogar auf bei Klicken, um zu sagen Ja, das ist wertvoll, was du dir da überlegt hast. Und da würde ich gerne dran teilnehmen. Das würde ich auch so sagen. Was auch wichtig ist Es gibt diesen Businessmodell. Kern Was kann ich in einer Episode in den Scharnhorst verlinken? Das ist ein Plan mit einigen Feldern, wo man sich Gedanken macht generell zu dieser Idee, also noch vor der Landingpage.

Vielleicht, dass man sich überhaupt erst mal Gedanken macht Wie monetarisiert das Produkt? Welche Features muss es bringen? Welche Partner brauche ich, um das zu realisieren? Welche Advantage habe ich vielleicht, wenn ich ein Wir sind ein Thi Unternehmen unser Anführer Advantage, das für uns sehr gut mit Althaus kennen und da viele Möglichkeiten kennen, die vielleicht jemand, der nicht aus dem Gewerbe kommt, nicht so einfach nutzen kann? Vielleicht haben dafür andere Unternehmen ein Vertriebs Team, was schon da ist, was Produkte absetzen kann.

Dann wäre das deren Anfeuert. Vantage und die einzelnen Felder dieses Businessmodell kennen. Was sollte man ausfüllen, um sich Gedanken zu machen, wie die Idee überhaupt funktionieren kann? Kann. Ich muss, weil man wird auch immer überrascht von vielen Punkten.

Dieser Businessmodell soll ja quasi unter dem Schirm diese liegen, wo das alles Glaskugeln ist. Ich habe auch schon ein paar Seiten Zeug, natürlich ein bisschen den Markt zu analysieren. Aber gerade diese ganzen Zahlen, die man nicht aus dem Kreuz fünf-jahres-plan Dreijahresplan. Ich glaube, da ist schnellere Iteration und Nutzer.

Befragung und Beobachtung ist da wichtiger, als dass man wirklich sagt Jetzt mal angenommen, deine Website, deine Landingpage, da würden sich genug Leute registrieren, und man würde sagen Okay, ich mache einen ersten Test, dass man sich wirklich ein Feature heraussucht, das Feature und eine ganz Basic Version implementiert, die nur das eine kann, das schon ausliefert an Kunden. Das ist auch ganz wichtig, dass man gerade bei Webentwicklung, wenn es vielleicht nicht daten, kritisch ist, dass man sich traut, das Ding auch online zu stellen und benutzbar zu machen für Kunden, wenn es noch nicht perfekt ist.

Das ist, glaube ich, so eine Krankheit in Deutschland. Nein, und dann wird da noch geschraubt und hier noch geschraubt. Nein, das Ding muss raus, sobald der Kern leistungsversprechen funktioniert und es einigermaßen benutzbar ist. Man kann es ja noch gratis. Stark reduziert anbieten, dass jedem klar ist, dass es eine Testversion ist, aber dass man etwas hat, was also so schnell wie möglich in die virtuellen Hände der Nutzer bekommt, um zu gucken Wie gehen Sie damit um?

Das Lernen muss einfach im Zentrum stehen. Wie gehen Sie damit um? Funktioniert das so? Liefert es ein Wert für die Benutzer? Und diesen Zyklus, dass man den schnellstmöglich startet. Und dann lernt man so schnell haughey. Die Benutzer brauchen eigentlich das. Oder man bekommt sowieso Anfragen. Muss ich das so umbauen? Muss ich das so umbauen? Muss ich das so umbauen? Und dann gibt quasi der Benutzer ein Stück weit vor, wie der Prozess optimal für die Zielgruppe des Benutzers zu funktionieren hat, damit er möglichst ohne Reibungsverluste das Werkzeug nutzen kann.

Und der sogenannte Product Market Fit ist dann erreicht, wenn die Kunden sagen Ja, dieses Tool kostet X im Monat, und das ist auf jeden Fall wert. Dafür bekomme ich ja diese Leistung, und diese Leistung ist viel wichtiger als das Geld, was ich dafür bezahlen.

Das ist auch ganz, ganz wichtig. Das möchte ich noch mal betonen. Zahlen die Kunden für diese Lösungen? Ja, das hört sich jetzt so kapitalistisch an. Meine Philosophie ist die Ein echtes Produkt hat die Kraft oder liefert so viel Wert, dass es sich selber finanzieren kann und die eigene Weiterentwicklung dann auch wirklich finanzieren kann aus dem eigenen Cashflow. Wenn du etwas baust, was zwar genutzt wird, aber die Leute bezahlen nicht dafür, das ist ein Hobby. Das ist kein Produkt für ein Produkt, wird bezahlt und kann aus sich selber wachsen.

Alles, was ich sonst mache, Foren, die gratis betrieben werden, mit Tausenden von Mitgliedern. Hey, dieser Podcast zum Beispiel, der ist ja nicht monetarisiert. Das ist ein Hobby, das kein Produkt. Produkt wird es dann, wenn etwas beginnt, sich selber zu tragen, oder das Potenzial hat, sich selber zu tragen.

Das ist ein Hobby, das ist einfach meine Philosophie.

Und ich denke, das passiert auch, wenn du etwas schaffst, ein Produkt erschafft, was so viel Wert liefert oder was Leuten so wertvoll ist, dass sie einen bestimmten Betrag dafür bezahlen. Dann strömt diese Energie ja auch wieder in dem Produkt zu und gibt dir. Das Geld ist ja nur eine Energieform. Davon kann man niemanden beschäftigen, der das weiterentwickelt. Man kann es selber weiterentwickeln, kann Marketing machen, man kann Grafikdesign machen und als Geld sozusagen wieder in ein besseres Produkt um zurück umwandeln.

Und dann läuft dieser Kreislauf, und dieser Schneeball, der dann rollt, wird dann eben immer größer, oder das Produkt wird immer besser. Allerdings, und das möchte ich jetzt auch ein streuen, das es aber mehr so eine Kritik an Produkten generell. Vielleicht kennst du das auch? Ich habe manchmal das Gefühl, wenn ein Produkt zu gut funktioniert, dann wissen die Entwickler nicht, wann es fertig ist. Das ist auch ein ganz wichtiger Punkt. Irgendwann ist ein Produkt meiner Ansicht nach auch fertig.

Dann kann man es noch warten. Aber es ist ganz wichtig, ist dann nicht mit Tausenden Funktionen zu überfrachten. Und jetzt könnten verschiedene Softwarelösungen Pack Programme sind da ganz vorne. Die fangen an mit als Pack Programm. Irgendwann kann man Videos damit bearbeiten. Das ist für mich immer so ein Symbol zum Zeichen. Jetzt haben wir es wirklich übertrieben. Also Mediaplayer oder Pack Programme finde ich ganz schlimm das man auf einmal einhundert Funktionen da drin hat und keiner benutzt die oder oder Prömel nutzt die.

Meiner Ansicht nach wäre das dann wieder ein anderes Produkt, weil es dann eine andere Zielgruppe anspricht. Aber steht vielleicht auf einem anderen Blatt, wann ein Produkt fertig ist?

Ich meine, das ist natürlich schwierig. Klar. Aber auch Kunden und oder neue. Wiederum ein Produkt, das am Markt bleiben, am Kundennutzen bleiben. Für mich ist es schwierig zu sagen, weil ich es mir schwer nicht mehr weiter lieber.

Gravity, wie sich das auch nicht so, aber zum Beispiel PDF Reader ist für mich so ein Beispiel. So Man hat eine Software installiert, ein Programm installiert, um PDFs anzuschauen.

Das ist die Kernfunktionen, und irgendwann nimmt dieses Werkzeug so überhand, dass es wiederum ein Feature ist, wenn PDF Reader rauskommt. Denn nur PDFs anzeigen kann, der total klein ist 300 Kilobyte, so schnell ein PDF auf klickt und wieder zu klickt. Also unter Windows, dann Sumatra PDF wäre so eines, das man sagt Okay, jetzt ist das normale PDF Programm vom Hersteller so groß geworden, dass wieder ein Markt entsteht für Leute, die einfach nur die Dienstleistung PDF angucken haben wollen.

Und da biete ich jetzt wieder eine abgespeckte Lösung an, die nur die Dienstleistung anbietet. Weißt du das? Der Grund, warum das Produkt ursprünglich mal entstanden ist, so weit aus dem Fokus gerückt ist, dass es wieder ein Feature ist, nur genau diesen Punkt zu bedienen? So, und da wäre für mich so ein Punkt, wo ich sagen würde Jetzt haben wir das Rad zu weit gedreht. Was sind denn die häufigsten Gründe bei ablösungen oder bei Teck Produkten, wenn es nicht klappt?

Entweder bin ich nicht lang genug dran geblieben, zu schnell aufgegeben oder ich hab das vielleicht unterschätzt, was meine Arbeit ist und kann ich alleine nicht leisten. Also bin ich Programmierer, bin zum Beispiel kann ich das Marketing nicht selber machen? Ich bin und finde auch keine geeigneten Partner. Wenn ein Produkt dann erfolgreich werden soll, kann man das schon allein nicht mehr schaffen. So wie früher. Keine Ahnung. Einer hingesetzt hat und in drei Tagen programmiert und komplizierte Teams daran mehrere Jahre.

Ich will jetzt nicht sagen, dass die Entwicklung so weiter genauso kompliziert ist. Aber als Einzelkämpfer ist es schwierig. Man braucht jemanden, mit dem man sich austauschen kann, Sparringspartner, der vielleicht sogar einem anderen Gebiet unterwegs ist als man selbst. Das sind für mich die Gründe.

Das ist auch so ein verzerrtes Bild, das man wie bei meinen Krafft oder so dann denkt Oh, das hat jemand alleine programmiert. Aber man blendet aus, dass der irgendwie zehn Jahre vorher schon nur Spiele programmiert hat, also das auch sein 21. Versuch ist und das zufällig jetzt einer von Hunderttausenden Mal so ein Hit gelandet hat. Aber wenn man heute zuhause sitzt und darüber nachdenkt, ein erfolgreiches Produkt zu bauen, dann möchte ich ja nicht Lotto spielen und sagen Okay, die Wahrscheinlichkeit ist eins zu 100 000, dann lege ich mal los, sondern ich möchte ja.

Ich glaube ja, dass ich ein wichtiges Problem löse und möchte, dass möglichst smart angehen. Was natürlich auch zur Folge haben kann, dass man herausfindet, dass das Problem, was man selber glaubt, was wichtig ist, gelöst zu werden, gar nicht so wichtig ist. Das glaube ich. Ehrlich gesagt Ist denn Nummer 1 Grund, warum Produkte scheitern, dass Lösungen gebaut werden für Probleme, die zu wenige Menschen haben oder wo zu wenige Menschen bereit sind, dafür zu bezahlen?

Ja, da bin ich gespaltener Meinung. Jetzt wirds spannend. Also ich finde, man muss nicht immer ein Problem lösen, um erfolgreiches Produkt haben. Bestes Beispiel Apple und dem iPod. Was für ein Problem hatte man damals mit dem Walkman Cassette?

Langsam muss es ja nicht, dass es langsam mal Schnelleres gab. Das war damals halt Alltag. Es stand der Technik. Du hattest kein Problem, nur Musik gehört. Und auf einmal kam einer, der einfach ein besseres Produkt, also mehr Lieder und Songs speichern, schnell hin und her spulen konnte, nicht einfach ein Produkt, was es schon gab, verbessert oder mit dem Telefon genauso? Wir hatten kein Problem mit dem Telefon. Problem gelöst. Da ist es noch eher so, aber er hat einfach irgendwas erschaffen, das die Leute noch gar nicht wussten, dass das was ist.

Das würde ich faszinieren und ab dem Nichts ein Ding zu erschaffen, wo die Leute gar nicht wissen, was sie wollen, dass es auf jeden Fall die höchste Kunst.

Man darf natürlich nicht vergessen, dass bei Apple die smartes Leute arbeiten mit den größten Budgets, die man sich überhaupt vorstellen kann, und dass man da natürlich andere Möglichkeiten hat, als das vielleicht jetzt ein mittelständisches Unternehmen ganz klar hat. Aber das muss man auch sagen. Apple geht natürlich auch die großen Probleme an, einen Computer einfach zu bedienen. Die Musikindustrie zu revolutionieren, die Telefon Industrie einfach zu revolutionieren. Und das haben sie jedes Mal geschafft. Das muss man auch.

Muss man den Hut ziehen? Da ist es ja so, dass Sie im Markt auch erschaffen haben. Ja, da hast du recht. Das ist ganz große Kunst. Da gibt es nichts zum umzu Reden. Noch Gründe, warum es schwer wird für. Ich sag einfach mal Start ups oder so. Loprieno wäre die eigene Projekte. Bauen Sie direkt am Anfang alles wollen, was das eben mit zu früh aufgeben bezeichnet. Und es muss sicher sein, und das muss sexy sein.

Es muss gut aussehen, und es muss schnell sein, und es muss perfekt skalieren. Und das Marketing muss sitzen, das man einfach zu viel will und dann untergeht. Früh das Produkt ausliefern, wenn es etwas kann, und dann lernen mit dem Kunden. Das, glaube ich, ist der erfolgsversprechend weg, anstelle fünf Jahre im Kämmerlein das Produkt zu entwickeln. Und dann? Tadashi ist es, und niemand hat auf dich gewartet, so wie ihr das mit dieser Plattform hattet, von der du gesprochen, dass man an das Beispiel Summen denkt.

Anfang des Jahres dieser Video Spätdienst, die haben ja auch erst Sicherheit eingebaut, als es zum Problem wurde. Wenn man mal böse sagt Nein, im Moment, wo die halbe Welt das benutzt hat. Doch eine Priorität, aber auch die gibt es noch, die leben noch und das hat sie nicht umgebracht. Dass sie dann schnell, schnell die Sicherheit noch dran geschuftet haben.

Wie übrigens auch viele andere. Das ist auch kein Geheimnis. Wer die PayPal Geschichte kennt, der weiß, dass auch PayPal sehr viel Geld verloren hat. In den Anfangszeiten einfach durch, also durch Kreditkartenbetrug. Und die haben das einfach erstattet, bis irgendwann das Budget für Erstattungen von Kreditkartenbetrug so groß war, dass sie gesagt haben Da kann man jetzt auch eine Lösung für entwickeln, dass das gar nicht mehr passiert, weil wir glauben, dass das mittlerweile günstiger ist. Und die haben das sozusagen einfach übers Bankkonto entschieden.

Und einen Grund hast doch schon angesprochen, dass sich das Team nicht gut ergänzt. Also 100 Teck Könige? Das wird schwierig, sondern man muss ein bisschen. Also ich glaube, man muss sich schon gut verstehen, sonst macht das nicht so viel Spaß, und man kommt doch nicht so weit. Aber die Kompetenzen müssen sich gut ergänzen. Der eine ist ein bisschen zurückhaltender, dafür kontrollierter, etwas besser. Der andere ist Puschilin und setzt sich durch, guckt nicht so genau hin, aber der bringt halt auch die Sachen vorwärts, sodass man da alle Perspektiven ein bisschen bedenkt.

Um da nicht zu sehr auf die Füße zu fallen und auch Chancen nutzt, wenn sie da stehen und nicht zu verkopft, die an sich vorüberziehen lässt.

Und was passieren kann, ist, wie Gekehrten startet. Und dann, wenn das mal heiß und unproblematisch, dann geht sowas auch oft schief. Man streitet sich um, geht irgendwie auseinander. Deswegen hoch her, egal wie gut man sich versteht. Alles zu regeln. Einmal eine Woche einschliessen, alles schriftlich fixieren für den Fall der Fälle, damit kein böses Blut gibt, hat das bei Klarheit hat also vielleicht nicht genau ganz am Anfang.

Aber sobald das professionellere Züge annimmt, würde ich das auch so sehen. Und man jetzt gemeinschaftlich entscheidet da substanziell Zeit, Geld zu investieren. Dann auf jeden Fall. Wenn da noch andere Kulturen aufeinandertreffen. Du hast schon von Offshoring gesprochen. Ich habe auch meine eigenen Offshoring Erfahrungen. Nein, nicht immer. Nein, heißt ja nicht immer Ja, heißt so oder so. Zeitplanung, das als durchaus kreativ ausgelegt werden kann, das sind dann andere Herausforderungen, die man meistens selbst unterwegs klar werden.

Super. Vielen Dank mir.

Sehr, sehr gerne. Ja, mir auch wie immer. Auch wenn, wenn alte Erinnerungen und Wunden.

Es gibt eine Veranstaltungsreihe, ich weiß sie in Düsseldorf abgehalten wird. Ich bin mir nicht sicher, ob Sie auch in anderen Städten Deutschlands abgehalten werden, die sogenannten FA-Cup Neids, wo Unternehmer von ihren schlimmsten fals erzählen. Ich weiß nicht, ob es die schlimmsten sind oder von fals erzählen Fehlentscheidungen, die sie getroffen haben. Dinge, die gehörig daneben gegangen sind. Das ist ein großer Erfolg, weil gerade in Deutschland, öSTERREICH und der Schweiz spricht man ja nicht so gerne übers Scheitern.

In Amerika ist es okay, bisher hingefallen. Jetzt ist wichtig, aufzustehen und weiterzumachen. Da ist ist man schneller verbrannt. Deshalb spielt man hier mehr auf Sicherheit. Da ist das ein ganz erfrischendes Format, das man sich mal angucken kann. Ich glaube, es sind auch Videos davon online. Also einfach mal FA-Cup, Neids Düsseldorf bei YouTube suchen oder FA-Cup Neids generell suchen. Und da gibt es einige Videos dazu und auch Veranstaltungen. Wenn unsere Zuhörer Fragen haben oder Feedback zu der Podcast Episode, können Sie gerne ein E-Mail schicken an Podcast Gilbert.

Lass uns gerne eine Bewertung da und abonnieren sein Kanal. Weitere spannende Technologie Themen findet ihr auf skillbyte Slash Blog. Wir freuen uns immer über Kommentare. Ich wünsche noch einen schönen Abend bis zum nächsten Mal.

Maurice KnoppSkillbyte Podcast #27: Erfolgreiche (Tech-) Produkte bauen – so geht’s!
Mehr

Skillbyte Podcast #26: So verändert Corona die IT-Welt!

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

In diesem Podcast geht es um das Thema: So verändert Corona die IT-Welt!

// Inhalt //
01:06 – Der Turbo für Digitalisierung in Deutschland
03:34 – So funktioniert die Corona App
09:36 – Unternehmen: Fachanwendungen auf IT Lösungen umstellen um vollständige Remote-Arbeit zu ermöglichen
11:13 – Grundausstattung für Kopfarbeiter und notwendige Infrastruktur
14:19 – Remote-Arbeit: Paradigmenwechsel als Chance
22:55 – IT-Fachkräfte: Ausstattung und Tools für effektive Zusammenarbeit
32:48 – Negative Aspekte von Remote-Arbeit
34:47 – Was bleibt nach der Krise?

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

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Ich hab ein Ziel formuliert, was Unternehmen anstreben sollten. Ich denke, es liegt in der Verantwortung der IT Entscheider und wir bei Skillbyte halten es ja genau so, dass ein Arbeitsplatz eines Kopfarbeit Mitarbeiters muss im Grunde überall funktionieren. Das muss das Ziel sein.

Herzlich willkommen zum skillbyte Podcast Nummer 26. So verändert Corona die IT-Welt. Abonniert unser Kanal für mehr spannende Themen aus dem Technologie Umfeld. Wenn euch im Verlauf des Podcasts eine Frage beschäftigt, schickt uns gerne eine E-Mail an podcast@skillbyte.de. Und wenn euch die Episode gefällt, freuen wir uns über eine Bewertung und ein Abo sowie einen Daumen hoch. Ich bin heute wieder mit Masiar. Hi Masiar.

Hallo Maurice, grüß‘ dich!

Ich grüße dich, wunderbar, und wir sprechen zusammen über die veränderte Welt bzw. die veränderte IT-Welt, die seit der Corona Pandemie Anfang 2020 oder die Entwicklungen, die seither stattgefunden haben.

Allerdings hat sich was getan, hoffentlich in den Köpfen der IT Entscheider und Firmen.

Das denke ich ganz besonders. Also 10 Investitionsprogramme hätten nicht diesen Dienst für den Digitalisierungsschub leisten können, den wir jetzt durch die Pandemie in den letzten Wochen und Monaten erleben. Da gibt es ja ganz vielschichtige Entwicklungen. Also fangen wir vielleicht mal bei den klassischen Digitalisierungen der Unternehmensprozesse an. Das hat ja vorher schon begonnen, hat aber durch Corona natürlich einen riesigen Schub bekommen, also das man, ich sag mal mal ganz kleine Beispiele sind, dass man bei Ärzten nicht einfach vorbeigeht, sondern Termin auf der Webseite über so ein Tool abstimmt oder auch anruft und sagt: „Vielleicht bin ich infiziert, ich möchte mich nicht zu Ihnen ins Wartezimmer setzen.“

Wie mache ich das? Das ist natürlich ein digitaler Prozess. Restaurants haben angefangen, diese Listen zu führen mit den Leuten, die am Tisch essen. Manche machen das so ganz analog auf Papier. Das sind explizit die nicht digitalen. Aber ich weiß nicht, hattest du es auch schon mal, dass es mit App geregelt ist?

Bei den Ärzten?

Nee, beim Restaurant.

Ne, hab ich noch nie erlebt.

Ich hatte das jetzt vor zwei Wochen. Du hast dann am Tisch einfach einen QR-Code, den scannst du und wenn dich das System kennt, wars das schon. Ansonsten hinterlässt du deine Kontaktdaten, sodass das Gesundheitsamt dich im Falle einer Infizierung kontaktieren kann. Ich glaube der Restaurantbetreiber, also vielleicht der Chef. Sonst hat auch niemand Zugriff auf die Daten und du hast keine herumliegenden Papierbögen. Niemand muss den Stift anfassen, sondern kann das einfach in zwei Sekunden mit seinem eigenen Smartphone erledigen. Und das ist ziemlich komfortabel.

Ich weiß, dass es solche Apps gibt in diesem QR-Code, aber ich habe echten keinen erlebt. Ich weiß auch nicht, wie das mit dem Datenschutz ist. Datenschutz hier, datenschutz-grundverordnung und überall. Entscheidend ist ja, wie mit den Daten umgegangen wird.

Also der Anbieter zum Beispiel Radicova. Punkt App ist einer davon. Die App ist hier in Köln entwickelt worden. Oder diese Lösung Softwarelösung ist hier in Köln entwickelt worden. Und da geht es halt wirklich so, dass die Daten gespeichert werden in Deutschland und nach 14 Tagen automatisch gelöscht. Es sei denn, jemand meldet sich und sagt Oh, er hat jemanden, der es positiv getestet hat zu dem und dem Zeitpunkt, in dem man dem Restaurant gegessen. Wir sollten die anderen Gäste informieren.

Und dann? Ich weiß gar nicht, wie der Prozess dann läuft, nämlich an das Gesundheitsamt, dann die Leute entsprechend anrufen kann. Ich bin gottseidank noch nicht angerufen worden, deshalb weiß ich es nicht. Aber ich nehme es mal an Die Coruña App selber ist natürlich auch eine digitale Lösung für das Problem, Infektionsraten zu unterbrechen. Dass man möglichst frühzeitig selber in Kenntnis gesetzt wird, wenn man mit Risiko Personen Kontakt hatte, um sich dann selbst zu isolieren und entsprechend haben mit dem Arzt zu sprechen oder dem Gesundheitsamt zu sprechen, um die weiteren Schritte dann gehen.

Aber wie funktioniert das genau? Denn ich mache mir ja nicht mit wenig Grund. Wir haben einen Kontakt gehabt, der infiziert ist. Es gibt einen Scola, und zwar ist es z.B. so Wenn du die App misst. Ja, also sammelt ja diese Nummern ein, die von den anderen Handys in deiner Umgebung ausgesendet werden, per Bluetooth Low Energy profil aus einer Reichweite von etwa 100 Metern hat und merkt sich einfach die Nummern, die in deiner Umgebung gesendet wurden, und die Entfernungen, die quasi die Signal Dämpfung wird, in eine Entfernung umgerechnet.

Und dann weiß ich, wie lange die Nummer in welcher Entfernung zu mir war. Und wenn jetzt jemand positiv getestet wird und sich freiwillig dazu entschließt, seine Nummer hochzuladen? Alle Corona Apps, die draußen installiert sind, ziehen einmal am Tag diese Liste runter. Von den positiven Nummern gucken sie in der eigenen Historie nach. Habe ich jemanden, habe ich eine dieser Nummern bei mir selber eine Historie. Und wenn das der Fall ist, wird ein Score berechnet. Es könnte ja sein, dass du nur eine Minute in der Straßenbahn drei Meter von jemandem weg gestanden hast, der positiv getestet wurde.

Dann hast weiterhin ein niedriges Risiko. Aber du hattest ein Risiko Kontakt. Erst wenn du dich länger mit einer Person in großer Nähe aufgehalten hast, die nachweislich positiv ist, dann bekommst du auch eine erhöhte risikowahrnehmung sogar per Puschel kation und kann sich dann entsprechend selbst isolieren und. Lokales Gesundheitsamt anrufen, um zu klären, wie die nächsten Schritte sind? Das ist ein digitalisierter Prozess, der am Anfang ja sehr, sehr mühselig händisch durchgeführt wurde. Also Leute, die positiv getestet wurden, mussten händisch eine Liste abgeben, mit welchen Personen sie in den letzten zwei Wochen Kontakt hatten mit Kontaktdaten.

Und dann ist das Gesundheitsamt quasi durchgegangen, manuell und hat jeden Einzelnen informiert. Wenn man jetzt gesagt hat, ich war im Fußballstadion, dann hatte man nicht die besten Karten erwischen, würde ich sagen, ich bin ganz erstaunt. Ganz, ganz viele Unternehmen, also große Unternehmen, Taxiunternehmen, können natürlich auch ihre Aktionärsversammlungen online ein ONLINE Events abhalten, wo die Leute dann per Videoschaltung zugeschaltet sind, damit sich niemand infiziert. Die Unternehmen haben ja schon sehr schnell geschaltet und eben online Events durchgeführt statt offline Events durchgeführt.

Bei sehr folgenreichen Ereignissen. Also eine Aktionärsversammlungen ist ja jetzt nichts, wo man sagt Okay, das probieren wir mal aus, sondern da muss ich mir schon relativ sicher sein, dass das auch alles klappt.

Ja, aber grundsätzlich. Dass es überhaupt solche Massenveranstaltungen online stattfinden oder stattfinden können, das finde ich gigantisch. Ich habe auf jeden Fall einen Kollegen, der arbeitet in Hamburg und pendelt immer hin und her. Ich muss freitags einmal im Monat einmal dahin kriegen, wo man da nur beschallt wird ohne konstruktiv. Man kann jetzt ein Workshop oder so was rauskommt. Man sieht da vorne, erzählt einer. Sehen wir mal, warum muss einer dafür nach Hamburg fliegen? Thema Zeitverschwendung.

Produktivität, Klimaschutz. Und das multipliziert mal Millionen von Menschen, die permanent reisen müssen, um einfach an so einem Ding teilzunehmen. Warum nicht online und so blöd? Corona ist mit seinen Folgen. Aber die Digitalisierung hat einen echten Dienst.

Genau. Also ich glaube auch. Thema Geschäftsreisen. Das wird hinterher deutlich anders gehandhabt, als das vor der Coruña Krise durchgeführt wurde. Genau diese Reisen, die du jetzt beschreibst. Man lernt heute, es geht mit einer Videoschaltung. Man lernt, wie viel mehr Lebensqualität man dadurch hat. Die Reiserei wird weniger, und die Umweltbilanz ist natürlich auch besser. Gerade für solche Informationsveranstaltungen ist das eigentlich auch okay. Also ich sage nach wie vor Bei so einer Messe oder Wenn es wirklich intensiven Kundenkontakt, Verhandlungen oder so geht, ist, glaube ich, eine Videokonferenz, kein optimales Medium.

Das geht immer noch besser in Person. Allerdings Wenn man gezwungen ist, ist es auch okay und durchaus auch eine Alternative, die man in Betracht ziehen kann. Was mir aufgefallen ist. Es gibt ja schon Prozesse, die waren früher sehr analog, sind jetzt digital, und das beschleunigt sich immens. z.B. als es losging mit diesen Autos. Herring Anbietern Kartograf muss sich regelmäßig in so eine. Ich glaube es war eine Europcar Filiale und mein Führerschein vorzeigen, dass ich den noch hab, dass meine Kunath gültig blieb.

Und heute kann ein Foto machen und dann validieren. Die das direkt online innerhalb von fünf Minuten. Oder als ich meine ersten, mein erstes Konto bei einer Direktbank eröffnet habe. Ich glaube, da war ich noch Student, da musste ich mit dem Post den Verfahren zur Post laufen, mich da ausweisen, anstellen. Heute geht das alles per Videochat. Wahnsinn! Samstagabend, 10 Uhr Ganz Ihr Konto eröffnen. Und auch für die Post ist diese Entkopplung sehr gut, weil Sie nicht auf das Filialnetz angewiesen ist, um dieses Post all den Verfahren durchzuführen.

Ob der Geschwindigkeit. Ich hatte mal bei der. Bei der Deutschen Post AG war die zwei Wochen gedauert und noch eine PIN und nochmal Post und nochmal drei Mal hier mein Konto aufgemacht haben. Zwei Wochen gedauert. Das ist heute.

Wenn du ein Aktiendepot öffnest, ist das teilweise immer noch so, dass man 3/4 Pints zugeschickt bekommt. Aber man muss zu keiner Bank oder Postfiliale mehr, um dieses Depot zu eröffnen. Dass dieser erste Schritt entfällt, auf jeden Fall also ein bisschen viel beschäftigt. Ich sehe das immer, wenn ich einkaufe online oder so zu nachtschlafender Zeit, dann kann ich das besser so abbilden, als bin ich jetzt wirklich mich an die Ladenöffnungszeiten halten müsste. Also für Unternehmen, glaube ich, kann es nicht schnell genug gehen, Ihre Fach Anwendungen auf IT-Lösungen umzustellen.

Jedes Unternehmen, wo jetzt noch wirklich physikalische Akten gewälzt werden müssen, die kann man digital schlecht weiterreichen. Das muss an denen. Dann muss das an den. Da muss es an denen man muss es an den Regelkreise. Die sollte man schnellstmöglich digitalisieren. Und ich bin auch dafür, dass man das mit Web Technologien umsetzt, gerade in öffentlichen Bereichen oder staatlichen Bereichen. Weil dadurch schafft man eine ganze Reihe von Vorteilen. Man ist nicht mehr abhängig von bestimmten Betriebssystem Herstellern.

Man kann es. Auf dem Tablet, auf dem Smartphone und welches Gerät auch immer da kommen möge, man kann ziemlich sicher sagen, dass es ein Browser haben wird. Ja, man ist halt auch als Unternehmens ein Stück weit Pandemie. Wenn alle von zu Hause arbeiten können. Viele Unternehmen haben damit schon begonnen. Das wird natürlich jetzt beschleunigt. Prozesse wie zu Reisekosten Abrechnung, die ja zurzeit sowieso sehr wenig durchgeführt werden. Wahrscheinlich, diese Prozesse ebenfalls digital abzubilden und Rechnungsstellung und so weiter, damit man da auch wenig echte Hände dran hat an einem Prozess.

Ich habe gesehen, es gibt für viele Bereiche. Gibt es, so OpenSource, Lösungen zur Rechnungsstellung und so weiter. Da muss halt jedes Unternehmen sehen, ob da eine Lösung bereits schon existiert für die eigenen Anforderungen oder ob man da vielleicht noch etwas Eigenes entwickeln muss. Termine bei der Stadt bekommst du digital, zumindest in Großstädten. Ich hab ein Ziel formuliert, was Unternehmen anstreben sollten. Ich denke, es liegt in der Verantwortung der IT Entscheider und wir halten es sehr genau so, dass ein Arbeitsplatz eines Kopfarbeit Mitarbeiters muss im Grunde überall funktionieren.

Das muss das Ziel sein, egal ob derjenige im Büro sitzt oder zu Hause oder sonst wo. Wenn er ein Laptop hat, ein Diensthandy, ein gutes Headset, dann muss dieser Mensch eigentlich arbeiten können. Dann hab ich das geschafft. Und Diensthandy und Laptop gehört bei Kopfarbeit dann zur Grundausstattung, so wie ein Dienstwagen bei Aussendienst Mitarbeitern. Zusätzlich muss man das System schon anklingen lassen nach dieser Corona Pandemie niemandem mehr erklären, warum man vor allem kein Politiker mehr, warum man eine schnelle Internetverbindung benötigt.

Es ist ein bisschen Infrastruktur, ob man das überhaupt kriegt. Selbst in größeren Städten ist es nicht selbstverständlich, ist eine schnelle Internetleitung sprechen. Wir haben Glück, weil da 100 Mbit gehen, ist auch schon Ende der Fahnenstange. Mehr wäre mir lieber. Wir haben jetzt unsere abblockt Geschwindigkeiten, obwohl ich das Maximale steigern können. Aber es gibt Pfarrbüro so weiter. Ich mache mir keine Abstossen mehr. Das ist alles so klein bemessen. Die Infrastruktur ist einfach nicht da.

Man muss ja sagen, es ist ein Neubaugebiet. Man hätte ja direkt in Glasfaser Anschluss in den Keller legen. Jetzt wird das in drei Jahren aufgerissen und nochmal reingelegt. Wahrscheinlich ne Dama. Auf jeden Fall Glück, aber ja, jedes Bürogebäude sowieso. Aber ich denke auch Jedes Wohngebäude braucht einen Internet-Anschluss, schnellen Internetanschluss wie ein Wasser und ein Stromanschluss direkt mit dazulegen. Ob jetzt jeder Haushalt heute schon Glasfaser haben muss, weiß ich nicht. Ich sage mal, wenn ein Verteilerkasten auf der Straße ist, Thema per Glasfaser erschlossen hat und dann die Leute die letzten 100 Meter per dsl-modem zurücklegen okey.

Na, weil die letzten Meter also jedes Haus einzeln anzuschließen, das ist ja das Teure. Aber im Grunde, wenn ich eine Straße neubau, müsste ich jedem zumindest ein Leerrohre an jedes Haus legen und was auch immer die Technologie bringt. Und es scheint ja nach Glasfaser auszusehen. Da Grundversorgung schaffen wird in Großstädten. In Köln wird es auch so gemacht, dass viele Häuser haben bis im Keller Glasfaser. Und dann wird es dann im Haus nochmal über die letzten 30 Meter klingelt Raad per VDSL verteilt oder per Fernsehkabel.

Und wenn man zu Hause schnelles Internet hat oder im Büro schnelles Internet hat, dann lassen sich auch so manche Funk Lücken mittels WiFi Cooling dann umschiffen. Aber klar, das ist. Ich sage mal, wir sind da ziemlich verwöhnt. Als Firma ist uns das natürlich klar, dass wir irgendwo hingehen können, wo kein schneller Internet-Anschluss ist. Es gehört ja zu unserer grunt Arbeit. Aber klar Unternehmen, die ihren Sitz 50 Jahre irgendwo bereits festgelegt haben und vielleicht große Industrie Maschinen dort stehen haben, die sind darauf angewiesen, angeschlossen zu werden.

Wie siehst du denn das Thema Remote Arbeit?

Wir haben einen persönlichen Bezug zum sehr starken Bezug zu. Ich bin früher viel Runden gefahren, habe wirklich stundenlang im Auto gesessen und Zygmunt in Flugzeugen quasi überall Berlin-Hamburg bearbeiten. Und man verbrennt einfach produktive Zeit. Abgesehen von der produktiven Zeit mache ich das persönlich auch, raubt die Energie allein schon die Koffer packen und morgens aufstehen, da hinfahren und muss früh aufstehen, damit du im Prinzip in den Krieg ziehen. Das heißt, du kommst da an und bist im Prinzip schon äsche.

Und diese Hin und her Reiserei einfach mit. Das ist für einen Kunden schlecht, das ist für mich schlecht. Ich bin halt nicht hundertprozentig produktiv und kann nicht das geben, was sie geben können. Natürlich kann ich dann auch sagen So bleibt da einfach Ort, die ganze Zeit. Aber dann bin ich weg und zu Hause von der Familie, was andere Auswirkungen hat. Und man? Oft umsonst Ja, ich hatte einen Kunden in einer deutschen Großstadt gestanden hat, als ich dann komme, und hat mir auf der anderen Seite zum Beispiel mich den Arbeitsplatz zur Verfügung gestellt.

Ich bin da eine Stunde oder zwei rum laufen, um ihren Arbeitsplatz zu suchen, der jetzt gerade nicht belegt, reserviert oder sonst was. Am Ende habe ich mich dann anderen an einen Tisch gesetzt, der eigentlich ein Konferenztisch ist, und hab mir damit meine Kabel zurecht gesucht und geguckt, wo ich eine Steckdose findet. Da war ich nach zwei Stunden einsatzbereit. Ich muss das sein. Was soll dieses Gesicht, diese Präsenz haben wollen, wenn das auch nicht ausgenutzt wird?

Einfach nur da sitzen, sieben, acht Stunden zu machen und dann wieder zurückzufahren. Und dann bist du vier Stunden gefahren, und es macht einfach keinen Sinn. Da bin ich beim Büro um acht Uhr startklar, als man sich natürlich absprechen muss. Bei mir ging auch sinnvoll Meetings und Kommunikation. Alles schön und gut. Aber gerade im Büro kannst du das über moderne Kommunikationsmittel tun. Kannst du das supergut abwickeln? Müssen wir durch Deutschland reisen? Permanent.

Ich glaube, als ein Entscheider muss man eine ganz große Wende vollziehen mentaler Natur, und zwar muss man. Statt Kontrolle der Anwesenheit muss man die Arbeitsleistung in den Fokus stellen. Und das bringt natürlich Veränderungen mit sich und hier und da auch unangenehme Veränderungen. Aber man muss im Grunde oder so ist es meine Meinung, muss man sagen Okay, also die Person etwas abschätzen lassen. Und dann muss die Person auch ein Stück weit dafür geradestehen, dass sie das schafft in dem Zeitrahmen.

Alles dauert mal irgendwie länger oder so. Das ist auch kein Problem, wenn das mal vorkommt. Aber dass man einfach wirklich an diese Arbeitsleistung einfordert und nicht nur jemanden, der da sitzt, was du beschrieben hast, das ist wurde mir mal von jemandem als typisch deutsche präsenzkultur bezeichnet. Diese Person kannte das gar nicht erst in Deutschland, bemerkt, dass es so etwas gibt, dass man da vor Ort sitzen muss, einfach, dass man wie in so einer Industrie Produktionshalle man weiß, er ist da er arbeitet.

Ich denke aber, wenn ich mich als Entscheider dieser Herausforderung stelle und sagt Okay, ich bewerte die Arbeitsleistung statt der Anwesenheit, kann also auch auf die Anwesenheit verzichten. Dann erweitere ich natürlich ganz immens mein Talent Pool, auf den ich zugreifen kann. Dann ist nämlich auf einmal nur noch die Zeitzone wichtig oder einigermaßen wichtig statt der geografischen Nähe. Das wiederum ermöglicht mir, entweder die passgenauen Spezialisten zu finden, weil ich im Grunde den ganzen Kontinent als Arbeitskraft Markt nutzen kann.

Und für STANDARD aufgaben, oder so ermöglicht es auch Einsparungen, vielleicht durch Nier sharing, nicht ganz offshoring, dass man sagen kann Okay, die Person finde ich in einem anderen Land mit einem niedrigeren Lohnniveau finde ich die eher, und das kann ich dann sehr günstig abbilden oder auch Mitarbeiter halten, die umziehen. Ein Kunde von mir Da ist ein Mitarbeiter umgezogen, weil er eine Atemwegserkrankung hat und deshalb in den Süden gezogen ist. Weil das wärmere Klima sehr vorteilhaft ist, um den Verlauf dieser Atemwegserkrankung abzumildern, und weil der Mitarbeiter jetzt schon jahrelang dort gearbeitet hatte, war das okay, dass er remote gearbeitet hat.

Und er war in einigen Sprints der produktivste Mitarbeiter.

Ich habe von vielen Freunden Bekannten hier im Home arbeiten. Gehört Sie tatsächlich länger arbeiten? Ich meine, ist doch klar Wenn du zuhause bist, kannst du früher an, und meistens arbeitest du tatsächlich länger, weil als Beispiel Ich bin eine Zeitlang nach Düsseldorf gefahren. Da war ich, nachdem man sich mit einer Stunde und zwei Stunden unterwegs. Das heißt, ich war irgendwann um zehn Uhr da und hat sich dann gearbeitet. Dann hab ich um alles angefangen. Ich habe schon zwei Stunden gearbeitet, bevor ich da war, präsent gewesen, um zehn, und so habe ich um 9 Uhr angefangen, und meistens reicht dann da so um fünf, dann wieder los und zurück oder sechs, je nachdem.

Und dann bin ich um sieben Uhr zu Hause, und im Büro bin ich ja mal locker drei Stunden mehr gearbeitet und so fest angestellten Genau, weil du hast, wenn du zuhause sitzt, hast.

Du kommt jetzt auf die Familiensituation an, aber hast du nicht so ein Zwang, die Bahn zu bekommen, die um 17 Uhr 30 fährt? Punkt. Da musst du egal was aufstehen und gehen und die bekommen, weil sonst eine Stunde länger da, und im Homeoffice musst du halt kommen. Das mache ich noch. Oder jetzt? Die zwei E-Mails beantworte ich noch, und dann gehe ich in Feierabend. Dann hab ich das von der Platte und kann morgen frisch starten.

Bei mir ist es auch so, dass ich gerne Dinge abschließe, dass ich morgens nicht mehr auf der Platte habe. Und klar. Einen harten Anschlag habe und raus muss, weil die Bahn weg ist oder ein katastrophaler Stau auf der Autobahn sich entwickelt, dann habe ich die Möglichkeit nicht. Das ist noch mal was ganz anderes, was das an mehr Lebensqualität bedeutet, das natürlich auch Mitarbeitermotivation steigert. Und jetzt kommen wir also da. Das ist aber jetzt ein Fass ohne Boden.

Bermann Grimaud Arbeit oder Homeoffice oder mobil auf, wie man es auch bezeichnen möchte? Konsequent weiterdenkt, dann hilft das natürlich dem Unternehmen, auch im Büro Kosten zu sparen. Meine Mitarbeiter brauchen Laptop und ein gutes Headset, und einen externen Monitor setze ich jetzt auch einmal voraus, weil das einfach das Arbeiten viel angenehmer macht. Dann bist du für drei vier null null null Euro. Hast du den eingerichteten Arbeitsplatz per du mir vorstellen, dass das an Miete für ein Büro Arbeitsplatz in wenigen Monaten anfällt?

China statt. Und das ist natürlich schon eine Möglichkeit, auch Leute, die auf dem Land wohnen, nicht zwingen zu müssen, dass die herkommen. Also man erweitert einfach sein Talent Pool. Ob das jetzt innerhalb des eigenen Landes ist oder sogar über die Grenzen hinaus. Ich glaube, das ist aber für ein Fuhrunternehmen ganz, ganz wichtiger Punkt, auch wenn man die demografische Entwicklung anschaut und die Verrentung der Babyboomer, die jetzt in den nächsten zehn Jahren ansteht, vor allen Dingen auch die Infrastruktur, Verkehrsinfrastruktur, Städte gibt nicht mehr.

Das ist sehr schmerzhaft. Also ich denke mal, dass wir beide sowohl die Mitarbeiter als auch die Firma Bildungssituation.

Ich meine wir im Beratungsgeschäft, das muss man sagen, bei Grimaud Arbeit auch kein Hexenwerk, oder? Wir waren das schon gewöhnt drauf. Deshalb hatten wir auch alle Werkzeuge parat und Farner im Grunde innerhalb von einem Wochenende einsatzbereit und konnten einfach weiterarbeiten. Zusätzlich hatten wir das Glück, die tolle Internet-Infrastruktur zu haben. Zuhause wie auch im Büro. Da hat man keine Probleme. Aber ich merke es jetzt auch in Besprechungen mit Kollegen, dass es oftmals je nachdem, wo sie wohnen, welchem Bundesland oder wie weit von der Großstadt entfernt, das durchaus noch ein Thema ist.

Oder ab einen Kollegen im Projekt, der zum Dayli morgen Meeting per Telefon zugeschaltet ist und immer einen Spaziergang macht nach draußen, damit er mit dem Empfang klappt. Das ist die, die Entscheider oder Unternehmens perspektiven. Was hat sich durch die Corona? Pandemie Was ändert sich an Möglichkeiten? Ich habe mein Unternehmen nach vorne zu bringen oder Prozesse zu digitalisieren. Die Fachkräfte sparen natürlich Anfahrtsweg. Zeit und viele Stunden auf der Autobahn oder im Zug haben natürlich auch was davon.

Zu den Voraussetzungen haben wir schon gesprochen. Ich wiederhole sie einfach nochmal Man braucht ein ordentliches Laptop oder ordentlichen Laptop. Externen Bildschirm würde ich empfehlen. Gutes Headset. Allein schon, damit man seinen Kollegen verständlich, ja verständlich sie hört und b verständlich auch spricht. Ich würde auch einen guten Stuhl und einen guten Schreibtisch empfehlen. Und jetzt kommen wir wieder zur Firma Instabiles VPN, die die Firmen nicht spart bei der VPN Verbindung, weil es. Wenn das zusammenbricht, kann niemand mehr arbeiten.

Und dann muss man sich Produktivitäts mäßig vorstellen, wie wenn man den Feueralarm ausruft. Dann kann nämlich niemand mehr irgendwas machen. Mir ist es wichtig, dass VPN gut eingerichtet ist. Die Zusammenarbeit, die virtuelle Zusammenarbeit der IT-Fachkräfte, erfordert natürlich neue Werkzeuge. Ich habe ein paar Favourite und ein paar überhaupt keine favourite. Ich denke im Grunde, man braucht ein Stuhl. Also wir benutzen intern Slack. Viele Unternehmen benutzen Teams, da gibt es aber Rocket hab ich auch schon gesehen, da gibt es aber keinen.

Die Anbieter sehen das natürlich anders. Ich sage jetzt mal Generell gibt es nicht so große Unterschiede, als dass man da sagt, dass eines besser ist als andere, sondern die Vorteile liegen im Detail. Aber man braucht so eine Art Chat. Würde ich schon sagen, einfach um Dateien zu tauschen. Kurz zu sagen Hast du Zeit, darüber zu sprechen und so weiter. Video Kaltz ist ein ganz zentrales Thema. Dadurch, dass keine Raum Buchungen mehr notwendig sind, sind natürlich alle immer sofort verfügbar.

Und die Meetings? Das ist mir jetzt aufgefallen. Die starten dann auch um Punkt 10 Uhr oder um Punkt, wenn der Termin angesetzt ist, weil jeder schon am Platz sitzt. Ich bin beliebig groß sein, weil man eben keinen Raum mehr braucht. Auf der einen Seite ist der Video cool. Finde ich gar nicht so entscheidend, weil bei vielen, gerade wenn man auch Leute hat, ihn nicht zu Internet ausgebauten. Regionen kann man das ja auch viel per Audio machen.

Aber den Bildschirm zu teilen, das ist super praktisch. Das ist einmal super praktisch, wenn man was präsentieren möchte. Und wenn IT-Fachkräfte zusammenarbeiten. Entwickler ist es natürlich auch super praktisch, wenn man etwas nachvollziehen will. Das ist das Virtuelle. Ich gehe mal zum Büro Kollegen, und der zeigt mir was an seinem Rechner. Das benutze ich zum Beispiel, oder? In unserem Team benutzen wir das super häufig, um uns abzustimmen oder einfach Probleme gegenseitig zu zeigen und sagen.

Das Problem Wie würdest du das lösen? Sharing ist absolut wichtig. Dann benutze ich mehr grafische Tools, habe ich festgestellt. Ich weiß nicht, wie es bei dir ist. Mit grafischen durch grafische Tools sind meine Tools, um Dinge zu visualisieren.

Also ganz klassisch, wer das Microsoft Video ich benutze. Oh, das ist so eine Webanwendung, da kannst du halt zusammen Skizzen, Grafiken, Diagramme visualisieren. Wenn du darüber sprichst, so per Telefon oder per Chat, dann ist das einfach besser. Wenn du so eine gemeinsame Grundlage hast, ganz hier, wie du einem Architektur Diagramm in Schritt 4 erkennen kannst, sind die Daten Flüsse. So und so, im normalen Gespräch kannst du das ja zeigen. Eine Tafel was zeigen, aber digital musst du das irgendwie abstrahieren.

Und da mache ich sozusagen ein Doppelschlag. Ich mache eine Skizze und zeige, wie die Daten Flüsse sind oder wie die Architektur ist, spreche darüber. Durch die Rückmeldung verbessert ich das und hab dann hinterher gleichzeitig direkt eine Dokumentation, die ich dann im Code ablegen kann oder als Grafik ablegen kann. Grundlage Offline kennt man das. Wenn man an Tafel irgendwas gezeichnet hat, macht man hinterher ein Foto, bevor man es weggewischt. Und hier würde man dann eben mit dem Diagramm Tool die Datei Narvik speichern.

Ja, dann nutze ich persönlich. Finde ich jetzt für mich Architekturgeschichte, mache ich Lusitania. Aber wenn ich zum Beispiel Dinge tue und so weiter, wenn man arbeitet, ist gemeint, dass man mehr visualisiert und sich so als gemeinsames Miró irgendwo mal kannst du gut, mal mit der Maus, mal wie ich dir nur recht umzuformen, mal nicht wirklich. Ich halte diese plotter Diagramme, Komponenten.

Ein Teammitglied aus dem aktuellen Projekt hat sogar ein Tablet und zeichnet dann ja. Den Unterschied sieht man dessen Unterschied wie Tag und Nacht. Also meine @-zeichen Fähigkeiten sind schon nicht so toll, und wenn ich das mit der Maus noch versuche zu illustrieren. Oh mein Gott, ja, dann wirds finster. Aber mit so einem am Tablet oder zeichnend Tablett ist man dann natürlich nochmal anders aufgestellt. Ich glaube es gibt auch so Windows Tablets, da kannste quasi die Tastatur so nach hinten umklappen und der Bildschirm ist ein Touchscreen plus.

Du kannst halt mit dem Stift drauf zeichnen. Das wäre dann auch eine sinnvolle Sache, dass man mit diesem Gerät.

Ich nutze es gerade bin ich erklär Videos, nutze ich mein eigenes Pro mit dem Stift? Da gibts halt eine Screen. Dann zeichnet sich ab, und das kann ich dann nutzen. Oder auch gibt es zum Beispiel Whiteboard, Funktionalität in bestimmten Tools wie Zoom und so weiter. Was ich dann auch spiegeln kann und meinem Malen kann dann übertragen.

Aber das ist ja genau dieses Grafische, das eigentlich nur noch so eine. Das gehört heute bei weitem nicht zum STANDARD. Aber vielleicht setzt sich da auch ein günstiges Tablet durch. Die Tablets sind eher für Profis gedacht, die wirklich gestalterisch am Rechner arbeiten. Also an Creative? Ja, das wäre eine Sache, das man entweder mit einem Pen auf dem Touchscreen malen kann oder ein günstiges Gerät bekommt, was wie ein Tablet funktioniert, auf dem man zeichnen kann. Das wird das bestimmt noch steigern.

Dann hab ich gemerkt, dass ich mehr dokumentiere in Tickets oder in Konferenz. Also einfach, damit das durchsuchbar ist, damit ich links generieren kann, die ich dann rum schicken kann, um einfach zu sagen OK. Wie findest du das? Hab ich was vergessen? Request Vorkommens? Das ist auf jeden Fall ein Punkt. Ich denke auch positiver ist, weil wenn du weißt es auch. Wenn man Dokumentation geschrieben hat, ist die durchsuchbar und wird dann auch sehr lange noch genutzt werden.

Ansonsten Als IT-Fachkräfte hat man oft mit Code zu tun, gibt und Börsenneuling. Da würde ich fast sagen Das macht keinen Unterschied mehr, ob man lokal in der Firma nebeneinander sitzt oder remote arbeitet. Also ist mein Code. Allein schon was Backup begründen, dass man sich Requests schickt aus control gründen, dass der andere nochmal drüber guckt, ob die Qualität stimmt. Das macht man im Grunde genauso wie vorher. Ich habe es eben schon angesprochen. Das Queen’s Sharing hilft da vielleicht, Unklarheiten zu besprechen.

Dann nimmt man das so als zusätzliches Werkzeug dazu und sagt Hier hab ich, habe ich eine Frage oder so kannst mir das mal erklären. Das macht man beim Screen Sharing. Es ist ganz interessant. Momentan arbeite ich auch in einem Projektteam. Da sind zwei Mitarbeiter, die haben die Firma. Vor drei Monaten und zwei Monaten sind Sie eingestellt worden. Wir arbeiten zusammen seit einiger Zeit. Das klappt doch super. Aber ich habe sie noch nie persönlich gesehen. Der eine säße normalerweise neben mir, war aber bisher nur einmal im Unternehmen.

Am ersten Tag an der wahren Ausgabe die waren Ausgabe, um sein Notebook abzuholen und. Zu sein Homeoffice Kid. Und ja, das ist eine tolle Sache, dass ich noch nie gesehen habe. Aber dass das einfach möglich ist, dennoch produktiv zusammenzuarbeiten, das halte ich für eine tolle Sache. Jetzt stell dir mal vor, diese Pandemie wäre vor zehn oder 15 Jahren ausgebrochen. DSL gab es gerade, aber fünf Prozent der Menschen in Deutschland hatten einen DSL-Anschluss, und der kostete dreimal so viel.

Und die PCs zuhause waren auch noch Fenster. Und es gab noch nicht diese ganzen Web, Chat, Videochat, Lösungen. Das wäre der Ausfall noch viel größer gewesen. Und heute ist es ja schon so, dass viele. Ich sage mal die breite Masse der Menschen viele ONLINE Services nutzt und das nichts Großes, Neues mehr ist.

Ja, das sagt man immer, dass man grundsätzlich Online-Services nutzt und nichts mehr Neues in diesem Sinne ist. Wir reden von der IT-Welt. Ja, genau, die Prozesse gerade. Was ich mag, diese ganzen Collaboration Tools wie z.B. keine Ahnung. Bei Google arbeite ich ja mit diesen Uka, wie man unternehmen viele Objektive Query Salz sollte man vielleicht. Und da gibt es halt tun, wo man mit mehreren hundert Mitarbeitern an solchen Systemen arbeiten kann. Immer mehr Prozesse und gerade was die Kollaboration zwischen Menschen angeht, wird ins Internet verlagert.

Warum? Weil auch Team werden immer internationaler, und es geht auch schneller. Du kannst jederzeit Dinge regeln.

Es gibt Jobbörsen oder Project Börsenboom Nori mot Projekte eingestellt werden. Das zeigt schon, dass sich die Arbeitswelt flexibilisiert, Unternehmen darauf eingestellt werden oder sich darauf einstellen müssen und auch neue Lebensentwürfe möglich werden. Ich könnte im Ausland sitzen. Ich könnte in einer spärlich besiedelten Region, die aber eine gute Internetanbindung hat. Die gibt es tatsächlich, die Vulkaneifel. Da gibt es einige Dörfer, die da erstaunlich gut wegkommen. Zum Beispiel, denen völlig klar ist Wenn wir hier eine Chance haben wollen, dann müssen wir schnelles Internet bieten.

Wie sollen die Leute sonst arbeiten? Weil sie wollen nicht jeden Tag anderthalb Stunden ins Büro fahren und wieder zurück. Oder die wenigsten wollen das, weil es auch ökologischer Schwachsinn ist und man binnen kurzer Zeit in vier, fünf Jahren fährt man ein Auto durch ein neues und dann wieder ab, dann wieder. Das geht auch effizienter. Natürlich haben wir viele positive Aspekte beleuchtet. Was wären zum Beispiel negative Aspekte?

Naja, dass man dann auch alleine da sitzt und keinen menschlichen Kontakt hat, sondern was ja auch im Team oder in Unternehmen wichtig sein kann. Neben der Produktivitätssteigerung auf der einen Seite den positiven Effekten auch die züchte, dass man nicht mehr gestresst durch und so hat es natürlich auch einen negativen Impact Kollegen Anschluss an sich verliert, wenn es nicht persönlich. Es wird auch total austauschbar. Ja, genau. Aber ich sage ganz klar, dass das für mich täglich auch wie so oft im Leben eine Art von Extremismus ist, meistens nicht gesund.

Man wird hinterher nicht sagen Okay, wir bleiben alle im Homeoffice. Man wird ja nicht sagen Je huhu, alle wieder fünf Tage die Woche ins Büro. Sondern ich erwarte schon eine Flexibilisierung. Es gibt einfach zum Beispiel bei entwicklungsteams der Tag mit dem Sprint Review oder der Sprint Planung. Das ist ein Tag, das ist eigentlich ein Präsens. Tag, das kann man so sagen.

Oder auch Wenn irgendwelche Deployment anstehen oder kritische Phasen, wo was fertiggestellt werden muss, dann, denke ich, ist es besser, wenn man zusammensitzt und wie in so einem Control Room das Kind zur Welt bringt oder das System zur Welt bringt? Negativer Punkt ist natürlich auch dieser, diese ständige Verfügbarkeit, wobei da ein Stück weit selber jeder für sich verantwortlich ist, dass es da nicht einreißt, dann den Fokus zu halten, das private Zeit oder private Aufgaben nicht in die Arbeitszeit dann reinfallen.

Wobei das natürlich auch ein Gewinn sein kann. Zum Beispiel ist es bei mir häufig so, dass ich in der Mittagspause dann einkaufen gehe. Einfach um einen Break zu haben im Mentalen. Und dann kann ich mich wieder um die geschäftlichen Themen kümmern. Aber ich genieße das, wenn ich einfach mal 20, 30 Minuten unterwegs bin und was anderes im Kopf habe.

Wie gesagt, für mich sind die positiven Aspekte überwiegen, weil ich so durch diese Fahrerei und Reiserei gebrandmarkt bin. Das ist auch aktuell. Wenn ich Kunden aktiviere oder Ermittler, dann bestehe ich einfach noch mindestens drei Tage Nachbar mir gegenüber. Der sagt auch, der Arbeitgeber werde das einfordern, was passieren wird, weil viele Menschen gemerkt haben Es geht, es geht ja. Sie haben sich vorher das vielleicht nicht. Zu fragen und jetzt musste es passieren und jetzt sitzen sie seit drei Monaten im Homeoffice.

Die Kinder dürfen auch wieder zur Schule gehen. Ich glaube, das ist auch ein ganz wichtiger Punkt für viele Mitarbeiter, die kleine Kinder haben, oder Arbeitnehmer, die kleine Kinder haben. Und jetzt hat man sich auch zu Hause so sein Studio eingerichtet, sein Arbeitsplatz eingerichtet. Und diese Kinderkrankheiten am Anfang sind auch behoben worden. Das hoppla, die Hopp riesige Mengen an Arbeitnehmern ins Home-Office gegangen sind und die Firmen gar nicht darauf eingerichtet waren und erst mal Kapazitäten aufbauen mussten, damit sie genug Laptops haben.

Das VPN stabil ist die Internetverbindung der Firma. Wer die Daten noch liegen, stabil genug ist und groß genug ist? Ja, schon eine Herausforderung. Die Unternehmen, mit denen wir zusammenarbeiten, die haben natürlich eine große IT-Abteilung. Das heißt, sie sind da schon eher vorne mit dabei. Aber so einem Mittelständler kann ich mir schon vorstellen, dass das eine große Herausforderung war. Dann bedanke ich mich bei dir sehr gerne.

Wenn unsere Zuhörer Fragen haben oder Feedback. Dann können Sie uns gerne eine E-Mail senden an Podcast Gilbert. Wenn euch die Frage gefallen hat. Lasst gerne eine Bewertung oder ein Daumen hoch da und abonniert unseren Podcast. Und für weitere spannende Technologie Themen schaut auf skillbyte Slash Blog vorbei. Ich wünsche dir noch einen schönen Abend.

Maurice KnoppSkillbyte Podcast #26: So verändert Corona die IT-Welt!
Mehr

Skillbyte Podcast #22: Digitale Transformation ist eins der Härtesten

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

In diesem Podcast geht es um das Thema: Digitale Transformation ist eins der Härtesten

// Inhalt //
01:00 – Definition von digitaler Transformation
02:46 – „Sofortness“
03:28 – Daten, Konnektivität, Rechenleistung
05:28 – Digitaler Reifegrad eines Unternehmens
08:11 – Verschiebung: Kunden wollen Nutzen statt Produkt
09:55 – Vorhandene Prozesse digitalisieren und neue Digitalprozesse anbieten
14:20 – Digitale Transformation für den Mittelstand
16:43 – Digitale Chance: Konzentration auf Kundennutzen
17:13 – Herausforderungen der digitalen Transformation sind Chefsache
21:14 – Keine Angst vor neuer Technologie
25:27 – Wie kann Skillbyte bei den Herausforderungen unterstützen?
27:23 – Skillbyte hilft bei agiler Softwareentwicklung, CI/CD
29:30 – Skillbyte hilft bei DevOps, DevSecOps, Skalierung
35:04 – Skillbyte hilft bei Big Data, ETL, Dashboards, Reporting, Prediction
37:39 – Digitalisierung als Chance begreifen!

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 zur aktuellen Podcast Episode Nr. 22 Digitale Transformation ist eines der härtesten. Ich bin heute hier wieder mit unserem Stammgast. Masa Hallo Maria! Hi, wenn unsere Zuhörer Fragen haben, können Sie gerne eine E-Mail schicken. Podcast. Wenn euch unser Podcast gefällt, freuen wir uns über ein Abo oder über eine Bewertung. Vielen vielen Dank im Voraus. Heute wird es sehr, sehr spannend. Denn digitale Transformation ist natürlich ein Thema, was derzeit in aller Munde ist, also schon länger digitale Transformation.

Das ist der Oberbegriff, was in der deutschen Wirtschaft herumgeistert.

Genau. Und heute wollen wir darüber sprechen. Also wollen wir dieses buzzword ein bisschen herunterbrechen und auseinander nehmen und schauen. Warum ist das so ein großes Problem? Warum tun sich Unternehmen schwer damit? Was sind die Herausforderungen? Warum ist es überhaupt wichtig, dass sich Unternehmen damit beschäftigen? Ich glaube, es ist ganz, ganz wichtig. Ich denke, das können wir ganz gut herausstellen. Ich würde gerne beginnen mit einer Definition, die ich von der Wikipedia ausgeliehen haben und natürlich immer eine neutrale Quelle, einfach um nochmal das Framework einzuführen.

Worüber sprechen wir, wenn wir über digitale Transformation sprechen? Als die digitale Transformation wird auch als digitaler Wandel bezeichnet, bezeichnet einen fortlaufenden, in digitalen Technologien begründeten Veränderungsprozessen, der in wirtschaftlicher Hinsicht speziell Unternehmen betrifft. Im engeren Sinne wird als digitale Transformation häufig durch die digitalen Technologien oder darauf beruhenden Kunden Erwartungen ausgelöste Veränderungsprozess innerhalb eines Unternehmens bezeichnet. Also auch hier ganz zentral Die Unternehmen verändern sich, aber auch die Kunden. Erwartungen desto jünger, desto mehr, würde ich sagen, desto jünger die Kunden, desto stärker treiben die Kunden Erwartungen.

Die digitale Transformation voran.

Was mir an der Definition nicht gefällt, ist, dass von digitalen Technologien die Rede ist. Ja, natürlich. Digitale Transformation betrifft natürlich digitale Technologien. Aber meines Erachtens ist das viel mehr als das. In so einem Unternehmen gibt es Personen, wirkende Menschen, wirkende Personen. Es gibt Prozesse, und es gibt die Technologie und natürlich den Kunden. Das heißt, im Unternehmen müssen all diese drei Entitäten miteinander entsprechend harmonieren und interagieren, damit so eine Transformation überhaupt stattfinden kann.

Es ist nicht nur die reine Technologie, es ist nicht nur ein Tool, oder ich führe ein Technologie Prozess neu ein und schon bin ich dabei, sondern es betrifft viel, viel mehr.

Ich würde auch sagen, die digitale Transformation ist sehr, sehr stark, auch eine Meinzer Sache. Ein Freund von mir hat das so schön formuliert.

Er sagte Für mich ist die digitale Transformation, ganz vereinfacht ausgedrückt, die sofort eines die sofortige Verfügbarkeit von Informationen, sei es jetzt Entertainment oder Information.

Oder ich möchte einen Prozess anstoßen. Ich möchte meiner Versicherung ein Dokument hochladen. Ich möchte jetzt eine Antwort auf meine Frage. Ich möchte in meiner Reise buchen. Ich möchte jetzt dieses Lied hören. Ich möchte jetzt genau diesen Film schauen. Das Bedürfnis entsteht und kann sofort befriedigt werden. Das ist einer der Haupttreiber der digitalen Transformation.

Sehr, sehr Kulturbegriff. Sofort, wenn man vielleicht irgendwie so ein bisschen abstrakter, eine Ebene drüber zieht. Warum findet überhaupt eine digitale Transformation statt oder sollte oder was hat das in Gang gesetzt? Es ist in meinen Augen einmal die Menge der Daten, die zur Verfügung steht, über viele, viele verschiedene Channels hinweg, sei es jetzt Web, sei es mobil, sei es Booty, sei es über Kunden. Telefone im Call-Center da entstehen überall Daten. In einer sehr hohen Geschwindigkeit ist das eine, das andere ist die Konnektivität all dieser Komponenten und die massive.

Die dritte Komponente ist für mich die Massive Processing Power, die zur Verfügung steht, um all das auszuwerten, auszuwerten, um auf gewisse Dinge oder Marktgeschehen zu reagieren. Das heißt, diese Datensammelei stu, um abzuschalten. Was will der Markt? Wie hat der Markt auf diesem jedes reagiert? Bei mir, beim Konkurrenten darauf, schnell reagieren zu können, sei es von den Entscheidungsprozessen her, sei es von der Technologie, eher sei es von allgemeinen Prozessen, die in so einem Unternehmen laufen.

Diese drei so auszulegen, dass sie schnell reagieren kann. Das macht es für mich insgesamt aus. Was sind die drei Komponenten?

Nochmal sagen Sie nochmal nacheinander? Ja, die eine Komponente ist, dass Daten global zur Verfügung stehen über verschiedene Channels. Es werden sehr an sehr vielen Kontaktpunkte Daten generiert. Das zweite ist die Konnektivität, dass man viele dieser Channels miteinander verbinden kann, um so Korrelationen herzustellen. Die massive Rechenpower quasi auf haben wir zur Verfügung stehen. Damit erreiche ich im Saids mit diesen drei Komponenten oder generieren um mag es schnell mitzubekommen und darauf reagieren zu können. Um darauf reagieren zu können, muss ich natürlich den digitalen Wandel in meinem Unternehmen vollzogen haben.

Einmal nämlich meine Leute abgeholt haben. Geändert haben, die Prozesse umgestellt haben und natürlich die Technologie am Start haben.

Die drei Komponenten, die du benanntes, führen ja schon dazu zur Entwicklung gegebenenfalls neuer Geschäftsmodelle. Ich finde, es gibt es einen unterschiedlichen Reifegrad von digitalen Unternehmen, digital transformierten Unternehmen. Das kann man ganz gut erklären. Zum Beispiel? Nehmen wir mal ein Unternehmen wie die Bahn oder auch eine Airline. Und da sieht man okey, die gibt es seit vielen, vielen Jahren, und die digitalisieren sich. Angefangen, sich zu digitalisieren. OK. Man kann jetzt Tickets online kaufen.

Also früher bist du in den Shop gegangen, hast ein Ticket gekauft, heute kannst du die Tickets online kaufen. Das ist für mich der erste Schritt zur digitalen Transformation. Dass man einfach sagt, ein Prozess, den es bisher gibt, den verlagere ich ins Digitale, weil dann ist mein Ticketschalter 24 Stunden auf. Die Leute können das von jedem Fleck der Erde zu einem Ticketschalter kommen, müssen nicht anstehen und klicken sich quasi selber durch die Masken und bestellen ihr Ticket selber.

Das ist der erste Schritt, den ich sehe. Ein weiterer Schritt ist Wenn du wirklich aus diesen Daten, die ansprichst, selber wieder neue Geschäftsmodelle baust. Also wenn die Bahn zum Beispiel sagen würde Dein Zug fährt um viertel nach. Aber wir wissen, dass es um die Zeit immer so voll ist, immer fünf Minuten verspätet oder so was, dass Sie das quasi mit berücksichtigen würden. Das wäre so der nächste Schritt. Und der dritte Schritt oder die voll digitalen Unternehmen, das sind wirklich die Champions heute.

Das ist eigentlich total verrückt. Das vermitteln eigentlich nur noch z.B. Booking.com besitzt kein einziges Hotel, und die bringen einfach nur diese Nachfrage von Kunden und Hotels, bringen sie zusammen und stehen in der Mitte. Uber besitzt vermutlich besitzen ein paar Autos, aber wenige keine Taxis. Aber sie sind der größte Taxi Dienstleister. Airbnb besitzt keine Wohnungen, aber auch eine gewagte These vermieten wahrscheinlich mehr Wohnungen, wenn darüber abgewickelt als eine kleinere Stadt oder Ferrando nimmt. Die z.B. haben kein Restaurant und beschäftigen keinen Fahrer fest.

Aber die bringen halt Restaurants und die Leute, die gerne essen wollen, aber sich nicht aus dem Haus bewegen möchten, zusammen. Das ist für mich ein weiteres. Es ist so krass. Ich habe heute einen Unterbreche, habe heute erfahren, dass, liebe Ferrando, 30 Prozent von dem Umsatz kriegt, eine Pizza für sieben Euro bestellt kriegt, die zwei Euro zehn. Das finde ich unfassbar.

Ich dachte, dass es pro Bestellung gibts. So eine Fixkosten drauf kommen 30 Prozent.

Ich habe mich heute mit dem Restaurant unterhalten. Der Restaurantbesitzer bezahlt.

Ich dachte, der Endkunde bezahlt die Lieferung gewissermaßen.

Nein, bezahlte er, bezahlt der Restaurantbesitzer 30 Prozent. Aber das Verrückte ist Diese digitale Transformation führt auch dazu. Du siehst es schon. Die Wertschöpfung wird quasi an anderer Stelle abgegriffen. Das Essen muss irgendwie zum Mund, und je nach Themen, wo der Mund ist, muss es da hinkommen. Und das Essen zuzubereiten ist nur noch zwei Drittel, und das Essen auszuliefern ist dann schon ein Drittel der Wertschöpfung. Wenn man so möchte, ja, auch diese Abo-Modell, die heute, die es heute überall gibt, die würden ja gar nicht funktionieren.

Die mobile Apps für die e-roller, die hier rumstehen oder es gibt es, heißt das da für 20 Euro im Monat. Wenn du die App stellst, stellen sie dir ein Fahrrad hin. Wenn was kaputt ist, reparieren die das Fahrrad, und du hast quasi ein funktionsfähiges Fahrrad im Abo. Wenn du so möchtest. Ich merke das, wenn ich mit älteren Semestern spreche, die sagen Hey, ich will das Fahrrad besitzen. Und warum sollte ich ein Fahrrad mieten und Salzkonsum jetzt einen Monat irgendwo sind in einer anderen großen Stadt.

Und wo das angeboten wird, wäre das ja ein super System. Oder auch für Leute, die ihr Fahrrad sehr viel nutzen und sehr viel für die Reparatur kaufen. Klar ist das auch im System, was lobenswert ist, dass man quasi sagt Eigentlich das Fahrrad ist. Ich zahle für den Service, ein Fahrrad zu haben und nicht mehr für das physikalische Ding. Man zahlt für das Erlebnis oder für den Nutzen beim Streaming. Du kriegst keine CD mehr oder keine DVD mehr.

Aber du siehst in Filmen oder beim Carsharing Du bezahlst für den Nutzen, von A nach B zu kommen mit dem Auto und nicht für das Auto. Ja, ja, die Anforderungen der Kunden, seien es jetzt Endkunden und natürlich auch Businesskunden. Das verschiebt sich schon ganz erheblich. Und jetzt kommen wir zu dem Punkt Warum ist das für Unternehmen ein großes Problem? Die digitale Transformation dazu gesagt?

Das fand ich sehr wichtig. Deswegen will ich nun mal gern herausstellen, dass. Was du gesagt hast, ist, dass ich bestehende Prozesse in meinem Unternehmen digitalisieren. Das heißt, ich gucke mir an definieren oder oder identifiziere Prozesse, die von A nach B nach C D laufen und gucke. Was kann ich davon automatisieren? Digitalisieren, um es schneller zu machen und effektiver zu machen? Ein ganz einfaches Beispiel Ich muss Daten, die ich von einem Lieferanten bekomme, in mein System reingehen.

Kein Witz, ganz oft gesehen. Da steht ein Faxgerät, da kommt ein Fax rein. Dann nimmt sich irgendeiner das Fax, setzt sich einen Rechner und gibt die Daten in SAP ein. Gibt’s. Ganz aktuell habe ich sogar den Fall. Mein Vater ist jetzt in Pflege, und ich musste diese Pflege beantragen. Das sind fünf Parteien involviert. Das ist einmal die Krankenkasse, die Rehaklinik, der Hausarzt, der Pflegedienst. Und die müssen sich alle miteinander irgendwie austauschen.

Und alles offline, alles mehr oder weniger offline. Eine muss oder will oder kann nur das Ding per Post verschicken, der andere kann nur Fax, der andere kann das per E-Mail machen. Das ist furchtbar. Da gibt es so viele Reibungsverluste innerhalb dieses Prozesses. Du kriegst das terminlich nie hin, weil der eine muss das dem anderen kommunizieren. Dann ist mein Vater zu Hause. Da gibt’s die Geräte noch nicht, weil der andere das nur per Post verschicken muss.

Und, und, und. Man sieht da dran, wie ich sage, mal ganz, ganz, ganz einfache Mittel schon solche Abläufe voll digitalisiert und automatisiert werden können, um einfach effektiver und effizienter zu werden. Das ist das einender, das ich in meinem Unternehmen oder in so einem gesamtprozess mit Lieferanten und Kunden und so weiter Wege digitalisieren, automatisieren. Das andere ist ein Begriff. Muss ich dazu noch einführen, nämlich die Value Proposition, das heißt, das Werte versprechen?

Was du als Unternehmen dem Kunden gegenüber gibst, sei es jetzt zum Beispiel das Produkt oder eine Dienstleistung. Eine gewisse Eigenschaft hat eine gewisse Haltbarkeit. Wenn man grundsätzlich diese value proposition zu verbessern. Das ist erst einmal der erste Ansatz der digitalen Transformation. Indem ich, wenn ich zum Beispiel als Kunde Ja sage, mal so ein Pflegefall habt, dann kann ich das Werbeversprechen als Krankenversicherung erhöhen, indem ich solche Prozesse automatisieren.

Das heißt, es ist so witzig, ist doch günstiger für alle Seiten besser?

Ich habe fünf Mal von der Krankenversicherung den selben Antrag bekommen. Ich weiß nicht, wie der Prozess gelaufen ist. Wahrscheinlich tatsächlich einmal per E-Mail, einmal per Post und fünfmal. Ich habe eine Stunde gebraucht, um allein herauszufinden, dass diese fünf Anträge eigentlich alle die gleichen sind. Damit kannst du schon mal gegenüber dem Kunden. Das ist nur ein Beispiel, wenn du effizienter bist und schneller bist. Bei der eigenen Kosten senken und das Kunden Erlebnis verbessern?

Absolut. Das andere ist, wie du dein Werbeversprechen noch verbessern kannst, du neue Angebote schaffst, wie digital unterstützte. Nehmen wir als Beispiel Amazon. Wir haben am Anfang 94 angefangen mit dem Buchhandel, und zwar per Mail. Das heißt, du hast eine Mail geschrieben und hast gesagt Ich will das und das Buch. Und dann ging das ein paarmal hin und her per Mail. Und dann hast du ein Buch bekommen, als es losging, das mehr und mehr Menschen Browser adaptiert haben, benutzt haben.

Hat Amazon sich gedacht, das wäre doch cool, wenn wir diese Kette irgendwie verkürzen würden und nutzen jetzt den Browser damit für die Bestellungen online abgeben können und noch halten können. Und so eine Kommunikation über die Weboberfläche. Was im Prozess mega beschleunigt hat, mederer vereinfacht für beide Seiten. Als die Robotik stärker wurde und die Technologie besser wurde, hat Amazon einer der ersten, der seine Lager effizienter gestaltet hat, mit Robotern. Was Roboter liefern jetzt diese Ware zu dem Menschen, der da vorne steht und das verpackt.

Das ist durch und durch ein digitales Unternehmen. Der guckt sich an Welche Technologien sind Murchison und nutzt das, um einfach das kum Erlebnis dieses Superposition einfach zu ölen, zu verbessern für den Kunden.

Es geht ja noch weiter. Dann hat er gesagt Für das Weihnachtsgeschäft oder für Peace-Zeichen haben wir so viel Rechenkapazität übrig. Können wir wiederum anderen anbieten, eine einheitliche Schnittstelle darüber ziehen und daraus das A-WM?

Exakt genau so funktioniert das also für mich ein Musterbeispiel einer durch und durch digital nativen Firma?

Absolut. Aber hier geht es natürlich auch darum, dass wir Unternehmen in Deutschland vielleicht doch nicht so Großunternehmen zeigen wollen, wie sie auch selber die digitale Transformation gestalten können. Oftmals stehen ja auch gerade kleinere Unternehmen vor der Herausforderung. Die digitale Transformation erhöht ja erst einmal den Grad an Komplexität im Unternehmen, weil ich mit dieser Technik Sicht durchgehen muss, alle Prozesse beleuchten muss. In vielen Unternehmen sind Prozesse gar nicht dokumentiert, sondern die haben sich so eingebürgert. Ich brauche neue tech Experten.

Ich kann vielleicht nicht einschätzen. Sind Sie wirklich gut oder sind die nicht gut? Damit geht natürlich auch Kontrollverlust einher. Digitale Prozesse sind. Nicht mehr Wenn du kein Techniker bist, verstehen sie nicht mehr analoge Prozesse. Hast du halt in der Hand oder haben die Leute in der Hand und die sind einfach leichter verständlich. Dennoch, da bin ich ganz bei dir, gehe ich davon aus, dass es diese ganzen STANDARD Prozesse der Unternehmen, die nur Geld kosten.

Ich weiß nicht, wieviel Versicherungen generell billiger werden könnten, wenn man diese ganze Verwaltung runter dampft, auf die wirklich schwierigen Fälle und die ganzen Standart Fälle einfach mit Software abwickeln kann. Das ist ja heute auch schon. Es gibt Versicherungen, die Kasse monatlich ein und ausschalten zum so eine Reiseversicherung. Die buche ich nur, wenn ich eine Reise mache und schaltet einen Monat danach wieder aus.

Und das sind so einfach cool, dass man das machen kann.

Warum das so schwierig ist? In deutschen Unternehmen ist meines Erachtens, weil man noch sehr in Strukturen denken. Das heißt, du ziehst Strukturen in deinen Unternehmen ein mit Abteilungsleitern und Bereichsleiter, mit einer eigenen Profit, Lein, eigenen Reporting und so weiter und so fort. Das führt dazu, dass Silos entstehen und die vielleicht vielleicht ein Anführungsstrichen für sich effizient und effektiv arbeiten. Aber wir wissen nun alle, dass im Prinzip so ein Unternehmen nicht nur in Silos funktioniert, sondern kurz funktional sein muss, wo viele Menschen miteinander Abteilungs, Grenzen, arbeiten müssen, kommunizieren müssen.

Und da vergeht halt extrem viel Energie darauf, allein schon Entscheidungsprozesse. Wenn du im Entwickler-Team bist und irgendwas machen willst oder brauchen willst, dann musst du das nach oben kommunizieren. Dann von einem Teamleiter, dann geht so ein Abteilungsleiter vielleicht sogar irgendwo in den Vorstand, bis es wieder zurück kommuniziert ist all diese Wege, diese Entscheidungsfindungen, die funktionieren in einem digitalen Unternehmen nicht. Das heißt, du musst schnell Entscheidungen treffen.

Das zum einen und zum anderen glaube ich auch die Unternehmen. Das hängt mit der digitalen Transformation zusammen, ist aber nicht eine ausschließliche Folge. Davon müssen sich wieder mehr auf den Kundennutzen konzentrieren, weil dem Kunden nutzt das überhaupt nichts. Ob da fünf Abteilungen miteinander sprechen oder eine, das ist dem Kunden auch vollkommen egal. Er möchte seine Leistungen haben, das Herz der Geschäftskunden oder der Privatkunde. Er möchte einfach sein, seinen Job erledigt haben, und ich glaube, es ist Aufgabe der Unternehmensführung, eine große Herausforderung.

Jetzt haben mehr über die Probleme der digitalen Transformation gesprochen. Jetzt kommen wir mal zu den Herausforderungen für die Unternehmen. Ich glaube, die Aufgabe, die digitale Transformation voranzutreiben, ist ganz klar eine Aufgabe der Unternehmensführung. Schafft ein Unternehmen die digitale Transformation nicht, liegt das in der Verantwortung der Führung. Ganz klar für mich. Weil die Führung muss verstehen Okay, wir müssen uns wandeln. Sie müssen das tragen müssen. Meiner Ansicht nach funktionieren auch diese klassischen Hierarchiestufen nur noch bedingt, sondern sie müssen quasi lernen, Verantwortung abzugeben in einzelne Fachbereiche, die dann autark Entscheidungen treffen können, um eben schnell reagieren zu können.

Das haben mir auch manche mitbekommen, dass sie quasi Verantwortung für ein Projekt, für ein Produkt komplett abgeben. In Anführungsstrichen Startup Team Cross funktional besetzt ist und selber entscheiden kann, also schnell mit einem gewissen Budget ausgestattet ist. Und man sieht das schon mal hier und da, aber leider viel zu selten.

Dieses Abgeben von Verantwortung bedingt natürlich auch eine offene Fehlerkultur. Natürlich werden Fehler passieren, und natürlich ärgert sich der Vorstand darüber. Aber in der digitalen Welt ist es oftmals wichtiger, schnell zu sein, an Stelle fehlerfrei zu sein. Mir fällt jetzt ein großer amerikanischer Zahlungsdienstleister ein. Wenn er schon Jahre am Markt ist, dann überlegen sich die europäischen Banken Mensch, so was machen wir auch. Und wir haben auch schon drei Banken, die mitmachen. Also für mich als Digital Native ist völlig klar Das kann so nicht funktionieren.

Entweder müssen alle mitmachen, und das am besten auch schon schnell. Wenn der amerikanische Dienstleister sozusagen gerade auf ploppt oder du kannst es gleich sein lassen, dann hast du diesen Markt einfach verloren. Und dann Post oder gar nicht mehr anfangen. Wenn ein digitaler Player laufen ist und Erfolg hat. Und jetzt kommen die anderen auf die Idee Mensch, das mache ich auch. Dann ist der Drops gelutscht, weil durch diese Netzwerke Effekte in der digitalen Welt ist es unmöglich oder nur mit extremen Ressourceneinsatz möglich, diesen Weg gelaufenen schon einzuholen?

Das beste Beispiel ist WhatsApp auf dem Handy. Du könntest jetzt einen Messenger rausbringen, der doppelt so gut ist, schöner, schneller, bunter auf mehr Handys läuft. Den würde keiner mehr laden, weil das einfach verloren ist, weil es keinen Bedarf mehr gibt. Und der Bedarf wird von einer vorhandenen Lösung zu hundert Prozent erfüllt. Und damit bist du da raus. Also offenes Mainstadt? Offene Fehlerkultur ist ganz, ganz wichtig und meiner Ansicht nach die größte Herausforderung auch für den Vorstand oder für die Leitung eines Unternehmens.

Und es reicht nicht, einfach nur Coaches zu beauftragen.

Da spricht ja ich weiß frei. Die sagen Okay, wir machen alles agil, und damit wird das schon. Man muss sich wirklich als. Die harten, ehrlichen Unternehmer fragen stellen Können wir unsere Mitarbeiter schulen? Auf diese neue Denke können und wollen diese Menschen diesen Transformationsprozess gestalten. Es gibt, wenn man sich ehrlich fragt, auch Branchen. Da muss man mit Nein antworten. Da ist die Frage Was machen wir hier? Weil die digitale Transformation wird jedes Unternehmen betreffen, unabhängig davon, auch wenn man in der Industrie tätig ist und Werk Teile herstellt.

Das ist ganz klar, dass man davon betroffen sein wird. Und die Antwort ist Nein, wir schaffen das nicht mit diesen Menschen. Dann muss man auch daraus Konsequenzen ziehen. Auch das haben Unternehmen gemacht, dass sie sagen Okay, die Firmen Bereiche, die noch laufen, die verkaufen. Wir nehmen dieses Geld und investieren in digitale Unternehmen, um sozusagen über die, wenn man so will, über die Kreditkarte oder übers Bankkonto die digitale Transformation zu gestalten. Man verkauft die Unternehmensteile, die eben nicht sich nicht digitalisieren wollen oder wo man den Aufwand als zu groß vermutet, und beteiligt sich dann an Digital Unternehmen, also auch die Mitarbeiter mitnehmen.

Welche ängste haben die Mitarbeiter? Wie können wir diese abbauen und sich wirklich hart fragen Kriegt man das mit der Mannschaft hin? Ich glaube, das muss man, muss man sich eingestehen, wenn es so ist. Und wenn auch nicht so ist.

Dazu muss man sagen Was mich auch nur ein bisschen irritiert, ist grundsätzlich die Angst Schüren der Medien. Datenschützer Katastrophen heraufbeschwören, jede aufkommende Technologie erst einmal hinterfragen und schlecht reden und immer nur die Seite herausstellen. Was als Gefahr gesehen? Bestes Beispiel künstliche Intelligenz. Wir haben für die meisten Deutschen Dawid nicht den Vorteil, dass diese Technologie alles bewirken kann, egal, ob es mein Leben physikalisch, finanziell oder so verbessern kann. Was für ein Potenzial dahinter steckt? Darüber reden wir nicht.

Wir fangen sofort an mit den Bedenken und was das alles kaputt machen könnte. Oh Gott, ich habe mir einen normalen Deutschen. Künstliche Intelligenz würde sagen, ich habe Angst um meinen Job. Aber das Einzige, was hauptsächlich hörst, dass dein Job zerstört. Ja, das ist ein Aspekt. Aber könnte ich zehn andere Aspekte aufzeigen, wie es wieder neue Jobs schaffen, wie es dein Leben vereinfacht? So, und das ist jetzt ein Bumerang. Genauso wie mit dem Internet.

Das böse Internet. Und jeder ist eine böse Datenkrake. Wir müssen jetzt wie auf den Straßen überall Schilder hochhalten Achtung, Achtung, JavaScript! Achtung! Das ist schon fast absurd. Aber was das bewirkt, ist, dass es bei den Menschen subtil Angst heraufbeschwört vor diesen Technologien. Und wenn du all das, ohne zu hinterfragen, jahrelang praktiziert, dann darfst du dich nicht wundern. Wenn die Menschen Angst vor der Technologie haben, dann ist es schwierig, Menschen abzuholen, Mitarbeiter abzuholen, weil sie schon eine subjektive Meinung gebildet haben über die Zeit.

Genau das meinte ich mit Mitarbeiter mitnehmen. Es ist natürlich die Berichterstattung, und die Medienberichterstattung ist so, wie du sagst, dass man da sehr ängstlich, aber auch Politik Cumbia das Einzige.

Das Einzige, was uns zum Thema einfällt. Alle sind sich bewusst künstliche Intelligenz. Wir müssen da mehr tun. Wir müssen fördern bla, bla, bla, bla, bla. Die erste Amtshandlung ist doch tatsächlich ein Vorschlag. Wir müssen in alle Unternehmen einen Algorithmus Beauftragten installieren, so ähnlich wie der Datenschutzbeauftragte. Das ist in Absurdität gar nicht mehr zu überbieten.

Die deutsche Angst German Angst ist natürlich auch legendär. Ich glaube, das einzige, wo digitale Transformation wirklich ein Dämon ist, ist, wenn du Angst vor Veränderung hast. Es wird sich was verändern. Das ist jedem klar. Aber Veränderung Nummer ist das kann man gestalten, und das kann man zum Positiven und zum Negativen gestalten. Die KI ist ja nur ein Vehikel, wie ein Flugzeug ein Vehikel ist oder ein Auto ein Vehikel. Und viele Menschen fahren mit dem Auto zur Arbeit, und ein paar Verrückte fahren mit dem Auto, verletzten andere Menschen.

So und genau so ist das auch mit neuen Technologien. Die sind nicht per se gut oder per se schlecht, sondern es kommt darauf an, was man daraus macht. Ich meine jetzt, wir sitzen hier in der Mitte der Coruna, Pandemie, viele Leute, die überwiegend am Bildschirm arbeiten oder digitale Arbeitsplätze haben, die konnten normal weiterarbeiten. Man stelle sich nur mal vor, diese Pandemie hätte uns Mitte der 80er erreicht, wo das Internet noch überhaupt nicht ausgebaut war.

Das wäre einfach Hetze, die Volkswirtschaft komplett gestoppt.

Da wäre keiner zur Arbeit gegangen oder hätte keiner seine Arbeit erledigen können von zuhause, außer vielleicht mit dem Telefon. Aber das ist schon ein riesengroßes Glück, dass das Internet so gut ausgebaut ist. Zu der Zeit, wo das passiert war, definitiv. Und ich glaube, auch das ist ein absoluter Beschleuniger. Jetzt auch. Covert 19 hat so viel zur digitalen Transformation beigetragen, mit zehn Regierungen das nicht leisten können. Für mich als Technologie begeisterten. Ich kann das nicht so ganz nachvollziehen, wie man immer vor allem Angst hat.

Ich versuche immer Okay, das hat Risiken. Wenn man den Führerschein macht ja, natürlich hat ein großes Auto, was man bewegt, irgendwie Risiken, aber man lernt, damit umzugehen. Dann kann man eben auch damit sehr schöne Strecken fahren und Mobilität genießen. Aber man muss eben lernen, damit umzugehen. Und das ist auch ganz wichtig. Oder die Botschaft an die Menschen und draußen lernt und die Unternehmen lernt, damit umzugehen, und beschäftigt euch damit, weil die digitale Transformation wird euch früher oder später auf jeden Fall betreffen.

Egal, welches Geschäft ihr heute habt.

Vielleicht haben wir auch darauf ein, was die wirklich wichtigen Entscheidungen für Unternehmen sind, die von der digitalen Transformation stehen oder diese gerne aktiv gestalten wollen. Das ist ja ganz wichtig, um wie wir dabei helfen können. Wir haben ja schon mal so einen Prozess skizziert, wie wir Big Data Projekte durchführen. Um bei der digitalen Transformation ist es auch wichtig, dass man am Anfang erst einmal eine Bestandsaufnahme macht. Wo steht die Firma heute? Welche Prozesse sind überhaupt wertvoll und wer welche überhaupt nicht digitalisiert werden und schon rausfallen, weil man sie eigentlich nicht braucht?

Welche Prozesse sollen digitalisiert werden? Also hier. Die Strecke für zur Pflege wäre hier ein super Beispiel. Dafür Geld sparen können, wenn das einmal implementiert ist und der Service sogar noch besser würde für die Endkunden. Was wir als Gilbert machen ist, dass wir erst einmal eine Digitalisierung Landkarte erstellen und gucken. Wo sind denn deine Potenziale als Unternehmen und die mit den strategischen Zielen des Unternehmens? Im Prinzip übereinanderliegenden zu gucken. Was ist im ersten Schritt notwendig, um die digitale Transformation zu gestalten?

Und welche Technologien können wir verwenden, um dich dahin zu bringen? Das ist ganz wichtig. Digitale Transformation steht schon. Der Name sagt es schon, hat immer auch mit Technologien zu tun. Und wir konzentrieren uns am Anfang immer darauf, dass wir den Unternehmen erst einmal. Ich sage mal die einfachen Punkte zeigen, die schnell erreicht werden können. Auch dass man so ein Motivationsschub mitnehmen kann, um dann eben in weiteren Schritten dann die Ausbaustufe 2 und drei der Komponenten anzugehen.

Also wir gucken schon Welche digitalen Lösungen gibt es heute oder welche können wir entwickeln, um die aktuellen Unternehmensziele zu unterstützen? Und während dieser Brainstorming Session oder dieser Planung fallen oftmals auch Ideen für neue Geschäftsmodelle ab, die man dann erproben kann mit der WP Methode. Andreas von Valeo Salopp gesprochen Genau da geht es ja. Darum geht es ja darum zu prüfen. Hat das Perlet für die Kunden vielleicht, sagen wir, als Gilbert helfen können. Also einmal bei der Enterprise Softwareentwicklung.

Wir können gerne zeigen, wie man agile Lösungen entwickelt im eigenen Unternehmen also. Agil heißt für uns, dass man kurze Zyklus Zeiten hat und dabei das Unternehmen die volle Kostenkontrolle besitzt, quasi eine fortwährende Ost und Leistungskontrolle sehen kann, ob sich die digitalen Prozesse in die richtige Richtung entwickeln. Ein ganz zentraler Punkt ist das Aufsetzen von Pipelines, also Continuous Integration, Continuous Delivery. Da geht es darum, dass im Grunde die Artefakte oder die Software Komponenten, an denen die Entwickler bauen, dass sie jeden Tag ausgerollt werden können, an Borten Feature.

Man testet das Feature, und es kann. Die Zeit von Coding zu Produktions Release ist relativ gering. Was wir auch machen, ist Enterprise Softwareentwicklung, vorzugsweise mit Java und Micro Services, wo wir dann eben die in der Identifikationen Phase ausgeschriebenen Anforderungen umsetzen.

Genau. Wir konzentrieren uns auf den Technologiepark in der digitalen Transformation, können aber natürlich, weil wir das in mehreren Unternehmen schon gemacht und gesehen haben, sehr, sehr gut einschätzen, was die Schiedsstellen dazu sind, wie die Kommunikationsprozesse zu den Mitwirkenden sein müssen, wie die Entscheidungsprozesse sein müssen, also nicht nur die reine Technologie. Wir setzen sein Programmieren, sondern können dem Kunden gegenüber auch sehr gut kommunizieren, wie das bei einer digitalen Transformation auch die Technologie implementiert sein muss, kommuniziert werden muss, um zu den anderen Schnittstellen zu funktionieren.

Meistens ist es ja so, dass man es eingangs als ersten Grad bezeichnet, dass man im Prinzip vorhandene Prozesse digitalisiert, also eine Bestell schrecken. Dann zum Beispiel auf eine API Strecke, also eine Schnittstellen Strecke umbaut, das Thema automatisch Bestellungen auslösen können anhand gewisser Parameter, und dass man im Zuge dessen dann weitere Potenziale identifiziert. Dass man dann auch strategisch den Unternehmen unterstützt und sagt hier das und das und das sind Potenziale als Entscheidungs Vorschlag im Prinzip für den Vorstand, dass er schauen kann, ob das auch noch Projekte sind, die interessant sind und die strategisch zum Unternehmen passen.

Gerade im Bereich der Dobbs kann man Unternehmen ja sehr stark unterstützen, was die digitale Transformation angeht. Vielleicht möchtest du dazu etwas sagen.

Das Thema, was unten drunter schwingt, ist, wie du gesagt hast, sofort ein ganz einfaches Beispiel ein Konkurrent, ein Feature eingeführt, und das funktioniert super. Du brauchst das auch.

Wie lang will sie jetzt warten und diskutieren implementieren und die Pleuel bis zu dieses Feature am Start? Vielleicht bist du auch selber der Innovator und sagt Ich möchte verschiedene Interaktionsmöglichkeiten ausprobieren. Mit dem Kunden, um zu gucken und messen natürlich, was am besten funktioniert, um zu sagen Okay, wir schlagen jetzt diesen Weg weiter ein. Und das ist das, wobei es hilft. Das heißt, es nimmt hier in der gesamten Software-Entwicklung Sketche gefegt, dass die Entwickler Operations und die Infrastruktur schnell zu sein, wenn es sein muss, mehrmals am Tag in Produktion.

Eine änderung in der Webseite zu bringen, kennen die meisten, die diese digitale Transformation noch nicht haben, wenn sie Software bauen wollen oder lesen wollen. Selbst ins Web dauert das monatelang. Und wenn du etwas machst, dann machst du etwas anderes kaputt. Fürs neue Batz ein und, und, und, und. Das wollen wir mit der Woolfs Movement, mit den Tools und Prozesse auch. Da geht es nicht nur um Technologie, sondern auch um ein Meint.

Es geht auch um Daten getriebenes Handeln. Ich messe, wie oft ich am Tag die Pleuel vielleicht eingeführt habe, um mich dann verbessern zu können. Das heißt, dieser ganze Zyklus geschieht auch innerhalb des Webs für sich allein, um den Prozess kontinuierlich zu verbessern und Software immer schneller und Qualitätssicherung an Bord zu kriegen. Da gibt es neue Bewegungen wie Check ups. Oft ist es so, dass du, wenn du entwickelst, dann hast du noch die Security Abteilungen, die ein Strich durch die Rechnung macht.

Die verlangen dann Stadtmodell. Wie wollen, wie compliance-abteilung sagen Wir müssen aufpassen, dass da keine Third Party Lizenzen verletzt werden? Beispiel Lycée von Oracle oder bestimmte Compliance-Regeln Policies eingehalten werden. Das ist alles, was diesen Zyklus behindert. Und das führt Tools ein Voodoo. Stichwort Policy Code.

Dass du quasi diese Firmenpolitik genauso wie Infrastruktur Code als Code signiert hast und Tools automatisiert checken können, ob du Compliance bist. Das verhindert einmal Fehler, teure Fehler. Wenn du mal mit so einem Ding durchgeht, weil der Mensch vielleicht einen Fehler gemacht hat. Das macht ein Tool nicht, wenn es automatisiert ist und man dementsprechend gefüttert hat. Da wird jetzt immer mehr automatisiert, um so einfach Geschwindigkeit aufzunehmen. Und es ist ganz einfach der, der das macht, der ist schneller.

Werde es nicht mal langsamer und geht die Gefahr ein, irgendwann obsolet zu werden, weil die anderen an ihnen vorbeiziehen?

Das eine ist Geschwindigkeit beim Ausrollen neuer Funktionen, das andere ist natürlich auch Geschwindigkeit in der Skalierung selber. Also wenn eine Anwendung dann gefordert wird. Ich sehe das bei unseren Kunden. Die starten ein Service oder auf einer Webseite integriert. Dann funktioniert es ganz gut aus dem Datenblatt. Ich spreche jetzt mal und dann sag mal okay, wir möchten das in allen unseren Webseiten drin haben, haben aber dann pro Monat 4 Milliarden Requests. Von heute auf morgen explodieren die Zugriffszahlen, und das kriegt man natürlich auch hin mit dieser DVB-S Entwicklungsmodell, das man auch sagt.

Okay, die Infrastruktur beschreiben wir heute als Code und das läuft im eigenen Rechenzentrum oder in der Cloud. In der Cloud können wir dann raus skalieren. Heute machen wir es auf zwei Servern, übermorgen machen wir es dann auf 200, ohne was zu bestellen. Sehr schnell. Vielleicht funktioniert die Anwendung auch nicht. Dann melden wir die 200 Server wieder ab und können dann weitermachen. Mir kann dann aber sehr schnell verloben und sehr schnell neue, werthaltige Geschäftsführer des Unternehmens finden.

Das, was wir eingangs gesagt haben Geschwindigkeit, ist oftmals wichtiger als fehlerfreiheit, um eben natürlich auch in Grenzen. Wenn man eine Steuerung fürs Atomkraftwerks sollte man vielleicht dann doch anders priorisieren. Aber gerade im Bereich Web muss man einfach schauen, dass man schnell neue Dinge ausprobieren kann.

Ich will hier mal ein Beispiel nennen, was ich anfangs sagte dass dieses Silo, Denken und Kommunikation mit dazugehört. Ich habe mal einen Kunden gehabt im konsumgüterbereich, der mit vielen filial, da die Marketingabteilung eine Werbung geplant und geschaltet, wo plötzlich dann natürlich über Nacht die Zugriffszahlen, genau wie eben gesagt, in die Höhe geschnellt sind. Dementsprechend der Schopp nicht mehr funktioniert hat. Das heißt, man hat irgendwie künstlich Service selber eingeführt. In einem Unternehmen, das die digitale Transformation durchmacht, gilt es, diese Kommunikationswege so zu vereinfachen, so agil zu gestalten, dass man voneinander weiß und dann zum Beispiel für die Skalierung sorgen, für die automatische Skalierung mit Autos gelingt oder was auch immer.

Wozu das dann führt, wenn man das nicht macht, sieht man halt.

Das Unternehmen ist gewissermaßen Opfer seines eigenen Erfolgs geworden. Ich kann auch aus dem Nähkästchen erzählen. Das war nicht mein Projekt. Aber ein befreundeter Berater hat mir mal erzählt Eine Bank wollte ein Online-Konten beworben, zur Prime Time während eines Bocks Kampfes. Da sind auch die Call-Center, und die Webseite dieser Bank war überlastet, weil so viele Leute sich dann anmelden wollten. Und das war der beste Tag für die Konkurrenz, die dann alle verstehen. Oh ja, bei A kann ich das jetzt nicht abschließen.

Aber B hat doch auch ein Online-Konten. Und genau da ist der Schuss. Nach hinten losgegangen. Okay, das war jetzt Softwareentwicklung und warum ist das wichtig? Du hast ja schon die Datentypen angesprochen. Wir bei unserer Big Data Abteilung gehen so vor. Wir brauchen eine eigene podcaster Episode, wo wir genau zeigen, wie der Prozess ist. Aber ich fasse ihn hier noch mal kurz zusammen. Dass wir anfangs eine Daten Anamnese machen bei den Unternehmen, die Unterstützung im Bereich digitaler Transformation anfragen, dass wir sagen Welche Daten hat das Unternehmen, welche Möglichkeiten ergeben sich aus diesen Daten?

Dass wir neue Daten, Produkte, proben. Das haben wir ja auch letztes Jahr schon mal für den Kunden gemacht. Ich glaube, einen Monat oder zwei Monate haben wir ausprobiert, ob das so funktioniert, wie wir uns das vorstellen. Und dass man dann sehr schnell sagt Okay, die Daten sind hinreichend. Man kann das neue Produkt bauen, oder man muss noch hier und da mehr Daten einsammeln oder die vorhandenen Daten bereinigen, um dann die gewünschte Leistung herauszubekommen.

Das ist natürlich sehr charmant, dass man da sehr schnell einsteigen kann. Oftmals ist es auch so, dass unsere Kunden möchten, dass wir die Daten mittlerweile in Echtzeit bereitstellen oder in Echtzeit ein sammeln, damit die Software Komponenten in Echtzeit Entscheidungen treffen können und letztlich damit auch die Unternehmen in Echtzeit Entscheidungen treffen können. Und wir hatten jetzt eine Anfrage Anfang des Jahres, wo es darum ging, Daten Markt zu konzipieren. Also, wenn du dich daran erinnerst, aber ein großes Unternehmen, was von vielen, vielen Kunden Verbraucherinformation sammelt und eben diese Informationen in anonymisierter Form dann wiederum weiteren Geschäftskunden bereitstellen möchte und im Grunde mit diesen Daten handelt, zum datenblöcke wird.

Großes Potenzial liegt auch an der Vereinheitlichung von Daten Strecken innerhalb der Unternehmen, sodass man mal dokumentiert Welche Daten habt ihr eigentlich und was geht wohin und was kommt von b&o? dashboards und Reports stehen auch einmal ganz vorne, gerade damit die Unternehmensführung oder das Controlling weiß. Wo steht die Firma gerade? Es gibt oft regulatorische Anforderungen von Börsen gelisteten Unternehmen, die quasi zu jedem Zeitpunkt sagen müssen, wie viel, wie viel Geld es in der Kasse. Sag ich mal vereinfacht Um welche Verbindlichkeiten haben wir sie im Prime STANDARD richten können?

Immer mehr. In der jüngsten Vergangenheit werden Produktion Modelle angepackt. Wann fällt welche Maschine aus? Welche Kunden werden vermutlich kündigen? Welche Reichweiten haben wir mit diesen und jenen Kampagnen? Voraussichtlich nehmen wir die Kampagne so und so gestalten. Welche demografischen Daten füllen die Nutzer, die diese Kampagne vermutlich konsumieren werden, sodass man quasi im Vorfeld schon so eine Art Erfolgs Abschätzung macht? Bei all diesen Punkten unterstützen wir natürlich gerne, um den Unternehmen zu helfen und sie nach vorne zu bringen.

Also Angst haben muss niemand. Man muss sich nur vor der digitalen Transformation Angst haben, muss niemand zu dem Punkt stehen eine Chance? Auf jeden Fall. Man muss sich eben nur mit dieser Thematik beschäftigen und auch den Mut haben zu sagen Hey, wir gehen das an. Wir gestalten das aktiv. Lidl hat jetzt die Schwarz-Gruppe. Muss man sagen. Die Familie hinter Lidl hat jetzt vor einer Woche bekannt gegeben, dass Sie ein eigenes Klout Angebot aus dem Boden stampfen möchten.

Ich bin gespannt, wie sich das entwickelt. Meiner Ansicht nach 15 Jahre zu spät, aber beste. Die werden auch nicht dumm sein und werden sich genau überlegt haben, was sie tun. Sie haben eine Menge Innovationskraft und Finanzkraft, um da was auf die Beine zu stellen. Da bin ich ganz gespannt. Hast du noch einen Punkt? Eine wirklich wichtige Entscheidung, der sich ein Unternehmen stellen muss, welches über digitale Transformation nachdenkt.

Was wir machen können. Ich finde, das Thema lässt sich noch ein bisschen länger diskutieren. Und was hältst du davon, wenn wir so eine Serie mit vielleicht noch zwei oder drei weiteren Podcast machen, um dieses Thema dann die nächsten, vielleicht etwas praktischen Tipps, wie man, wenn man diese Dinge angehen kann, sehr gerne.

Wenn man mal cool, wenn unsere Zuhörer Fragen haben oder Feedback. Können Sie uns gerne eine E-Mail schreiben? An Podcast bei T. Wir freuen uns, wenn ihr den Podcast abonniert oder eine externe Bewertung da lasst und für weitere Technologien Themen. Schaut gerne auf www. Skill bei slash blog vorbei. Wunderbar.

Ich wünsche dir noch einen schönen Abend, dein gewöhnlich gut, du auch.

Maurice KnoppSkillbyte Podcast #22: Digitale Transformation ist eins der Härtesten
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