Muchas veces, durante la fase de licitación de un proyecto, recibo los requisitos de un sistema de software de nuestros clientes potenciales en un formato muy desestructurado de varias fuentes [correo electrónico, documentos de Word, Excel]. Por lo general, son un grupo de personas de "desarrollo de productos" del lado del cliente quienes presentan estas "soluciones propuestas" a los problemas comerciales que tienen. Si bien son expertos en el dominio comercial, muchas veces no tienen las soluciones correctas.
Esto resulta en
- múltiples versiones del mismo requisito
- mezcla de dos requisitos en uno
- algunas versiones del requisito más adelante en la línea, los requisitos que se combinaron se separan nuevamente, cada uno con algunas de las nuevas incorporaciones
¿Cómo se trabaja con tales requisitos y los clasifica en casos de uso adecuados y antes de que comience el desarrollo? ¿Qué herramientas podemos usar para rastrear el historial de un requisito particular, desde la primera vez que se concibió hasta el momento en que se cristaliza en un caso de uso adecuado? Estimar el trabajo en función de los requisitos recibidos de esta manera es una pesadilla que termina cometiendo errores al comprender el requisito correctamente y estimar el esfuerzo en consecuencia.
Una vez que ganamos el proyecto, los clientes han reflexionado un poco más sobre sus requisitos y han podido articularlo adecuadamente. Lo que sucede en este caso es que algunas funciones se caen, otras se mejoran, otras toman un giro completamente nuevo. Básicamente, esto puede anular algunas de las estimaciones del elemento de trabajo que se hicieron antes de que se ganara el proyecto. Me interesaría saber si hay algún sistema mediante el cual podamos construir un árbol de un requisito particular y cómo cada rama resultó en una estimación diferente.
¿Algún consejo, herramienta o truco para que esta actividad sea más manejable? Solo estoy tratando de obtener algunas ideas de alguien más experimentado que yo en gestión de requisitos y estimación de esfuerzo.
Respuestas:
Los requisitos crecerán y cambiarán. No creo que nadie pueda discutir eso.
Cómo recopilar y procesar solicitudes entrantes .
En mi experiencia, ayuda a la hora de reunir los requisitos si hay un grupo único o muy pequeño de clientes que actúa como un filtro para entregar requisitos nuevos o actualizados a un pequeño grupo de planificadores de desarrollo. Cualquiera de su lado puede proponerlos o escribirlos, pero la entrega debe hacerse solo a través de unos pocos. Cuantas menos personas participen en el intercambio de una parte a otra, mejor.
El propósito de filtrar a través de un grupo más pequeño de personas no es descartar o disminuir el esfuerzo y la información que otros ponen, incluso si están duplicados o aparentemente sin importancia en la superficie, sino limitar los puntos de falla: información perdida o mal manejada. Sigue un principio similar al propósito de la encapsulación y las interfaces: proteger los datos privados y establecer un protocolo común para manejar solicitudes similares. Permítanme reiterar: la presentación de duplicados está bien. Como planificador, eso me dice que lo que están hablando o proponiendo es importante. Guarda o graba todo.
Cómo rastrear y organizar los requisitos
En el corto plazo, vaya con tecnología baja
Obviamente, existen soluciones de baja tecnología que pueden ser efectivas en gran medida para organizar y rastrear los requisitos entrantes: pizarras, adhesivos, carteles, lo que sea que tenga. Estos pueden ser excelentes para la planificación a corto plazo. Son altamente visibles, aceptan notación de forma libre y fáciles de 'reconfigurar'.
A largo plazo, use una herramienta de software que se pueda buscar, ordenar y vincular
Para esfuerzos de mayor alcance, algún tipo de software sería valioso. Existen herramientas especializadas de gestión de requisitos: Puertas, Clearcase / Clearquest y muchas otras. Esas herramientas altamente especializadas son excelentes en lo que hacen, pero a menudo son excesivas. A veces, incluso una hoja de cálculo vieja y simple es más que adecuada. Personalmente, considero que los sistemas de seguimiento de problemas generales son bastante útiles para lograr esto, y en este momento mi favorito es Redmine, pero estoy seguro de que otros también estarán bien.
Con un sistema de seguimiento de problemas, cualquier persona que elija permitir puede crear un 'nuevo problema' o requisito, y agregar cualquier detalle que considere conveniente incluir. Pueden ver el problema y dar su opinión sobre cualquier acción que realice con él. Puede volver a clasificarlo, ajustar la prioridad, reescribir el cuerpo, adjuntar información complementaria, asociarlo con otros 'problemas', promocionar a una función de nivel superior o 'caso de uso' o historia o cualquier terminología que se ajuste a su sistema, hasta la saciedad. En otras palabras, puede hacer mucho para crear una lista de requisitos relacionada, rastreable, ordenada, priorizada, consciente del historial a través de problemas. Además de ser bastante configurable de fábrica y de código abierto, si la herramienta no es lo que necesito o quiero en algún momento, puedo cambiarla con bastante facilidad para satisfacer mejor las necesidades de mi proceso.
Una nota final sobre las herramientas, algunas personas con las que he hablado tienen mucho éxito al usar archivos de texto antiguos en un sistema de gestión de cambios y versiones. Obviamente obtienen los beneficios de las versiones históricas. También utilizan el sistema operativo base y herramientas complementarias para encontrar, vincular y catalogar los requisitos. No pueden agregar tanta metainformación relacionada y estructurada, pero no sienten que la necesiten y, por sus esfuerzos, no agregan suficiente valor. Ese puede o no ser el caso para usted. La ventaja es que es potencialmente un poco menos de software en su pila de desarrollo para administrar y mantener.
Requisitos posteriores a la adjudicación del contrato / desarrollo inicial del proyecto
El aspecto final de la pregunta es cómo gestionar los requisitos después de que un esfuerzo ha comenzado. Creo que hay dos ideas principales sobre esto, y parte de cómo las maneja depende de la naturaleza de su relación con el cliente: en primer lugar, si está bajo contrato a un valor fijo, se pueden incorporar los requisitos que vienen después de la adjudicación del contrato. La implicación es que pueden cambiar el alcance del esfuerzo, por lo que la tasa o factura será mayor cuando se entreguen y acepten esos artículos adicionales; a menos que se elimine una cantidad equivalente de esfuerzo de la propuesta aceptada. Si se va a realizar un cambio en el alcance, debe asegurarse de que el cliente comprenda y acepte la consecuencia; de lo contrario, esos envíos tardíos deberán presentarse.
En segundo lugar, para los nuevos requisitos que llegan después de la adjudicación del contrato, y el contrato está orientado más hacia un esfuerzo de tiempo y material (lo que sea necesario para completar el cuerpo de trabajo), puede y debe ser un poco más flexible si el el cliente insiste en incluirlo durante ese recorrido en particular. Se le pagará si lo incluye o no, siempre y cuando todo lo que diga que haga se haga.
Si no está familiarizado con ellos, es posible que desee ver un enfoque Kanban y métodos ágiles. Estas técnicas pueden ayudar a enfocar las preocupaciones inmediatas, sin perder necesariamente de vista los objetivos de desarrollo a largo plazo.
Presente opciones como escenarios de "qué pasaría si" y brinde al cliente una opción y la decisión
En cualquier caso, una estimación de "qué pasaría si" es una buena estrategia para emplear al negociar con el cliente y su equipo. Construya una comparación lado a lado de las tareas, sus costos y el cronograma según lo planeado, con una columna que muestre la misma información para los enfoques alternativos. Microsoft Project es probablemente un buen candidato para hacer esto, ya que puede construir diferentes estimaciones basadas en un conjunto de tareas en gran medida similar.
Sin embargo, incluso una hoja de cálculo básica suele ser igual de efectiva para demostrar cómo los cambios o inclusiones específicos afectarían el costo y el cronograma. Una lista en este caso es probablemente tan efectiva como un árbol para demostrar las diferencias. La herramienta y el método que elija para construir estos escenarios dependen en gran medida del tamaño del proyecto y del personal (pero incluso el software triple A como MS Project tiene sus propios límites de utilidad y capacidad).
Considere estos escenarios hipotéticos como elementos de trabajo internos y guárdelos durante la duración del proyecto. Fueron demostraciones críticas en el proceso de toma de decisiones y negociación. También es posible que tenga que volver a visitarlos o repetirlos para una ronda sucesiva de qué pasaría.
Al preparar escenarios hipotéticos, una explicación complementaria de los pros y los contras desde una perspectiva técnica o de implementación (en términos simplificados) podría ser útil para ayudar a justificar por qué una alternativa tendría un impacto tan significativo.
fuente
Vería esto como un proceso iterativo. El primer paso es reunir los requisitos. El paso 2 es ordenarlos. El paso 3 es priorizarlos. El paso 4 es dividir cada uno en bits lo suficientemente pequeños como para estimar el esfuerzo. El paso 5 es unir estos bits en un grupo de esfuerzo global (digamos 84 días-persona). El paso 6 es asignar el esfuerzo a los recursos (84 días-persona / 2 desarrolladores = 42 días).
Así que ahora está atrapado entre el paso 1 y el paso 2. Tiene requisitos, pero no los tiene en la forma que necesita.
Digamos que tiene varias versiones del mismo requisito. ¿Son estos esencialmente lo mismo? Si es así, elige lo que parece ser el más claro y úsalo. Si varían en detalles, elija lo que parece ser el más lógico y utilícelo. Luego envíe un mensaje al cliente pidiéndole que verifique el requisito. Es posible que tenga que ir y venir varias veces para cumplir con los requisitos. No te rindas ni te desanimes. Muchos proyectos han fallado debido a requisitos deficientes.
Utilice el proyecto de Microsoft para mantener el trabajo y la programación sincronizados con los requisitos cambiantes. Si el cliente solicita un cambio, especifique el trabajo adicional, conéctelo a su modelo e infórmeles sobre la nueva fecha. No se deje engañar por creer que solo puede traer nuevos desarrolladores a intervalos aleatorios para recuperar la holgura. Su programación debe tener en cuenta el tiempo de aceleración cada vez que se agrega un nuevo recurso. Solo podrá modelar esto correctamente si presta atención a cada proyecto y aprende de él. Digamos que trajo a Bob a bordo del proyecto X después de que estuvo en marcha durante 4 meses. ¿Cuán productivo fue en el primer mes? ¿La tercera?
Debe volver a visitar el modelo de proyecto semanalmente, realizando actualizaciones donde sea necesario. Mantenga un registro histórico de los cambios. Esto lo ayudará a proporcionar mejores estimaciones en el futuro.
Doug
fuente