Der Projektablauf folgt unserem bewährten Vorgehensmodell oder richtet sich nach den Abläufen im Entwicklungsteam.
Klassisches Vorgehensmodell
Für Dokumentationsprojekte, die ganz in unserer Hand sind, wenden wir unser bewährtes Vorgehensmodell an. Das Projekt wird hier in kontrollierbare Phasen unterteilt:
- Projektplan – wir erstellen einen Projektplan, den Sie abnehmen.
- Konzept – wir schreiben ein Konzept, das Sie abnehmen.
- Input – Sie liefern den Input, wir sichten ihn.
- Korrekturvorlage – wir schreiben und liefern eine Korrekturvorlage, die Sie prüfen.
- Endversion – wir erstellen die Endversion, die Sie abnehmen.
- Fertige Dokumentation – wir produzieren die fertige Dokumentation und liefern Ihnen alle Sourcen und Ergebnisse.
Dabei orientieren wir uns natürlich an Ihren Release-Terminen und versuchen Sie auch kurzfristig zu unterstützen. Kontaktieren Sie uns möglichst frühzeitig, wenn Sie ein neues Release planen. Dann bleibt genug Zeit für eine qualitativ hochwertige und vollständige Dokumentation.
Agile Dokumentation
Wenn Sie agil mit Scrum entwickeln, können wir uns in Ihr Team und Ihre Abläufe integrieren:
- Teilnahme an Review- und eventuell Stand-Up-Meetings
- Verwendung von Jira als Input und für Dokumentationsaufgaben
- Iterative Dokumentation
Neue Funktionen können so zeitnah dokumentiert werden, die Dokumentation wird fortlaufend geprüft. Kurz vor dem Release muss dann nur noch die Endversion erstellt werden.
Welchen Input braucht eolas?
Wir verwenden alle Informationen, die Sie uns zum Produkt geben können, zum Beispiel:
- Spezifikationen
- Jira-Tasks
- Interviews mit den Entwicklern
- interne Wikis
- die Software selbst
Ein Systemzugriff für das Arbeiten mit der Software ist sehr hilfreich und erspart Ihnen viel expliziten Wissenstransfer. Der Zugriff kann beispielsweise über eine Testinstallation bei uns im Haus, über einen VPN-gesicherten Remote-Zugang oder über eine gesicherte Website geschehen. Sollte dies nicht möglich sein, vereinbaren wir gerne Termine bei Ihnen im Haus.
Was wird beim Review erwartet?
Wenn Sie eine Korrekturvorlage zum Review erhalten, sollte idealerweise jemand die Dokumentation lesen, der das Produkt im Überblick kennt und trotzdem auch Detailfragen beantworten kann oder zumindest den richtigen Ansprechpartner kennt.
Das kann zum Beispiel eine technische Produktmanagerin sein, ein Product Owner, oder ein erfahrener Entwickler.
Während des Reviews sollten Sie vor allem auf Folgendes achten:
- Vollständigkeit
- sachliche Richtigkeit
Über die sprachliche Korrektheit, Verständlichkeit und die Formatierung müssen Sie sich keine Gedanken machen, das ist unsere Aufgabe. Die Dokumente, die Sie zum Review bekommen, haben bereits einen internen Korrekturlauf bei uns hinter sich.
Wann bekommen Sie die Endversion?
Den Liefertermin für die Endversion vereinbaren wir mit Ihnen in der Regel schon zu Projektbeginn. Oft muss der Termin noch angepasst werden, weil sich in der Entwicklung Verzögerung ergeben, oder ein Reviewer gerade keine Zeit für das Korrekturlesen hat. Hier sind wir flexibel und tun unser Bestes, um Ihnen rechtzeitig zum Release die Dokumentation zu liefern.