Die Frage ist warum lehnt das Board die Spezifikation immer wieder ab.

Haben sie bei jeder Iteration die gleichen Bedenken? Dann müssen sie dem Autor ein besseres Feedback geben, warum sie es ablehnen und welche Änderungen erforderlich sind.

Haben sie dem Autor Feedback gegeben, aber der Autor weigert sich, die Änderungen vorzunehmen? Dann muss es einen direkten Dialog zwischen Vorstand und Autor darüber geben, warum diese Änderungen vorgenommen werden müssen / nicht.

Erheben sie neue Bedenken hinsichtlich der Dinge, die bereits zuvor vorhanden waren? Dann müssen sie ihren Überprüfungsjob ernster nehmen und gebündeltes Feedback geben. Anstatt einen Grund für die Ablehnung anzugeben, müssen sie alle Gründe für die Ablehnung angeben.

Machen sie neue Bedenken in Bezug auf Dinge, die waren nicht dort vorher? Dann könnte es tatsächlich notwendig sein, das Dokument einem weiteren Überprüfungszyklus zu unterziehen.

Ist es nur ein Machtspiel, das bestimmte Vorstandsmitglieder mit dem Autor spielen? Dann müssen Sie ein soziales Problem lösen, und das können Sie nicht mit einem Prozess tun.

Der produktivste Ansatz könnte darin bestehen, Architekten und Entwickler an einem Tisch zusammenzubringen und sie zu erreichen einen Konsens darüber, was geschehen muss, um das Dokument durch den Überprüfungszyklus zu bringen.

Ich kann nicht viel sagen, ohne ein Beispiel zu sehen, aber ich bin sicher, Ihr Unternehmen erlaubt Ihnen nicht, ein technisches Dokument ins Internet zu stellen! Es gibt jedoch mehrere Dinge, die Sie betrachten können:

1. Die Art der Probleme - finden sie ständig Fehler an denselben Dingen? Wenn ja, müssen Sie herausfinden, warum der Entwickler es beim ersten Mal nicht richtig gemacht hat.

2. Sind die Vorschläge vage? z.B. "Dieser Bereich muss verbessert werden" oder "Das gefällt uns nicht wirklich". Die Gutachter müssen so spezifisch wie möglich sein. Versteht der Entwickler, warum die Änderungen vorgenommen werden müssen?

3. Gibt es ein Dokument vom Typ Geschäftsanforderungen, mit dem der Entwickler jede technische Spezifikation verknüpfen kann? Wenn nicht, hat der Entwickler möglicherweise das Gefühl, dass er versuchen muss, einen Teil der Geschäftslogik zu erraten.

4. Ändern die Prüfer ihre Meinung? Widersprechen sie sich? Wird die Überprüfung in einer Sitzung durchgeführt oder ist es so, als würde das Dokument einzeln an sie weitergeleitet, und alle kommen mit unterschiedlichen Kommentaren zurück, ohne sich gegenseitig zu sehen? Letzteres könnte eine große Ursache für mehrere Überprüfungen von Punkten sein, die besser in einem einzigen Meeting herausgearbeitet und vereinbart werden könnten. (Auch wenn es keinen Konflikt zwischen Kommentaren zu geben scheint, kann dies zu vermeidbaren Nacharbeiten führen.)

5. Wie hoch ist die Erfahrung des Entwicklers? Verstehen sie richtig, was der Rezensent will? Treffen sie ihre eigenen Entscheidungen oder Annahmen auf der Grundlage dessen, was sie für am besten halten, anstatt den Prüfer um Klärung zu bitten?

6. Fragen Sie die Prüfer und den Entwickler, warum sie denken, dass das Dokument kontinuierlich überprüft werden muss.

7. Könnte es sein, dass die Geschäftsregeln nicht vollständig festgelegt wurden (oder von den Überprüfern verstanden wurden) und dass es neue gibt Informationen oder Entscheidungen auf einer höheren Ebene werden zwischen den Iterationen getroffen?

ol>

Dies ist ein Verwaltungsfehler. Der Prozess wurde falsch eingerichtet und den Aufgaben wurden die falschen Personen zugewiesen. Die Möglichkeit, dies zu beheben, besteht darin, den Prozess zu ändern und die richtigen Personen den richtigen Aufgaben zuzuweisen.

Es ist nicht klar, wo Sie hier hineinpassen. Denken Sie daran, dass es verschiedene Dinge gibt, die als "Spezifikationen" bezeichnet werden. Auf höchster Ebene gibt es die Anforderungsspezifikationen. Dies sagt was i> das Produkt tun soll, nicht wie es das erreichen soll. Dann gibt es eine hohe architektonische Spezifikation. Das erklärt, wie alles strukturiert sein wird. Dies ist die Blockdiagrammebene. Dann gibt es detaillierte Schnittstellenspezifikationen, die einzelnen Ingenieuren mitteilen, wie ihr Teil mit den von anderen entworfenen Teilen zusammenpassen muss. Je jünger der Ingenieur ist, desto mehr kann dies zu Hinweisen oder direkten Erläuterungen dazu führen, wie die Dinge innerhalb der Schnittstellenspezifikationen ausgeführt werden.

Die Spezifikation für hohe Anforderungen stammt im Allgemeinen von Kunden, die einen Bedarf sehen oder eine Nische. Sie sollten sich dann mit hochrangigen Ingenieuren zusammensetzen, um herauszufinden, was innerhalb der von ihnen als Chance erachteten Möglichkeiten möglich ist.

Nach meiner Präferenz schreibt das Engineering dann eine allgemeine Beschreibung der Funktionsweise des Produkts und gibt diese an andere zurück, bis sie sich einig sind, dass dies das ist, was sie gerne hätten. Manchmal gibt es nicht genügend Überschneidungen zwischen dem, was gewünscht und dem, was möglich ist, und das Projekt endet dort.

Danach liegt alles am Engineering. An diesem Punkt lassen Sie einen leitenden Architekten darüber nachdenken, wie er das Problem angreifen und die kurze Architekturspezifikation erstellen kann. Danach ist es ziemlich organisationsabhängig, wie die Details spezifiziert werden. In einem kleinen Team gibt es auf dieser Ebene möglicherweise überhaupt keine formale Spezifikation. In einem großen Team lässt sich dies häufig weiterentwickeln, wenn einzelne Ingenieure mit dem Entwerfen beginnen, wobei leitende Architekturmitarbeiter den Fortschritt des Entwurfs überwachen und leiten. Meiner Erfahrung nach ist es keine gute Idee, diesen Schritt vor dem Entwurf in detaillierte Spezifikationen zu formalisieren. Sie müssen damit rechnen, dass sich die niedrigen Ebenen des Entwurfs im Laufe der Zeit weiterentwickeln, solange der Architekt oder Chefingenieur weiterhin involviert ist und auf das Gesamtbild achtet.

Beachten Sie, dass der von Ihnen beschriebene Prozess nicht funktioniert. passt nirgendwo oben gut. Wie ich schon sagte, dein Prozess ist kaputt. Dies ist ein Verwaltungsfehler und kann nur als solcher behoben werden.

Dies ist eine natürliche Folge davon, dass der Wert eines überprüften Dokuments schlecht definiert ist. Überlegen Sie, was der Unterschied zwischen einer Spezifikation und einer überprüften Spezifikation ist. Im Fall einer Spezifikation, die die Überprüfung bestehen würde, ist der Inhalt derselbe, sodass der Unterschied eindeutig nicht im Inhalt der Spezifikation liegt. Der Unterschied muss sein, dass der Segen des Prüfungsausschusses für die Menschen eine Bedeutung hat. Dies ist im Geschäftsleben sehr vernünftig: Ein Segen eines Prüfungsausschusses zeigt an, dass die Verwendung der Informationen gerechtfertigter ist.

Es gibt jedoch eine Grenze, die Sie möglicherweise erreicht haben. Wenn der Wert des Genehmigungsstempels des Prüfungsausschusses zu hoch wird, müssen sie extrem pingelig sein. Was sie dem Prozess zur Verfügung stellen, ist ihr Name, der erklärt: "Ja, diese Spezifikation ist wahrlich gut." Wenn sich ein Unternehmen weigert, ein Dokument zu verwenden, bis es das Überprüfungsgremium passiert hat, ist es sehr leicht, in entartete Situationen zu geraten, in denen das Überprüfungsgremium seinen Zweck aus den Augen verliert. Sie geraten in Schwierigkeiten, wenn sie etwas segnen, das nicht richtig war. Wenn sie also nicht vollständig verstehen, wie die gesegnete Spezifikation verwendet wird, zerreißen sie sie natürlich in Stücke, um sicherzustellen, dass nie etwas Schlimmes zurückkommt, um sie zu beißen.

Dies führt zu einem Problem bei Spezifikationen, für die diese Genauigkeit nicht erforderlich ist. Wenn Ihre Spezifikation tatsächlich auf höchstem Niveau gesegnet werden muss, weil das Unternehmen aus diesen Informationen wichtige Entscheidungen treffen wird, ist diese Genauigkeit möglicherweise erwünscht. In diesem Fall sollte die Entscheidung wichtig genug sein, damit die Mitglieder des Überprüfungsausschusses in einer Offline-Umgebung mit dem Entwickler zusammenarbeiten können, um sicherzustellen, dass die Spezifikation bei der Überprüfung bestanden wird. Dies ist ein gängiger Trick im Geschäftsleben: Bringen Sie niemals etwas auf den Tisch, es sei denn, Sie haben bereits sichergestellt, dass es erfolgreich ist.

Wenn Ihr Unternehmen diese Genauigkeit nicht wirklich benötigt, aber keine Möglichkeit zur Implementierung hat, hat das Unternehmen ein großes Problem, das weder vom Entwickler noch von den Gutachtern zu vertreten ist. Das Unternehmen hat einfach keine Möglichkeit, umsetzbare Informationen schnell genug zu erstellen, um mit dem Geschäft Schritt zu halten. Das Geschäft muss sich ändern. Möglicherweise können Sie ein untergeordnetes Überprüfungsgremium erstellen, das es den Benutzern ermöglicht, die Spezifikation in begrenzter Form zu verwenden, und das endgültige Überprüfungsgremium nur dann aufrufen, wenn alle mit dem Dokument vertraut sind (bringen Sie es niemals zur Besprechung, es sei denn, Sie wissen es es wird den Test bestehen).

Es gibt viele Möglichkeiten, dies zu tun, aber der erste Schritt wäre zu identifizieren, ob die Spezifikation tatsächlich das Maß an genauer Aufmerksamkeit verdient, das sie erhält. Die richtige Art und Weise, auf die Situation zu reagieren, hängt stark davon ab, wie angemessen der Prozess für die Aufgabe ist.

Als ich in einem anderen Bereich arbeitete, hatten wir ein ähnliches Problem bei einer technischen Überprüfung. Die Lösung bestand darin, dass ein sehr leitender Manager alle Personen, die das Dokument genehmigen mussten, und den Autor des Dokuments in einen Besprechungsraum stellte, den sie nicht verlassen durften bis das Dokument fertiggestellt wurde. Zu diesem Zeitpunkt ist dies der einzige Weg, auf dem die Spezifikation aus der Tür kommt.

Das heißt, Sie haben anscheinend die falsche Person, die die Spezifikationen erstellt, sodass es nicht verwunderlich ist, dass sie die Qualität nicht erfüllen Bedürfnisse der Architekten. Sobald Sie dieses spezielle Problem behoben haben, müssen Sie sich Ihren gesamten Prozess genau ansehen und sicherstellen, dass Sie keine Mitarbeiter für Fehler einrichten.