Ein Takt, denIhr Fachbereichmitgeht.

Kein Wasserfall, kein Agilitäts-Theater. Alle zwei Wochen etwas, das man installieren und benutzen kann, und ein Ansprechpartner, der Ihre Sprache spricht.

01WOCHE 1–3

Discovery

Mehrere Gespräche, bis wir verstanden haben, worum es geht. Nicht als Formsache, sondern weil ein Angebot ohne dieses Verständnis geraten wäre.

  1. 01.1

    Erstes Gespräch

    Was läuft heute wie, wo hakt es, und wer arbeitet später damit. Eine halbe Stunde reicht meistens, um zu sagen, ob eine App das richtige Werkzeug ist.

  2. 01.2

    Nachfassen, bis es sitzt

    Meist zwei bis drei weitere Termine mit den Menschen, die den Ablauf kennen. Wir fragen so lange nach, bis wir ihn selbst erklären könnten.

  3. 01.3

    Was mitspielen muss

    Welche Systeme hängen dran, wer darf was sehen, welche Schnittstelle gibt es wirklich und welche nur auf dem Papier.

  4. 01.4

    Angebot statt Schätzung

    Am Ende ein Umfang, den wir vertreten können, mit benannten Risiken und einem Festpreis. Keine Konzeptmappe.

Danach liegt vor:
  • Gesprächsprotokoll
  • Systemlandkarte
  • Rollenmodell
  • Risikoliste
  • Festpreis
  • 02WOCHE 3–6

    Erste Version

    Eine erste lauffähige Version am echten Gerät, benutzt von den Menschen, die später damit arbeiten.

    v1
    1. 02.1

      Designsystem statt Screendesign

      Echte Komponenten, die später im Code genauso heißen, nicht 40 Einzelbilder.

    2. 02.2

      Installiert auf echten Geräten

      Nicht im Simulator, sondern auf den Telefonen, auf denen die App später läuft. Ältere Modelle inklusive.

    3. 02.3

      Test durch echte Nutzer

      Bedient von den Menschen, die später damit arbeiten, nicht nur von uns.

    4. 02.4

      Freigabe

      Erst wenn die Menschen, die damit arbeiten, den Ablauf ohne Erklärung schaffen.

    Danach liegt vor:
  • Designsystem
  • Lauffähige Version
  • Nutzertest
  • Freigabe
  • 03WOCHE 6–20

    Bauen im Zweiwochentakt

    Sie sehen den Fortschritt auf dem eigenen Gerät, nicht im Statusbericht. Was nicht funktioniert, merken wir in Woche 6, nicht in Woche 26.

    W2W6W10W14zwei Wochen
    1. 03.1

      Alle 14 Tage eine Version

      Installierbar und benutzbar auf Ihrem eigenen Gerät, dazu eine kurze Liste, was neu ist.

    2. 03.2

      Review mit dem Fachbereich

      Ein kurzer Termin mit den Menschen, die die App später benutzen, nicht mit der Projektleitung allein.

    3. 03.3

      Änderungsbudget

      15 % des Umfangs sind für Kurskorrekturen reserviert. Sie sind eingeplant, nicht erstritten.

    Danach liegt vor:
  • TestFlight-Build
  • Änderungsvideo
  • Review-Protokoll
  • Änderungsbudget
  • 04AB RELEASE

    Release & Betrieb

    Eine App wird nicht benutzt, weil sie fertig ist, sondern weil die Einführung funktioniert hat und danach jemand zuständig bleibt.

    1. 04.1

      Pilotgruppe

      Erst eine kleine Gruppe, die alle Rollen abdeckt, dann alle. Mit fester Runde, in der Rückmeldungen zusammenlaufen.

    2. 04.2

      Mitbestimmung

      Wo ein Betriebsrat zustimmen muss, etwa bei Zeiterfassung, planen wir das früh ein und nicht kurz vor dem Start.

    3. 04.3

      Betriebsübergabe

      Am Tag des Go-live läuft das Betriebspaket bereits, inklusive Monitoring und Rufnummer.

    4. 04.4

      Quartalsgespräch

      Vier Mal im Jahr: Was lief, was kostet es, was kommt als Nächstes.

    Danach liegt vor:
  • Store-Release
  • Pilotgruppe
  • Monitoring
  • SLA
  • Quartalsbericht
  • Starten Sie mit einer Discovery.

    Zwei bis vier Wochen, ein fester Preis, und am Ende wissen Sie, was Ihre App kostet und ob sie sich lohnt.