Veo varios enlaces similares, pero ninguno parece tener una solución, en su mayoría "no deberían estar haciendo eso". Estoy de acuerdo, pero por favor, sigue leyendo:
Escenario: 800 000 páginas de documentos, narrativos (por ejemplo, correos electrónicos)/estados de cuenta bancarios/legales (por ejemplo, acuerdos de opciones). Somos un equipo pequeño, con solo 2 investigadores (1 de los cuales es el principal responsable de la producción), 1 persona financiera y 1 persona jurídica (junto con algunos asistentes administrativos y especialistas externos). Tenemos múltiples proyectos en curso (piense en diferentes casos en diferentes tribunales en diferentes países).
La cuestión es que las 800 000 páginas de documentos no se han revisado por completo (en este punto, tal vez el 50 %). Por lo tanto, decidimos el producto del trabajo (lunes; la persona 1 hará x el viernes), pero el martes por la tarde, inevitablemente, descubrimos documentación adicional.
Con demasiada frecuencia, esta documentación cambia toda la historia, cambia el ángulo que necesitamos para llegar a ella, cambia las relaciones. Para el martes por la tarde, los diversos equipos legales (que investigan poco) solicitan varios productos de trabajo en relación con este nuevo hallazgo. Mi investigador/campeón del producto de trabajo se pone manos a la obra, con el corazón lleno, y (adivinaste) antes de que termine (con demasiada frecuencia) tenemos aún más información que cambia las cosas o provoca una redirección. es una locura
Estamos procesando, a veces, 2-3K páginas/día. Entonces puede ver cómo incluso unas pocas bombas allí causan estragos como si no hubiera mañana y, sin embargo, en realidad son incluso menos del 1% del total de documentos.
¿Cómo se supone que debemos manejar esto? ¿Forzar una semana de terminar lo que empezamos? ¿Qué pasa si es inútil o incorrecto? ¿Esperar para producir hasta que termine la investigación? La mayoría de las veces, sigue un hilo en particular que en sí mismo conduce a nuevas revelaciones, Y tenemos estatutos de limitaciones para presentar esto y aquello. ¿Contratar más personal? Se necesitarían meses para que ganaran suficiente tracción para ser útiles, ¿y adivinen quién tendría que entrenarlos?
Probamos kanban: los tableros se llenaban de tonterías en una semana o dos. Tener un "carril rápido" de alta prioridad era una buena idea... hasta que dejó de serlo. Un gráfico de trabajo pendiente parece una meseta, después de ajustar las tareas adicionales y cuántas quedan sin terminar... el cliente (y el propietario del producto, en realidad) quiere que alguien maneje esta locura (su servidor), pero en realidad no quiere cambiar su hábitos (que en su mayoría se basan en papel... ¿mencioné que estamos imprimiendo y revisando manualmente todos estos documentos?)
Todos y cada uno de los consejos y perspectivas sobre esto (especialmente con modelos o ejemplos o sugerencias reales de "hacer esto") son muy, muy apreciados.
TL; DR: La gerencia quiere más control, más producto del trabajo, más valor por $.
El personal quiere evitar la reelaboración constante, tener una idea de cuál es la estrategia general, ver cómo se envía realmente el producto de su trabajo
Quiero mostrar que los dos anteriores no son mutuamente excluyentes, y que hay una manera de que estas necesidades se relacionen bien, sin poner un gran freno al flujo de trabajo, reuniones desperdiciadas, etc. Puedo ver que estos tres deseos son razonables y racional, pero ahora mismo hay un serio problema entre ellos...
Mi primer paso sería preguntarte cómo estás haciendo Kanban.
Kanban es la herramienta de referencia para los requisitos que cambian rápidamente. El principio básico de "Tener un tablero, tener un WIP, priorizar diariamente", es increíblemente simple. Sin embargo, Kanban es realmente difícil de hacer bien. Es por eso que casi siempre comienzo nuevos equipos con Scrum primero, solo para que puedan comenzar a comprender los fundamentos de los enfoques ágiles.
Una cosa que parece que está sucediendo es una eliminación selectiva de los "retrasos" o requisitos. Si las cosas están cambiando cuando descubre algo nuevo, debe preguntar si el trabajo pendiente existente sigue siendo válido. Para un proyecto de software normal, entreno a los equipos para que se elimine todo lo que tenga más de 6 a 12 meses. Si era importante, se volverá a mencionar. Para su proyecto, diría que más de un mes está maduro para su eliminación.
En segundo lugar, la claridad de su cartera de pedidos o historias de usuarios. Siempre debes preguntarte "¿Para quién es esto?" y "¿Por qué les importa?". Rápidamente caemos en la trampa de decir "¡Necesito un taladro!", cuando en realidad lo que necesitamos es medio agujero en un trozo de madera. Un taladro es solo la forma más común de obtener ese agujero.
Te aconsejaría volver a Kanban como base. Tenga en cuenta la selección rigurosa del trabajo pendiente y la claridad del trabajo pendiente. Cuando encuentre un problema, realice un análisis de "Cinco por qué" del problema y tenga siempre al usuario en primer plano.
Creo que la declaración simple de su problema es que para planificar necesita al menos poder contar la cantidad de cosas que necesita hacer. Sin embargo, no tiene un número base en este momento además de 800K y 50%.
También creo que puede estar tratando de aplicar la gestión de proyectos a lo que suena como gestión de procesos. Tal vez sea un poco de ambos. Estoy adivinando.
Si necesita más personas, quien esté a cargo preguntará cuántas y no tiene idea. Totalmente comprensible, pero debe poder pedir algo de manera racional.
Herramientas: Me vienen a la mente las viejas herramientas stand by como el "estacionamiento" o la lista de problemas. Las hojas de cálculo de Google son una gran herramienta para administrarlas con poca inversión para configurar algo mejor. Todavía es una pesadilla de hojas de cálculo, pero la colaboración funciona de inmediato y es gratis. Tienes que registrar problemas, priorizarlos, trabajar en las prioridades más altas. Necesitará tener columnas para casos, tribunales, etc., para que pueda clasificar las cosas.
Opción uno, calcule la base: Dada la urgencia que parece expresar, me quedaría con esto.
En este momento, quizás tenga una idea al menos anecdótica de cuántas investigaciones posteriores ocurren cuando revisa, digamos, un archivo de caso de 100 páginas. No te concentres en que ese número sea perfecto. Piensa mejor, medio, peor. Por lo general, los equipos terminan con una peor ventaja, por cierto. Ve con eso. Entonces, 200 casos, 50 son los mejores, 75 son medios, 75 son los peores. Eso debería equivaler a horas persona.
Opción dos: mejor estimación: haga que al menos una persona revise el último 50% de los documentos. Lea páginas, registre problemas y continúe. Eso le dará un recuento de, digamos, problemas de "nivel uno". Su equipo probablemente pueda estimar más fácilmente cuántos problemas secundarios surgirán de cada tipo.
Avance: cada vez que recibe un nuevo caso, si ese es el problema, debe clasificarse para que pueda asignarle una carga de trabajo inicial.
Entonces, en revisión: a.) Estructure su seguimiento de problemas / trabajo con una herramienta súper simple b.) Estime el trabajo utilizando un modelo de mejor, medio y peor caso y derive a las personas necesarias de allí c.) Determine si necesita más personas y cómo tiempo que tomará d.) Avanzar clasificar todo lo nuevo, agregarlo a la carga de trabajo, ajustar la mano de obra, la programación, otras prioridades desde allí.
Ese es mi conjunto de ideas dado lo que me has dicho. Lo siento si eso es un gigante "duh".
Las metodologías ágiles están diseñadas para hacer frente a las cambiantes realidades empresariales. No como los requisitos cambiantes comúnmente establecidos.
Es una diferencia sutil, pero me parece que es importante en su caso.
Un enfoque en cascada sería recopilar y leer todos los documentos (hacer un plan) antes de comenzar a trabajar (implementar el plan).
El riesgo en los negocios con ese enfoque que aborda Agile es que durante la implementación o las etapas posteriores de la planificación, suceda algo en el mundo real que invalide el plan. Digamos que un trato fracasa o se abre un nuevo mercado y, por lo tanto, todo el proyecto falla.
Agile aborda esto haciendo pequeños bits rápidos. Pero cada bit ofrece valor porque se conoce el estado del mundo en ese momento. Puede ver claramente si el trabajo es correcto o no. Si algo cambia más tarde, el trabajo puede perder valor, pero el ritmo del cambio lo marcan los acontecimientos del mundo real. Eventos que no se pueden planificar.
Sin embargo, en su situación, los cambios ocurren al ritmo al que lee y comprende los documentos. Una tarea conocida que se terminará antes del final del proyecto.
Por lo tanto, un poco de trabajo no le ofrece ningún valor si está mal, ¡no sabrá si está bien hasta el final y potencialmente tiene un valor NEGATIVO!
Para usted, Agile es un enfoque de alto riesgo. Esencialmente, apostar a que afortunadamente más bits saldrán bien que el tiempo que pasa arreglando los incorrectos.
Le sugiero que lea toda la documentación primero y luego haga el trabajo.
Esto puede no ser una recomendación ágil pura. Pero, siguiendo su problema, esto es lo que sugeriría para este entorno totalmente dinámico.
Tengo la impresión de que necesita más estructura en su proyecto. Estructúralo en:
subproyectos, por ejemplo:
fases del proyecto, por ejemplo
diferentes prototipos
Para cada subproyecto, debe generar un acta de constitución del proyecto que defina claramente los objetivos y no objetivos de esta parte.
Especialmente los primeros prototipos no necesitan cumplir con todos los requisitos. Podrías definir por ejemplo como:
Prototipos:
El beneficio aquí es que para las primeras muestras puede trabajar con un número muy limitado de requisitos básicos. Estos requisitos deberían ser bastante sólidos y no cambiar mucho con el tiempo. Puede obtener un sistema en ejecución, donde puede obtener más información. Si puede convencer a su patrocinador de que está en el camino correcto, puede aumentar su equipo para construir prototipos más maduros.
Pero el paso más importante es primero generar dicha estructura y la hoja de ruta de desarrollo. Este será un esfuerzo de planificación significativo. Comunique, discuta y alinee este plan con su equipo y las demás partes interesadas. Es fundamental que todos sepan qué esperar en qué momento.
Editar 1
Acabo de ver que ha etiquetado su pregunta con 'ágil'. Mi sugerencia es solo un enfoque clásico de PM. Tal vez ágil es simple, no es la herramienta correcta para su demanda. Podría usar elementos ágiles en algunos de los paquetes de trabajo, pero tengo dudas de que solo pueda confiar en la metodología ágil para la ruta de desarrollo completa.
Editar 2
Algunos comentarios sobre la naturaleza de los requisitos:
Con la carga de material, espere que haya requisitos conflictivos. Especialmente si considera la demanda de las partes interesadas. Por ejemplo: no se puede construir un automóvil perfecto que satisfaga los requisitos de todos los clientes de automóviles. Un cliente quiere un Ferrari Spider, el otro quiere un Volkswagen Multivan. Tendrás que decidir qué requisitos seguir.
No espere que pueda hacer el diseño correcto desde el principio. Que cada línea de código, cada tornillo y cada procesador sea elegido correctamente desde el principio. El desarrollo de productos suele ser un proceso iterativo, por lo que tendrá que volver a trabajar en su diseño varias veces.
Algunos requisitos son bastante robustos. Por ejemplo, requisitos legales. Algunos son más flotantes. Trate de comenzar primero con los requisitos sólidos.
Si tiene los primeros prototipos, esto influirá en los requisitos de sus partes interesadas. Tal vez un actor tenga un Problema A y por lo tanto demande como un deber absoluto la solución X a ser implementada. Sin embargo, cuando diseñe su producto, puede encontrar una solución Y más elegante para el Problema A, en la que la parte interesada no estaba pensando. Si la parte interesada ve Y, podría cambiar de opinión y X ya no es obligatorio. La clave es comprender los problemas de las partes interesadas y encontrar soluciones, en lugar de tratar de implementar cada función que soliciten.
editar 3
El escaneo del material está bien para el primer lugar. Pero no intentaría extraer todos los requisitos en la primera ejecución. Trataría de tener una idea de lo que se discute aproximadamente en las secciones individuales de su material.
Comenzaría a escanear una parte del papel y luego decidiría:
"En este capítulo parecen estar los principales desafíos para mi concepto. Investigaré e implementaré estas soluciones en una fase temprana/prototipo (¿Cuál?)", O
"Esto parece no ser un desafío para los requisitos. Puedo adaptar mi diseño a estos requisitos en una fase posterior".
dKen
Joel Bancroft-Connors
dKen
Apalala
Grifo
Apalala
aventura2099
Grifo
aventura2099
Grifo
Grifo
aventura2099