¿Tratar con especificaciones malas / incompletas / poco claras? [duplicar]

Si está encontrando problemas durante la etapa de diseño, ¿realmente tiene un problema?

Asegúrese de que aquellos que crean las especificaciones no sientan que tienen que hacer todo por adelantado. No pueden pensar en todo y nosotros tampoco. También deben saber que no pueden hacer un cambio total en algún documento de especificaciones y luego terminar con el proyecto. Esta práctica también lleva a que agreguen todo lo que puedan pensar porque "pueden" necesitarlo y si no lo piden ahora, lo obtendrán. Deben estar disponibles para revisar, probar y aprobar sus requisitos una y otra vez.

No intentes diseñar o construir toda la aplicación a la vez. Cualquier proyecto / aplicación se puede dividir en algún tipo de fases, partes, módulos o como quieran llamarlo. No tienes que ser ágil si eso no es lo tuyo. Comience con la pieza de seguridad del usuario y vaya desde allí.

Tómate un tiempo para sentarte con estas personas y descubrir lo que realmente quieren. Me encantaría que alguien me entregara especificaciones que me permitieran crear todo el proyecto a la vez, pero ¿qué haría durante el próximo año y medio?

Uso el Cono de incertidumbre ^{Diga con una voz fuerte y fuerte}

Básicamente, usted hace la mejor estimación que puede dar a la información que tiene.
Pero también señala que dada la imprecisión en las especificaciones, existe una gran incertidumbre en estas estimaciones (la gestión de puntos en el sitio para que puedan leer sobre el principio).

A medida que avanza hacia el objetivo y ajusta las especificaciones, puede actualizar su estimación y reducir la incertidumbre.

Sí, soy generoso con las estimaciones. No olvides la ley de Hofstadter

Ley de Hofstadter: siempre lleva más tiempo de lo esperado, incluso si se tiene en cuenta la Ley de Hofstadter. De Gödel, Escher, Bach: Una trenza dorada eterna.

El proceso que estás describiendo es bastante normal. El problema es que los tipos de negocios tienden a pensar las cosas en términos de "la fase de requisitos", luego "la fase de diseño", etc. Cuando un equipo está creando un producto, realmente necesita un enfoque iterativo. Un par de ideas que encontré trabajo son:

• Defina los objetivos principales para los cambios propuestos / nueva aplicación. Estos son objetivos relacionados con el negocio, como "reducir el costo de procesamiento de reclamos en un 10%" o "compartir el estudio de mercado de nuestras oficinas satélites para que los productos satisfagan mejor las necesidades de nuestros clientes". Ayuda a concentrarse en los requisitos abiertos sobre cuáles son las necesidades reales.
• Haga su SWAG inicial (Seriously Wild-A ** Guess) para los requisitos incorrectos a medida que se escriben, pero documente lo que usted asumió que será la implementación. Este es un comentario que la gente de negocios (y su cliente) necesitan mejorar y pensar en estas cosas. Ellos confían en usted para ellos.
• Si tiene una opción entre una estimación realmente larga y una muy corta, siempre vaya largo. Es probable que sorprenda a quien te pida que hagas un trabajo, lo cual es bueno. Los obligará a los dos a discutir qué es lo que realmente buscan.

Recuerde que su primera estimación no puede ser precisa. Base sus estimaciones en interpretaciones razonables de los requisitos que obtiene, y documente sus suposiciones / interpretaciones. Habrá más requisitos derivados de los agujeros que descubrió. Esto es normal.

Ser generoso con las estimaciones puede sonar bien, pero ¿qué problema resuelve? No mejorará las especificaciones, no facilitará la planificación. Es decir "no puede ser mucho peor que X", a diferencia de decir que "podría ser Y". La verdad es que no lo sabes. Averigua lo que puedas.

Si los analistas de negocios deben involucrar a los desarrolladores antes, infórmales. Un informe escrito no es realmente el mejor método de comunicación. Si puede contar con la ayuda de un desarrollador para reunir los requisitos iniciales y con un analista de negocios que lo ayude con el desarrollo y las pruebas, sus resultados serán mejores.

Acabo de leer el Cono de incertidumbre; Es bueno, pero es fácil equivocarse. La gerencia puede ver la primera imagen y decir: 'bien, tenemos los requisitos comerciales, por lo que su estimación debe ser con un 50% de precisión según su cono. Dime'. Eso no ayudará.

Analogía del automóvil: alguien le pregunta cuánto cuesta un automóvil y le entrega un documento con sus requisitos. El periódico dice que debe pesar alrededor de 1200 kg, tener cuatro ruedas y al menos dos puertas, pero tal vez cuatro, que tengan capacidad para cuatro personas, y que los buenos faros sean realmente importantes. El color debe ser gris (¿pero también es posible el negro?).

Puedes decir $ 25K, y si resulta que más tarde quiere un nuevo Range Rover, estás jodido. Eso no lo hace más correcto, o más útil decir que cuesta $ 100K. Puede que solo necesite un Prius usado (lo siento, usado). Si no tienes tiempo para descubrir cuál, nunca lo sabrás.

  

La mayoría de las veces resulta que los escritores de especificaciones realmente no han pensado en todo, y generalmente, cuando empezamos a diseñar y desarrollar, terminamos en problemas, ya que muchas de las especificaciones parecen tener agujeros. / p>

El uso de most es incorrecto.

No es posible para los escritores de especificaciones pensar en todo . Período. Si lo pensaran todo , sabrían cuántas líneas de código escribir y qué líneas de código eran correctas.

Dado que la especificación debe ser incorrecta, no hay mucho que puedas hacer al respecto.

El terminar en problemas es el problema.

  

Tanto la administración de negocios como la administración de TI requieren estimaciones y proyecciones de plazos, como deberían.

Quizás no. Las estimaciones generales y los plazos no son las cosas más útiles.

De ahí el desarrollo de métodos ágiles.

El punto es este. Todas las estimaciones basadas en especificaciones deben tener errores. Sólo son correctos por suerte. La mitad del tiempo, la estimación está muy por debajo y la mitad del tiempo la estimación está muy por encima. Esta es una consecuencia lógica de intentar predecir el futuro con información incompleta.

Ya que tiene que suceder, no debes terminar en problemas cuando te equivocas. Tienes que estar equivocado Y tienes que estar constantemente equivocado al azar. De lo contrario, estás manipulando los números.

Debe explicar a la gerencia que, con especificaciones vagas, hay un bajo grado de confianza en la estimación. es decir, usted estima que puede variar entre un 30% o un 40% o un 50% o lo que sea que piense. Entonces, si se estima que algo es de 2 días, es en realidad un rango de 2 a 3 días.
Luego cree un registro de problemas de proyectos (puede estar en un wiki o Jira, etc.). Cree todas sus preguntas como problemas y haga que el negocio responda a su pregunta. Mientras un problema permanezca sin resolver, la estimación permanece incierta. Si es posible, haga que un analista de negocios sea un conducto para facilitar esto y hacer mejores requisitos. Haga que su equipo de pruebas revise las especificaciones, ya que tienen que crear casos de prueba contra las especificaciones. A menudo, su participación puede llevar a escribir mejores especificaciones. Informe a la administración diariamente / semanalmente cuántos problemas no resueltos tiene. Cuanto más se resuelva, mejores serán tus estimaciones. Presente siempre las métricas a la administración, ya que las cifras hacen que piensen objetivamente y también lo coloca en un terreno sólido.
También, dependiendo del tamaño del proyecto, disponga de 1 a 4 semanas para la fase de diseño de la solución en la que resuelva los problemas principales (tanto los requisitos como los técnicos). Organice muchos talleres con PYMES comerciales y trate de comprenderlos y, a su vez, explique sus puntos de vista para llegar a una conclusión. Solo después de que se hayan entendido los principales casos de uso y sus estimaciones alcancen aproximadamente el 80% de confianza, debe proceder a la etapa de construcción.

Convenza a la gerencia / cliente de que vale la pena invertir en mejores especificaciones. Intente involucrar más a las personas con conocimiento del dominio . Al final, todos se beneficiarán de ello.

Eliminar las especificaciones.

Convenza a los negocios de probar Agile (o al menos un proceso Agile-ish) para un proyecto.

En lugar de escribir especificaciones

• reunirse con la gente de negocios para identificar características
• trabaje con ellos para identificar el conjunto mínimo de características / funciones que serían útiles (aunque solo sea para una versión interna)
• anota el trabajo
• establezca una fecha para el trabajo (cuantas menos funciones / trabajo, más fácil debería ser estimar con precisión una fecha).
• trabaje con empresas para priorizar el trabajo, asegúrese de que tengan la capacidad de cambiar de opinión acerca del pedido de la tarjeta, dígales cómo afecta la fecha
• con cada característica completa, tiene un sistema de trabajo para mostrarlos y hacer que firmen cada parte del trabajo como se hace
• liberación
• enjuague
• repetir

Mostrando las características a medida que se realizan. Suelte temprano y con frecuencia. Sea transparente y receptivo. Descubrí que esto conducirá a la eliminación de fechas límite inútiles.

Editar para arquitectura

Quienquiera que sea el protagonista debe tener una reunión inicial para comunicar a los desarrolladores cuál debe ser la arquitectura. El líder también es realmente la persona que debe estar pendiente de la diligencia para asegurarse de que se cumplan todas las necesidades.

Si necesita pasos adicionales en su proceso que agregarlos. Hay un proceso para facilitar la capacidad del equipo para realizar el trabajo. Si algo no funciona, cámbielo. Agregue a él, elimínelo, cámbielo para satisfacer sus necesidades. Si necesita estar especialmente preocupado por la seguridad, agregue pasos para ello.

La comunicación generalmente ayuda, al menos en una organización saludable.

Esto no es una bala de plata, pero lo que intenté hacer (y funcionó en nuestra empresa) es convencer a los empresarios para que expliquen el problema, en lugar de sugerir una solución de inmediato. Por lo tanto, nuestras solicitudes de características comienzan con una descripción del problema o el objetivo que desean lograr.

Luego, un desarrollador con algunos conocimientos de dominio intenta desarrollar una solución, mientras consulta con alguien del lado comercial de las cosas. Por lo general, este proceso produce varias soluciones alternativas, completas con estimaciones.

Está en condiciones de hacer negocios en este momento para elegir uno según el costo y la forma en que se completa una solución. Esta es también la forma en que podría venderles este método, que aquí tienen opciones, no solo una serie de mandays, lo tomen o lo dejen. Por supuesto, también necesita más recursos de su lado, pero si tiene problemas con las estimaciones y especificaciones, es una inversión que vale la pena.

Recuerde, cada vez que se modifica la especificación para agregar una nueva funcionalidad o para aclarar preguntas, es hora de revisar la estimación. No es tanto que nuestro cálculo original sea malo dado lo que nos dijeron, sino que no nos echamos atrás y decimos que no lo necesitamos cuando haya más detalles disponibles. Si yo fuera un contratista que construyera una casa y estimara el costo basándose en el uso de una encimera lamiante y un mes más tarde el cliente desea uno de granito, puede apostar a que volvería a visitar el presupuesto con él. Dejamos que nuestros clientes se salgan con los requisitos de mala calidad y luego no nos echamos atrás cuando resulta que hay muchas más cosas que hacer de lo que originalmente se había previsto.

¿Por qué aceptaría una especificación de requisitos que está incompleta, contiene requisitos en conflicto o es inviable? Recomendaría que su proceso incluya una manera de evaluar las especificaciones y enviarlas para que las corrija antes de aceptarlas y proporcionar estimaciones.