La domanda è perché il consiglio rifiuta la specifica più e più volte.

Sollevano le stesse preoccupazioni ad ogni iterazione? Quindi devono fornire un feedback migliore all'autore perché lo rifiutano e quali modifiche sono necessarie.

Hanno fornito feedback all'autore ma l'autore si rifiuta di apportare le modifiche? Quindi ci deve essere un dialogo diretto tra il consiglio e l'autore sul motivo per cui questi cambiamenti devono / non devono essere fatti.

Sollevano nuove preoccupazioni su cose che erano già presenti prima? Quindi devono prendere più seriamente il loro lavoro di revisione e fornire feedback in bundle. Invece di dare una motivo per il rifiuto, devono fornire tutti i motivi per il rifiuto.

Sollevano nuove preoccupazioni su cose che erano non lì prima? Quindi potrebbe essere effettivamente necessario sottoporre il documento a un altro ciclo di revisione.

È solo un gioco di potere che alcuni membri del consiglio stanno giocando con l'autore? Allora hai un problema sociale da risolvere e non puoi farlo con un processo.

L'approccio più produttivo potrebbe essere quello di riunire architetti e sviluppatori su un tavolo e farli venire un consenso su ciò che deve accadere per portare il documento attraverso il ciclo di revisione.

Non posso davvero dire molto senza vedere un esempio, ma sono sicuro che la tua azienda non ti permetterà di mettere un documento tecnico sul web! Ma ci sono diverse cose a cui puoi guardare:

1. La natura dei problemi: trovano continuamente difetti nelle stesse cose? In tal caso, è necessario capire perché lo sviluppatore non ha capito bene la prima volta.

2. La natura dei suggerimenti è vaga? per esempio. "Questa zona deve essere migliorata" o "Non ci piace molto". I revisori devono essere il più specifici possibile. Lo sviluppatore capisce perché è necessario apportare le modifiche?

3. Esiste un documento relativo ai requisiti aziendali a cui lo sviluppatore può collegare ciascuna specifica tecnica? In caso contrario, lo sviluppatore potrebbe ritenere di dover provare a indovinare alcune delle logiche di business.

4. I revisori cambiano idea? Sono in conflitto tra loro? La revisione viene eseguita in una riunione o è come se il documento fosse inoltrato a ciascuno individualmente e tutti tornano con commenti diversi senza vedersi l'un l'altro? Quest'ultimo potrebbe essere una grande causa di più revisioni su elementi che potrebbero essere meglio smentiti e concordati in una singola riunione. (Anche se non sembra esserci un conflitto tra i commenti, ciò potrebbe causare una rielaborazione evitabile)

5. Qual è il livello di esperienza dello sviluppatore? Comprendono correttamente ciò che vuole il revisore? Stanno prendendo le proprie decisioni o ipotesi sulla base di ciò che pensano sia meglio invece di chiedere chiarimenti al revisore?

6. Chiedi ai revisori e allo sviluppatore perché ritengono che il documento debba essere continuamente rivisto.

7. Potrebbe essere che le regole aziendali non siano state completamente fissate (o comprese dai revisori) e che ci siano nuove informazioni o decisioni a un livello più alto tra le iterazioni?

Questo è un errore di gestione. Il processo è stato impostato in modo errato e le persone sbagliate sono state assegnate alle attività. Il modo per risolvere questo problema è cambiare il processo e assegnare le persone giuste ai compiti giusti.

Non è chiaro dove ti trovi qui. Tieni presente che ci sono diverse cose chiamate "specifiche". Al livello più alto, ci sono le specifiche dei requisiti. Questo dice cosa dovrebbe fare il prodotto, non come dovrebbe farlo. Poi c'è una specifica architettonica di alto livello. Questo spiega come sarà strutturato tutto. Questo è il livello del diagramma a blocchi. Poi ci sono specifiche di interfaccia dettagliate che dicono ai singoli ingegneri come la loro parte deve combaciare con le parti progettate da altri. Più l'ingegnere è giovane, più questo potrebbe andare in suggerimenti o editti definitivi su come le cose saranno fatte all'interno delle specifiche dell'interfaccia.

Le specifiche dei requisiti di alto livello provengono generalmente da persone che si confrontano con i clienti che vedono una necessità o una nicchia. Dovrebbero quindi sedersi con gli ingegneri senior per esporre ciò che è possibile all'interno di ciò che vedono come un'opportunità.

A mia preferenza, l'ingegneria scrive quindi una descrizione di alto livello di ciò che farà il prodotto e la trasmette ad altri finché non concordano che è quello che vorrebbero avere. A volte non c'è abbastanza sovrapposizione tra ciò che si vuole e ciò che è possibile e il progetto finisce qui.

Dopodiché, dipende tutto dall'ingegneria. A questo punto si lascia che un architetto senior pensi a come affrontare il problema e creare le specifiche architettoniche brevi. Dopodiché, dipende dall'organizzazione come specificare i dettagli. In un piccolo team, potrebbe non esserci alcuna specifica formale a questo livello. In un team numeroso, spesso lasci che questo si evolva quando i singoli ingegneri iniziano a progettare, con gli esperti di architettura che monitorano e guidano mentre la progettazione progredisce. Formalizzare questo passaggio in specifiche dettagliate prima che la progettazione sia completata non è una buona idea nella mia esperienza. Devi aspettarti che i bassi livelli del design si evolvano nel tempo, a condizione che l'architetto o l'ingegnere capo continui a essere coinvolto e attento al quadro generale.

Nota che il processo che descrivi non funziona. t si adatta bene ovunque sopra. Come ho detto, il tuo processo è rotto. Si tratta di un errore di gestione e può essere risolto solo come tale.

Questa è una conseguenza naturale del valore di un documento revisionato che è mal definito. Considera, qual è la differenza tra una specifica e una specifica rivista? Nel caso di una specifica che passerebbe la revisione, il contenuto è lo stesso, quindi la differenza chiaramente non è nel contenuto della specifica. La differenza deve essere che la benedizione del comitato di revisione ha un significato per le persone. Questo è molto ragionevole negli affari: una benedizione di un comitato di revisione indica che l'uso delle informazioni è più giustificato.

Tuttavia, c'è un limite a questo, che potresti aver raggiunto. Se il valore del timbro di approvazione del comitato di revisione diventa troppo grande, sono costretti a essere estremamente pignoli. Ciò che forniscono al processo è il loro nome, che dichiara "sì, in verità, questa specifica è buona". Se un'azienda rifiuta di utilizzare qualsiasi documento fino a quando non supera il comitato di revisione, è molto facile entrare in situazioni degenerate in cui il comitato di revisione perde di vista il proprio scopo. Si mettono nei guai se benedicono qualcosa che non era giusto, quindi se non capiscono appieno come verrà utilizzata la specifica benedetta, la ridurranno naturalmente a brandelli per assicurarsi che niente di male tornerà mai a morderli.

Ciò causa un problema per le specifiche che non richiedono questo livello di rigore. Se la tua specifica ha davvero bisogno di essere benedetta al massimo livello perché l'azienda prenderà decisioni chiave sulla base di tali informazioni, allora quel rigore potrebbe essere desiderato. In tal caso, la decisione dovrebbe essere sufficientemente importante da consentire ai membri del comitato di revisione di lavorare con lo sviluppatore in un ambiente offline per garantire che la specifica venga approvata quando viene rivista. Questo è un trucco comune negli affari: non portare mai nulla al tavolo a meno che non ti sei già assicurato che passerà.

Se la tua azienda in realtà non ha bisogno di questo livello di rigore, ma non ha un modo per implementarlo, allora l'azienda ha un grosso problema che non è colpa né dello sviluppatore né dei revisori. L'azienda semplicemente non ha un modo per creare informazioni utilizzabili a un ritmo abbastanza veloce da tenere il passo con il business. L'azienda deve cambiare. Potresti essere in grado di creare un comitato di revisione di livello inferiore che permetta alle persone di utilizzare le specifiche in una forma limitata e chiamare il comitato di revisione finale solo quando tutti sono a loro agio con il documento (di nuovo, non portarlo mai alla riunione a meno che tu non sappia supererà il test).

I modi per farlo sono molti, ma il primo passo sarebbe identificare se la specifica garantisce effettivamente il livello di attenzione che sta ottenendo. Il modo corretto di rispondere alla situazione dipende fortemente da quanto il processo è commisurato all'attività.

Quando lavoravo in un campo diverso, abbiamo riscontrato un problema simile in una revisione tecnica. La soluzione era che un manager molto senior prendesse tutte le persone che dovevano approvare il documento e l'autore del documento e le mettesse in una sala riunioni da cui non era consentito lasciare fino alla finalizzazione del documento. A questo punto, questo è l'unico modo in cui la specifica uscirà dalla porta.

Detto questo, sembra che tu abbia la persona sbagliata a redigere le specifiche per cominciare, quindi non sorprende che non soddisfino la qualità esigenze degli architetti. Una volta risolto questo particolare problema, è necessario esaminare attentamente l'intero processo e assicurarsi di non impostare le persone per il fallimento.