Dio la casualidad de que últimamente he estado trabajando mucho con los requisitos de productos del "cliente interno", incluidos colegas de varios departamentos y equipos técnicos (dentro de la empresa). Y la gente constantemente viene a mí para que nuestro equipo implemente ciertas funciones, rehaga algo, agregue, elimine.
En este artículo quiero decir cómo puedes trabajar con todo este caos entrante.
El artículo está escrito en base a la práctica del trabajo, y no tiene la intención de cubrir todo el tema de gestión de proyectos, requisitos, equipos, la calidad de la implementación posterior de requisitos por parte de los desarrolladores, el tema de análisis de resultados de implementación, etc.
Pero cubre solo una pequeña parte estrecha entre "Lista de deseos" e "implementación", que se trata precisamente de los requisitos en sí mismos: la lista de deseos / requisitos / deseos / problemas arbitrarios, etc. vuelan hacia nosotros, y trabajamos con ellos y al final obtenemos lo que Apto para desarrollo.Descubriendo el verdadero problema
Cuando a alguien se le ocurre un problema, una demanda, una idea para una nueva función, etc. entonces no siempre nos trae este listo para usar, adecuado para la implementación. Como regla general, este o algún tipo de "cosmos" es algo muy grande, noqueador, poco realista, que requiere rehacer todo por completo para resolver un pequeño problema, cuya relevancia es desconocida. O simplemente un requisito "crudo", incomprensible, no específico.
Por ejemplo, una persona sugiere agregar una nueva función. Y hágalo de esta manera, ofreciendo algún tipo de implementación técnica. En este caso, no saber qué se organiza y cómo se puede implementar. Obviamente, uno no puede simplemente tomar tales requisitos e implementarlos. Si lo hubieran hecho, el mundo se habría sumido en el caos y la oscuridad del inframundo hace mucho tiempo.
Para empujar un poco el caos y la oscuridad del inframundo, necesitamos entender qué hay detrás de estas ideas y propuestas. ¿Qué problema quería resolver la persona que vino a usted? ¿Qué problema debería cerrarse?
Esto está lejos de ser siempre claro y obvio de inmediato. A menudo tiene que pasar, haciendo las mismas preguntas muchas veces. O diferentes preguntas. Hasta que finalmente quede claro lo que está mal en esencia, en esencia del problema, y cómo, en la comprensión de una persona, debería haber "así". Y esta comprensión, como regla, es muy diferente de la declaración original de la tarea / problema. Pero sin recibirlo, es imposible continuar con los siguientes pasos y satisfacer la necesidad.
Comprender lo que una persona
realmente necesita es un arte completo, al que están dedicadas parábolas enteras (por ejemplo, "Vladimir Tarasov - Acércate a un ciervo"), libros (por ejemplo, "Rob Fitzpatrick - Pregúntale a tu madre") e intensidades prácticas (por ejemplo, en el desarrollo personalizado).
Bicicleta vieja sobre el comprador del taladro
Un hombre llega a la tienda y compra un taladro allí. Pero, de hecho, no necesita un taladro, necesita un agujero en la pared que quiere perforar. Por lo tanto, él compra un taladro.
Pero eso no es todo. No se necesita un agujero por sí solo. Se la necesita para colgar una hermosa foto grande en un marco pesado. Y este héroe quiere colgar una foto para complacer a su suegra, quien durante mucho tiempo le pidió que colgara una foto, pero aún no lo hizo.
Nos parece que ya hemos encontrado un problema fundamental. Pero no
De hecho, en un día habrá un partido de fútbol, que nuestro héroe realmente quiere ver. Y para que la suegra no tuviera motivos para molestarlo, se arregló para tener el derecho de ver fútbol, hizo lo que le habían pedido durante mucho tiempo, colgó una foto.
Es decir, al comprar un taladro, realmente quería ver fútbol con calma.
Aquí debe tenerse en cuenta que la situación en la que a alguien se le ocurren extraños, incomprensibles, formulados torcidamente o, desde su punto de vista, requisitos incorrectos, es
normal . Para las personas en general, es natural que quieran algo, pero no siempre pueden articular de manera exacta y correcta lo que quieren. Las personas, por regla general, son así, esto es natural. Es decir, el punto no es que alguien esté equivocado, sino cómo sabes cómo trabajar con tal situación.
En este momento en particular, trabajar con un cliente interno no es muy diferente de trabajar con un cliente externo.
Requisitos para funciones que ya existen
La bicicleta espía.
De alguna manera, enviaron un espía a una ciudad para averiguar dónde se encuentra la fábrica de cartuchos. Proporcionaron información para ayudar a que haya una iglesia en la ciudad, y si caminas derecho y a la izquierda por la calle, en algún lugar en esa dirección habrá una fábrica.
Aquí viene un espía en la ciudad. Se encuentra con la abuela y le pregunta:
- Dime, ¿cómo llegar a la iglesia?
- ¿Pero ves la fábrica de cartuchos? Desde él, siga recto y luego a la derecha. Habrá una iglesia.
El caso más simple, cuando resulta que lo que una persona quiere, ya lo tenemos. Quizás no del modo que una persona esperaba, asumía, imaginaba. Es solo que la persona no sabe que es, o no sabe cómo usarla, o tiene información incorrecta sobre cómo funciona. O simplemente necesita configurar / habilitar algo para obtener lo que necesita.
Cuando todo es tan simple, todo lo que queda es darle a la persona instrucciones sobre cómo obtener el resultado que necesita utilizando las oportunidades existentes.
Listo
Requisitos duplicados
A menudo sucede que los requisitos son similares, difieren solo en los matices de la configuración (potencial) o casi lo mismo, pero en palabras ligeramente diferentes. Dichos requisitos se pueden combinar para comprender cuánto y en qué lugares se necesita flexibilidad (o se necesitará en el futuro) y dónde no se necesita. ¿Cuáles son las características principales? Hacer un sistema o pieza de funcionalidad una vez que satisfaga todas estas necesidades a la vez. Quizás con diferentes configuraciones o variaciones, pero no será necesario que cada necesidad haga lo mismo por separado varias veces.
Un ejemplo:
Representantes de varios departamentos diferentes se acercan a usted (generalmente de forma independiente el uno del otro y en diferentes momentos) y le dicen que uno debe enviar informes a los correos electrónicos a los clientes de la lista, el otro: notificaciones a un cierto círculo de direcciones que algunos sistemas técnicos no son trabajo El tercero viene y quiere, de acuerdo con los resultados de tal y tal procesamiento de datos del cliente, se envía una carta con los resultados del procesamiento al cliente.
Es obvio aquí que en todos los casos, se necesita un sistema para enviar cartas, y las tareas para enviar provienen de diferentes lugares en diferentes circunstancias.
En consecuencia, está surgiendo un cierto sistema unificado de envío de cartas. En el que las tareas pueden provenir de diferentes sistemas. Y si todos los eventos anteriores (con los cuales aquellos que desean enviarnos cartas) ocurrieron dentro del mismo sistema, entonces aún mejor: significa que el sistema puede hacerse aún más uniforme y simple.
Si no trabajamos con los requisitos entrantes de esta manera, y se desarrollan inmediatamente en forma cruda, luego de un tiempo encontraremos nuestro sistema con varios remitentes de cartas diferentes, cada uno de los cuales funciona de acuerdo con su propia lógica, tiene su propia implementación especial, ajustes, funciones. Y para cambiar una pequeña pieza de lógica en los tres, o agregar una función de otra a uno de estos remitentes, debe copiar y pegar el código, o reescribir una parte bastante grande y refactorizar después de la implementación y operación. Aunque, en principio, uno podría entender de antemano que todo será así.
Requisitos en conflicto
Sucede que dos o más requisitos particulares se contradicen entre sí. A veces "completamente", que no se puede combinar de ninguna manera. A veces, sin embargo, se pueden prever "modos diferentes", en cada uno de los cuales se cumple un requisito, mientras que el otro no está disponible. O resuelva uno de los problemas de otra manera: la contradicción desaparecerá.
Para avanzar hacia una solución, debe comenzar a desenrollar la cadena de "por qué / por qué". Para cada uno de los requisitos (como se describe en la primera parte del artículo). Es decir, debemos entender lo más profundamente posible de qué surgieron exactamente esos requisitos, y que las personas que vinieron con estos requisitos quieren "realmente".
Luego tenemos la oportunidad de encontrar otras soluciones a estos "problemas reales" o de comprender cómo se pueden combinar estos requisitos en conflicto.
Por ejemplo, si un requisito de hecho es necesario solo en algunas condiciones específicas estrechas, y otro en otras condiciones específicas específicas. Entonces resulta que no se cruzan. O la tarea para la cual se inventó tal requisito se puede resolver de una manera completamente diferente, quizás aún más simple y efectiva. Y luego uno de los requisitos desaparece (o se convierte en uno completamente diferente, que no tiene nada que ver con el segundo), y el segundo permanece. Y no hay contradicción.
O comprenda: estos requisitos no se pueden combinar de ninguna manera, y debe elegir uno. Pero, afortunadamente, esto sigue siendo bastante raro.
Todo esto es posible porque casi todas las tareas se pueden resolver de varias maneras. Y si nos elevamos cada vez más a partir de una formulación específica inicial, cruda, tal vez semi-técnica, en la comprensión de cuál es la tarea, en principio, entonces hay más y más opciones de solución. Incluyendo soluciones no técnicas (nivel de configuración, proceso, organización, etc.). Y cuanto más amplia sea la elección de opciones, más fácil será elegir dos opciones para resolver dos problemas que no interfieran entre sí, e incluso, tal vez, ayuden, si es posible.
Requisitos de caldera
La idea es que inicialmente todos los requisitos diferentes de todas las fuentes se fusionen en un único montón, en una sola caldera. Luego puede desarmarlos, analizarlos para las opciones anteriores: "repetir" o "contradictorio", para dar requisitos ya preparados: no repetitivos y consistentes que se pueden "tomar y hacer" en el orden correcto.
Es decir, la idea es mirar la imagen completa. Para todo lo que es ahora y que quieren agregar, cambie. Y sobre la base de todo este panorama, ya está decidido: qué, cómo y cuándo hacerlo.
En este contexto, todos los requisitos entrantes son materias primas para prepararse para las tareas de desarrollo en la salida. Además, las tareas en la salida no siempre coincidirán uno a uno con alguna necesidad entrante. Una tarea puede satisfacer varias necesidades a la vez o cerrar una clase completa de requisitos. O simplemente ser parte de una gran historia.
Resumen
Así es como el caos entrante se convierte en un conjunto hermoso, útil y comprensible para los desarrolladores de tareas y funciones de su sistema que agrada a sus colegas.