Der Freigabe-Workflow, den jedes Team hat
Etwas wird angefordert, jemand macht ein Review, Änderungen gehen zurück und irgendwann wird es freigegeben. Tasked macht daraus einen Phasen-Typ, keinen Status. Wenn ein Element in eine Freigabe-Phase eintritt, startet das System eine Freigabe dafür. Das Element kann die Phase nicht über den Freigegeben-Übergang verlassen, bis eine Entscheidung erfasst wurde, und die Person, die entscheidet, kann dies über einen Zugang ohne Account tun. Dasselbe Objekt ist eine Skript-Freigabe, ein finaler Schnitt, ein Marken-Review, ein Release oder ein Kunde, der einen Fix verifiziert.
Eine Phase, kein Status
Wenn ein Element in eine Freigabe-Phase eintritt, startet das System eine Freigabe dafür. Das Element kann die Phase nicht über den Freigegeben-Übergang verlassen, bis eine Entscheidung erfasst wurde. Eine Ablehnung oder eine Änderungsanforderung schickt das Element in die im Workflow definierte Überarbeitungsphase.
Das Freigabe-Workflow-Paket hat diese Struktur: angefordert (Arbeit, 24 Stunden), im Review (Freigabe, 48 Stunden), Änderungen angefordert (Arbeit, 48 Stunden), freigegeben (Arbeit, 24 Stunden), fertig. 'Im Review' ist das Gate. 'Änderungen angefordert' führt zurück zu 'im Review', sobald die Checkliste abgearbeitet ist.
- Freigabe startet beim Eintritt, Verlassen ohne Entscheidung gesperrt
- Eine definierte Überarbeitungsphase für angeforderte Änderungen
- Das Freigabe-Objekt enthält keinen Verweis auf einen Dateityp
Wo die Pakete das Gate platzieren
Werbespots und Imagefilme setzen die Drehbuch-Freigabe vor den Dreh und die Final-Cut-Freigabe vor die Auslieferung. Dokumentarfilme nutzen eine Treatment-Freigabe und eine Final-Cut-Freigabe. Hochzeitsfilme setzen auf eine einzige Final-Cut-Freigabe nach dem kompletten Film. Ein Social-Content-Batch nutzt eine Planungsfreigabe und ein Veröffentlichungs-Gate. Eine Design-Anfrage platziert das Kunden-Review nach dem internen Review. Kampagnen nutzen Marken-Reviews und rechtliche Reviews. Software und Releases setzen auf eine Release-Freigabe. Incidents nutzen eine Kundenverifizierung. Das System dahinter ist in jedem Fall dasselbe Objekt.
Wer entscheiden darf und das Protokoll
Jede Phase benennt die Rollen, die für sie verantwortlich sind. Ein Freigebender außerhalb des Workspace erhält einen Zugang: einen Code, einen Link, eine Telefonnummer oder eine E-Mail-Adresse. Darüber sieht die Person das Element, fügt Notizen hinzu und klickt auf Freigeben, Ablehnen oder Änderungen anfordern. Die Entscheidung wird zusammen mit der Identität des Zugangs, der Uhrzeit und der Information gespeichert, ob sie von einem Mitglied oder über das Portal getroffen wurde.
Jede Entscheidung wird in ein fälschungssicheres Audit-Log (Append-only) geschrieben. Nichts darin kann über die Anwendung bearbeitet oder gelöscht werden. Der Datenexport enthält diese Daten. Webhooks werden bei Entscheidungen mit einem Zustellungsprotokoll ausgelöst. Erinnerungen werden verschickt, bevor die Frist abläuft. Eine Freigabe, die tagelang aussteht, ist ein definierter Grund im Risikowert des Projekts.
Häufige Fragen
- Kann ein Element zwei Freigaben benötigen?
- Ja. Zwei aufeinanderfolgende Freigabe-Phasen, jede mit eigenem Verantwortlichen, Zeitfenster und Überarbeitungspfad. Das Kampagnen-Paket wird so mit Marken-Review und Rechtsprüfung ausgeliefert.
- Was ist, wenn der Freigebende kein Nutzer des Workspace ist?
- Sie erhalten einen Zugang und entscheiden darüber. Kein Account, kein Seat.
- Kann eine Entscheidung später geändert werden?
- Eine neue Entscheidung kann erfasst werden; die vorherige bleibt im Append-only-Log erhalten. Nichts wird überschrieben.
- Ist das nur für Video?
- Nein. Das Freigabe-Objekt ist ein Gate für einen Task und eine Phase. Es funktioniert genauso für ein Skript, ein Design, ein Release oder einen Incident.