La maggior parte dei team vive la compliance come una stagione. Arriva, tutti accantonano la roadmap, circola un foglio di calcolo, vengono raccolte schermate e, dopo alcune settimane, scompare fino alla prossima volta. Il lavoro è reale, ma la forma è sbagliata.
Gli eventi creano panico; i controlli creano abitudini
Qualsiasi cosa accada due volte l'anno è un evento, e gli eventi generano panico, perché l'intervallo tra di essi è esattamente abbastanza lungo da dimenticare tutto ciò che si è imparato l'ultima volta. L'audit diventa una sessione di studio intensivo contro mesi di derive accumulate che nessuno ha monitorato.
Qualsiasi cosa accada su ogni pull request è un controllo. I controlli non generano panico. Generano correzioni piccole e costanti, nello stesso modo in cui fallisce un test. Non si organizza un'esercitazione antincendio trimestrale per i test; i test vengono eseguiti su ogni modifica, quindi il codice rimane sempre vicino alla correttezza. Anche la compliance può funzionare allo stesso modo.
La tassa dell'esercitazione antincendio viene pagata nella peggiore valuta: la concentrazione
Il vero costo della stagione degli audit non sono le ore. È il cambio di contesto. Un team immerso in un problema complesso viene distratto per raccogliere prove relative a modifiche effettuate mesi prima, poi deve tornare a concentrarsi sul problema. Questa tassa è invisibile in qualsiasi budget e enorme nella pratica.
Un controllo che viene eseguito in modo continuo distribuisce quel costo in incrementi così piccoli da sparire. Un riscontro su una PR viene letto nello stesso contesto mentale della revisione del codice in cui si trova. Nessuna stagione, nessun studio intensivo, nessun cambio di contesto.
Rendetela noiosa
L'aspirazione non è rendere la compliance eccitante. È renderla noiosa: un controllo di stato che di solito è verde, occasionalmente segnalerà qualcosa di specifico e lascerà molto meno da scoprire durante la stagione degli audit, perché la maggior parte è stata gestita già al momento della diff.
heygrc pubblica uno stato di controllo GitHub su ogni pull request, basato sui framework selezionati, che è possibile richiedere opzionalmente nella protezione del branch. Lo scopo di un controllo è essere banale. Quello stato noioso e costante è ciò per cui heygrc è stato creato.