Warum ist die technische Dokumentation bei der agilen Entwicklung so wichtig?

0:07 Hallo und herzlich willkommen zur 56. Folge des Podcasts "Wege der Digitalisierung". Heute spreche ich mit Manfred Parsson von der Parsson AG. Er wird uns erzählen, was technische Dokumentation und Digitalisierung mit unser aller Alltag zu tun haben und wie sich das über die Jahre gewandelt hat. Das ist ein sehr spannendes Thema. Vorweg eine ganz interessante Ansage für viele, die hier zuhören, sicherlich. Wir sind Medienpartner des zweiten Forums Deutscher Mittelstand geworden. Das ist eine Digitalisierungskonferenz speziell für den Mittelstand, die am 11. und 12. September in Stuttgart stattfinden wird. Es gibt dazu auch einen Rabattcode. Am einfachsten, wer daran teilnehmen möchte, geht über unsere Webseite www.wegederdigitalisierung.de da findet ihr einen Banner, womit man dann auf die Registrierungsseite kommen kann, auch mit einem Rabattcode, über den man 20% Rabatt für diese Messe und die Konferenz bekommt. So, das war der Werbeblog für heute.

1:08 Auf geht's mit Herrn Parson. Vielen Dank fürs Zuhören und auf geht's.

1:15 Schönen guten Tag. Zunächst einmal muss ich sagen, was meine Frau und ich gemacht haben. Hier ist meine Frau Big Boss. Sie ist die Fachfrau, die technische Redakteurin. Ich bin hier im Unternehmen für Finanzen und für Informationssysteme zuständig und habe von daher die Berührungspunkte zur Digitalisierung. Technische Dokumentation ist landläufig bekannt als das Handbuch für die Bohrmaschine aus dem Baumarkt. Kein Gerät in Deutschland darf verkauft werden ohne eine solche Bedienungsanleitung. Das gilt natürlich dann auch für größere Anlagen. Je größer, je komplexer eine Anlage, desto komplexer das Werk. Vieles davon ist auch gesetzlich geregelt. Technische Dokumentation ist erstmal ein großer Kostenfaktor für Hersteller und Hersteller sind natürlich bestrebt, diese Kosten so gering wie möglich zu halten, gleichzeitig aber ihrer gesetzlichen Informationspflicht nachzukommen.

2:25 Große Regularien gibt es zum Beispiel im Bereich Medizintechnik. Man kann sich vorstellen, dass Bedingungsanleitungen einer Herz-Lungen-Maschine schärferen Auflagen unterliegen als für einen Küchenmixer. Aber nichtsdestotrotz, wenn man sich so etwas mal anschaut, es gibt immer Entsorgungshinweise, Warnhinweise. Bitte machen Sie dieses Gerät nicht auf, gehen Sie nicht mit diesem Mixer in die Badewanne und all so etwas, was da drin steht. Wir erstellen vor allem Software-Dokumentation. Also wir haben uns der Dokumentation von Software-Anwendungen verschrieben. Wir dokumentieren Prozesse, beraten in diesem Bereich auch dazu. Und wir beraten Unternehmen im Bereich der Informationsstruktur, des Informationsmanagements.

3:23 Und das ist der eigentlich spannende Teil, weil es tief in die Prozesse, in den Kern dieser Unternehmen eingreift. Informationen sichtbar machen soll. Teilweise sind Informationen verschüttet, nicht zugänglich, nicht am richtigen Platz oder nicht zur richtigen Zeit zugänglich. Wir haben uns auf die Fahnen geschrieben, Informationen verfügbar zu machen, verständlich zu machen und intelligent zu machen. Eine Information soll künftig selbst wissen, wie wichtig sie ist, wo sie hingehört, für wen sie wichtig ist, wann sie gebraucht wird, um sich selbst dorthin zu bringen, wo der Bedarf besteht.

4:10 Wie kann ich mir das als Anwender vorstellen? Also das Handbuch bei der Bohrmaschine aus dem Baumarkt kenne ich.

4:16 Nehmen wir mal einen klein wenig komplexeren Vorgang, Fahrzeugbau. Ein Lkw, das ist so ein Fahrerhaus, Pritsch, ein Motor drin. Und da gibt es jetzt schon mal Informationen, die bei der Entwicklung entstanden sind. Die müssen dokumentiert sein, damit weiterentwickelt werden kann, Dinge an Kollegen übergeben werden können. Also eine interne Dokumentation. Irgendwann soll das Ding, wenn es fertig ist, verkauft werden. Dann braucht das Marketing Informationen über das Fahrzeug, um es irgendwie verkaufen zu können. die Farbe, wie viel PS das Ding hat, wie viele Räder, keine Ahnung was alles. Und dann landet das Ding beim Kunden. Der Kunde kriegt jetzt auch eine Bedingungsanleitung für dieses Fahrzeug.

5:05 Da geht es schon los. Diese Fahrzeuge werden alle konfiguriert. Es gibt kaum gleiche Fahrzeuge. Das heißt, auf dieses Fahrzeug muss diese Dokumentation zugeschnitten sein. Dann muss dieses Fahrzeug gegebenenfalls mal repariert werden. Das heißt, die Werkstatt braucht auch ein Handbuch. Dort sind andere Informationen enthalten als in dem Handbuch fürs Marketing oder für den Kunden. Und dann gibt es noch einen Aufbauhersteller, der auf diese Pritsche irgendwie einen Kran baut oder die Pritsche runterreißt und einen Kipper drauf baut oder irgend so etwas. Der braucht auch Informationen. Wenn jetzt der Ingenieur vorne im Prozess eine Schraube ändert, der sagt also hier, das Ding muss nicht aus Metall sein, das kann Plastik sein, dafür machen wir es dicker und ein anderes Gewinne drauf, dann ist dem Marketing das völlig egal.

6:00 Also die Information über diese Schraube muss nicht zum Marketing. Der Kunde wahrscheinlich ist auch nicht betroffen, aber der Aufbauhersteller und natürlich auch die Werkstatt. Das heißt, diese Information muss wissen, für wen bin ich wichtig? Ich bin eine Schraube, ich habe einen Durchmesser, ich bin möglicherweise sicherheitsrelevant. Vielleicht habe ich ein Zubehörteil, ich muss verklebt werden hinterher, irgend so etwas. Also all diese Informationen muss die Informationen für die Schraube mitbringen, sogenannte Metadaten, nach denen sich diese Informationen dann in zum Beispiel Handbücher einsortieren. Vorteil ist, ich muss diese Informationen alle nur einmal pflegen. vermeide Fehler, abschreibe Fehler und die Handbücher werden etwas dünner.

6:50 Man kennt ja diese Handbücher, wo dann drinsteht, gilt für die Modelle A bis Z mit Ausnahme der Modelle D in Verbindung mit Modell F oder aber auch und so weiter. Diese Schachtelsätze kann kein Mensch lesen, wird man irre bei. Das soll damit aufhören.

7:12 Wow, ja, das macht total Sinn. Ich versuche mir jetzt gerade vorzustellen, an welcher Stelle welche dieser Metainformationen entstehen.

7:26 Das sind Eigenschaften. Metadaten sind Eigenschaften. Um bei der Schraube zu bleiben, hätte man dann eine Gewindegröße, ein Material, möglicherweise eine Farbe, einen Kopf, einen Drehmoment, mit dem die Schraube befestigt werden muss oder eine Sicherheitsinformation muss verklebt sein oder verblombt sein oder irgendetwas. Das wären alles vorstellbare Metadaten.

7:55 Genau, das heißt, diese Informationen über die Schraube würden jetzt irgendwo aus dem Engineering kommen und am Ende hatten Sie ein paar Beispiele gesagt, der Fahrzeugendkunde, die Werkstatt und so weiter, das Marketing.

8:10 Wenn da zum Beispiel das Metadatum sicherheitsrelevant dabei ist oder Aufbau, dann landet das im Werkstatthandbuch, im Aufbau, also im Handbuch für den Aufbauhersteller, nicht beim Marketing. Wenn das der Kotflügel ist oder die Verglasung, das würde möglicherweise auch beim Marketing landen. Weil das ist ein Verkaufsargument, die Sonnenschutzverglasung möglicherweise.

8:43 Wenn ich jetzt mir das vorstelle, das eine ist, also man hat dann eine beliebige Menge von Datenquellen, Diese Metadaten entstehen. Dann habe ich eine beliebige Menge von Daten senken, in diesem Fall Handbücher, die unterschiedliche Zielgruppen haben wollen. Was ist da Ihre Rolle in diesem Konstrukt? Also wie viel Handbuch produzieren Sie und wie viel Metainformation sammeln Sie ein? Und an welcher Stelle sind Sie eher Tool-Hersteller, sage ich mal, und begleiten Prozesse, aber sowohl das Generieren der Handbücher als auch das Eintragen der Daten passieren woanders?

9:26 Also wir, das, ja, depends. Also unsere Spezialstrecke ist halt die Beratung und die Gestaltung des Informationsflusses. Festlegen von Metadaten zum Beispiel. Das Schreiben können wir auch, machen wir aber nicht immer. Manchmal haben diese Unternehmen eigene Dokumentationsabteilungen. Die können das sehr, sehr gut. Wenn dann das erledigt ist, springen wir da an dieser Stelle wieder raus und das Schreiben macht dann niemand anders. Tools selbst stellen wir gar nicht her. Und wenn wir Tools einsetzen, wir haben da auch, sagen wir mal, wir haben schon Zugang zu Herstellern, sodass wir auch Informationen bekommen. aber wir beraten grundsätzlich toolneutral. Wir sind nicht irgendeinem Hersteller verpflichtet.

10:18 Da legen wir auch allergrößten Wert drauf.

10:23 Wenn ich das Ganze jetzt ein bisschen weiterdenke, also weg von so einem sehr spezialisierten Informationsfluss, wie das Beispiel mit der Schraube und so ein Fahrzeug-Reparatur-Handbuch. In jedem Unternehmen gibt es ja Informationsflüsse, auch was interne Prozesse und so weiter angeht. Also im Prinzip, seit ich angefangen habe zu studieren, ist das Wiki als das Allheilmittel gepriesen worden. Ist das auch irgendwo Teil Ihrer Arbeit? Und wenn ja, sehen Sie das als etwas Hilfreiches?

10:58 Also sicherlich nicht als Allheilmittel. Ja, es ist hilfreich, kann hilfreich sein. Aber es ist eben eine Frage dessen, wie man es strukturiert. als dieser Hype aufkam um die Wikis. Da hat man alles in Wikis reingetan, um es dann nie wiederzufinden. Also die Wikis waren dann die modernen File-Server. Das hat sich nicht bewährt. Man muss auch diesen Daten, sind wir wieder beim Thema Metadaten, irgendwas mitgeben. Ich bin eine Arbeitsanweisung. Ich bin bitte alle zwölf Monate zu überprüfen, ob ich noch aktuell bin. Ansonsten muss ich mich irgendwo melden bei meinem Owner, damit ich überprüft werde. Wenn solche Wikis oder auch andere Wissensplattformen, wenn die solche Funktionen nicht mitbringen, mutieren sie ab einer gewissen Größe immer zu einem schwarzen Loch.

11:59 Das ist meine eigene Erfahrung auch in diesem Unternehmen. Wenn man da nicht ganz konsequent hinterher ist und Daten versucht, mit Metadaten anzureichern, wird das nichts werden. Die Datenmengen sind zu groß, das schaffen wir nicht mehr. Und es wird nicht besser werden. Die Datenflut wird nicht abebben oder übersichtlicher werden. Das sehe ich nicht für die Zukunft.

12:30 Okay, das heißt aber, wenn ich mir Gedanken mache, also jetzt bin ich Softwareentwickler und kenne das Konzept der Metadaten aus anderen Kontexten, aber wenn ich jetzt sage, ich habe so ein Wiki, um grundsätzlich Unternehmensprozesse zu dokumentieren, wenn ich da nur mit hinreichend Metadaten beigehe und im Prinzip dem Wiki ein bisschen mehr Intelligenz mit an die Hand gebe, haben Sie die Erfahrung gemacht, dass das funktionieren kann?

12:58 Ja, also wir selbst zum Beispiel haben für unsere Jesu-Zertifizierung die ganzen Prozesshandbücher, also für 9.001, 27.01, die haben wir in einem Wiki untergebracht, parallel und so, dass die Gemeinsamkeiten, die Schnittmengen gekennzeichnet sind. Das ist sehr hilfreich und sehr schlank. Wir sind ja ein recht kleines Unternehmen mit hohen Anforderungen und großen Wünschen. Wir leiden eben daran, dass wir eben auch nicht so viel Manpower haben mit 20, 25 Leuten. Das heißt, das System muss das alleine können und muss übersichtlich sein. Sonst können wir es nicht pflegen. Und diese Anforderungen haben viele.

13:44 Das finde ich jetzt spannend. Also das heißt, eine ISO-Zertifizierung in einem Wiki dokumentiert wird. Das ist cool.

13:51 Ich würde das niemals mehr anders machen. Diese starren PDFs, die sind ja nur Momentaufnahmen. Und ich weiß das aus unserer Erfahrung. Wir sind von einer One-Man-Show zu einem 25-Mann-Unternehmen geworden. da haben sich diese Prozesse permanent irgendwie anpassen müssen. Und wenn wir dann jedes Mal so ein PDF-Dokument da hätten, und so haben wir eben auch solche Sachen wie die Einbindung von Prozessgrafiken, eine Versionierung dabei und wir können gucken, wer hat wann dran rumgeschmiert und können sagen, Mensch Meier, das hast du dann und dann gemacht, was hast du dir dabei gedacht, ich verstehe es nicht, erkläre es mir oder bitte mehr Informationen. das kann ich in so einem PDF immer alles schlecht.

14:46 Vicky ist da schon sehr hilfreich.

14:47 Ich habe es mir damals gewünscht, dass ich habe vor, ich weiß nicht, 15, 16, 17 Jahren mal eine 9001 Zertifizierung für meinen damaligen Arbeitgeber mit begleitet. Und da hatten wir so einen QM-Manager aus der Steinzeit. Also das wurde danach nicht nur als PDF gemacht, das wurde ausgedruckt in jedes Büro gestellt. Und das war ja wertlos in dem Moment, wo es den Drucker verlassen hat.

15:10 Ja, das muss so sein, ja. Okay, aber dass das heute mit Blick geht, dass das geht, das finde ich... Das würden wir ablehnen, das ist ja nur, ja, dann zahlt man Geld, um irgendein Zertifikat zu bekommen, aber es nutzt ja nichts. Und wenn man das nicht als Chance begreift, auch wirklich was in seinem Unternehmen nach vorne zu bringen, dann ist die Sache zu teuer. Dann kann man das sein Geld sinnvoller anlegen.

15:31 Ja, deswegen sind wir bisher noch nicht ISO 9001 zertifiziert, aber dann finde ich...

15:36 Das können wir gerne zeigen. Das geht ganz hervorragend.

15:40 Cool. Okay, damit hatte ich nicht gerechnet, aber das finde ich eine sehr hilfreiche Information. Wahrscheinlich wird der eine oder andere, der hier zuhört, das eben so sehen. Ich erinnere mich, dass wir, als wir uns kennengelernt haben an dem Abend, dass Sie da das Beispiel mit den Fritzboxen gebracht haben, mit der Doku und den CD-ROMs. Falls Sie das nochmal erzählen wollen würden, das fand ich einfach so schön anschaulich. Nicht nur, was einfach technische Doku ist, sondern auch, wie sich auch die technische Dokumentation in sich selbst digitalisiert hat in der Zeit.

16:21 Ich kenne das nicht mal so ganz zusammen, aber tatsächlich habe ich das bei meiner Frau über die Jahre beobachtet. Am Anfang war das Handbuch. Und dann gab es immer zu jedem Release ein neues Handbuch. Natürlich hatte das Handbuch dann die Version was weiß ich was und das wurde gedruckt, das wurde beigelegt und man konnte damals sogar Handbücher nachkaufen. Das muss man sich vorstellen. Dann wurden Handbücher auch elektronisch beigelegt, es kam die Zeit des Downloads. Aber die Beschreibung einer Software beschränkte sich damals auch oft auf die Beschreibung der Oberfläche. Ja, dieser Knopf mit der Schere schneidet aus. Oder wenn Sie diesen Knopf drücken, dann wird, was weiß ich, da Pest gemacht oder irgend so etwas.

17:16 Es war alles nicht Aufgabenorientiert, nicht Taskorientiert. Also wenn ich mir zum Beispiel so eine Personalverwaltung ansehe, dann interessiert mich nicht, was dieser einzelne Knopf macht. Ich habe jetzt das Problem, ich muss einen neuen Mitarbeiter anlegen und muss festlegen, wie viel Urlaub der in seinem Arbeitsvertrag da zu stehen hat und wie viel da im System stehen muss. Diese Frage muss ich stellen können. Früher hat man dann PDFs durchsucht nach Stichworten, auch diese Online-Hilfen, F1 drücken und dann nachschauen. was das System dazu hergibt. Das war eine Zeit lang, mittlerweile ist es so, dass ich eigentlich den Systemen Fragen stellen kann, Freischnauz. Also Office macht das ganz gut vor. Wenn man sich die Office 365 Hilfe anschaut, dann ist das recht gut gelöst.

18:09 Also Microsoft hat dort eine Menge gemacht an der Stelle. Das ist einfach ein komplexes Produkt. Die mussten das tun. Und da sie agil entwickeln, haben sie eben das Problem, dass diese Innovationszyklen, die Releases, auch immer in kürzeren Abständen rauskommen. Man kann dann nicht mehr ganze Handbuchstrukturen irgendwie anpassen, sondern man muss Einzelinformationen ändern, anpassen und sie müssen sich trotzdem in ein Gesamtwerk fügen. Das Gesamtwerk aber auch nur insofern, ich will das nicht falsch verstanden wissen, niemand baut heute mehr ein Handbuch, das man von vorn nach hinten liest. Sondern üblicherweise habe ich ein Problem und dann suche ich Hilfe. Und dann schaue ich in die Dokumentation, in die Online-Hilfe, was steht denn dazu?

19:00 Finde ich mein Problem dort wieder? Wenn ich mein Problem dort nicht wiederfinde, dann ist die Dokumentation leider schlecht. Handbücher liest kein Mensch.

19:13 jetzt ist ja die software die man irgendwo runter lädt und die sich dann vier jahre nicht

19:17 ändern auch nicht mehr teil der welt das cloud software die man kriegt die änderungen oft gar nicht mit man schaltet am nächsten morgen ein und oft merkt man gar nicht dass sich unter der haube was geändert hat oder man sieht oh mensch heute alles im blau was haben sie denn hier gemacht Dann muss man schauen, dass man eben die Informationen, die der Anwender sucht, dass man sie auch findet. Das Problem ist oft, dass in der Softwareentwicklung viele Funktionen gebaut werden, die so aber vom Anwender gar nicht gesucht werden. Oder auch gar nicht so sehr wertgeschätzt werden. Obwohl der Softwareentwickler extrem viel Hirnschmalz da reingesteckt hat und viel Mühe, der Anwender nutzt das oft nicht so, wie wir uns das denken.

20:14 Es ist sehr, sehr wichtig zu gucken aus Anwendersicht, das ist immer diese Zielgruppenorientierung, von der gesprochen wird. Wenn ich mir so ein Hochschulsystem zum Beispiel angucke, wir haben so einen Kunden, da hat der Verwaltungsbereich ganz andere Anforderungen als der Studierende oder der Prof, der seine Benotungen dort vornimmt. Also wir haben ganz, ganz unterschiedliche Blickwinkel darauf und all dem sollte im Idealfall die Softwareentwicklung dann gerecht werden können.

20:48 Jetzt weiß ich nicht, wie viel Einblick Sie in die Entwicklungsprozesse bei der Software selber haben.

20:54 Sagen wir mal so, wir haben auch Kunden, wo wir nichts weiter machen, als die Softwareentwicklung zu begleiten. Das heißt, wir stellen die Scrum Master oder den Product Owner, weil in dem Unternehmen ist jemand, der diese Rolle ausfüllt. Dann machen wir das sozusagen mit und dann verkommt, wenn ich das mal so ausdrücken darf, die technische Dokumentation dann zum Beiwerk, weil wir die dann nebenbei schreiben. Also das machen wir auch.

21:26 Jetzt gibt es ja die eine Art von Firma, wo die Entwickler irgendwo im Keller versteckt werden und also weit weg von jedem Kundenkontakt ein Zeug bauen. Und es gibt die Unternehmen, wo die Entwickler sehr eng am Kunden sind, also mindestens durch einen Product Owner schnelles Feedback kriegen, eventuell sogar selber mal im Kundenservice sitzen müssen. Wenn Sie da bei einigen Firmen Einblick haben in die Entwicklungsprozesse, ist denn die Dokumentation oder der Input, den Sie bekommen, für die Dokumentation da besser, wo die Leute eng am Kunden sind?

22:02 Ja. Grundsätzlich ja. Wobei ich, also diese Einteilung, diese Klassifikation kenne ich auch. Meines Erachtens ist das aber nicht der kriegsentscheidende Faktor für den Erfolg eines Softwareentwicklungsprojekts, sondern was lässt der Kunde zu, worauf lässt er sich ein und wie genau ist er in der Lage, seine Wünsche zu formulieren. Das ist eigentlich egal, ob ich diesen weißkäsigen, im Keller wohnenden Entwickler habe oder der da ständig bei dem Kunden drumherum schubert. Wenn der Kunde seine Prozesse nicht offenlegt, nicht bereit ist, seine Prozesse zu überdenken, diese Prozesse aufzuschreiben und auch wirklich vollumfänglich zur Verfügung zu stellen, dann hat jeder Softwareentwickler erstmal ein Problem.

23:02 Er entwickelt dann etwas und hinterher kommen die üblichen Querelen. Das beobachten wir überall, wo wir auftauchen. Für uns ist es immer sehr schön, wenn wir am Anfang des Entwicklungsprozesses mit eingebunden werden, wenn wir gleich, also auch im agilen Prozess, also mitschreiben können. Das vereinfacht die Sache für uns und macht das gesamte Projekt günstiger. Wenn das Produkt erst fertiggestellt ist, wir dann anfangen, die Dokumentation zu schreiben, ist der Klassiker, dass wir beim Erstellen der Dokumentation feststellen, dass die Software nicht den Anforderungen entspricht, sich so nicht bedienen lässt, die Qualität nicht stimmt oder ähnliches. Und solche Softwareprojekte verlängern sich dann also immer um Monate.

23:52 Ja gut, ich denke, solche Projekte kennt jeder irgendwo aus seinem Arbeitsalltag. Gut, das ist aus unserer Perspektive im Prinzip einen Schritt weiter gedacht. Also wir machen ja nun genau solche Softwareprojekte. Wenn bei uns jemand ankommt und ein fertiges Lastenheft hat, dann ist das eigentlich immer ein schlechtes Zeichen. Also im Idealfall holt man die, die es umsetzen sollen, auch frühzeitig ins Boot und denkt halt Wertschöpfungsketten und Endkunden schon mal vor durch.

24:25 Genau so ist das.

24:26 Aber gut, das macht natürlich Sinn, dass das bei der Doku, das ist ja letztendlich einfach im Idealfall ein paralleler Arbeitsprozess, aber das Ergebnis kann ja erst fertig werden, wenn die Software auch fertig ist.

24:38 Nein, nein, da widerspreche ich ganz vehement. Wir können sogar Dokumentation einsparen, wenn wir wissen, also wenn wir vorne eingebunden sind im Entwicklungsprozess, können wir die Gestaltung der Software so weit beeinflussen, dass wir Dokumentationen sparen, dass wir sie dann nicht brauchen. Oder Prozesse versuchen anders zusammenzufassen, dass wir Dokumentationen schlanker gestalten, dass wir eben nur für einen bestimmten Bereich eine Online-Hilfe machen, für den was weiß ich, Administrationsbereich eine völlig andere. Also da können wir eingreifen und in hohem Maße zum Erfolg beitragen. nein, also wenn wir reinkommen, wenn das Produkt fertig ist, ist es zu spät. Dann ist schon was schief gelaufen.

25:28 Also das ist ein weit verbreiteter Irrglaube.

25:31 Wie oft so prozedural gesehen passiert das?

25:35 Dass wir zu spät reinkommen? 80% der Fälle würde ich mal schätzen. Weil Entwickler das nicht auf dem Schirm haben. Die denken wirklich, also sie müssen erst fertig sein, damit jemand kommen kann. Dann fehlt den Entwicklern oft auch das Vertrauen, dass jemand anders das beschreiben kann, was sie da gemacht haben und verstehen gar nicht, dass es darum gar nicht geht. Das ist, also bei API-Dokumentation vielleicht. Aber wenn ich für Anwender oder Administratoren irgendwelche mache, geht es ja um eine völlig andere Zielgruppe. Das ist leider in der Software-Erstellung immer ein großer Knackpunkt.

26:18 Gut, 80% ist hart.

26:20 Ja, es wird da extrem viel Geld verbrannt. Das ist wirklich leider so. Deswegen glaubt auch niemand an den Erfolg von Softwareprojekten, weil das eben so häufig ist. Wenn man sich so, ich darf den Kunden jetzt nicht nennen, aber das ist ein großes Verwaltungssystem, mit öffentlichen Geldern finanziert und ja, dann kommen wir auch, das Produkt ist beim Kunden installiert. Dann kommen wir und sollen das dokumentieren und stellen dann fest, naja, die haben sich nicht richtig unterhalten, Auftraggeber und Auftragnehmer. Das Produkt passt nicht zu den Anforderungen und umgekehrt. Das ist immer wieder dasselbe. Ja, und dann, das war in diesem Fall so, dass wir angefangen haben im, ich glaube, Oktober. Das sollte dann im März online gehen, das System.

27:24 Nun, das war im Oktober 2017 und wir sprachen vom März 2018, das ist jetzt online. Wow. Und auch nur, weil wir wirklich mit viel Know-how und mit viel Manpower da reingegrätscht sind, sonst wäre das Projekt wirklich, es hätte nicht funktioniert.

27:47 Ich denke gerade an das agile Manifest, das irgendwo sinngemäß sagt, wir wertschätzen laufende Software höher als umfangreiche Dokumentationen. Und andersrum, ich habe ja am Anfang meiner Karriere irgendwo so Steuergeräte für fliegendes Gerät mitentwickelt, wo ja die Dokumentationsanforderungen auch mal massiv anders sind, als man das von so einer Websoftware heute kennt. Ich glaube ja nach wie vor daran, dass man agile Entwicklung, also die positiven Teile, die an agiler Entwicklung hängen, auch in sicherheitskritischen Embedded-Projekten nutzen kann. Trotzdem habe ich das Gefühl, dass das agile Manifest bei allem Gutem, das es bewirkt hat, auch vieles so ein bisschen in einen Abgrund getreten hat, wo Dinge vorher auf der Kante waren.

28:37 Da würde mich jetzt interessieren, rein aus dem Blick dieser Dokumentation von Prozessen und Produkten, hat da die agile Entwicklung Ihnen die Tour eher noch schwerer gemacht oder war es vorher ähnlich?

28:51 Nein, würde ich nicht sagen. Da hat sich, glaube ich, so viel gar nicht geändert. Und es ist da kein Widerspruch aus meiner Sicht. Also wir schätzen funktionsfähige Software oder auch einen Baustein höher als umfangreiche Dokumentation. Ja, na klar. Ich muss jetzt auch nicht vollumfänglich alles dokumentiert haben und ein riesen Bohai, ein riesen Handbuch aus allem machen. Das ist auch nicht erforderlich. Wozu denn? Und die Dokumentation ist ja mehr als das Aufschreiben von irgendeinem Status, sondern es soll ja dem Nutzer nachher den Mehrwert bieten, sofort herauszufinden, wie komme ich hier am schnellsten zum Ziel. Und bei dem Versuch, das aufzuschreiben, sehe ich ja schon, ob das funktioniert oder nicht.

29:48 Wir sind die ersten Beta-Tester. Also wir schreiben das auf. Und wenn wir merken, das geht nicht, dann kommt die Rückmeldung ganz schnell. Also wirklich agil. Ey Jung, komm, mach nochmal. Das kommt sonst erst beim Kunden rum.

30:11 Ja, das macht Sinn.

30:12 Und da geht es nicht darum, also vollumfänglich und alles in schick oder so. Muss man nicht. Sondern es geht darum, dass man guckt, ob eine Sache funktionieren kann oder nicht. Und da gliedern wir uns voll ein. Immer gucken, ist das Ding lebensfähig? Wenn ja, weitermachen. Wenn nicht, wegschmeißen, neu. Ja, so gesehen macht das Sinn. Das ist natürlich viel billiger als jetzt, egal wie ich die Sprints gestalte, damit zum Kunden zu gehen. Weil das kostet zumindest Zeit. Dann ist der Fachmann beim Kunden, der ist im Urlaub, im Krankenhaus, Elternzeit, was weiß ich was, dann bleibt das liegen. Und ja, was macht man in der Zeit? Weitermachen. Und dann kommt der irgendwann und sagt, nee, Leute, das funktioniert leider so nicht.

31:07 Ja, dann schmeißt man große Brocken weg. Das wollte man eigentlich nicht, deswegen macht man ja kurzes Prinz. Also es macht Sinn, also gleich von Anfang an, nur um diesen begrenzten Aspekt mal zu betrachten, also da die Dokumentation von Anfang an mit zu beteiligen. Das geht damit los, dass die Dokumentation oder der technische Redakteur zunächst einmal User-Stories schreibt. Das machen klassischerweise Redakteure, nicht Entwickler. Und das ist ganz vorne im Prozess. Wenn die User-Stories Mist sind, dann haben wir dieses Input-Output-Problem.

31:49 Genau, ja. Okay, ja, das ist spannend. Also jetzt machen wir ja oft Sachen, bei denen Doku erforderlich ist, sodass das für uns Teil des Prozesses ist, aber dass man das als Teil des agilen Feedback-Prozesses sehen kann. Das ist ein neuer Gedanke für mich. Das ist wertvoll.

32:12 Und damit sind wir wirklich erfolgreich. Diese Projekte laufen butterweich und machen Spaß. Und das bringt erheblichen Mehrwert.

32:24 Cool. Was ist denn die große Herausforderung, die man unter diesem Buzzword Digitalisierung nennen könnte, an der Sie jetzt als nächstes arbeiten?

32:38 Die große Herausforderung ist herauszufinden, was das alles bedeutet. Zu schauen, wie wir mit dem immer größer werdenden und immer schneller werdenden Informationsfluss, mit dieser Informationsmenge umgehen können. Bei gleichzeitig sinkenden personellen Ressourcen. Wir haben immer weniger Menschen, die das tun können. Es werden nicht genug Leute ausgebildet, weil einfach auch nicht genügend da sind. Also wir müssen uns etwas überlegen, wie wir Prozesse automatisieren, wie wir Informationen so intelligent machen, dass sie sich selbst automatisieren. Da steckt dann immer so ein bisschen das Stichwort künstliche Intelligenz dahinter. Das Handbuch, das sich selber schreibt, ist so ein bisschen die Utopie, um das mal auf die Spitze zu treiben.

33:39 Aber schlussendlich müssen wir deutlich effizienter werden. Das wird die größte Herausforderung im nächsten Jahr.

33:51 Ja, das Handbuch, das sich selber schreibt, erinnert mich so ein bisschen an die Software, die sich selber schreibt. Wo ich mich immer frage, wie würde man einfach nur ingenieurmäßig, technisch gedacht, wie kriegt man denn den Input so hin, dass ein nicht selbstdenkendes System das gut macht? Aber ich denke, die Antwort wird die gleiche sein.

34:13 Ja, also wir müssen da, also ich sehe nicht, dass es uns gelingt, da irgendwie den großen Sprung zu machen. Da setzen wir beide uns hin und machen mal so ein bisschen in künstliche Intelligenz und dann kommt da irgendwie sowas raus, was dann am Ende des Tages die Weltherrschaft übernimmt. So wird es nicht laufen. Aber es wird in kleinen Schritten Effizienzfortschritte geben müssen. Sonst schaffen wir einfach die Arbeit nicht. Wir sind ja jetzt schon in der Situation, dass wir völlig ausgebucht sind, Aufträge ablehnen müssen. Und das sind teilweise richtig spannende Projekte, die wir gerne machen würden, aber können nicht. Das ist auch nicht so, dass dieser Auftraggeber, dieser Potenziale so ganz einfach jemand anders findet.

34:58 Oft werden Projekte nicht gemacht, weil nicht gelungen Fachkräfte da sind. Die sind deutschlandweit nicht zu finden. Und das ist ein Zustand, dem müssen wir irgendwie entgegenwirken. Wir können nicht alles irgendwie mit Outsourcing beantworten. Stichwort Indien, China, sonst irgendwie. Das wird so nicht auf Dauer funktionieren. Also müssen wir dort in kleinen Schritten zumindest zusehen, wie wir die Effizienz steigern und Informationen dazu bringen, dass sie sich selbst verwalten. Ein Stück weit zumindest. Und dann schauen wir weiter.

35:29 Ja, aber ein guter Anfang. Sie hatten schon im Vorfeld gesagt, ich hätte die Quellenfrage ankündigen sollen. Trotzdem gibt es Quellen, die Sie empfehlen wollen oder können, mit denen man sich da aktuell halten kann?

35:44 Wenn man sich mit Digitalisierung beschäftigt, dann kommt man zwangsläufig auch immer so ein bisschen auf Internet der Dinge, Industrie 4.0. Spannend werden sein die Entwicklung der Standards, an denen jetzt geschraubt wird. Da bauen viele verschiedene Interessengruppen an Standards. Wir sind auch beteiligt daran. Da könnte man den ARDS-Standard, an dem auch die TECOM, also Berufsverband der Technischen Redakteure, beteiligt ist, nennen. Da tun sich spannende Sachen. Ob sich das am Ende durchsetzen wird, das wissen wir heute noch nicht. Das ist wie mit den VHS-Kassetten dazu mal. Es gewinnt nicht immer das technisch beste System. Wir müssen gucken, wo da die Marktmächte verteilt sind. Gerade durch Tool-Hersteller wird da viel getrieben, aber auch viel gebremst. Das ist, wenn jemand politische Studien betreiben möchte, bestimmt sehr interessant. Aber es ist fürs Fortkommen des Standards leider im Moment nicht so ideal.

37:13 Zumal da eben auch auf internationaler Ebene sehr wenig passiert. Das sind oftmals nationale Bestrebungen.

37:21 Ja, wie so oft leider. Okay, letzte Frage. Gibt es jemanden, den Sie gerne in einem späteren Interview mal von mir ausgefragt hören würden?

37:38 Das schaffe ich jetzt alles nicht aufzuzählen. Ich würde Ihnen da eine Liste zukommen lassen.

37:43 Okay, perfekt. Das lassen wir gelten. Okay, dann bin ich soweit durch mit meinen Fragen. Also ich glaube, ich könnte jetzt aus meiner Entwicklerbrille raus noch ganz viel weiterfragen, aber ich weiß nicht, wie spannend das noch für zuhörende Leute ist.

37:59 Ich bedanke mich.

38:00 Ja, ganz vielen Dank für Ihre Zeit, für das Wissen. Ich glaube, dass das wirklich sehr, sehr spannend für viele Leute war, weil es halt jeden irgendwie betrifft. Ja. Einen schönen Tag, Jeno. Super. Ganz vielen Dank. Das war die 56. Folge des Podcasts Wege der Digitalisierung mit Manfred Parson von der Parson AG. Vielen Dank fürs Zuhören. Wie immer teilt das Ganze gerne in den Netzwerken eurer Wahl. Schreibt uns Kommentare, schreibt uns E-Mails, bewertet uns bei iTunes. Vielen Dank fürs Zuhören. Ich hoffe, dass ihr auch viele spannende Sachen gelernt habt. Nochmal der Hinweis, wie schon am Eingang, wir sind Medienpartner des Zweiten Forums Deutscher Mittelstand. Eine spannende Digitalisierungskonferenz mit Fokus auf Mittelstand in Stuttgart am 11. und 12. September.

38:52 Wer daran teilnehmen möchte, kann über unsere Webseite www.wegederdigitalisierung.de den Weg finden zum Registrierungsformular. Dabei steht auch ein Rabattcode, über den man 20% Rabatt auf die Tickets kommt. Vielen Dank fürs Zuhören, bis zum nächsten Mal und vielleicht sehen wir uns in Stuttgart.