La Estación de Penitencia

12 07 2009

Hace tiempo que quedó atrás la Semana Santa, una de las fiestas más señaladas en el calendario de cualquier sevillano; no obstante, tras un reencuentro con un amigo cofrade hace unas semanas (él es cirial en la Hermandad del Santísimo Cristo de la Buena Muerte y María Santísima de la Angustia), me planteó una serie de cuestiones que me llamaron la atención, en respuesta a varias curiosidades que le trasladé: ¿qué sucedería si el aguador, los contraguías o el capataz no hicieran bien su labor?, ¿hace más el fervoroso devoto que quiere o el fornido joven que puede?

La Estación de Penitencia

La Estación de Penitencia

De sus respuestas llegué a la conclusión de que cualquier grupo de personas que se unan para alcanzar un objetivo común (como concluir una estación de penitencia, o abordar un proyecto software) se ha de regir por una serie de pautas que, expresadas con la suficiente generalidad, pueden ser reutilizadas con independencia del tipo de grupo y de los objetivos que éste persiga.

Las respuestas de mi amigo parten de sus experiencias, todas ellas vividas de cerca, teniendo mayor o menor cabida en esta metáfora en función de las experiencias de cada uno, pero de lo que estoy seguro es que hacen resentir el trabajo de los costaleros, llegando incluso a resentir el esfuerzo humano y económico que realiza la propia Hermandad preparando con ilusión cada estación de penitencia, e incluso el propio patrimonio histórico del que estas Hermandades disponen.

  1. El aguador, en multitud de ocasiones, suele dar más líquido refrescante a los costaleros que se encuentran más en el exterior (próximos al perímetro que marcan los respiraderos), mientras que los que se encuentran en el centro de la parihuela reciben menos hidratación, resultando su trabajo más costoso que el de los otros al experimentar cierto sufrimiento ante esta deshidratación.
  2. En una salida o entrada dificultosa, si el capataz no da correctamente las órdenes o no escucha las indicaciones de los contraguías (o las escucha pero estas indicaciones son incorrectas), el paso puede fallar en sus movimientos hasta tener un accidente con el dintel o la jamba que se quiere salvar. En este caso encajarían algunas de las salidas del palio de la Hermandad de Santa Cruz, donde por no ser correctas las órdenes del capataz, en más de una ocasión se ha dañado la orfebrería del palio al rasparse contra el pórtico del templo.
  3. El capataz y los contraguías, de forma inconsciente, tienden a animar a los costaleros más pegados a ellos (es decir, los que van en el perímetro que marcan los respiraderos), cuando la realidad es que los costaleros que van en medio de la parihuela suelen soportar mucha más presión y peso en sus “morcillas” que los anteriores.
  4. Si el capataz no ha ensayado bien con sus costaleros las “levantás” podrían surgir accidentes graves como la caída de enseres o de la propia imagen (por muy atornillada que esté), como sucedió en 2004 (tal vez 2005, mi amigo no lo recordaba con nitidez), en plena calle Sierpes, cuando la Virgen de la Estrella hizo una “levantá” tan brusca que rompió uno de sus varales maestros.
  5. Si el capataz no ha ensayado bien con sus costaleros las “chicotás” podrían aparecer casos de desvanecimientos, lipotimias, bajadas de tensión y lesiones crónicas de cervicales entre los hermanos costaleros, en el mejor de los casos; en el peor, podrían producirse incluso insuficiencias cardíacas (nada habituales, pero hay algún caso).
  6. Al hacer el capataz las “igualás” de la cuadrilla, es decir, la selección de las personas en función de sus medidas para portar el paso, podría suceder que la asignación no estuviera igualada en altura en cada trabajadera. En este caso el paso estará descompasado y sus movimientos serán torpes y desgarbados.
  7. Hay capataces que realizan decenas de ensayos antes de la salida procesional, junto a sus contraguías y su cuadrilla de costaleros. Otros, en muchos casos de gran prestigio, confían tanto en su buen hacer que realizan pocos o ningún ensayo con los contraguías y la cuadrilla, y desconocen las cualidades de cada uno de ellos. Durante la estación de penitencia, estos pasos también suelen acusar de falta de garbo (especialmente acusada en pasos de palio).
  8. En una cuadrilla de costaleros hay algunos que están mejor preparados que otros (bien por cuestiones físicas o simplemente por edad), pero todos hacen la estación de penitencia íntegramente. A título anecdótico, en 1999, el misterio del Cristo de las Aguas a su paso por el Arco del Postigo del Aceite perdió a uno de sus hermanos costaleros tras sufrir éste un infarto al corazón (casualmente, era uno de los que iban en el centro de la parihuela). Tal vez físicamente no estuviera al nivel de los otros, pero indiscutiblemente su devoción y su entrega eran absolutas.

Además de estas cuestiones podrían plantearse otras muchas, todas ellas ajenas a cómo de bien o mal hagan su labor capataz, contraguías, aguador o costaleros, y relacionadas con factores externos, que también pueden resentir el trabajo de los costaleros y el esfuerzo humano y económico que realizan las Hermandades (entre ellos, las desavenencias climatológicas, los retrasos durante la Carrera Oficial impuestos por otras hermandades en procesión, etc.).

En fin, espero que saquéis partido de la metáfora y, si os he transmitido algo de sentimiento cofrade, recomiendo que vayáis a ver el próximo Martes Santo al Cristo de la Buena Muerte, considerado la obra cumbre de Juan de Mesa y perteneciente al patrimonio del Estado.

¡¡Ahí quedó!!





Analizando… desde Documentos

11 06 2009

En ocasiones se remite al Analista Funcional a Guías de Usuarios de distintos sistemas, y otros documentos de muy diversa índole, como fuente única de necesidades y/o expectativas en el Proceso de Definición de Requisitos. Esta circunstancia suele presentarse cuando …

  • los usuarios finales son muy dependientes de dichos sistemas,
  • los usuarios finales no tienen claro lo que desean,
  • los usuarios finales son poco indulgentes asumiendo la programación de horas asignadas para el análisis,
  • la comunicación con los usuarios finales es muy lenta,
  • la cultura de empresa permite vislumbrar que los usuarios finales no se involucrarán en la elaboración de requisitos,
  • la cultura de empresa permite vislumbrar que los usuarios finales no participarán en revisiones o serán incapaces de hacerlo,
  • se “invita” al equipo a obtener los requisitos de todas las maneras posibles antes que entrevistar a usuarios y grupos focales.

Reunir requisitos a partir de Manuales de Usuario no es la forma ideal de trabajar. La lectura de la documentación es realmente útil, pero no será suficiente. Si no es posible acceder a los usuarios finales, existen ciertos aspectos a tener en cuenta durante las actividades de análisis.

  1. Deshacerse de la sombra del pesimismo: si los usuarios y las distintas las unidades de negocio por parte del cliente están contentos con las características que ofrecen los sistemas actuales, y el nuevo sistema debe ser creado manteniendo dichas características, entonces reunir los requisitos a partir del manual de usuario no es un mal comienzo.
  2. Tratar de conseguir una lista de características y beneficios, acudiendo a personas de Organizaciones o sistemas de respaldo, o a la propia Dirección, para conseguir una visión global del problema.
  3. Será necesario acudir a otras personas para disponer de una visión más detallada, como programadores encargados del mantenimiento o administradores de los sistemas en cuestión, y hablar de las principales funciones del sistema. No se obtendrán hallazgos acerca de qué funcionalidades son las que realmente aportan valor, pero posiblemente la visión adquirida y el propio juicio permitan obtener una primera aproximación válida.
  4. Documentar las características encontradas en la documentación y, a continuación, refinar los hallazgos con diagramas de contexto para determinar el alcance del actual sistema y para identificar las principales funciones y sistemas externos.
  5. Los manuales de usuario, en general, no especifican qué reglas de negocio o qué lógica utiliza el sistema para llevar a cabo sus tareas. Por ejemplo: el manual del usuario podría decir: “Para saber la TAE para el préstamo, pulsar [Calcular TAE] en la pantalla Detalles de Préstamo”. Este nivel de detalle es lo suficientemente bueno para el usuario final, pero no lo es para el Analista Funcional dado que será necesario construir un nuevo sistema que calcule la TAE (con su correspondiente lógica y fórmulas para ello).
  6. Si en algún momento se percibe algún tipo carencia, defecto o elementos que no están presentes en el sistema actual, serán documentadas y volcadas en un modelo to-be. Priorizar la lista resultante y utilizarla para estudiar otras alternativas existentes sobre soluciones similares al sistema considerado, con las que anticiparse al fenómeno de la Ignorancia, del que ya se ha hablado en posts anteriores.
  7. No perder de vista otras fuentes de información; las más útiles: checklist de características pendientes, peticiones de cambio o de mejora en el sistema y especificaciones originales de Requisitos del momento en el que el sistema se introdujo por primera vez, para cotejar con él que todas las características están cubiertas en la forma convenida.
  8. Ser capaz de “robar con disimulo” el tiempo de personas que conozcan el sistema. Ir a almorzar con ellos y conversar sobre el sistema en torno al menú del día. En el arsenal de herramientas del Analista Funcional no todo debe girar alrededor de los canales oficiales.




Si no puedes medirlo, no puedes mejorarlo

8 12 2008

Llevo bastante tiempo preguntándome cómo medir un requisito, sin encontrar respuestas que me satisfagan plenamente. Después de estos meses, creo que la pregunta de partida estaba mal formulada; antes de determinar qué atributos son medibles en un requisito es necesario determinar cuál es el objetivo de esta medición.

A diferencia de otras parcelas del desarrollo software donde la medición es tangible y persigue unos objetivos claros en cuanto a métricas de calidad, mantenibilidad y sostenibilidad del código, complejidad, cobertura de los test, etc., la medición de requisitos debe centrarse en otro tipo de atributos, tales como personas involucradas en el proceso, seguimiento y mantenimiento de requisitos, prioridad, estado, etc.

La adquisición de los atributos con los que obtener estas mediciones está repartida durante el ciclo de vida de un proyecto software, por lo que ser ordenado y metódico es fundamental. Algunas mediciones podrán ser obtenidas durante el Proceso de Toma de Requisitos, otras durante el Proceso de Definición de Requisitos, y otras en el Análisis, Verificación y Validación de Requisitos.

Métricas del Proceso de Toma de Requisitos
Para hacer estas mediciones es imprescindible disponer de mecanismos que en cualquier momento permitan responder a las siguientes preguntas:

  • ¿Quién solicitó el Requisito y cuándo, y quién es el responsable del mismo? Cuantificar y localizar el trabajo involucrado en la definición y mantenimiento del Requisito para poder tomar decisiones cualitativas al respecto. Esta métrica permitirá sentar las bases del historial de modificaciones para cada requisito.
  • ¿Por qué lo solicitó? Cuantificar el grado de cobertura de los objetivos definidos (objetivos que son alcanzados). Esta métrica permite evaluar si se cumplen los objetivos (a nivel de Análisis), con el cumplimiento de los Requisitos que lo sustentan. Los Requisitos sirven para alcanzar, al menos, un objetivo. De lo contrario, el Requisito dejará de ser vital en el negocio y por tanto negociable.
  • ¿Qué prioridad tiene? Cuantificar el impacto o criticidad del requisito en el negocio del usuario originario de cada Requisito.

Métricas del Proceso de Definición de Requisitos
Estas mediciones se realizan sobre las especificaciones definidas para cada Requisito, y están íntimamente relacionadas con cuestiones de forma, recogidas en los 13 mandamientos del Proceso de Definición de Requisitos:

  • Condicionalidad: grado en el que intervienen tiempos condicionales.
  • Especificidad: grado en el que intervienen expresiones vagas en significado, como “generalmente …”, “comúnmente …”
  • Opcionalidad: grado en el que intervienen opciones en la descripción de un Requisito. La opcionalidad en un Requisito se modelará como atributos del Requisito o en nuevos Requisitos, pero nunca en el mismo Requisito.
  • Atomicidad: grado en el que se detalla en un Requisito cada necesidad, de forma individual. Inversamente proporcional a la Opcionalidad. Muchos verbos concentrados en un Requisito dificultan su comprensión y su posterior trazabilidad.
  • Legibilidad: grado en el que un Requisito es legible y comprensible. Evitar el exceso de información en cada Requisito; las informaciones se mezclan si se proporciona demasiado detalle (ese detalle se indicará en Casos de Uso, refinando los Requisitos). No recurrir a Acrónimos, salvo que se recojan en Glosarios u Ontologías de Términos. No usar pronombres.

Métricas del Proceso de Análisis de Requisitos

  • ¿Relación con otros Requisitos? Cuantificar el grado de cobertura de los Requisitos definidos (Requisitos que son alcanzados). Esta métrica permite evaluar si se cumplen los Requisitos (a nivel de Análisis), con el cumplimiento de otros Requisitos que los sustentan.
  • ¿En qué versión se encuentra el Requisito? Cuantificar la variabilidad en base al cambio y al impacto del mismo, es necesario disponer de mecanismos que permitan llevar a cabo control de versiones para los Requisitos. De esta forma se podrán seguir los cambios durante la vida de cada Requisito, acorde al avance de las etapas/iteraciones de análisis, diseño y desarrollo, así como el feedback que se genere con los usuarios originarios de cada Requisito.
  • Negociabilidad: grado en el que los Requisitos son negociables. Para mejorar el feedback con el cliente, se partirá de Requisitos que recojan una breve descripción de los mismos. La negociabilidad de estos Requisitos es alta. Los detalles se recogerán progresivamente, durante la fase de “conversación”, reduciéndose su negociabilidad. De este modo se evita partir de Requisitos con demasiados detalles, que limitan la conversación con el cliente. Con esta métrica se controla la aparición del fenómeno “Ignorancia”, descrito en posts anteriores.
  • Valor: cada Requisito tiene que generar valor para el cliente (ya sea el usuario final o “el que paga”). Una buena manera de conseguir Requisitos valiosos es hacer que sea el propio cliente quien los escriba; les será mucho más cómodo escribirlos una vez se den cuenta de que los Requisitos no son un contrato y son negociables. Con esta métrica se controla la aparición del fenómeno “Pollaque”, descrito en posts anteriores.
  • Estimable: los desarrolladores tienen que ser capaces de estimar (de forma aproximada) el esfuerzo necesario para construir cada Requisito, para permitir al equipo fijar prioridades e hitos. Los problemas más comunes que pueden encontrar los desarrolladores al estimar Requisitos son: falta de conocimiento de dominio (en cuyo caso hay una necesidad de una mayor negociación/conversación con el cliente), y Requisitos demasiado grandes (han de ser divididos en pequeñas historias).
  • Pequeño: un buen Requisito debe ser pequeño en esfuerzo; por lo general, nunca debe representar un esfuerzo de más de 2-3 semanas de trabajo una persona. De lo contrario, pueden haber errores asociados con el alcance y la estimación.
  • Testeable: cada Requisito tiene que ser comprobable, y cada aserción y verificable y medible de forma sencilla, para la “validación” final que tendrá lugar. Si no es posible probarlo/medirlo/verificarlo, nunca se sabrá cuando se ha terminado. Típicos ejemplos de Requisitos no testeables o difíciles de medir: “el software debe ser fácil de usar”, términos como “accesible”, “amigable”, “rápido” y “eficiente”.




Pollaques vs Ignorancia

6 12 2008

Recientemente, en una de las últimas entradas se lanzaba la pregunta siguiente: ¿Qué es peor? ¿Un pollaque o la ignorancia? Antes de exponer mis conclusiones (mías, propias), me gustaría presentar varias perspectivas sobre los pollaques y la ignorancia, todas ellas fruto de experiencias que he tenido recientemente, analizadas con cierto grado de pesimismo (pero reales en definitiva).

Perspectivas de un “pollaque”

El pollaque visto desde la perspectiva del cliente no suele ser concebido como tal. El cliente no entenderá que existan necesidades o expectativas que no sean críticas en el negocio y que de ser incluidas en la especificación harán peligrar las planificaciones inicialmente definidas, y esto provocará, en el mejor de los casos, malestar:

  • El cliente considerará que todo es crítico en el negocio, y por tanto todo ha de ser incluido en la especificación de los sistemas a construir.
  • Es cierto que existen clientes con los que es posible razonar; tras justificar por qué ciertas consideraciones no son vitales para el negocio y por qué la inclusión de dichas consideraciones (no planificadas inicialmente) hacen peligrar el cumplimiento de planificaciones temporales y económicas, se retractan del pollaque. No obstante, en mi experiencia (no demasiado dilatada, todo hay que decirlo), esto no es lo común.
  • Este riesgo que genera una vulnerabilidad se puede convertir en oportunidad. La clave, la negociación. Si tras justificar la no viabilidad temporal y económica del pollaque éste finalmente ha de ser incluido en las especificaciones, la negociación es la única salida. ¿Y qué negociar? la planificación temporal y económica; cuando éstas sean intocables, el alcance del proyecto (si meto por aquí, habrá que quitar por otro lado).

El pollaque visto desde la perspectiva del equipo de desarrollo. Si se supo justificar al cliente la no viabilidad del pollaque y éste lo acepta, el pollaque se disolverá o dejará de ser pollaque para convertirse en nuevos requisitos (tras haber revisado la planificación temporal, económica, o el alcance del proyecto). Por este motivo el equipo de desarrollo no debería percibir pollaques. Sin embargo, si llegan a observarlos:

  • Será síntoma de que se incluyó en las especificaciones sin revisión de tiempos, costes ni alcances, lo cual se traduce en sobre-esfuerzo, y éste a su vez en malestar el equipo de desarrollo.
  • Haciendo malabarismos con los recursos, podría ser posible asumir estos sobre-esfuerzos sin sobrecargar al equipo de desarrollo, pero siempre a costa de resentir otros proyectos, trasladando ese malestar desde el equipo hacia los clientes de esos otros proyectos.

El pollaque visto desde la perspectiva de la Jefatura de Proyecto. Al igual que en el caso anterior, el pollaque habría podido desaparecer o convertirse en nuevos requisitos (tras haber revisado la planificación temporal, económica, o el alcance del proyecto). Por este motivo la Jefatura de Proyecto tampoco debería percibir pollaques. Sin embargo, si llegan a observarlos, ésta cuestionará el trabajo del Analista Funcional por:

  • Malestar del cliente.
  • Malestar del equipo de desarrollo.
  • Asumir riesgos (no sé hasta qué punto innecesarios) que podrán poner en peligro la ejecución del proyecto en cuanto a planificación temporal y económica. 

Perspectivas de la ignorancia

La ignorancia vista desde la perspectiva del cliente no suele ser concebida como tal. El cliente no entenderá que existieran cosas que no sabías que no sabías y esto provocará, en el mejor de los casos, malestar:

  • El cliente considerará que se transmitieron todas sus necesidades y expectativas, y que se hizo en un lenguaje claro, directo y sin ningún tipo de vacíos.
  • Los procesos de toma y verificación de requisitos suelen ser costosos y el cliente no suele recibir con entusiasmo estos costes (aunque estén planificados), menos aún si se trata de abordar las consecuencias de esa ignorancia (que no suelen estar planificadas). Por otra parte, los usuarios expertos tampoco los encajan bien porque iterar sobre la visión adquirida del negocio para refinarla, resolver ambigüedades, … supone esfuerzo que se traduce en tiempo, tiempo que a veces se concibe como perdido y no como invertido.
  • Si la ignorancia se manifiesta sobre el sistema en producción, entonces las consecuencias pueden ser desastrosas ya que la solución podría no aportar valor al cliente. En este caso el malestar puede elevarse a la enésima potencia: no fidelización con el cliente, rescisiones de contratos, etc.

La ignorancia vista desde la perspectiva del equipo de desarrollo hace que éste se cuestione cualquier omisión sobre los requisitos: ¿no está porque no tiene que estar o porque no lo hablaste con los usuarios expertos? El equipo, una vez se sumerge en el negocio, detecta restricciones, reglas de negocio, etc. que pueden parecer lógicas y aplicables. Algunas serán fruto de esa hiperactividad mental que nos caracteriza y se desechan. Otras, serán el fruto de lo que no sabías que no sabías y se formularán a los usuarios expertos para generar nuevos requisitos.

  • Éstas fomentarán las consecuencias anteriores sobre la ignorancia vista desde la perspectiva del cliente.
  • Además, podrán hacer crecer cierta desconfianza por parte del equipo sobre lo especificado, y esto aumenta esa hiperactividad mental, que a su vez hace que aumenten las preguntas ¿no está porque no tiene que estar o porque no lo hablaste con los usuarios expertos?, y así sucesivamente.
  • En cada iteración completa de este bucle el malestar del cliente y la desconfianza del equipo tenderán a crecer.
  • Si la ignorancia se manifiesta sobre el sistema en producción, será necesario dedicar esfuerzo adicional (normalmente no presupuestado, ¡ni remunerado!) para poder remendar los efectos de la ignorancia (a costa de robar dedicación a otros proyectos y de sobrecarga en el equipo).

La ignorancia vista desde la perspectiva de la Jefatura de Proyecto hace que ésta cuestione el trabajo del Analista Funcional por los puntos expuestos anteriormente:

  • Malestar del cliente.
  • Desconfianza del equipo de desarrollo.
  • Si la ignorancia se manifiesta sobre el sistema en producción, existirán proyectos abiertos eternamente que nunca llegan a facturarse, aumentando el malestar del cliente y el del equipo de desarrollo que probablemente tenga que retrabajar para cubrir esas carencias fruto de la ignorancia.

Mis conclusiones

Antes responder a la pregunta ¿Qué es peor? ¿Un pollaque o la ignorancia? , es necesario conocer el entorno (Cliente, Equipo de Desarrollo y Jefatura de Proyecto) y sus características (asunción de responsabilidades -el cliente también asume las que le corresponden-, empatía, concepción del equipo -el cliente también forma parte de él-, percepción del tiempo -es perdido o invertido-, tolerancia ante el cambio, implicación y motivo de implicación, grado de interés en alcanzar el éxito y hasta dónde se está dispuesto a llegar para alcanzarlo).

Conociendo mi entorno y sus características, mi conclusión es que los pollaques son menos perjudiciales que la ignorancia:

  • Sus consecuencias son menos dañinas que las de la ignorancia. Las perspectivas anteriores lo justifican.
  • A pesar de ser su gestión más compleja e incómoda, ofrecen más margen de maniobra. Es mejor ponerse la cara colorada al inicio del proyecto que el que te la pongan al final.
  • Pueden tornarse en oportunidades cuando son gestionadas con maestría (no lo digo por mí, pero sí he presenciado algunas). De la ignorancia nunca surgirá una oportunidad (tal vez sí, oportunidades para la competencia …).
  • Se ven venir, y en consecuencia se pueden definir estrategias con las que sobreponerse. La ignorancia, por contra, es un enemigo que acecha desde la sombra. Lo único que puedes hacer es rezar para que ataque lo antes posible.




Lo que sé que sé (Parte I)

27 09 2008

En entradas recientes hablaba sobre aquello que sé que sé, sobre aquello que sé que no sé, sobre aquello que no sé que sé y sobre lo que no sé que no sé. Acontecimientos de los últimos días me han hecho reflexionar sobre cómo de axiomático debe ser lo que sé que sé.

Las responsabilidades del Analista Funcional deben ir más allá de volcar lo que sabe que sabe en requisitos:

  • Durante el Análisis de los requisitos, tras la captura de los mismos (tras la definición de lo que se sabe que se sabe), las responsabilidades del Analista Funcional podrían resumirse en la verificación de cómo de realistas son estas necesidades y expectativas volcadas en requisitos, en la priorización de los mismos y en la identificación de problemas como ambigüedades, inconsistencias y escenarios mal negociados que hagan peligrar los alcances y los propios planes de hitos.
  • Tras el Análisis de los requisitos, comienza una iteración de especificación y refinamiento de los mismos: los requisitos continúan tomando forma, permitiendo a los individuos involucrados añadir detalles (que en fases previas eran impensables) sobre los distintos modelos y reglas de negocio, casos de uso (o historias de usuario, o escenarios funcionales, etc.) y prototipos (en papel, no ejecutables). También es en esta iteración cuando comienza a tener sentido la gestión del cambio (en base a mecanismos de trazabilidad entre artefactos de Análisis), e identificar la forma en que se han de satisfacer ciertas necesidades de información mediante la integración con aplicaciones y procesos existentes (en el mejor de los casos, cajas negras mantenidas por terceros).
  • Tras esta iteración de especificación y refinamiento, se lanza la verificación y validación de lo especificado: los distintos individuos involucrados validan que su visión inicial del negocio es la que se refleja en los flujos generados y que los detalles son exactos y completos, para asegurar que el sistema a construir se ajusta (desde su concepción) a las necesidades deseadas, incluso en materia de integración con sus entornos de trabajo.

Algunas de estas responsabilidades parecen requerir además de la colaboración de otros perfiles del equipo, más teniendo en cuenta el skill del Analista Funcional (del que hablaremos en futuros post). De lo contrario …

  • ¿Cómo de idónea será la identificación de ambigüedades que realice el Analista Funcional? No perdamos de vista que el cliente final del Análisis es el propio equipo de desarrollo (ajeno a los procesos anteriormente descritos), y que siempre existirá una porción de información que no sabrás que no sabías (de hecho, los propios individuos involucrados en el proceso de toma de requisitos tampoco sabrán que no sabían, de ahí que antes hablase de visión inicial).
  • ¿Cómo de idónea será la negociación y priorización que lleve a cabo el Analista Funcional sobre cada una de las necesidades detectadas? Del conjunto de necesidades se han de distinguir aquellas que impactan transversalmente en el negocio de las que simplemente quedarían bien. Tal vez en esta cuestión el Analista Funcional con su skill tenga mucho que aportar por su papel de interlocutor, pero no perdamos de vista que la viabilidad, el esfuerzo y el impacto final de cada requisito está en la mente del propio equipo de desarrollo (naturalmente hablo de equipos de desarrollo relativamente auto-organizados, experimentados y disciplinados).

El equipo, la comunicación y la colaboración sencilla y eficaz son la clave de este proceso, aunque le pese a Confucio y a uno de sus proverbios más citados: saber que se sabe lo que se sabe y que no se sabe lo que no se sabe; he aquí el verdadero saber.





Lo que sé que sé (Parte II)

24 09 2008

Estas conclusiones apuntan a que los procesos de definición y gestión de requisitos pueden mejorarse enormemente aplicando ciertas buenas prácticas (inspiradas por valores). En el lugar donde trabajo intentamos día a día refinar y mejorar nuestros procesos, y creo que empezar por adoptar ciertas ideas de Scrum y del Product Backlog puede ser un buen punto de partida.

Sin ser un experto en metodologías ágiles, y con mucho camino aún por recorrer, sí vislumbro ciertos valores y prácticas que mejoran los procesos, y que deben acompañarlos en cada fase del ciclo de vida. Concretamente, y en las fases en las que interviene el Analista Funcional, considero interesantes los siguientes valores y prácticas:

  • Los artefactos de Análisis deben contener información viva, en continuo crecimiento y evolución, que durante el ciclo de vida se va desarrollando en paralelo con el resto de actividades; de esta forma siempre se proporcionará al cliente el mayor valor posible. Este valor es fundamental, aunque se ha de asumir que los alcances (medidos en necesidades a su vez expresadas en requisitos) son negociables.
  • La concepción del negocio por parte del cliente (su visión) ha de ser conocida por todo el equipo. Cuando esta visión sea comprendida por el equipo, sus aportaciones introducirán (o descartarán) funcionalidades, mejoras y tecnologías, permitiendo la detección y corrección de errores de forma prematura, que se incorporarán a los productos de Análisis a través de sucesivas iteraciones del proceso.
  • Como resultado de estas iteraciones, el equipo generará una visión real, aún más comprendida y compartida por todo el equipo. Este valor, a su vez, refuerza a las anteriores prácticas.

Esta es mi visión (mía, propia, particular), que espero seguir refinando y mejorando poco a poco (porque será un síntoma claro de madurez) en futuros post sobre cómo materializar estos propósitos y buenas intenciones en el día a día.





Lo que sé que sé, lo que sé que no sé, lo que no sé que sé y lo que no sé que no sé

17 09 2008

Ante una frase como la que titula este post, hace 8 años, en el instituto, lo que se me hubiese pasado por la cabeza serían figuras retóricas como aliteración, anadiplosis, anáfora, encabalgamiento o paradoja. A día de hoy me evoca otras mucha sensaciones, que me llevan a pensar que la retórica no sólo puebla la literatura universal, también se presenta en el día a día del Analista Funcional.

Este perfil, por la horizontalidad de su trabajo, se suele ver salpicado por cualquier conflicto que aparezca durante la vida de un proyecto software. En mi opinión esto no es ni bueno ni malo, es inherente a la naturaleza de las responsabilidades asumidas por el propio perfil. Cuanto más expuesto se está al peligro, más consciente se ha de ser de este tipo de circunstancias. Recientemente un compañero de la oficina pasaba el enlace a un artículo que trataba estas cuestiones; me gustaría rescatar de él esta frase, mordaz y a la vez llena de sentido (FA, Functional Analyst): … All fingers often point to the FA. If the FA does their job, then everything should work out. If something is found to be missing from the solution, then the FA is often the role that is blamed first.”

En los procesos de toma de requisitos existen factores que condicionan el éxito de los mismos; según el porcentaje de ocurrencias de estos, la balanza se inclinará hacia un lado o hacia el otro. Estos cuatro factores que me acosan cada día son los plasmados en la siguiente imagen (probablemente se podrían definir con una granularidad mucho más fina).

Cuando sé que sé, lo que sé adquiere validez axiomática, y se plasma en un requisito. Este es el factor en el que el riesgo en el proceso de toma de requisitos es nulo, siempre y cuando los requisitos capturados se definan de acuerdo a los 13 mandamientos en el proceso de definición de requisitos.

Cuando no sé que sé, lo que sé es porque hay un bagage de información, buenas prácticas y habilidades que en cierto modo están arraigadas en la metodología de trabajo, en la forma de concebir el negocio de cada cliente, etc. En definitiva, es el resultado de la experiencia (la mía no es aún demasiado dilata, todo hay que decirlo). Este factor incorpora un cierto nivel de riesgo, que se puede mitigar.

Cuando sé que no sé, es necesario lanzar una nueva iteración en el proceso de toma de requisitos. De este tema me gustaría hablar más detalladamente en futuros posts, aunque todo gira en torno al enfoque JIT (Just In Time), consistente en obtener el nivel de detalle necesario en el momento oportuno.
En la capacitación del Analista Funcional, las suposiciones no suelen ayudar. Lanzar preguntas abiertas (la respuesta no es un sí o un no) sí. Las preguntas sí/no, si son necesarias, se harán en la última iteración del proceso. Estas preguntas abiertas serán del tipo ¿y si …? y ¿qué sucede en caso de …?, entre otras. No obstante, constituyen un arma de doble filo dado que las respuestas podrían venir acompañadas a su vez de preguntas del tipo ¿Pues ya que …? (comúnmente denominadas “pollaques”), las cuales, en el peor de los casos, derivarán en una revisión del alcance del proyecto (y en el consecuente arrojo a la hoguera del Analista Funcional).

Cuando no sé que no sé, … cuando no sé que no sé … ¡No sé! Este factor es el que introduce mayor riesgo en el proceso, la felicidad del ignorante, y si no es detectado puede originar auténticos fracasos. Por orden de aparición y de magnitud del desastre, nos encontramos el retrabajo (y el consecuente esfuerzo malgastado), las planificaciones y alcances infravalorados, retrasos en hitos, malestar de los involucrados en el proyecto y, por qué no, rescisiones de contratos (afortunadamente para el Analista Funcional, fue echado a la hoguera hace mucho). ¿Realmente se debe delegar este factor al destino? Estoy empezando a alcanzar conclusiones sobre esto, y necesito madurarlas un poco. La respuesta, en futuros posts.