La pregunta es por qué la junta rechaza la especificación una y otra vez.

¿Plantean las mismas preocupaciones en cada iteración? Luego, deben proporcionar una mejor retroalimentación al autor por qué lo rechazan y qué cambios se requieren.

¿Le dieron retroalimentación al autor pero el autor se niega a realizar los cambios? Entonces es necesario que haya un diálogo directo entre la junta y el autor sobre por qué estos cambios deben / no deben realizarse.

¿Surgen nuevas preocupaciones sobre cosas que ya existían antes? Luego, deben tomar su trabajo de revisión más en serio y proporcionar comentarios combinados. En lugar de dar una razón para el rechazo, deben dar todas las razones para el rechazo.

¿Presentan nuevas preocupaciones sobre cosas que fueron no antes? Entonces, de hecho, podría ser necesario someter el documento a otro ciclo de revisión.

¿Es solo un juego de poder que algunos miembros del tablero están jugando con el autor? Entonces tiene un problema social que resolver, y no puede hacerlo con un proceso.

El enfoque más productivo podría ser reunir a arquitectos y desarrolladores en una sola mesa y hacer que se unan un consenso sobre lo que debe suceder para que el documento pase por el ciclo de revisión.

No puedo decir mucho sin ver un ejemplo, pero estoy seguro de que su empresa no le permitirá publicar un documento técnico en la web. Pero hay varias cosas que puede ver:

1. La naturaleza de los problemas: ¿continuamente encuentran fallas en las mismas cosas? Si es así, debe averiguar por qué el desarrollador no lo hizo bien la primera vez.

2. ¿La naturaleza de las sugerencias es vaga? p.ej. "Es necesario mejorar esta área" o "Eso no nos gusta mucho". Los revisores deben ser lo más específicos posible. ¿El desarrollador comprende por qué es necesario realizar los cambios?

3. ¿Existe un documento de tipo de requisitos comerciales al que el desarrollador pueda vincular cada especificación técnica? De lo contrario, el desarrollador puede sentir que debe intentar adivinar parte de la lógica empresarial.

4. ¿Los revisores cambian de opinión? ¿Están en conflicto entre sí? ¿La revisión se hace en una sola reunión o es como el documento que se les reenvía a cada uno individualmente y todos regresan con comentarios diferentes sin verse entre ellos? Esto último podría ser una gran causa de múltiples revisiones sobre temas que podrían ser mejor discutidos y acordados en una sola reunión. (Incluso si no parece haber un conflicto entre los comentarios, esto podría causar una reelaboración evitable)

5. ¿Cuál es el nivel de experiencia del desarrollador? ¿Están comprendiendo correctamente lo que quiere el revisor? ¿Están tomando sus propias decisiones o suposiciones basándose en lo que creen que es mejor en lugar de pedir una aclaración al revisor?

6. Pregunte a los revisores y al desarrollador por qué ellos creo que el documento debe ser revisado continuamente.

7. ¿Podría ser que las reglas comerciales no se hayan definido completamente (o que los revisores no las hayan entendido) y que hay nuevas información o decisiones a un nivel superior entre iteraciones?

Esto es un error de gestión. El proceso se configuró incorrectamente y se asignaron las personas equivocadas a las tareas. La forma de solucionar esto es cambiar el proceso y asignar las personas adecuadas a las tareas adecuadas.

No está claro dónde encaja usted aquí. Tenga en cuenta que hay varias cosas diferentes llamadas "especificaciones". En el nivel más alto, están las especificaciones de requisitos. Esto dice qué se supone que debe hacer el producto, no cómo se supone que debe hacerlo. Luego hay una especificación arquitectónica de alto nivel. Eso explica cómo se estructurará todo. Este es el nivel del diagrama de bloques. Luego están las especificaciones detalladas de la interfaz que le dicen a los ingenieros individuales cómo su pieza debe encajar con las piezas diseñadas por otros. Cuanto más joven sea el ingeniero, más se podría incluir esto en pistas o edictos directos sobre cómo se harán las cosas dentro de las especificaciones de la interfaz.

La especificación de requisitos de alto nivel generalmente proviene de personas que se enfrentan al cliente que ven una necesidad o un nicho. Luego, deben sentarse con ingenieros superiores para analizar qué es posible dentro de lo que ven como la oportunidad.

En mi preferencia, la ingeniería luego escribe una descripción de alto nivel de lo que hará el producto y se la pasa a otros hasta que estén de acuerdo en que eso es lo que les gustaría tener. A veces no hay suficiente superposición entre lo que se desea y lo que es posible, y el proyecto termina ahí.

Después de eso, todo depende de la ingeniería. En este punto, deja que un arquitecto senior piense en cómo atacar el problema y crear la breve especificación arquitectónica. Después de eso, la organización depende bastante de cómo especificar los detalles. En un equipo pequeño, puede que no haya ninguna especificación formal en este nivel. En un equipo grande, a menudo deja que esto evolucione a medida que los ingenieros individuales comienzan a diseñar, con personas de arquitectura senior que monitorean y guían a medida que avanza el diseño. En mi experiencia, formalizar este paso en especificaciones detalladas antes de que se realice el diseño no es una buena idea. Debe esperar que los niveles bajos del diseño evolucionen con el tiempo, siempre que el arquitecto o el ingeniero jefe continúe involucrado y esté atento al panorama general.

Tenga en cuenta que el proceso que describe no lo hace ' t encaja bien en cualquier lugar arriba. Como dije, su proceso está roto. Se trata de un error de gestión y solo se puede abordar como tal.

Esta es una consecuencia natural de que el valor de un documento revisado no esté bien definido. Considere, ¿cuál es la diferencia entre una especificación y una especificación revisada? En el caso de una especificación que pasaría la revisión, el contenido es el mismo, por lo que la diferencia claramente no está en el contenido de la especificación. La diferencia debe ser que la bendición de la junta de revisión tiene un significado para las personas. Esto es muy razonable en los negocios: una bendición de una junta de revisión indica que el uso de la información está más justificado.

Sin embargo, existe un límite para esto, que puede haber alcanzado. Si el valor del sello de aprobación de la junta de revisión se vuelve demasiado grande, se ven obligados a ser extremadamente quisquillosos. Lo que proporcionan al proceso es su nombre, declarando "sí, en verdad, esta especificación es buena". Si una empresa se niega a utilizar cualquier documento hasta que pase la junta de revisión, es muy fácil entrar en situaciones degenerativas en las que la junta de revisión pierde de vista su propósito. Se meten en problemas si bendicen algo que no estaba bien, por lo que si no comprenden completamente cómo se usará la especificación bendita, naturalmente la romperán en pedazos para asegurarse de que nada malo vuelva a morderlos.

Esto provoca un problema con las especificaciones que no necesitan este nivel de rigor. Si su especificación realmente necesita ser bendecida al más alto nivel porque la empresa va a tomar decisiones clave a partir de esa información, entonces puede ser deseable ese rigor. En ese caso, la decisión debe ser lo suficientemente importante como para que los miembros de la junta de revisión puedan trabajar con el desarrollador en un entorno fuera de línea para garantizar que la especificación se apruebe cuando se revise. Este es un truco común en los negocios: nunca traiga nada a la mesa a menos que ya se haya asegurado de que pasará.

Si su empresa no necesita realmente este nivel de rigor, pero no tiene una forma de implementarlo, entonces la empresa tiene un problema importante que no es culpa del desarrollador ni de los revisores. El negocio simplemente no tiene una forma de crear información procesable a un ritmo lo suficientemente rápido como para mantenerse al día con el negocio. El negocio necesita cambiar. Es posible que pueda crear una junta de revisión de nivel inferior que permita a las personas usar la especificación en una forma limitada y solo llamar a la junta de revisión final cuando todos se sientan cómodos con el documento (nuevamente, nunca lo lleve a la reunión a menos que sepa pasará la prueba).

Las formas de hacer esto son muchas, pero el primer paso sería identificar si la especificación realmente garantiza el nivel de atención que está recibiendo. La forma correcta de responder a la situación depende en gran medida de qué tan acorde sea el proceso para la tarea.

Cuando trabajé en un campo diferente, tuvimos un problema similar en una revisión técnica. La solución fue que un gerente muy senior tomara a todas las personas que tenían que aprobar el documento y al autor del documento y los pusiera en una sala de reuniones de la que no se les permitía salir hasta que se finalizó el documento. En este punto, esta es la única forma en que la especificación saldrá por la puerta.

Dicho esto, parece que la persona equivocada redacta las especificaciones para empezar, por lo que no es sorprendente que no cumplan con la calidad necesidades de los arquitectos. Una vez que solucione este problema en particular, debe analizar detenidamente todo el proceso y asegurarse de que no está preparando a las personas para el fracaso.