Skillbyte Podcast #38: Darum müssen IT-Manager programmieren können!

Skillbyte Podcast #38: Darum müssen IT-Manager programmieren können!

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

In diesem Podcast geht es um das Thema:

Darum müssen IT-Manager programmieren können!

// Inhalt //
01:20 – Was ist das Problem?
03:35 – Nur general Management Skills reichen nicht für IT-Projekte
06:29 – IT-Management braucht zwigend technischen Sachverstand
07:40 – Kardinalfehler: Aufgrund mangelnden IT-Verständnisses werden fachliche Anfoderungen sehr ungenau spezifiziert
09:14 – Technischer Sachverstand und Coding Skills helfen extrem bei der Anforderungermittlung mit der Fachseite
12:02 – Technischer Sachverstand ist nötig um vom Team respektiert zu werden
13:05 – So schaffen IT-Manager den Programmier-Einstieg (Bugfix, Unittest, Hello-world, neue Technologien sichten)
17:07 – IT-Zeitabschätzungen validieren
21:36 – Technologiekenntnisse boosten die Anforderungsanalyse und die Ergebnisspräsentation
27:42 – Wo können IT-Manager coden im Projekt lernen?
31:02 – Workaround wenn keine Technikskills vorhanden sind
31:44 – Gegenfrage: Darum sollten Entwickler auch Management-Aufgaben übernehmen!

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

Feedback und Fragen gerne an podcast@skillbyte.de

AUTOMATISCH ERZEUGTES TRANSKRIPT

Also grundsätzlich finde ich das schon sehr wichtig, dass er im Prinzip das Team oder Ergebnisse repräsentieren kann, repräsentieren und präsentieren kann. Ich meine, das gibt ja beiden Seiten, also a den Manager Kollegen guten Eindruck, seinem Manager einen guten Eindruck, aber auch dem Team guten Eindruck.

Alle nehmen den Mann ernst oder sehen quasi als Autorität, dass er in beide Richtungen kommunizieren kann und auch den Sachverstand hat.

Wenn man solche Leute findet, dann ist das ein Gewinn fürs Unternehmen.

Herzlich willkommen zu unserer Skillbyte Podcast Episode Nr. 38 Darum müssen IT-Manager programmieren können Abonniert unseren Kanal für mehr spannende Technologien aus dem Technologie Umfeld, wenn er IT Entscheider oder IT Fachkraft seid. Wenn ihr Hörer Fragen habt, schreibt uns gerne eine E-Mail an Podcasts skillbyte und hinterlasst uns eine 5-Sterne Bewertung. Empfiehlt unser Podcast auch an Freunde weiter. Und wenn ihr selber auf der Suche nach interessanten Job seid, googelt einfach mal Skillbyte und Jobs. Ich bin heute hier wieder mit Masiar Hi Masiar Hallo Maurice, freut mich den Stammgast hier im Podcast zu haben und ich glaube zu dem Thema IT-Manager und Programmieren können wir beide eine ganze Menge zu sagen.

Ich würde ganz gerne ein kurzes Intro machen, was ich glaube, was das Problem ist. Warum ist es überhaupt ein Problem? Warum diskutieren wir das? IT-Manager müssen programmieren können oder nicht und dann können wir uns die Bälle zuspielen. Jetzt muss man sagen, dass es häufig so ist, dass sehr gute Entwickler, die natürlich programmieren können, zu Managern oder zu Teamleiter befördert werden. Und diese Menschen betrifft diese Episode explizit nicht, weil die können ja programmieren und kommen sozusagen aus der Praxis in die Management Position.

Was ich hier mit IT-Manager meine, ist so ein fachlich Verantwortlicher für den Betrieb einer Software. Die Weiterentwicklung eines technischen Systems, also einer Website, ein internes Software System, eine Komponente, ein Rechenzentrum, der direkt mit Entwicklern zusammenarbeitet. Das ist wichtig. Natürlich ist mir klar, dass der CTO, also der technische Gesamtverantwortung von Unternehmen, nicht unbedingt programmieren in seinem Tagesgeschäft lernen muss. Aber Leute, die direkt mit Softwareentwickler zusammenarbeiten, sollten das meiner Meinung nach machen.

Und das Problem? Jetzt komme ich darauf entsteht häufig, wenn diese Menschen, diese Manager das nicht können und nicht so richtig die Problem Sicht der Entwickler einnehmen können.

Ja genau so sehe ich das auch.

Die Jungs die ich sage mal aus der IT aufsteigen. So eine Management Position passiert hauptsächlich aufgrund ihrer Kommunikationsfähigkeit, dass sie so beweisen, dass sie auch den Blick über den Tellerrand hinaus haben. Das ist ja so der klassische Vorwurf der Programmierer Nerd. Der guckt einfach nur auf seinen Code und weiß nicht was drumherum abgeht oder will es nicht wissen, was auch immer.

Die gibt es natürlich auch.

Aber es gibt noch eine Spezies, die tatsächlich das mitbringen. Und das sieht man dann auch relativ schnell und befördert die Jungs dann schon mal eine Stufe hoch als Teamleiter, IT, Leiter, Bereichsleiter und so weiter.

Genau der Gedanke aus Unternehmenssicht ist glaube ich relativ einfach. Da habe ich jemanden, dem ich einfach meine Business Ziele kommunizieren kann, mit dem ich einfach darüber sprechen kann, welches Ziel ich mit dem Software System erreichen möchte. Und diese Person übersetzt das dann für das Team in technische Anforderungen.

Das ist ja ein positiv Fall, richtig? Das Problem entsteht meiner Ansicht nach, wenn das kommt bei Unternehmen vor Manager eingesetzt werden, die vorher aus einem anderen Fachbereich kommen oder die noch nie Software entwickelt haben, vielleicht auch gar nicht so viel darüber wissen. Und sie sagen halt Management des Managements und General Management, die einfach auch Unverständnis haben von den Vorgängen, die während der Softwareentwicklung eben ablaufen und die dann so ein halbes Management machen. Also sie kommen an, sagen Okay, das ist ganz einfach.

Die Business Seite sagt Wir wollen dies und jenes und wir bauen dies und jenes. Und wir arbeiten ja nach Scrum.

Das ist agil. Das Team organisiert sich selber hier. Das ist das, was ich will, macht mal. Und die so quasi die gesamte Verantwortung voll auf das Entwicklungsteam abwälzen. Das finde ich, ist ein großes Problem. Kommt vor, habe ich selber auch schon erlebt. Ein anderes Problem für mich ist ein Management. Job ist geprägt von Unterbrechungen. Du musst dich hier kümmern, du musst dich da kümmern. Du hast angerufen, da muss irgendwie reagieren. Und die Tätigkeit der Softwareentwicklung erfolgt halt am besten durch langfristiges, konzentriertes Arbeiten.

Störungsfrei arbeiten wie so eine Mathematik Hausaufgabe kann man sich das vorstellen. Da kommt es dann zu ersten Problemen, wenn die Arbeitsweise des Managers auch auf das Team abgedrückt wird. Das erlebe ich sehr oft.

Ja, gebe ich dir tatsächlich recht? Für mich stellt sich nur dieser direkte Vergleich dar, wenn wir mal unsere Ministerien angucken, was da für ein Gefummel ist und wer plötzlich alles Verteidigungsminister wird. Von links nach rechts ein Posten geschachere, wo völlig klar ist, dass der oder diejenige von der Domäne überhaupt keine Ahnung hat. Man ist der Meinung und das halte ich für das Gefährliche. Man muss im Management gut sein und alles andere ist egal. Das kaufe ich mir dann dazu oder hol mir Berater.

Wobei jetzt bei den Politikern. Ob diese Menschen gut sind, sei mal dahingestellt. In dem Falle können weder Menschen noch haben sie das Wissen. Aber gehen wir mal von einem normalen Menschen in der Wirtschaft. Dann kann es sein, dass er sich vielleicht in einem bestimmten Bereich auskennt, gut organisieren kann usw..

Aber das heißt noch lange nicht, dass er in der IT gut aufgehoben ist, ohne dies Domänen wissen.

Und man hat halt diese einhellige Meinung. Ja, dann kaufe ich mir als Berater dazu. Okay, was dann passiert, sieht man, dann nimmst du einfach blind an, was der Berater dir sagt. Ja, weil ich glaube, diese Ethik, diese ich sage mal, dass der Berater von sich aus tatsächlich berät, vernünftig berät, ohne seinen eigenen Vorteil zu sehen, ohne seinen eigenen Auftrag verlängern zu wollen, ohne weitere Kollegen mit ins Boot zu holen. Sorry, das habe ich persönlich gesucht und oft gesehen.

Da dürfen die Unternehmen oder als Menschen nicht einfach blind diesen Beratern vertrauen und müssen sie aber, weil sie kein Dohmen Wissen haben. Komischerweise vertrauen sie den eigenen Leuten weniger in der Aussage als irgendeinem externen Berater. Auch das passiert ständig. Allein deswegen schon muss meines Erachtens in der IT das Management auch Ahnung von Programmieren ist eine sehr spezifische Ecke. Egal ob es eine Infrastruktur ist oder Programmierung oder was auch immer. Er sollte sich mit Technologie auskennen.

Das unterschreibe ich. Und ich würde sagen, du hast es schon angesprochen. Programmieren ist jetzt sehr spezifisch, aber sich mal mit den Dingen im Kern beschäftigt haben. Wenn du die Produkt Broschüren der Hersteller liest, da kriegst du nur das Marketing Material und das ist wie so ein Werber Blättchen im Briefkasten. Da wird halt übertrieben und das hat wenig Substanz Kraft. Also man muss die Sachen prüfen. Das ist leider so, wenn man das beste für sein Unternehmen rausholen möchte.

Was ich noch festgestellt habe ist, dass die Team-Manager manchmal machen. Also mir ist schon klar, dass die Welt sich da draußen hektisch bewegt. Man kann nicht ein IT-Projekt vom Zaun brechen oder starten und sagen Okay, da fasse ich jetzt nichts mehr an, bis es fertig ist.

Alle Störung halte ich für von fern, aber dass man dennoch die Arbeitsweise der Entwickler versteht, versteht, wie die technischen Zusammenhänge sind, dadurch keine leichte Beute für Berater ist und folgendes Problem etwas anders angehen kann Ich weiß nicht, ob du das auch kennst, aber oft ist es so, dass IT-Manager, die sprechen ja mit der Business Seite oder auch mit dem höheren Management und das höhere Management kippt die Anforderungen ein und sagt Wir wollen strategisch da und dahin kommen. Wie machen wir das denn technologisch?

Und dann wird dort ein Projekt gestartet und der IT Manager, der ich sage jetzt mal direkt für das Produkt verantwortlich ist und sein Entwicklerteam hat, der hat aber Angst, jetzt die genauen Anforderungen sauber abzuklopfen, weil das könnte bedeuten, also eine Prozess Veränderung im Unternehmen bedingt ja auch relativ häufig eine Veränderung des Machtgefüges im Unternehmen. Prozesse laufen auf einmal anders. Auf einmal sehen Abteilungen Daten, die sie vorher nicht gesehen haben oder Abteilung kommen gar nicht mehr mit Daten in Kontakt, weil man diesen Arbeitsschritt einfach überspringt.

Und der IT-Manager? Dem ist das schon bewusst. Aber der umschifft jetzt diese Konflikte, indem er bewusst die Anforderungen schwammig formuliert oder nicht sauber spezifiziert. Das heißt, diese nicht sauber spezifizierten Anforderungen landen dann irgendwann in der Technik und sollen umgesetzt werden. Und dann geht die große Reiterei los. Und das kommt einfach daher, dass man das Projekt am Anfang nicht direkt stoppen möchte, weil man sagt Oh, also dann sieht ja jeder die Daten oder dass es so eine große Veränderung, das bekommen wir gar nicht hin.

Das ist letztlich so. Aber man gibt so diese Anforderung dann an das Technologie Team weiter und das ist meiner Ansicht nach auf jeden Fall eine Art Management Aufgabe, dass man nicht sagt ja, dann denkt euch was aus, sondern dass man da dann wirklich spezifisch sagt. Ja, wir müssen den Prozess jetzt aber genau festzurren, damit er eben entwickelt werden kann und effektiv entwickelt werden kann.

Der große Vorteil ist halt, dass der technisch bewanderten Manager die Schnittstellen auch genau einzuordnen weiß. Er weiß, was ein Entwickler braucht, um die Anforderung umzusetzen.

Wenn er die Anforderungen mitbekommt, weiß der, ob das tief genug ist oder ob das noch mal übersetzt werden muss oder angereichert werden muss. Und wer das tut, der kennt doch die Rolle. Das heißt, er kann viel schneller handeln, es verschwinden keine Information, entsteht keine stille Post. Man ist wesentlich akkurater und schneller.

Du meinst, er kann quasi schon anhand der Anforderung erkennen Ah, das ist was fürs Frontend, das ist was fürs Backend, das kann der machen, das kann der machen, weil der da und damit schon Erfahrung gesammelt hat und kann quasi im Kopf schon so eine Art kleinen Fahrplan zusammenbauen, klaren Fahrplan aufmalen, versteht die Zusammenhänge, welche Abteilung mit wem sprechen muss, kann das sofort Fachabteilung zurückgeben sagen Pass auf, wir brauchen eure Anforderung in der und der Detailtiefe.

Wenn ihr wollt, können wir was für euch organisieren, dass man euch das beibringt. Er sagt im nächsten Schritt an, was getan werden muss, damit es weitergeht.

So wie du gesagt hast, wird das einfach eben voran gekippt. Die Entwickler gucken sich das an, sagen Ja, was soll ich damit anfangen? Und dann geht das so ein paar Runden, bis es wieder an der Stelle ist, bevor es losgehen kann.

Und dann am Ende der engagierte Entwickler schwingt sich dann auf und macht die Management Arbeit so ein bisschen mit. Mit dem Fachbereich holt die Infos ein, schlägt auf den Konflikt auf, der nach wie vor da ist, er einfach nur noch nicht offenbar geworden ist.

Und dann dreht man diese runden Maurice. Was machen wir denn jetzt damit? Und dies und das genau. Und das ist einfach nicht sauber vorbereitet. Inwieweit da Coding hilft dem IT-Manager?

Es hilft ihm vielleicht soweit die Arbeit des Teams im Detail zu verstehen, dass er weiß Okay, die kommen immer an den Punkt, wo die nicht weiterkommen. Und heute können wir diese Fragen klären oder auch nicht. Oder sie können auch nicht von meinem Team geklärt werden, aber wir müssen sie klären, um da weiterzukommen. Wie gehe ich damit um?

Ja, als ob da jetzt irgendwie die Java Syntax kann oder so. Das ist jetzt mal dahingestellt. Aber wie gesagt, er kennt die Schnittstellen, was bis zum Detailtiefe er Informationen braucht.

Es geht ja in dieser Phase erst mal nur um Informationsfluss und das kann er sehr gut einschätzen, weil er diesen Prozess schon ewig mitgemacht hat.

Also im Grunde ist ein guter IT-Manager so eine Schnittstelle zwischen Manager und Architekt, oder?

Ich würde sagen, es gibt ja noch einige Rollen neben. Gerade in großen komplexeren Projekten kommt das Thema Requirements Engineer Business Analyst und ich wette, 40 prozent der Manager wissen gar nicht oder wenn nicht sogar mehr, was die genaue Aufgabe dieser einzelnen Rollen ist. Man hat irgendwo gehört Agil Team organisiert sich selber, das machen die schon.

Und jetzt werden Gilden gegründet und die Maskottchen geschnitzt.

Dein Lieblingsthema.

Da kommt mein Scrum Hass hoch.

Ich glaube auch, man muss vielleicht nicht jede Codezeilen verstehen, aber dennoch als Manager. Was ich sagen würde ist, man muss über ein gesundes Grundwissen verfügen und sollte auch wirklich mal ein Mini Programm geschrieben haben, weil sonst wird es sehr schwer vom Team auch respektiert zu werden, um technische Entscheidungen glaubwürdig dem Team zu kommunizieren. Dass man dann noch ernst genommen wird und jetzt kommt.

Aber das ist eine persönliche Erfahrung, desto weniger IT Kenntnisse der IT-Manager hat. Meiner Erfahrung nach desto mehr werden Buzzwords Nebelkerzen eingesetzt und wenn ganz viele Buzzwords fallen, dann ist das Team absolut demoralisiert, weil das sofort gemerkt hat, der hat keine Ahnung, wovon er spricht. Also wenn man keine Ahnung hat, vielleicht besser zugeben und dann hilft einem das Team. Das ist eine sinnvollere Sache, anstelle einfach mit dem, was man noch auf der Rückseite heute Morgen aufgeschnappt hat, ins Meeting zu gehen.

Also was cool wäre, wenn wir mal so eine Video Reihe machen. Hello World für Manager in 30 Sprachen oder so was.

Nein, also wie gesagt, das ist ja jetzt die Frage. Wir sagen Okay, die Manager müssen coden können. Jetzt fragen sie sich natürlich Okay, wie fange ich das denn an? Fange ich das mit einem Hello World Programm an oder wie löse ich diesen Konflikt dann auf, wenn ich nicht kaufen kann oder das sehr, sehr lange her ist? Und da gibt es ein paar Lösungsvorschläge. Im Internet findet man von den großen Gaffer Unternehmen, die sagen auch ein IT-Manager muss sechs Wochen im Jahr Kunden.

Andere sagen Oh, 30 Prozent der Zeit.

Wichtig ist, dass es Dinge sind, die nicht auf dem kritischen Pfad liegen. Und Team-Manager könnte zum Beispiel mal probieren, ein Unit Test zu schreiben oder etwas Neues auszuprobieren.

Also das aktuelle Projekt läuft auf Java 11 und er könnte es versuchen, auf die neue Version zu heben. Was passiert denn da? Und wenn das nicht klappt oder nicht rechtzeitig fertig wird oder eine Woche später fertig wird, ist das auch okay. Wichtig ist, glaube ich, dass man sich nicht dann auf den Kritischen fortbewegt, um das Team auszubremsen.

Ich meine, das lässt sich jetzt natürlich einfach sagen, wenn man sich selber aus der Programmierung kommt.

Aber früher war das auch ein bisschen einfacher.

Aber du hast ja heute mit so viel Technologie Stack zu tun.

Ich muss schon sagen, wenn ich mir das vorstelle, würde ich Regie im mittleren Management oder so, damit mir jetzt irgendwie einer kommen, sagte Masiar.

Programmieren lernen. Mit dem Programmieren allein ist es ja auch heute schon nicht mehr getan. Allein schon, wenn du das Programmieren dann für sich nimmst. Da hast du irgendwie Front und Back.

Obs da schon normale Programmierer nicht mehr durch, geschweige denn dann so ein Manager, den du jetzt abverlangt, programmieren zu können.

Ja wie gesagt, nicht höheres Management, sondern schon jemand, der verantwortlich ist vor ein Entwicklungsteam. Und ich gehe davon aus, dass viele auch programmieren können. Das muss man jetzt auch gucken. Was ist das für ein Projekt? Also wenn da Leute eine Steuerung vom Atomkraftwerk entwickeln, dann sollte man vielleicht nicht irgendwas dazwischen hacken. Wenn es eine Webseite ist, geht es vielleicht eher. Es geht einfach darum, so ein bisschen zu verstehen. Okay, was macht das Team denn?

Das ist so, stell dir mal vor auf der Baustelle. Ich meine der Polier wird nicht jede Mauer mauern oder da eine riesen Wand hoch mauern. Aber der muss wissen, mit den Steinen mauer ich die Wand am besten so, mit diesen Steinen mauer ich die Wand am besten. So, da ist die Isolation am besten. Hier muss ich ein bisschen Abstand lassen, das einschätzen zu können. Also das kannst du aber nicht, wenn du gestern fachfremd unterwegs warst und heute auf der Baustelle stehst und das managen sollst.

Also irgendwo musst du dich damit befassen. Ich meine, wir haben 2020. Wir sprechen darüber, dass Informatik in den Schulen präsenter werden soll und jeder hat so ein Mindestmaß an Programmierung mal machen sollte, damit er weiß. Wie die Systeme, die ihn zum größten Teil umgeben, wie die funktionieren und da denke ich auch als Manager sollte man zumindest mal ein Mini Programm schreiben, um einfach zu begreifen, dass das schwierig ist.

Schwierig ist auch, die Unterschiede der einzelnen Technologien gut auseinanderhalten können.

Zum Beispiel, wenn aus einer anderen Abteilung des Unternehmens einer auf dich zukommt und sagt Wir, wir haben dies und jenes zu machen. Das muss in der und der Technologie gemacht werden und du nimmst das Projekt an, obwohl das überhaupt nicht zu den Skills seines Teams passt. In der Richtung wollen die das machen. Wenn man selber Entwickler ist oder aus der Richtung kommt, dann weiß man, wie so ein Entwickler tickt. Was er grundsätzlich möchte oder nicht, möchte sich zum Beispiel mit alter Technologie beschäftigen, nur weil es irgendwo im Unternehmen eingesetzt wird.

Ja, kann man zwingen sein was ein Arbeitsvertrag. Aber ob das jetzt mittelfristig zum Ziel führt und ob man sich die Leute sauer wird, ist eine andere Frage. Was ich damit sagen will ist Du kannst das Team auch ein bisschen schützen vom ein kippen von Sachen, die sie gar nicht machen wollen oder gar nicht machen können.

Wenn du die Expertise hast und weißt, wie neue Technologien funktionieren. Ja, das glaube ich auch. Das ist auch durchaus ein Vorteil, wenn der IT Manager sagt ich mach halt ein Mini Programm mit den neuen Technologien oder ich guck sie mir meinetwegen an und beschäftige mich damit und dann weiß ich, wie das funktioniert und wie das zusammenspielt.

Aber ich kann mich erinnern, wir hatten auch schon Projekte, da haben wir im Grunde den Manager irgendwann gebeten, uns in Ruhe zu lassen, weil wir gesagt haben Du produzierst mehr Aufwand als du löst, weil man das einfach dann doppelt erklären muss, was ja auch kein Problem ist. Aber dann ist diese Person dann einfach fehlbesetzt an der Stelle. Was ich glaube, was auch ganz wichtig ist für IT-Manager, ist herauszufinden, ob die Abschätzungen der Entwickler, also die Zeit Abschätzung, die Aufwands, Abschätzung, ob die einigermaßen zutreffend sind zur Abschätzung.

Genau da kann alles und nichts passieren.

Aber wenn man da keinen Sachverstand hat, dann muss man im Grunde sich blind darauf verlassen. Und das ist so verrückt. Das wird in der normalen Welt ja auch niemals einer machen. Wenn du dein Auto in die Werkstatt bringst und der Meister sagt ja, Reifenwechsel 20 Stunden, dann würde ich ja auch sagen Ja, Moment mal, hier stimmt was nicht. Wie können Sie 20 Stunden zum Reifenwechsel brauchen? Normalerweise darf das fünf Minuten nur benötigen pro Rad. Und das ist ja auch ein wichtiger Bereich, weil die Aufwand Schätzungen haben ja meistens einen direkten Effekt auf das Projekt Budget bzw.

auch die Projekt Laufzeit. Ich meine klar, ich kann es per Brute Force auch ermitteln, aber dann muss ich ein Entwickler länger kennen. Ich würde mir immer so eine Schätzung auf und gucke am Ende wie lang hat er denn gebraucht und passt das so einigermaßen? Und auch wenn man die auch Schätzung hat der Entwickler muss man ja noch einen Puffer drauf einkalkulieren, weil bei dem einen Server ist die Netzwerkkarte nicht sauber konfiguriert und das rauszufinden dauert zwei Tage.

Das schreibt ja keiner in die Anforderungen auf und das sind Probleme, die durchaus auftreten.

Genau. Also im Prinzip so diese Dinge, die drum herum passieren können. Also wenn ich zum Beispiel heute irgendwo bei einem Kunden.

Früher hab ich drüber gelacht, dieses Jahr. Wie viel ungefähr, wie lange ungefähr dauert das denn? Ja gut, also um diese Anforderungen zu kennen und dann auf Basis schwammiger Anforderungen auch noch aus schwammigen Verso. Inzwischen bin ich aber aufgrund der relativ viel an Implementierungen Anforderungen schon durch hab. Kann ich wie so ein Baustein Baukastensystem, kann ich mir so eine Zahl aus dem Bauch drücken und als Beispiel nehmen, wenn es um Registrierung, Loggien, Anbindung an Kickls s.o. bla fasel.

Wenn du das jetzt ein paar Mal gemacht hast, dann hast du ungefähr eine Zahl im Kopf.

Aber das ist ja der Brute Force Ansatz von dem ich sprach, weil bis auf ein paar mal schon gemacht, das ja genau, aber paarmal gemacht, das Arbeiten, wenn ich dann sage okay, das ist jetzt reine programmiert seit soundso viel. Wenn ich aber mich als Entwickler einen halben Tag mit eurem Proxy rumschlagen muss, das kann ich jetzt nicht abschätzen. Das sind dann die Details, die im Unternehmen gegeben sind und das muss man halt oben drauf rechnen. Das kann locker mal das Doppelte sein.

Ja, es gibt so Klassiker, man bekommt die Zugänge nicht. Der Mensch, der die Zugänge verteilt, ist nicht da. Ist aber nur ein Tag nicht da. Deshalb lohnt sich eine Urlaubsvertretung nicht. So hat man schon verloren, Tag und Nacht. Es gab schon mal Projekte, wo ich sogar ein, zwei Monate gewartet habe.

Der Kunde, was er dann in der Zwischenzeit nicht nichts gemacht, aber was anderes. Aber dann dieses eine Ding ist halt quasi geblockt.

Man macht dann irgendwie so Trockenübungen, weil man nicht den richtigen Zugriff hat. Und das sind einfach Sachen.

Okay, das ist Managern auch klar, aber es kann durchaus passieren. Ich glaube auch, dass es IT Managern durchaus Spaß macht, wenn sie mal ein kleines Programm, einen kleinen Test, eine kleine Frontend Seite selber machen, die dann letztlich auch mit ausgeliefert wird und sie auf der Webseite sehen können. Guck mal, das drucken habe ich gemacht. Also jetzt als Beispiel oder die Drucken Funktion habe ich gemacht. Ich glaube das ist auch ganz wichtig und tolles Erfolgserlebnis und weshalb es sich schon lohnt sich damit zu beschäftigen.

Die Frage ist ja auch der IT-Manager ist ja ein Dolmetscher. Auf der einen Seite kriegt er die Chefs Anforderungen rein gekippt, auf der anderen Seite muss er das eben mit seinem Team besprechen. Dafür muss er ja sowohl die Business Perspektive als auch die. Perspektive einnehmen können. Problem Was ich beobachtet habe ist, dass weil die Business Perspektive oftmals mächtiger ist oder zumindest bei Unternehmen die IT als Mittel zum Zweck einsetzen und nicht dieselbe IT-Unternehmen sind und ihre Dienstleistung verkaufen, ist die Gefahr, dass das Oben oder die Business Anforderung Seite wichtiger ist, dass das eigene Team und das Manager sich dann dazu hinreißen lassen, mehr oder weniger alles einfach ungefiltert durch zu schieben.

Sagen der Business Seite war ja klar, das können wir machen und erscheint dort sehr kompetent. Der alte Manager hat gesagt das geht nicht und das ist schwer. Und dass man dann im Grunde die ganzen Anforderungen reinzieht und das Team sich selber überlässt damit. Und dann kommen dann oft so Glaubenssätze dazu wie die Entwickler. Da muss man einfach noch mehr drauf werfen auf das Problem und der gute Code ist nicht so schwer. Wir lassen die Tests weg und auch oftmals herrscht der Glaube vor, so eine Funktion zu implementieren.

Das ist so einfach wie eine E-Mail zu schreiben, um mal in der Manager Welt zu bleiben. Aber da hängt ja durchaus mehr dran. Dann die möglichst genaue Aufnahme der Anforderungen durch den Manager. Das haben wir schon besprochen.

Wobei die Frage ist also, ob er die Anforderungen aufnehmen muss und meistens kommt er mit ins Spiel, wurde in größeren runden Sets und dann wird über ein neues Projekt gesprochen oder da fällt mal was ab. Und genau um diesen Zeitpunkt geht es jetzt, dass er in dieser Runde sofort einschätzen kann, wer will was und was haben wir schon, um dann beurteilen zu können. Okay, muss ich jetzt was tun? Kann ich das schon jetzt bei uns reinkippen oder kann ich das erst mal sofort zurück spielen, ohne dass ich es noch mal ins Team geben muss?

Und jetzt kommt die Zeitersparnis ins Spiel, kann also ein paar Sachen halt filtern, bevor das quasi ins Team geht.

Also was du jetzt beschrieben hast ist Stufe 1 Stufe 2 wäre, wenn der Manager schon so viel Erfahrung hat, dass er direkt sagen kann Okay, das möchte dir eigentlich erreichen, da haben wir diese Komponente schon da. Und weil die eine moderne API benutzen, können die schon miteinander sprechen. Der Aufwand hier ist nicht so groß oder ihr fordert das an. Das ist sehr komplex, wenn wir es ein bisschen anders machen, so und so, dann ist es wieder handhabbar, weil das sind ja die wertvollsten Besprechungen im Grunde.

Man versteht, was die Business Seite will, macht dann einen Vorschlag auf Basis der eigenen Teamfähigkeit oder der bestehenden Infrastruktur und bestehenden Software, die schon da ist und hat trotzdem eine Karte im Kopf und kann sagen Ja, die und die Komponenten spielen zusammen, die und die Komponenten spielen aber überhaupt nicht zusammen. Oder ist es sehr aufwendig, die zum Zusammenspiel zu bewegen? Und was auch glaube ich, wichtig ist es von IT-Manager. Jetzt geht es aber nicht so sehr ums Programmieren, sondern dass er im Grunde sein Team kennt und weiß, wie aufwendig Änderungen im Frontend sind.

Im Backend sind, was das für die Infrastruktur bedeutet, wenn man statt 100 Kunden auf einmal 100000 Kunden willkommen heißen möchte. Ich habe einen Kunden, bei dem ist das so. Der hat ein System, was momentan nur einen Server bedient, einen Prozess. Das ist auch super gut funktioniert. Alle sind glücklich, aber mein Endkunde möchte alle seine Endkunden über dieses System schleusen. Irgendwann. So und dann habe ich direkt angesprochen, dann wird das Thema Skalierbarkeit und Ausfallsicherheit sofort sehr, sehr wichtig, weil dann zehntausende Zugriffe stattfinden und nicht mehr nur ein paar.

Was hältst du von dem Thema, das IT-Manager auch die Arbeit des Teams präsentieren können müssen?

Wie meinst du?

Also oft ist es ja so, dass zum Beispiel nach Ablauf eines Sprints das Team den Fortschritt zeigt. Aber das ist ja nur Scrum intern oder Sprint intern. Aber ein IT-Manager wird ja auch in unregelmäßigen Abständen immer mal wieder zu Runden eingeladen, wo er dann gefragt wird Okay, wie ist denn hier der Stand?

Wo stehen wir denn hier?

Sind wir auf Kurs oder nicht? Und da, glaube ich, ist es auch ganz wichtig, nicht zu programmieren in dieser Runde, sondern davon Ahnung zu haben, dass man eben die Arbeit des Teams entsprechend repräsentieren kann. Dass man sagen kann Das war jetzt eine aufwendige Änderung, die Datenbank da anzubinden aus den und den und den Gründen. Das ist nicht so einfach im Kubernetes Cluster mit Kickls und Verschlüsselungen und die Datenbank muss Ausfall sicher sein und so weiter. Wenn man davon keine Ahnung hat, dann sagt man einfach Da weiß ich nicht mehr, sage ich nur Datenbank anbinden dauert halt drei Wochen.

Habe ich auch schon erlebt.

Also hier sag du mal, warum ist das so langsam? Warum dauert es so lang?

Also grundsätzlich finde ich das schon sehr wichtig, dass er im Prinzip das Team oder Ergebnisse repräsentieren kann, repräsentieren und präsentieren kann. Ich meine, das gibt ja beiden Seiten, also den Manager Kollegen guten Eindruck, seinem Manager einen guten Eindruck, aber auch dem Team guten Eindruck.

Also alle nehmen den Mann ernst oder sehen quasi als Autorität, dass er in beide Richtungen kommunizieren kann und auch den Sachverstand hat.

Wenn man solche Leute findet, dann ist das ein Gewinn fürs Unternehmen.

Auf jeden Fall. Und das skaliert sowohl in die Business Anforderungen Ausrichtung als wie auch in das Entwicklungsteam. Der ideale IT-Manager lass uns mal so Anfang, der im Grunde über diese Coding Skills verfügt und über das Verständnis der Business. Und eben auch Leute managen kann. Der wird ja im ersten Schritt die Business Anforderungen vollumfänglich aufnehmen, verstehen mit der Business Seite so weit die Anforderungen erheben, dass er sagt Okay, die sind so fein Granulat, das kann man technisch eben umsetzen.

Es gibt auch immer mal so blinde Flecken, wo man sagt Okay, das wissen wir heute noch nicht, aber da können wir uns eine Lösung überlegen oder ein Konzept. Das ist überhaupt nicht schlimm, aber dass man diese Sachen halt erkennt und sagt Okay, das müssen wir noch genauer uns ansehen, nachdem man sie sehr fein Granulat erhoben hat, möglichst in genau definierte Teilaufgaben herunterbricht fürs Frontend Backend Infrastruktur. Da ist ja auch ne Menge jetzt gar nicht unbedingt Programmier Wissen erforderlich.

Aber einfach Technologie Wissen. Wie ist mein System aufgebaut? Wie spielen die Komponenten zusammen? Und nachdem diese Teilaufgaben erstellt wurden, geht man dann mit dem Team eben hin, geht den ganzen Aufgaben Batzen in Sprints mit dem Team durch und verteilt die Verantwortlichkeiten für diese Aufgaben. Und dann und das glaube ich, ist auch eine ganz wichtige Art Management Aufgabe schützt man das Team vor Störungen von außen.

Also ich habe in einem Entwicklungsbereich gesessen, da hatte kein Entwickler Telefon, es gab nur ein Telefon vorne und alle Anrufe sind vorne zentral aufgeschlagen. Und da muss jemand begründen, warum er denn mit einem Entwickler spricht. Umsonst gab es einfach kein Telefon. Das ist natürlich eine radikale Art, aber im Grunde zeigt es schon, dass dieses Unternehmen zumindest sehr ernst genommen hat, dass die Leute da vor Störungen geschützt werden und dass der Manager dann eben sieht, dass sein Team gut arbeiten kann in dieser konzentrierten, abgeschirmten Arbeitsatmosphäre.

Das Team schätzt das auch super hoch ein, wenn man sich dann eben so konzentrieren kann und darf und nimmt das als große Wertschätzung wahr vom IT-Manager. Und wenn der Manager selber mal programmiert hat, dann weiß er auch, wie wichtig das ist am eigenen Leib, dass man nicht gestört wird.

Und ich glaube, wenn man diese drei Punkte beherzigt, also die Anforderung sauber aufnimmt, die Anforderung sauber mit technischem Sachverstand herunterbricht, Frontend Backend, Infrastruktur und dann eben dafür sorgt, dass das Team diese kleinen Tickets auch dann umsetzen kann, ungestört, dann hat man schon viel richtig gemacht. Auf jeden Fall. So war es eben schon mal kurz angesprochen mit der Atmender ist voll motiviert und sagt Okay, ich möchte programmieren lernen oder ich möchte mein Wissen noch mal auffrischen.

Wo kann er sich denn da beweisen? Wir haben eben schon gesagt, abseits des kritischen Fats ist es ganz sinnvoll, eben um eine Blockierung des Projektes zu verhindern. Was hältst du von Code Reviews?

Eher bei anderen oder andere, bei ihm eher bei anderen?

Na ja, er kann sich ja eigentlich nur daneben setzen und sich mal zeigen lassen oder anhören, was der Entwickler da macht. Review heißt ja eigentlich normal, dass ein anderer, der genauso viel Ahnung hat, mindestens genauso viel Ahnung hat, da mal drüber geht und beurteilt ist was richtig, falsch und wie er das gemacht. Es geht ja um das Vier-Augen-Prinzip. Inwiefern das jetzt für den Manager Sinn macht, sich daneben zu setzen, der wird wahrscheinlich erst mal U-Bahnhöfe verstehen, weiß ich nicht.

Er kann sich ein kleines Ticket raussuchen. Irgendwo wird eine Anzeige geändert und an dem Code Review, also er muss sich ja gar nicht so daneben setzen. Das wäre natürlich ideal, aber er könnte sich ja einfach nur den Request angucken. Sozusagen sieht er, was die Business Anforderung für Implikationen auf den Quellcode hat. Also ich halte es einfach für relativ niedrigschwellig. Einfach mal der Manager guckt ins Kittler rein, guckt in die Materie rein und sieht den Code, sieht die Kommentare der Entwickler da dran und da ganz sicher Englisch kann, wird er da schon was mitnehmen.

Bin ich ganz sicher. Was ich auch denke. Was ganz sinnvoll ist, ist, dass man sich vielleicht so einen isolierten Bug mal vornimmt.

Das gut, also was kleines handhabbare es eine fel Darstellung, irgendeine Zahl, eine Zeitzonen Konvertierung, so was, dass man erst mal sehr viel Code lesen muss, um zu verstehen was wird hier eigentlich gemacht? Wie sind die Zusammenhänge? Und dann an genau der richtigen Stelle dann den fix zu hinterlegen, also möglichst kleines Paket, dann ein Punkt den ich noch aufgenommen habe ist, dass man ich glaube da braucht man aber nicht ein Detail Verständnis einfach die Bild Pipeline versteht ja, dass man weiß, der Code, den man Entwickler einsteckt, der geht nicht direkt durch auf dem Server nach vorne, sondern die Tests laufen erst mal.

Dann wird das Format homogenisiert, also das egal welcher Entwickler den Code schreibt, es mehr oder weniger gleich aussieht. Das sogenannte Lindh, das dann noch mal jemand anders drüber guckt und das ist dann ein Paket gebaut wird, was dann in eine Testumgebung ausgerollt wird. Und wenn das abgenommen ist, dann läuft es in die Produktionsbedingungen. Also das man sich dieser ganzen Kette nur Application Lifestyle Management bewusst wird.

Das ist ein gutes Stichwort, das diese einzelnen Stationen des Codes mal kennenlernt. Also live zeigt Software live. Definitiv ja.

Wenn es hoch hergeht, spricht ja nichts dagegen für einige Minuten um eine Katastrophe abzuwenden. Vorne auf der Produktions Maschine irgendwie was zu retten. Also im Katastrophenfall.

Aber dennoch muss klar sein, dass das natürlich keine Dauerlösung sein kann. Weil wenn das einmal funktioniert hat, schleicht sich das ganz schnell ein und wird dann zum.

STANDARD Und wenn man verstanden hat, warum man die Aktie Pipeline benutzt, also Continuous Integration, Continuous Delivery, dann wird einem schon klar, dass es sehr schlecht ist, da vorne auf der Produktion selber rum zu fummeln. Das ist wie bei der NASA. Wenn am Space Shuttle was undicht ist, dann kann man mal da rausgehen mit dem Schweißgerät und das Loch dichtmachen. Im Katastrophenfall ist das sicher angebracht. Dennoch sollte man normalerweise solche Reparaturen geplant ausführen und sollte gar nicht dazu kommen, dass man in diese Lage kommt.

Was macht man, wenn ein IT-Manager partout keine Programmier Erfahrung hat und auch keine Technik Hintergrund hat? Als Workaround habe ich es schon erlebt in Teams, dass dann im Grunde einfach ein technischer Leiter benannt wird, der erfahrenste Entwickler aus dem Team oder ein externer technischer Leiter.

Jetzt hat man im Grunde diese beiden Kompetenzen. Du hast diese Business Seite und diese technische Expertise, die idealerweise in einer Person vereint sind. Damit man diese schnellen Rückkopplungen Zyklen hat, hat man jetzt in zwei Personen, so dass im Grunde der technische Leiter dafür verantwortlich ist, mit dem IT-Manager die Probleme so fein Granulat runter zu spezifizieren, dass das Team arbeiten kann. Das funktioniert auch. Jetzt habe ich noch eine provokante Gegenfrage und wir sagen ja hier IT-Manager sollen programmieren können.

Wer glaubst du, dass auch Entwickler Managementaufgaben mal machen sollten?

Also verkehrt ist das nicht. Definitiv mal so ein bisschen die andere Seite kennenlernen oder auch mal Finanz Kennzahlen, was das alles bedeutet.

Also dümmer wird man nicht mehr. Auf jeden Fall wird man nicht dümmer. Und wir sagen ja, der IT-Manager sollte ein bisschen programmieren können, um die Zusammenhänge zu verstehen. Und ich denke genau den gleichen Grad sollte man auch dem Entwickler zumuten in Richtung Management, also dass der Entwickler selber überlegt macht das Sinn, dass ich jetzt hier drei Wochen von Refactoring investiere? Kann ja sein, kann nicht sein.

Aber dass man nicht die Technik als Selbstzweck sieht, sondern die Business Ziele nicht aus den Augen verliert, lass es mich so sagen.

Das ist übrigens der häufigste Vorwurf vom Management Richtung Entwicklung, dass die diese Business Seite nicht im Blick haben und nur im Prinzip auf ihr Code oder auf ihr kleines Häuschen achten und nicht einbeziehen, was das für das Unternehmen bedeutet. Ja, haben teilweise recht, teilweise Unrecht. Aber ich persönlich finde, dass es definitiv Sinn macht, dass auch Entwickler ich sage mal so, die generellen Prozesse, Flüsse, Notwendigkeiten eines Unternehmens kennen.

Ja, absolut. Und den Vorwurf, den du hier benannt hast, dass Entwickler sich nur um die Technologie kümmern und vielleicht die Geschäftsidee etwas aus den Augen verlieren, ist gerechtfertigt. Also nicht immer, aber häufig, weil das ist doch schwierig, da genau den richtigen Mittelweg zu finden. Und es gibt da Leute, die nehmen eher eine Abkürzung und sagen Okay, ich mache das technisch nicht so schön, dafür bin ich schnell da. Dann gibt es Leute, die sagen, ich möchte das technisch perfekt machen, auch wenn es sehr, sehr lange dauert.

Es kommt auch ein bisschen auf das Unternehmen an, aber ich glaube, dass man, weil die Business Sicht guckt ja auf Kennzahlen oder auf Termine. Es bringt dir nichts, wenn du den Wahl-O-Mat drei Wochen nach der Wahl fertig hast. Oder wenn du irgendeine Software, die zu einer Messe vorgestellt werden soll, wenn die drei Wochen später fertig ist. Das ist schon so ein harter Anschlag. Da ist manchmal die technisch schlechtere Lösung, die pünktlich fertig ist, viel besser als eine technisch tolle Lösung, die einfach zu spät fertig wird.

Aber die ist dann wertlos.

Gut, also ich denke, Entwicklern sollten auch diese Metriken kommuniziert werden. Selbstorganisation ist auch ein ganz wichtiges Thema.

Wobei wir da, auch wenn du das nicht hören möchte, ich glaube mit Scrum einen Sprung nach vorne machen. Aber dafür müssen die Entwickler natürlich auch die Geschäftsidee kennen und man muss sie ihnen kommunizieren. Das wird ja auch oft so ein bisschen vorenthalten. So macht ihr das mal hier. Wir haben hier eine große Vision.

Ja, man muss in diesem Austausch bleiben. Also ein vertrauensvolles Miteinander zwischen Management und Entwicklung ist auch sehr gut. Das ist jetzt kein Geheimnis, ist auf jeden Fall vorteilhaft. Und dann nützt es was, wenn beide Seiten sich aufeinander zu begeben und auch mal Aufgaben der jeweils anderen Seite übernehmen.

Wenn das Management Scrum und so einführt, sind sie ganz vorne dabei, aber auch ein bisschen agil rum. Die entwickeln sind ja nicht dumm, aber die nutzt das natürlich auch aus. Und sobald einer fragt Wie lange dauert das denn? Es dauert, wie es dauert. Es ist so dieser Klassiker. Wir haben ja eigentlich keine Tage oder Stunden geschätzt.

Acht Story Points dauert es.

Es dauert so lange wie es dauert, es manchmal witzig zu beobachten.

Also ich erlebe es trotzdem, dass sehr, sehr oft auch bei Scrum gesagt wird Ja, 3 Story Points, das ist ungefähr so ein Tag, oder das sind doch wieder so eine Metrik. Aufgemacht wird die dann eben nicht Komplexität als Grundlage hat, sondern einfach zeitlich. Aber es ist auch schwer.

Ich gebe das auch zu als Teammanager. Es ist schwer, weil auf der Geschäfts Seite kommunizierst du halt in Daten.

Wann ist was fertig? Das kennt ja jeder von sich selber. Wenn du ein Auto bestellst und jemand sagt ja, wenn es fertig ist. Also eine unbefriedigende Aussage. Bei Scrum muss man jetzt sagen, alle zwei Wochen purzelten raus. Das heißt, man hat immer etwas, was funktioniert. Man hat nicht nichts und man kann im Grunde sehen, wie es wächst und dann steuernd darauf einwirken. Wenn er eine Frage zur aktuellen Episode hat, schickt uns gerne euer Feedback und die Frage an Podcast Skillbyte Lass uns eine Bewertung da und abonniert unseren Podcast und empfiehlt ihn auch Freunden und Kollegen weiter.

Für mehr spannende Themen könnt ihr auf Skillbyte Slash Blog vorbeischauen Masiar Es war wie immer ein Vergnügen zu diesem sehr wichtigen Thema. Ich wünsche Ihnen noch einen schönen Abend.

Danke! Wünsch dir auch noch. Jetzt mach's gut.