Consejos y mejores prácticas para una mejor gestión de los requisitos

    1. ¿Qué significan las «mejores prácticas» en la gestión de requisitos?

Es tan interesante para mí que todo el mundo habla de querer una formación en las «mejores prácticas«. Este término se utiliza a menudo para describir el tipo de consultoría que podríamos ofrecer también. ¿Qué significa eso realmente? Creo que todos nosotros hemos alimentado el mito de que las mejores prácticas pueden ser la base para la formación de las personas. Las mejores prácticas no son entrenadas, son experimentadas.

Si comparamos el enfoque de mejores prácticas con la naturaleza, sabemos que no sólo es la especie más fuerte sino también la más prolífica que sobrevive. Esa es una de las razones por las que es tan difícil cambiar los procesos en una organización. Piensa en eso por un momento. Los más fuertes y más prolíficos probablemente describen la mayoría de los individuos que usted tiene en casi cualquier grupo de su organización. He visto esto una y otra vez en el campo de la ingeniería de sistemas. Los ingenieros más fuertes y prolíficos a menudo han estado haciendo su trabajo durante muchos años y tienen una forma específica de hacerlo. Pedirles que prueben nuevas técnicas y herramientas es a menudo inútil, ya que no saben cómo va a mejorar el ya maravilloso trabajo que están haciendo. Su práctica va a sobrevivir si continuamos empujando un enfoque de mejores prácticas hacia ellos.

Entonces, ¿qué hacemos? Las mejores prácticas comienzan con nuestra propia experiencia personal. Todos los libros que se recogen y se leen en torno a las mejores prácticas se refieren a la experiencia personal del autor en alguna área, ya sean casos de uso, obtención de requisitos, ingeniería de sistemas, pruebas, etc. En algún momento una organización decide que necesita un proceso consistente en toda la organización. Hay muchas buenas razones para hacer esto. Por lo tanto, se forma un grupo para crear un proceso que refleje estas mejores prácticas. Como hay muchas mejores prácticas en el grupo, adivina quién suele ganar, el más fuerte y el más prolífico. Y la mejor práctica resultante suele dar lugar a un compromiso entre el grupo de mejores prácticas y los miembros de la organización que desempeñan esta función. Los estudios indican que se tarda unos cinco años en llevar a cabo este proceso en toda la organización. Luego vienen los consultores que notan estas prácticas. Pueden ver una oportunidad para los negocios y, por lo tanto, se ponen detrás de las prácticas que los llevarán a más negocios para ellos. Comienzan a aparecer en conferencias y ferias comerciales promocionando estas prácticas y escribiendo libros. (Piense en el enfoque ágil.) Debido a que están buscando negocios, se centran en las prácticas que les proporcionarán la mayor parte de los negocios. Siempre estamos en busca de las mejores prácticas, así que no necesitamos saber con qué frecuencia funciona, sólo que PUEDE funcionar. Por eso, seguimos impulsando esa práctica en toda la organización, con la esperanza de obtener todos los beneficios de los que se ha hablado a lo largo de los años.

Debemos recordar que las mejores prácticas se basan en la retrospectiva. Las mejores prácticas para su trabajo se desarrollan a medida que usted aprende acerca de ese trabajo. Ciertamente podemos aprender unos de otros. Ese no es el objetivo de este debate. La cuestión es que debemos basar nuestras mejores prácticas principalmente en nuestra propia experiencia práctica. Debemos discernir cómo aplicar las mejores prácticas a nuestro trabajo y a nuestras organizaciones. Simplemente no acepte las mejores prácticas porque alguien escribió un libro sobre el tema o habló de ello en una conferencia. Investigue la práctica y determine el ambiente en el cual fueron fomentados. ¿Este ambiente es comparable al de hoy? A menudo hay poco en común. Escoja los chismes de las mejores prácticas que se aplican a usted y a su trabajo y que le proporcionarán un beneficio real. Empiece con pequeños cambios y construya sobre la práctica tal y como se aplica en su organización. Sepa dónde ha tenido éxito y dónde ha fracasado y aprenda de ello. Recuerde que si usted tiene objetores fuertes y prolíficos a la práctica, usted necesitará a alguien con una comprensión práctica de la práctica para ayudar a los objetores a ver cómo esta práctica puede ayudarles. Escúchelos y atienda sus preocupaciones. No los ignore y espere que desaparezcan. No lo harán.

En otras palabras, el sólo hecho de decir las palabras «mejor práctica» no significa que será una mejor práctica para usted.

    1. ¿Cómo mejorar la definición de sus necesidades?

Cada vez que se hace un cambio en un proceso o en las herramientas que se utilizan para apoyar el proceso, hay una curva de aprendizaje que afectará el tiempo requerido para llevar a cabo ese proceso. A medida que comience a pensar en mejorar su proceso de definición de requisitos, tenga en cuenta que habrá un esfuerzo asociado con este cambio. En la mayoría de los casos se produce una disminución de la productividad a medida que el trabajo comienza a progresar. Esta disminución se denomina a menudo «curva en J». A medida que los usuarios intentan cambiar la forma en que realizan una tarea en particular, llegan a un punto en el que sienten que es simplemente demasiado difícil hacer el cambio. La tentación aquí es volver a la antigua forma de hacer las cosas sólo para completar la tarea. Sin un plan para superar este obstáculo, muchas organizaciones fracasan en su objetivo de lograr este cambio. Hay dos estrategias que pueden acelerar la adopción de habilidades o herramientas.

En primer lugar, está la aproximación a la profundidad. En el enfoque en profundidad se selecciona un grupo central de personas que son entrenadas en el nuevo proceso o herramienta y continúan recibiendo tutoría como la cruz del abismo entre la formación y el trabajo en un proyecto real. Los mentores son a menudo consultores externos con experiencia en el área de habilidades específicas. Es importante tener expertos disponibles para ayudar a los profesionales a comenzar a utilizar sus nuevas habilidades en un proyecto en vivo. Este grupo central es bastante pequeño y la intención es utilizarlos como consultores para nuevos proyectos que utilizarán las nuevas habilidades. Se convierten en expertos que pasan de un proyecto a otro para ayudar a esas personas a utilizar sus nuevas habilidades.

El enfoque de la amplitud se centra en una base sólida de habilidades de mejores prácticas que se irán perfeccionando con el tiempo. En este enfoque, los mentores se incorporan para proporcionar esta base de habilidades de mejores prácticas, a menudo a través de la formación estándar en el área de habilidades específicas. Por lo general, se definen y documentan procesos y plantillas estándar para su uso por parte de los distintos equipos de proyecto. La formación inicial se imparte a un grupo grande de individuos frente al grupo más pequeño y centrado mencionado en el enfoque de profundidad. A medida que los proyectos comienzan a utilizar las nuevas habilidades y aprenden más acerca de cómo se ven afectadas sus tareas específicas, estos resultados se retroalimentan en la base de las mejores prácticas para que puedan refinarse con el tiempo.

Cualquiera que sea el método que elija para gestionar este esfuerzo, es fundamental para realizar con éxito los cambios necesarios. Sin un plan, estos cambios a menudo caen en el olvido cuando se siente la crisis del horario y el presupuesto. Hacer este tipo de cambios requiere disciplina, apoyo y determinación. Cada proyecto debe ser evaluado continuamente para asegurarse de que se están utilizando las nuevas habilidades.

Piense en un simple cambio en el proceso de definición de sus requisitos. ¿Quiénes son los expertos en los que puede confiar internamente? ¿Necesita ayuda externa para capacitación y/o tutoría? ¿Adónde irá para esta capacitación y tutoría? ¿Su proceso está bien documentado hoy en día o está empezando desde la zona cero? ¿Cuál es su plan para asegurarse de tener éxito (profundidad, amplitud, ambos)? ¿Cuál es el plazo para el cambio?

«La locura es hacer lo mismo una y otra vez y esperar un resultado diferente». (Albert Einstein) Si usted se siente de esa manera, comience a hacer cambios que le den los resultados que usted desea.

    1. Consejos para una mejor recopilación de los requisitos

Si está entrevistando a los usuarios y básicamente dice «Trick or Treat – give me some good requirements», ¿adivine lo que obtendrá? Obtendrá un montón de cosas que a los usuarios les gustaría ver. Algunos serán importantes para usted y otros no. Tendrá que clasificar todas esas necesidades y clasificarlas en categorías. Usualmente llamamos a estas categorías características. Algunas de esas características serán pertinentes para el proyecto y otras no. Así que si está empezando a reunir requisitos, ¿por qué no centrarse más en las preguntas que hace? Investigue un poco y analice cualquier información disponible que sea pertinente para el sistema. Identifique a los usuarios finales (no tiene que hacer trampas o golosinas en toda la subdivisión, concéntrese en un par de calles donde se dan las golosinas realmente buenas) y organice reuniones con ellos.

Identificar los procesos que se ven afectados por el proyecto: ¿cuáles están cambiando, cuáles son nuevos y cuáles ya no son necesarios? Pregunte a los usuarios qué procesos están funcionando bien para ellos. Trabaje para entender cómo están haciendo su trabajo hoy en día.

En segundo lugar, una vez que haya clasificado los requisitos en características, tendrá que priorizar esas características. ¿Cuáles son los «favoritos» de los clientes para hacerlos primero? A veces no damos prioridad y terminamos trabajando primero en las partes fáciles del sistema, en lugar de centrarnos en las partes del sistema que son de alto riesgo o que no se entienden bien.

Al final del proyecto, repase lo que sucedió. Podríamos preguntarnos si fuimos por las calles correctas, si seguimos el proceso o si nos desviamos por alguna razón, ¿conseguimos tantos dulces como esperábamos? ¿Qué funcionó bien? ¿Qué cambios se podrían hacer para mejorar el proceso? ¿Conseguimos los resultados finales esperados? ¿Estuvieron los usuarios satisfechos con el producto?

    1. 3 Consejos para capacitar a su equipo en la gestión de requisitos

Pedirle a alguien que nunca ha escrito o gestionado requisitos que siga un proceso de requisitos robusto y complejo es como pedirle a un niño de cinco años que toque la Sonata a la Luz de la Luna de Beethoven. Y ya que a menudo no proporcionamos ningún entrenamiento o tutoría, vamos a pedirles que aprendan a tocar esa pieza por su cuenta. Eso es lo que estamos haciendo cuando lanzamos a nuestros analistas a un proceso de requerimientos complejos.

Sugiero que consideremos entrenar a nuestro equipo. Dejemos de pensar que todos simplemente «sabemos cómo hacer nuestro trabajo». Eso no es verdad. Podemos aprender a tocar esa pieza por nuestra cuenta. Sugeriría que en lugar de tomarme cinco años, me hubiera tomado diez años por mi cuenta. Lo mismo ocurre con nuestros ingenieros y analistas de requisitos. Podemos dejar que aprendan por su cuenta. O podemos darles algo de entrenamiento, tutoría y tiempo para practicar.

Por supuesto, la clave para hacer que esto funcione (sin intención de juego de palabras) es tener algún tipo de proceso definido que usamos para entrenar a nuestros analistas. Solía odiar esa palabra de «proceso», pero es importante. He aquí algunas sugerencias para convertir rápidamente a sus nuevos analistas de requisitos en expertos analistas de requisitos.

  1. Las clases genéricas sobre la definición y gestión de requisitos son excelentes, pero deben estar en línea con los procesos que usted está siguiendo en su organización.

  2. Asigne un mentor a sus nuevos analistas y deje que alguien que «ha estado allí haciendo eso» y tiene las heridas y cicatrices para demostrarlo ayude al nuevo analista y les muestre las cuerdas, lo que ayudará a eliminar ese pensamiento de «conocimiento tribal».

  3. Deja que el analista practique. Esto puede no parecer demasiado práctico. Pero no inicie un nuevo analista en un proyecto que sea crítico para la compañía. O uno que tiene tanta historia y controversia a su alrededor que será difícil seguir adelante. Deje que «practiquen» un proyecto sencillo y bien entendido para mojarse los pies.

Escribir mejor los requisitos con la herramienta profesional ALM de requisitos – Visure

    1. 7 Consejos para escribir mejores requisitos

Los requisitos de escritura han sido un reto para nosotros durante muchas décadas. ¿Por qué es tan difícil? Bueno, una de las razones es el reto del lenguaje de los requisitos. Sabemos que necesitamos escribir los requisitos de una manera que pueda ser leída y entendida por el lector. Si estamos escribiendo los requisitos del usuario, el lector es el propietario de un negocio, un usuario final o una parte interesada y el foco en la escritura en un lenguaje «natural». El problema con un lenguaje «natural», sin embargo, es que es muy impreciso y es probable que se malinterprete o se malinterprete. ¿Cómo podemos salvar esa brecha?

Me sorprende el número de analistas con los que hablo que se resisten a cualquier tipo de estructura en la redacción de sus requerimientos. Parecen estar bastante satisfechos con su enfoque no estructurado, que suele consistir en párrafos y frases descriptivas que implican muchos requisitos adicionales. A sus lectores les gusta este método, argumentan. El problema es que una vez que estos «requisitos» son entregados a los desarrolladores o analistas de sistemas, suele haber mucha discusión para aclarar lo que estos requisitos significan realmente.

Creo que aquí hay que llegar a un compromiso.

Aquí hay algunos consejos para ayudar a cerrar esta brecha.

  1. Escribe con voz activa, asegurándote de que uno de los actores sea el sujeto de cada frase.

  2. Asegúrese de que cada oración sea completa y gramaticalmente correcta con un sujeto, verbo y predicado.

  3. Especificar claramente qué información se transmite entre los actores.

  4. Mantenga un nivel de detalle consistente. (es decir, los requisitos del usuario – un usuario final es el tema de cada frase, los requisitos del sistema – un sistema es el tema de cada frase)

  5. Cada requisito debe describir criterios claros de éxito. (El usuario podrá ver el Informe de Registro de Auditoría.)

  6. Cada requisito debe establecer una sola acción y un solo objetivo. Tenga cuidado con el uso excesivo de «y» y «o». Por ejemplo:(Si es el último viernes del mes y el pago se vence el día 31, y si el 31 es el último viernes del mes, entonces enviar el pago ese día después de las 6pm hora del este resultará en un pago atrasado.) Te reto a que lo entiendas!

  7. Un requisito no debe tener una cláusula de escape. (El Sistema determinará el número de intentos de inicio de sesión excepto cuando el usuario haya introducido claramente un nombre de usuario incorrecto).

    1. 4 Consejos para ayudarle a gestionar las complejas necesidades de los clientes

¿Cómo manejaría este escenario? Un cliente ha declarado que el sistema es fácil de usar. Yo llamo a esto un requisito complejo porque es efectivamente una colección de muchos requisitos únicos. Los requisitos solicitados deben ser de nivel atómico. En otras palabras, cada requisito debe ser un pensamiento único y completo. Pero, ¿cuál es la mejor manera de llegar a este nivel con el cliente? La realidad (y la experiencia) nos dicen que muchos requisitos son en realidad mucho más complejos de lo que se afirma.

Recuerde que no debemos esperar que el cliente nos dé buenos requerimientos. Se supone que nos proporcionan el problema que quieren resolver. Si esto no está claro, ¡tenemos que preguntarles! Son expertos en el problema. Si seguimos con esta afirmación un poco más, podemos encontrar que el requisito es que el cliente debe formar a 500 personas en tres meses para utilizar el nuevo sistema. Por supuesto, debe ser fácil de usar. Pero lo que el cliente realmente necesita es una manera de asegurar que los nuevos usuarios puedan ser formados rápidamente. Esto puede cambiar el enfoque de la solución: manuales de usuario, formación en línea, tutoriales, etc.

Así que vamos a tomar esa simple petición de un sistema fácil de usar. Aquí están algunos de los problemas.

  • Un cliente no quiere que un taller determine lo que significa»fácil de usar». El cliente quiere que pensemos por él. Después de todo, somos sus «consultores».

  • El Cliente no sabe completamente lo que quiere. No han pensado bien lo que significa para ellos la facilidad de uso. Es posible que hayan agregado esto porque es una buena idea y todos los demás lo están haciendo.

  • El cliente está demasiado ocupado para proporcionarnos información de calidad. Pídales que pasen media hora hablando sobre lo que significa para ellos la facilidad de uso y es posible que simplemente se nieguen a pasar el tiempo.

  • Es posible que el Cliente no haya determinado todos los usuarios que buscan un sistema fácil de usar. En otras palabras, puede que no haya identificado a todos los que quieran determinar si el sistema es fácil de usar (por ejemplo, clientes corporativos, no corporativos, usuarios experimentados vs. usuarios inexpertos, clientes extranjeros, etc.).

Hay algunas cosas que se pueden hacer para mitigar el riesgo asociado con un requisito de este tipo.

  1. Hacer algunos prototipos de pantallas y mostrarlas al usuario. Pregúnteles específicamente si piensan que son fáciles de usar. A continuación, capture los aspectos de las pantallas en un conjunto de requisitos de la interfaz de usuario.

  2. Cree su propia definición de fácil de usar. Defina los criterios y utilícelos para definir sus pruebas de aceptación de usuario. Proporcione éstos al cliente para que los revise.

  3. Siga buscando su comprensión del problema. No tenga miedo de seguir haciendo preguntas y ahondar en la verdadera razón detrás del requerimiento del cliente.

  4. Asegúrese de tener criterios claros para medir el requisito. Sin él, usted nunca pasará el requisito a los ojos del cliente. Y sin ella, el requisito no sirve para nada.

Gestionar las necesidades complejas gracias a los modelos de datos de Visure

    1. Utiliza casos en la gestión de necesidades

Los casos de uso son una herramienta eficaz para documentar cómo hace su trabajo el usuario. A menudo llamadas «tal cual» y «como son», estas narrativas ayudan a asegurar que entendemos cómo el usuario hace su trabajo hoy (tal como es), así como cómo puede imaginar hacer su trabajo mañana (ser). Los casos de uso se están volviendo cada vez más populares a medida que los analistas continúan luchando con los problemas relacionados con la relación de los requisitos.

Sin embargo, a veces los casos de uso se utilizan eficazmente durante la obtención y definición de requisitos, pero se pierden cuando se realiza la transición a la gestión de requisitos. Si piensa en los pasos de un caso de uso, cada paso describe una acción del usuario o del sistema. Dependiendo de la granularidad que desee en sus requisitos y trazabilidad, considere hacer de cada paso en el caso de uso una declaración de requisitos. Tomemos como ejemplo el siguiente caso de uso sencillo.

El Sistema muestra la información de la cuenta al Cliente.

El Cliente revisa la información de la cuenta.

El Cliente selecciona la opción de pago.

El Sistema muestra las opciones de pago al Cliente.

De este caso de uso queda bastante claro que hay dos pasos del Sistema y dos pasos del Cliente (es decir, del Usuario). Si extraemos las dos sentencias System y, si es necesario, añadimos «shall» a ellas, obtenemos los dos requisitos siguientes del sistema:

El Sistema mostrará la información de la cuenta al Cliente.

El Sistema mostrará al Cliente las opciones de pago.

Estos dos requisitos comienzan a formar la base de los requisitos del sistema. Estos requisitos del sistema probablemente se descompondrán en muchos requisitos del sistema, pero podemos rastrearlos directamente hasta los pasos del sistema en el caso de uso.

Recuerde que los casos de uso contienen información muy valiosa para el análisis y desarrollo de sistemas. Los casos de uso nunca están realmente terminados, ya que deben ser revisados continuamente durante el desarrollo para asegurarse de que reflejan con precisión el comportamiento del producto en el momento de su entrega. Asegúrese de que los estuches de uso no se coloquen en un estante, sino que se rastreen en función de las pruebas y los requisitos del sistema.

Top