Cosa significa tenere un verbale di riunione dal punto di vista legale nello sviluppo di sistemi

Quando un’azienda affida lo sviluppo di un sistema ad un’altra azienda, spesso il contratto firmato con il timbro aziendale dai rispettivi amministratori delegati e il documento di definizione dei requisiti redatto dal responsabile non rendono chiari aspetti come cosa deve essere realizzato e entro quando. Questo perché nella maggior parte dei progetti di sviluppo di sistemi, ci sono scambi quotidiani di e-mail e telefonate a livello operativo, riunioni organizzate da responsabili, durante le quali vengono definite le specifiche inizialmente vaghe, modificate in base ai cambiamenti delle circostanze, richieste di aggiunta di funzionalità e richieste di collaborazione su problemi emersi.

Per gestire efficacemente un progetto di sviluppo di un sistema e prepararsi per eventuali controversie, è fondamentale la creazione e la gestione di documenti.

In questo articolo, spiegheremo come conservare i verbali e i materiali delle riunioni utilizzati nelle riunioni di avanzamento dello sviluppo del sistema da un punto di vista legale.

Perché la gestione dei documenti è così importante nello sviluppo di sistemi

Nel contesto di un progetto di sviluppo di sistemi, mantenere un registro delle discussioni nelle riunioni di verifica, nonché dei progressi e delle circostanze del progetto, è estremamente importante anche da un punto di vista legale. Le ragioni di ciò possono essere riassunte nei seguenti due punti:

Per prevenire controversie in futuro

Lo sviluppo di sistemi è normalmente un progetto che coinvolge molte parti, sia dal lato dell’utente che dal lato del fornitore. Pertanto, se c’è una discrepanza tra la comprensione dell’utente e del fornitore su quanto ciascuno debba assumersi come ruolo e quali obblighi debba assumere, ciò potrebbe ostacolare l’andamento del progetto in futuro.

Inoltre, il fatto che molti individui siano coinvolti in un progetto significa che, se si cambia prospettiva, è facile che si verifichino problemi di comunicazione, come “le persone dicono cose leggermente diverse e non si sa chi ha ragione”.

Non solo è significativo riassumere per iscritto il contenuto dell’accordo per verificare se ci sono discrepanze nella comprensione tra le parti, ma anche riunire le informazioni in un documento che tutti i partecipanti possono verificare (a loro discrezione) contribuirà a mantenere tutti sulla stessa lunghezza d’onda.

A proposito, l’uso della conoscenza legale come mezzo per prevenire la comparsa di conflitti in anticipo è talvolta chiamato “prevenzione legale”.

Per prepararsi in caso di controversie future

Inoltre, se dovessimo spiegare l’importanza della gestione dei documenti da un punto di vista leggermente diverso da quello della prevenzione legale menzionata sopra, potremmo citare il “gestione delle crisi” in previsione di situazioni in cui si verifichino effettivamente controversie.

Immaginiamo una situazione in cui si verifica un problema, il progetto viene interrotto prima che il prodotto finale sia completato, o non si riesce a rispettare la data di consegna originale e si finisce in tribunale. Vale sia per l’utente che per il fornitore, ma se non si dispone di un registro scritto, non si sarà in grado di dimostrare il proprio punto di vista su ciò che è accaduto, e si potrebbe finire in una posizione svantaggiata in tribunale.

In particolare, nei problemi che derivano dal “non rispettare la scadenza”, questioni come “quando e in che modo è stato scoperto l’ostacolo”, “quando è stata fatta la richiesta di modifica delle specifiche”, “come ha risposto il fornitore alla richiesta di aggiunta di funzionalità da parte dell’utente” possono diventare punti critici che possono influenzare l’esito del processo. Se ci sono molti problemi di “ho detto, non ho detto” in queste situazioni, sarà difficile aspettarsi una risoluzione equa delle controversie.

Cosa è particolarmente importante nei verbali delle riunioni di sviluppo del sistema?

Tipi di riunioni nello sviluppo del sistema

Nel corso di un progetto di sviluppo del sistema, si svolgono frequentemente vari tipi di riunioni. Questo non è sorprendente, considerando che molti individui sono coinvolti nel progetto. È comune che i programmatori e gli ingegneri che implementano il programma sul campo di sviluppo tengano regolarmente riunioni per verificare lo stato di avanzamento del lavoro. Inoltre, potrebbero essere necessarie revisioni del codice implementato per verificare l’assenza di problemi come vulnerabilità in termini di manutenibilità e sicurezza.

Oltre a queste riunioni a livello di personale di sviluppo, ci possono essere riunioni in cui partecipano i direttori dell’azienda e i responsabili con autorità. In questi casi, le riunioni spesso servono a definire la direzione generale e le politiche del progetto di sviluppo. Queste riunioni di alto livello, volte a “prendere in mano” questioni importanti, sono spesso chiamate comitati direttivi.

Il comitato direttivo richiede particolare attenzione

Come abbiamo già menzionato, nel contesto dello sviluppo del sistema, vengono pianificate varie riunioni a seconda della posizione delle persone coinvolte e degli obiettivi. Tuttavia, dal punto di vista legale, la riunione che dovrebbe essere considerata particolarmente importante è il comitato direttivo. Rispetto alle riunioni di verifica del progresso e di revisione a livello di personale, il comitato direttivo dovrebbe riconoscere l’importanza della documentazione, soprattutto per prevenire vari conflitti e per le misure da adottare in caso di conflitto. Le ragioni per cui si dovrebbe dire così sono:

1. Il comitato direttivo, essendo una riunione organizzata da persone a livello di responsabilità, spesso coinvolge decisioni importanti e, come tale, è facilmente considerato importante dal punto di vista legale, poiché mostra come utenti e fornitori percepiscono la situazione.
2. Se la riunione è a livello di personale, il contenuto della riunione è spesso riflettuto in vari documenti di progettazione e specifiche, quindi è difficile immaginare realisticamente che si verifichi un problema di “mancanza di documentazione”. (Certo, se anche la documentazione di questi è scarsa, sarà necessario migliorare anche in questo aspetto.)

Possiamo citare questi punti.

Casi giudiziari relativi ai verbali del Comitato Direttivo

Di seguito, presentiamo un caso in cui i verbali di una riunione del Comitato Direttivo sono stati trattati come prove cruciali in un processo reale. Il caso citato nella sentenza sottostante riguarda un progetto di sviluppo di un sistema che si è interrotto a metà, e in cui è stata riconosciuta la violazione dell’obbligo di gestione del progetto da parte del fornitore. Il contenuto dei verbali della riunione ha avuto un significato molto grande nel processo, mostrando la comprensione iniziale di fornitori e utenti.

Il fornitore ha sottolineato che il contenuto dei verbali del Comitato Direttivo, su cui si basa per riconoscere l’andamento dello sviluppo del sistema in questione, è stato modificato dall’utente e non riflette necessariamente la realtà del lavoro. Tuttavia, il Comitato Direttivo è stato istituito con l’obiettivo di prendere decisioni a livello di alta gestione nello sviluppo del sistema in questione, e sia il fornitore che l’utente hanno partecipato, con i responsabili dell’attuazione dello sviluppo del sistema, per fare una valutazione complessiva, condividere i risultati e i problemi del programma e del progresso del lavoro, e prendere decisioni su questioni importanti. E i punti discussi sono stati registrati nei verbali della riunione, creati dal fornitore entro la mattina del secondo giorno lavorativo successivo alla riunione, registrati nel database dei verbali, e utilizzati per registrare le decisioni finali della riunione. Nel confermare i verbali, si può presumere che il fornitore e l’utente abbiano esaminato il contenuto e l’espressione, riconoscendo pienamente l’importanza di registrare il lavoro nei verbali, e li abbiano confermati come riflettenti la realtà della riunione. In particolare, il fornitore, essendo un professionista dello sviluppo di sistemi, avrebbe dovuto essere ben consapevole dell’importanza e del metodo di creazione di tali verbali. Pertanto, è appropriato trattare i verbali confermati come riflettenti la realtà del lavoro del Comitato Direttivo, e a meno che non ci siano circostanze particolari, è appropriato riconoscere che il contenuto del lavoro, ecc., è stato riassunto nel Comitato Direttivo alla data in questione, come registrato lì.

Corte d’Appello di Tokyo, 26 settembre 2013 (Anno 25 dell’era Heisei)

Si può pensare che la posizione del tribunale sia che, se i verbali di una riunione sono creati di comune accordo tra il fornitore e l’utente, essi possono essere considerati come “prove” con un certo potere presuntivo. Da un altro punto di vista, bisogna fare attenzione al fatto che se si scrive troppo facilmente nei verbali, essi possono diventare prove così come sono, e a questo si dovrebbe prestare molta attenzione.

Quali sono gli elementi specifici da registrare nel verbale di una riunione

Il verbale di una riunione ha un’importanza significativa come prova in caso di controversie legali (e anche per facilitare le negoziazioni tra le parti coinvolte). Ma quali sono gli elementi specifici che dovrebbero essere documentati e registrati nel verbale di una riunione? Vediamo di seguito.

Elementi da registrare dal punto di vista del fornitore

Il fornitore ha l’obbligo di gestire il progetto come esperto di sviluppo di sistemi. Per una spiegazione dettagliata di cosa comporta questo obbligo, si veda l’articolo seguente.

Tenendo conto di questo obbligo, gli elementi che il fornitore dovrebbe particolarmente registrare sono:

1. Il fatto che ciascuna fase di sviluppo è stata completata e la data corrispondente
2. La cronologia delle risposte date alle richieste di modifica delle specifiche o di aggiunta di funzionalità ricevute dal lato utente
3. Le misure adottate per richiedere la cooperazione quando il progresso dello sviluppo è ostacolato a causa di circostanze personali del lato utente, e la cronologia di tali eventi

Questi sono solo alcuni esempi.

Per quanto riguarda il punto 3 sopra, per esempio, se il lato utente non effettua l’accettazione, l’articolo seguente spiega cosa dovrebbe considerare il lato fornitore. L’articolo spiega, citando effettivi giudizi di tribunali, come il giudizio del tribunale può variare notevolmente a seconda di quanto il lato fornitore sia stato cooperativo nell’ottenere l’accettazione dell’utente.

Elementi da registrare dal punto di vista dell’utente

Naturalmente, anche l’utente ha un certo obbligo di cooperare con lo sviluppo del sistema, dato che si tratta di un sistema che verrà utilizzato internamente. Per una spiegazione completa di questo obbligo, si veda l’articolo seguente.

1. La cronologia delle informazioni che l’utente dovrebbe comunicare al fornitore, come le funzionalità desiderate e l’aspetto dell’interfaccia utente
2. La cronologia dei vari problemi che si sono verificati durante il processo del fornitore (ad esempio, la partenza improvvisa di un membro del team o il ritardo del programma di sviluppo a causa di una mancanza di ricerca da parte del fornitore, e le cause di tali problemi)

Riguardo al punto 2 sopra, un caso particolarmente incline a problemi imprevisti è quando si sviluppa un nuovo sistema mentre si elimina il sistema esistente. La migrazione dei dati dal sistema esistente al nuovo sistema è particolarmente incline a problemi. Per una spiegazione dettagliata delle questioni legali relative a tali problemi, si veda l’articolo seguente.

Riassunto

Quanto sopra rappresenta le linee guida su come tenere un verbale di riunione dal punto di vista legale nel contesto dello sviluppo di un sistema. Oltre alle pratiche operative, è importante approfondire la comprensione delle connessioni tra temi come “legge”, “sviluppo di sistemi” e “gestione dei documenti”. Proprio perché lo sviluppo di un sistema coinvolge molte persone e organizzazioni e tende a evolvere in transazioni commerciali su larga scala, la prevenzione e la gestione dei conflitti ad esso associati diventano importanti. E dal punto di vista legale, la necessità di conservare le prove porta alla conclusione che la presenza di “documenti” che possono essere verificati oggettivamente da chiunque ha un grande significato.

Certamente, verbalizzare completamente tutte le interazioni e l’evoluzione del progetto può essere oneroso e forse non realistico. Tuttavia, il punto che è importante identificare quali sono le questioni legalmente importanti e procedere con la documentazione di tali questioni come necessario, dovrebbe essere ampiamente riconosciuto da tutti coloro che sono coinvolti nel business, indipendentemente dal fatto che siano o meno esperti di legge.