People operations

Ritardi · timer · un pulsante sul nodo

L’onboarding è per lo più attesa, e la maggior parte delle sue automazioni fa scattare tutto il primo giorno perché tenere un processo aperto per undici giorni è costoso. Qui non lo è: un ritardo è un evento con un orario futuro su di sé, un controllo ripetuto è una riga di timer, e un’esecuzione parcheggiata su un pulsante costa una riga.

Il grafo del periodo di prova è un’unica esecuzione che si estende su tre mesi, si risveglia tre volte per sollecitare il manager, e termina da sé dopo l’ultima. Il suo periodo è l’unica cosa che un deployment cambia.

Come funzionano i grafi

1. Sei voci della checklist distribuite a ventaglio ai rispettivi proprietari

   Ciascuna datata a ritroso dalla data di inizio.

2. Un ritardo mentre l’ordine dell’attrezzatura si definisce

   Un evento con un orario su di sé, non un worker fermo ad aspettare.

3. Un pulsante sul nodo per ‘la postazione è pronta’

   Perché quella risposta non ha bisogno di alcuna motivazione allegata.

4. Un’esecuzione, tre check-in, novanta giorni

   Armato come una riga di timer che sopravvive a ogni riavvio.

Sul canvas

flow:delay · flow:interval · ui:trigger · entities:create · views:*

Viene distribuito con il prodotto

Questo progetto viene distribuito con DjiniousWorkflow. Un comando lo popola, un altro esegue ogni grafo al suo interno, e le schermate qui provengono da quelle esecuzioni.

Dove un grafo si appoggia a un fixture anziché a un sistema live, legge il fixture nel punto in cui il tuo deployment leggerebbe un database — sostituisci il nodo in cima e il resto del grafo non cambia. Il lavoro del motore — il fan-out, la raccolta, l’approvazione, la pubblicazione — è quello proprio del prodotto.