Technische Dokumentation: Mehr Skalierung im Unternehmen

Von Roland Golla
2 Kommentare

„Technische Dokumentation“? „Dafür haben wir keine Zeit!“, oder „Eine technische Dokumentation klingt gut, aber wie setzt man es um?“ Solche Aussagen sind stark verbreitet, wenn es um Webprojekte geht. Im besten Fall gibt es ein Readme File, damit neue Entwickler ihr Projekt lokal einrichten können. Das war es dann auch. Das ist schade, denn eine solche Dokumentation spart viel Zeit, wenn es darum geht, neue Mitarbeiter in bestimmte Prozesse einzuarbeiten. 

Doch was ist eine technische Dokumentation genau? Wikipedia definiert sie wie folgt: 

„Eine Technische Dokumentation (auch Technikdokumentation oder Produktdokumentation) umfasst alle Informationsprodukte, die ein technisches Erzeugnis beschreiben und zu seiner Nutzung, Wartung oder Reparatur anleiten. Sie bereitet die Informationen systematisch auf und strukturiert sie so, dass der jeweilige Zweck vollständig erfüllt wird. Die Technische Dokumentation wird dem dokumentierten Erzeugnis meist über Namens- und Nummernsysteme eindeutig zugeordnet.“

https://de.wikipedia.org/wiki/Technische_Dokumentation

Der Zweck einer solchen Dokumentation ist die:


„Information und Instruktion in der Regel definierter Zielgruppen, der haftungsrechtlichen Absicherung des Herstellers, der Produktbeobachtung, der Rückverfolgbarkeit und Reproduzierbarkeit sowie der dauerhaften bzw. gesetzlich geforderten Archivierung der relevanten Informationsinhalte.“ 

https://de.wikipedia.org/wiki/Technische_Dokumentation

Um es kurz zu machen: Eine solche Dokumentation ist im Grunde eine Anleitung und bietet je nach Kontext auch eine haftungsrechtliche Absicherung.

Ich sage es vorweg: Eine Dokumentation war bisher in unserem Team kein Thema. Vor allem keine technische. 

Bis vor 2 Wochen. Da habe ich einfach mal angefangen, das technische Onboarding von Neukunden zu dokumentieren. Eine solche Dokumentation werden wir auch für neue Mitarbeiter aufsetzen. Das erlaubt uns, bei TESTIFY in der Mitarbeiterzahl zu wachsen. Etwas, was wir dringend brauchen, wenn wir unsere Ziele erreichen möchten.

Unser Marketing-Manager initialisiert automatisierte Website Tests mit der Technischen Dokumentation

Einfach mal in den Urlaub fahren und der Laden läuft. Das ist aktuell bei uns noch nicht der Fall. Bisher müssen in der Firma alle auf mich warten, wenn es um bestimmte Programmierungen geht. 

Anders sieht es, wenn es darum geht, unsere Kunden mit Tests und Reportings zügig auszustatten. Seit Monaten arbeiten wir daran, die dafür nötigen Prozess zu vereinfachen. So haben wir Developer es geschafft, die initiale Tests, für die wir normalerweise Stunden brauchten, in unter 5 Minuten mit nur einer Zeile auf dem Terminal umzusetzen. 

Diese Erfahrungen habe ich genutzt, um eine Anleitung für unsere Nicht-Developer im Team zu erstellen, mit der sie die Tests anlegen können und sie in Git hinterlegen. Wer Git noch nicht kennt: Git ist eine Open-Source-Verwaltungssoftware. Hier lassen sich Dateien in einem Archiv mit Zeitstempel und Benutzererkennung ablegen. Mit der Dokumentation auf Git ist mein Team ohne mich in der Lage, Neukunden technisch aufzusetzen.

Konkret sind wir die Anleitung gemeinsam durchgegangen, haben weitere Schritte ausführlicher erklärt und die fachliche Sprache vereinfacht. Ergänzt wurde die Dokumentation mit hilfreichen Screenshots und weiterführenden Links, um die Anleitung zu ergänzen. 

In meinem Urlaub wurden so acht Projekte aufgesetzt, ohne dass hier ein Programmierer daran beteiligt war. Alle Mitarbeiter zeigen ein gesteigertes technisches Interesse und das Team in unserem Tech-Start-up wächst noch weiter zusammen. 

Langsam fühle ich mich überflüssig und kann mich im Hintergrund auf neue Ideen und Innovationen fokussieren. Was mich freut ist, dass Git jetzt auch schon als Tool beim Marketing angekommen ist. 

Eine Technische Dokumentation hilft bei der Skalierung 

Wie hilft eine Technische Dokumentation jetzt bei der Skalierung? Das hängt meiner Meinung nach vom Produkt ab. In unserem Fall sind es automatisierte Website-Tests.

Als Entwickler weiß ich, wie wichtig es ist, dass Website und Shops einwandfrei funktionieren müssen. Gerade, wenn es darum geht, Leads zu generieren und Kunden ein gutes Nutzererlebnis zu bieten. Mit den Tests stellen wir sicher, dass alle Funktionen (Log-Ins, Newsletteranmeldungen, Formulare, Downloads usw.) reibungslos laufen.

Dazu gehört, dass wir unsere Kunden bei einer Fehlfunktion direkt informieren. Sie erhalten eine Mail und ein Video. Darin können sie genau sehen, wann und wo genau der Fehler im Frontend aufgetaucht ist und was genau nicht funktioniert hat. Das hilft ihnen, im Gegenzug ihren Kunden eine gleichbleibende Qualität zu bieten, eine gute Nutzererfahrung sicherzustellen, Absprünge zu reduzieren oder sogar zu vermeiden. Sie sparen damit nicht nur viel Zeit bei der Fehlersuche, sondern bares Geld.

Für uns ist wichtig, dass unsere Prozesse nicht nur standardisiert sind, um neue Kunden zügig aufzunehmen, sondern jeder im Team nachvollziehen kann, wie alles die Prozesse ablaufen. Schriftlich festgehalten in Git. 

Das heißt: Auch wenn ich im Urlaub bin, ist jeder meiner MitarbeiterInnen in der Lage, die Tests bei jedem neuen Kunden zu implementieren. 

Die Voraussetzung dafür ist, dass wir unser Know-how so einfach wie möglich und leicht verständlich für jeden in unserem Team zugänglich machen. Dafür habe ich einen ersten Entwurf erstellt, bestehend aus Headlines und Text. Für alles habe ich gerade einmal 90 Minuten gebraucht. 

Als ich meine Dokumentation für das Team erneut durchgegangen bin, fiel mir auf, dass weitere Schritte automatisiert werden können. Und vielleicht sogar der gesamte Prozess. Ich bin sogar davon überzeugt, dass wir unsere Abläufe so weit entwickeln können, dass Neukunden selbst dazu in der Lage wären, ihr Onboarding durchzuführen. Das gibt uns ganz neue Möglichkeiten und eine deutliche Ressourcen- und damit Kostenersparnis. Aktuell wäre es aber zunächst ein Wettbewerbsvorteil gegenüber unprofessionellen Tech-Start-ups und ein großer Schritt in Richtung erfolgreicher Software Companies.

Automate all the things – Aufschreiben hilft, die Verbesserungen zu sehen

Und Innovationen entstehen immer dann, wenn wir alle als Team gemeinsam zusammenarbeiten. Technologisch ist uns das mit unserem GitHub Cypress.IO Base Template bereits gelungen. Durch unsere Zusammenarbeit an der Dokumentation ist uns aufgefallen, dass wir weitere Schritte im Onboarding unserer Kunden automatisieren und verbessern können.

Daraus hat sich für uns das Ziel ergeben, unsere neuen Kunden in die Lage zu bringen, sich einfach selbst onboarden zu können. Das spart uns einen halben Tag ein, den uns der Prozess bisher gekostet hat und ist mehr als eine Innovation. Für uns wäre das eine komplette Skalierung für einen offenen Markt, die uns schnell nach vorn bringt. 

Dass eine ausführliche Dokumentation für innovative Tech-Start-Ups und Unternehmen extrem wertvoll ist, zeigte mir auch der Talk von Martin Donath (Material for MkDocs) beim Webworker NRW Meetup von Christian Schäfer – alias der Shepp. Martin erklärte in seinem leidenschaftlichen Talk, wie er mithilfe einer Dokumentation ein GitHub Sponsorings von 100.000 Euro für sein Open Source Projekt bekommen hat

Zu dem Thema war ich bereits angetriggert, da André Neubauer bei dem CTO Special Podcast der programmier.bar in seinem Vortrag aufzeigte, dass für ImmobilienScout24 und SMAVA ohne Dokumentationen gar keine Skalierung möglich gewesen wäre. Die Kombination von beiden Vorträgen hat mich nicht nur begeistert, sondern stark motiviert, weiter nach vorn zu gehen.

Fazit 

Eine Technische Dokumentation hat für uns eine große Nachhaltigkeit. Zum einen halten wir dort wichtige Schritte für den Onboarding-Prozess von Neukunden fest. Zum anderen werde ich als Inhaber entlastet, weil auch Mitarbeiter ohne IT-Know-how in der Lage sind, unsere Kunden Step-by-Step anzulegen.

Ein weiterer wichtiger Faktor ist die Arbeit mit Open-Source-Software und -Tools. Ich bin ein großer Fan von Open Source, weil ich den Transparenzgedanken in der Community sehr schätze. Mit der Bereitstellung unserer Dokumentation in diese Gemeinschaft kann ich ihr etwas zurückgeben. Gleichzeitig sorgen wir als Team dafür, dass unsere Dokumentation stetig wächst. Aktuell für Neukunden und in Zukunft auch mit Prozessen für neue Mitarbeiter. Ich freue mich auf die nächsten Entwicklungen in unserem Team und im Unternehmen. 

2 Kommentare

Tutorials und Top Posts

2 Kommentare

Timo 4. November 2022 - 14:17

Schön, dass du dieses Thema aufgreifst. Ich bin ganz bei Dir, eine Technische Dokumentation ist absolut begrüßenswert, aber im IT-Umfeld ist sie der eigentliche Endgegner für Developer. Wenn sie noch nicht da ist. Ist sie da (und aktuell…), ist die TD die gute Fee und alle finden sie hilfreich. 🙂 Ich finde den Wikipedia-Begriff „Informationsprodukte“ wie häufig im Deutschen sperrig, er trifft aber gut, dass die Gesamtheit der verschriftlichten und/oder visualisierten Informationen eine Dokumentation schaffen (Dokumentierte Anforderungen, der Code selbst, Testergebnisse, Anleitungen zur Nutzung). Um das Ganze aber dann als Technische Dokumentation zu verstehen und zu nutzen, müssen meines Erachtens aus diesen ganzen „Informationsprodukten“ die wichtigen/entscheidenden Informationen extrahiert, zusammengefasst und vereinheitlicht werden, weil das Gesamtwerk an „Informationsprodukten“ sonst dazu führt, dass man die Information, die man gerade sucht, nicht findet (Wiki, Ticket-System, Code/Repository, E-Mail, Gehirne der Team-Mitglieder, Notizzettel aus dem letzten Meeting, etc.). Und an diesem Punkt ist meiner Meinung nach das Dev-Team inkl. PO/PM gefragt, sicherzustellen, dass die TD Teils des Denkens und Handelns von Developer-Rollen wird, also bei Spezifikationen/Akzeptanzkriterien, Schätzungen (Zeit und Komplexität), Code-Reviews immer mitgedacht und mitgemacht wird. Cypress-Tests (bzw. generell automatisierte Tests) finde ich im Übrigen auch ein super, um Funktionsweisen zu dokumentieren! 🙂

Reply
Roland Golla 16. November 2022 - 20:15

Hallo Timo,

vielen Dank für deinen ausführlichen Kommentar und deinen Input. Ich starte ja aktuell auch gerade erst mit dem Thema und bin völlig begeistert. Viele Dinge, die abgelehnt werden bringen mich weiter. Sie machen mich schneller und geben mir mehr Skills. Von daher war es klar, daß ich irgendwann bei technischen Dokumentationen landen werde. Und ich finde es einfach toll.

Viele Grüße
Roland

Reply

Gib uns Feedback

Diese Seite benutzt Cookies. Ein Akzeptieren hilft uns die Seite zu verbessern. Ok Mehr dazu