Archivo | Software RSS feed for this section

Arquitecturas Ágiles

21 Sep


El concepto de arquitectura de software se refiere, de forma genérica, al conjunto de módulos que se identifican como la solución software y todas aquellas implicancias técnicas referidas a la integración óptima de dichos módulos.

Definir una arquitectura nos conduce a reflexionar en una serie de decisiones que se toman detenidamente durante las primeras fases del desarrollo de un software como parte del denominado Diseño de Arquitectura del Software. Estas decisiones deben ser muy cuidadosas puesto que una vez definida la arquitectura se convierte en “cimiento” y el software se comienza a desarrollar sobre la misma. Encontrarnos con la necesidad de tener que cambiar por algún motivo puede llevarnos a un impacto importante en los tiempos y costos del proyecto.

Ahora bien, esta propiedad de previsibilidad que debemos considerar en esta etapa se contrapone un poco con la esencia ágil de abrazar los cambios. Entonces… ¿un arquitecto debe ser previsible para evitar dichos cambios o los aborda sin precuparse demasiado?.

Ante esta disyuntiva, aflora otra pregunta más: ¿podemos hablar de arquitectura en el sentido tradicional dentro de proyectos ágiles?. Al parecer…SI. Surge entonces el concepto de Arquitectura Ágil.

Sigue leyendo

Java 5, 6…7!

13 Sep

Desde el pasado julio de 2011, Oracle ha puesto en disponibilidad la versión 7 de Java luego de aproximadamente 5 años de trabajo no solo de ingenieros de Oracle sino también de miembros de la comunidad Java mundial  a través del proyecto OpenJDK.

En este post les quiero presentar algunas de los cambios que nos acompañan en esta nueva versión.

Sigue leyendo

La deuda técnica

1 Ago

En muchos proyectos de desarrollo software se suele presentar una disputa entre el satisfacer las restricciones de tiempo/costo versus el requerimiento de entrega de un producto de calidad.

Razones para esto son muchas entre las cuales tenemos:

  • Aspectos estratégicos: Las empresas buscan maximizar su rentabilidad estableciendo condiciones para que los productos se finalicen con tiempos y costos aceptables para el cliente (e ideales para la empresa) pero con niveles de calidad pobrísimos.
  • Aspectos Procedimentales: La calidad, no es correctamente gestionada durante el proceso de desarrollo del software.

Veamos algunos ejemplos gráficos que clarifican esta situación. Idealmente, tendríamos un esquema de avance en el proyecto como el siguiente:

Se espera que la totalidad de los requerimientos sean entregados en una fecha predeterminada.  Para lograr esto, el equipo trabaja a una velocidad planificada de entrega.

Comenzado el proyecto y con el correr del tiempo, aparecen los problemas debido al esfuerzo real que implica cumplir con un trabajo de alta calidad.  Son problemas puesto que las planificaciones iniciales subestimaron el esfuerzo de entregar calidad.

En el anterior gráfico se observa cómo se empieza desviar el avance real respecto al planificado.

Ante esta situación, el Project Manager (PM) acude a una presión extra sobre el equipo con el afán de que se pueda ajustar la fecha de entrega. Si esto funciona, tendremos un escenario como el siguiente:

Dicha presión sobre el equipo funcionó pero no es gratis, alguien tuvo que pagar y esa fue la calidad del producto. Se disminuyó en pos de poder cumplir con los tiempos y costos.

Viendo entonces que fue posible reencauzar el proyecto, el discurso de fundamentación del PM ante el cliente es que “se ha podido retomar el camino ya que el equipo ha adquirido una mejor performance, lo cual le permite avanzar mas rápido”. La realidad es que pudimos cumplir con los plazos y costos cuando se redujo la  calidad del producto. Esta diferencia entre lo que se entregó y lo que se debería haber entregado se denomina deuda técnica (ver orígenes del término en http://en.wikipedia.org/wiki/Technical_debt). Ésta deuda se genera al hacer las cosas de forma rápida y mal.

La deuda técnica es el trabajo vinculado a las funcionalidades comprometidas y que es diferido o descartado para poder cumplimentar con los cronogramas. Que sea diferido implica que no es entregado, por lo tanto afecta la calidad total del sistema.

Ahora pensemos que sucede si tomamos como base el código de proyecto “cumplido” para ejecutar otro proyecto similar. Todo se complica aún más puesto que se parte de código que ya acumula deuda técnica. Ocurre así un efecto de generación de mas cantidad de deuda técnica ya que el nuevo proyecto acumula no solo la deuda nueva generada sino también la heredada

Ejemplos de deuda técnica son, entre otros:

  • Retraso de las actualizaciones criticas.
  • Retraso en el refactoring  del código complejo.
  • En aplicaciones web, codificar toda la lógica de negocio en la capa de presentación.
  • No utilizar logs o manejo de errores robusto.
  • No realizar pruebas o realizarlas de forma muy superficial.

Consideremos una cuestión extra: si este trabajo técnico no hecho es necesario para la salud del producto ¿qué pasa cuando no se hace nada con él? ¿qué pasa cuando se acumula y continúa acumulando deuda técnica y no se la trata?

Veamos un ejemplo. Para un determinado producto, solemos crear la primera versión con deuda técnica. Luego se siguen mas versiones y así sucesivamente. Cada versión introduce nueva deuda. Esto crece al punto que cuando alguien solicita realizar un cambio al producto, el equipo de desarrolladores estalla de rechazo. ¿El motivo?: el producto es inmantenible, es muy complejo para modificar, el código tiene miles de LOC, se requieren desarrolladores expertos para poder modificarlo y cientos de etcéteras.

Cuando esto sucede se dice que el código ya presenta un diseño muerto.  Ante un diseño muerto, la verdad es que no queda mucho por hacer.

Sin dudas existen muchos proyectos como estos. Yo tengo un par de nombres que recuerdo con mucho “cariño”.

Como párrafo final, uno de los grandes facilitadores de este tipo de situaciones es, a mi criterio, el tipo de contrato que se establece entre el cliente y el proveedor, que suele ser del tipo predictivo y precio fijo. Estos contratos se establecen definiendo el alcance del proyecto en etapas tempranas (controlando luego que no se realicen los cambios sobre el mismo o que sean mínimos) e imponiendo restricciones de costo y tiempo. Esta situación, combinada con empresas como las mencionadas al inicio, en las que términos como patrones de diseño, pruebas continua, formación al personal, control de calidad prácticamente no existen, forman un cóctel que sirve deuda técnica en vasos cada vez más grandes.

¿Cómo se evitan o disminuyen los riesgos de deuda técnica?. Pensando solo en la arista referida a los contratos (la otra arista, la de las empresas ávidas de rentabilidad a cualquier costo la dejamos para otro momento) deberemos considerar la adopción de contratos ágiles. Simplemente se los comento ya que esto será inspiración para otro post.

Espero que les haya sido de utilidad.

Seguimos en contacto. Gastón.

Basado en: http://www.scrumalliance.org/articles/14-technical-debt-and-design-death

Usabilidad, haciendo bello el cántaro

17 Abr

Ha pasado un tiempito desde el último post pero aquí estoy de nuevo en el ruedo. Esta vez traigo un tema muy importante pero desprestigiado o subestimado al momento de llevar adelante proyectos de software: la usabilidad.

La usabilidad se define como:

Atributo de calidad que evalúa que tan fácil es la interfaz de usuario para utilizarla.
Este concepto también se aplica a los métodos existentes para mejorar dicha facilidad de uso durante el diseño del sistema.

– Jakob Nielsen –

Garantizar la usabilidad de un sistema informático representa un aspecto crítico, puesto que nos expresa el grado de satisfacción de uno de los interesados más importantes dentro de un proyecto: los usuarios.

¿Llegamos a 5?

Muchas veces se piensa que poder ir en búsqueda del cumplimiento de este requerimiento de calidad es algo tedioso o complejo, y que requiere muchos métodos de difícil aplicación. Para responder esto, existe un estudio realizado por Jakob Nielsen, uno de los gurús sobre la usabilidad que nos sugiere que la misma puede ser evaluada, con un importante grado de calidad, si consideramos…5 usuarios…si, solo 5 usuarios nada más.

Para ello, deberemos partir de una FORMULA, confeccionada a partir de la experiencia en gran cantidad de proyectos, que nos indica la cantidad de problemas de usabilidad que pueden ser encontrados considerando diferente cantidad de usuarios.

N = (1-(1-L)n)

En esta fórmula, N es el número de problemas de usabilidad detectados en el diseño, L es la proporción de problemas detectados con un solo usuario. El valor promedio de L es 31%. Para ir modificando la cantidad de usuarios utilizamos n.

n

L

N

0

0,31

0,00%

3

0,31

67,15%

5

0,31

84,36%

6

0,31

89,21%

9

0,31

96,45%

12

0,31

98,84%

15

0,31

99,62%

La siguiente tabla, rápidamente nos indica que para 5 usuarios, el porcentaje de errores que podremos detectar es de casi el 85%.

Así, podemos obtener las primeras conclusiones:

  • Con 0 usuarios, obtenemos 0 conocimiento. No conocemos ningún problema de usabilidad puesto que ningún usuario lo testea.
  • Con 1 usuario la cantidad de problemas alcanza casi un tercio de lo que podemos descubrir (30% aprox.)
  • Con 2 usuarios, muchos de los problemas descubiertos por ambos usuarios se comienzan a solapar, pero igualmente, el segundo usuario agrega un poco más información de utilidad.
  • Si continuamos agregando usuarios, lo nuevo que vamos a ir aprendiendo será cada vez menor, al punto que comienza a ser prácticamente insignificante.
  • Con el usuario 5 estaremos descubriendo un 85% de los errores de usabilidad.
  • Entonces, una primera conclusión es que la formula indica que más allá del usuario 5 estaremos gastando recursos en obtener problemas que, o ya fueron descubiertos, o son insignificantes.

Haciendo números

En cuanto a la cantidad de tests a realizar, se recomiendan muchos tests pequeños antes que un solo test grande.

Estos 5 usuarios encontraran el 85 % de los problemas en un primer test. Luego de modificar el diseño para solucionar lo reportado por dicho test, se realizara otro test.

Este segundo test estará verificando si los primeros problemas reportados han sido resueltos y si no se han introducido nuevos problemas.

Este segundo test encontrará la mayoría del 15% restante que quedo pendiente luego del primer test y será demás como un asegurador de la calidad del primero de los test. Además, este segundo test será capaz de poner sobre la mesa que tanto cubre la usabilidad el core del sistema (arquitectura de la información,  flujo de tareas, satisfacción del usuario, etc.).

No obstante el segundo test, necesitaremos un tercer test con un último lote de problemas  de usabilidad a resolver.

Usuarios de diferentes tipos o grupos
Los sistemas pueden tener diferentes tipos de usuarios (ya sea por los rangos de edad de quienes lo usarán o por los roles que contempla) con lo cual, lo analizado anteriormente deberá ser adaptado para contemplar esta situación.

Un primer y directo análisis seria resumir que si tengo dos tipos de usuarios diferentes, debemos considerar 5 usuarios de cada grupo y realizar 3  tests de usabilidad con cada uno de ellos.

No obstante, podemos mejorar esto si nos percatamos que cuando tenemos muchos grupos con diferentes usuarios, no necesitamos incluir tantos miembros de cada grupo como podría ser cuando tenemos un único grupo de usuarios.

Existe una superposición de las observaciones que los usuarios de ambos grupos aportan. Esto se debe hay que existen grandes similitudes entre las observaciones de los diferentes grupos, puesto que en el fondo, todos tienen algo en común: son personas. Así que, cuando tenemos diferentes tipos de usuarios, lo que se recomienda es:

  • Considerar 3-4 usuarios de cada categoría si estamos testeando con dos diferentes grupos de usuarios.
  • Considerar 3 usuarios de cada categoría si estamos testeando con más de 2 categorías o grupos de usuarios.

Conclusión

Podemos de manera sencilla y a bajo costo, apostar a identificar un lote de oportunidades de mejoras en materia usabilidad de nuestros sistemas informáticos.

Considerando solo unos pocos usuarios preparados podremos identificar muchos problemas de diseño y trabajar luego en su posterior resolución, beneficiando así, la experiencia de todos los usuarios con el sistema.

Siempre habrá entre nosotros cortadores de leña y sacadores de agua.
Nuestra maquinaria moderna no ha aliviado mucho el trabajo del hombre después de todo,
al menos, procuremos que el cántaro junto al pozo sea bello, y seguramente la labor de la jornada será más fácil.

– Oscar Wilde –

En la medida que podamos, procuremos que el cántaro junto al pozo sea bello haciendo que el software sea usable!.

Nos vemos, Gastón!.

Más información:

Cutteando el Scope

3 Feb

De la misma saga que Creepeando el Scope aquí les traigo unas ideas respecto a como, en determinadas ocasiones, podremos acortar el alcance de un proyecto que estamos gestionando.

El alcance de un proyecto se refiere al conjunto de requerimientos (funcionalidades, documentos, capacitación, etc.) que se han acordado, tanto con el cliente, usuarios y demás interesados, para que se encuentren todos entregados al finalizar el proyecto.

Ahora bien, el camino desde que no tenemos ningún requerimiento concluido hasta tenerlos a todos suele ser un camino con obstáculos. Por diversos motivos, muchas veces, en las fechas en las cuales se ha planificado entregar parte de los requerimientos, nos encontramos con que NO tenemos lo que debíamos tener y ya nos vemos dando las explicaciones del caso.

Para gestionar estos escenarios donde debemos dosificar la entrega del alcance del proyecto y disminuir el riesgo de no cumplir con los plazos, les propongo una serie de pasos que pueden ayudar.

Lo primero que se debe enfocar, ante cada entrega, cual es el nivel de expectativa a cumplir en el usuario/cliente y los demás interesados. La siguiente figura refleja este punto:

Las primeras entregas suelen ser las que concentran la mayor ansiedad puesto que se desea comenzar a observar el verdadero avance de un proyecto, y esto tiene relación directa con acceder a funcionalidades implementadas, no prestandole demasiada atención a cuestiones “extras” para ese momento, como son las validaciones de datos o las mejoras vinculadas a la eficiencia del producto. Asi, como primera consideración podemos decir que los requerimientos acordados para una entrega pueden recortarse según el nivel de detalle que la expectativa de la entrega genere. Por ejemplo, en las primeras entregas, de los requerimientos mas importantes a entregar, se tendrá mayor expectativa que los mismos funcionen a que los mensajes de error se presenten en rojo.  Es decir, en las primeras entregas se esperará que todas las funcionalidades acordadas para dicha fecha se encuentren en el entregable y no tanto que para todas esas funcionalidades, sus respectivos manejos de errores sea el final.

Esta estrategia de recortar según el nivel de expectativa la podemos combinar con otras tres estrategias extras:

Reduciendo el Alcance de un Proyecto

La forma más común para que los equipos entreguen productos más rápido es reduciendo el alcance de cada producto. Sin embargo, esto no puede hacerse de manera arbitraria. Hay motivos de negocio reales (en teoría al menos!) para cada una de los requerimientos que se piden.

Para lograr que un equipo entregue 50% más rápido se puede:

  • Entregar 50% menos de requerimientos.
  • Entregar todos los requerimientos pero con un 50% menos de detalles en cada requerimiento.
  • Entregar todos los requerimientos con distinto nivel de detalle en cada requerimiento.

Entregar 50% menos de requerimientos

  • Usando un backlog priorizado de trabajo: el Dueño del Producto puede hacer que el equipo trabaje en orden de prioridad hasta que se haya entregado el suficiente valor para hacer una entrega razonable. El peligro acá es no ser lo suficientemente agresivo sobre cuánto es suficiente..
  • Este método es simple y efectivo, excepto cuando los equipos de ventas y marketing “prometieron” características que están con baja prioridad en la lista. Si un equipo entrega 25 de las 26 características prometidas, el cliente podría enojarse. Si entrega estas mismas 25 características cuando se habían prometido sólo 20 van a ser felicitados como héroes. ¡Hay que ser muy cuidadoso con los compromisos externos para poder cumplirlos!

Entregar 50% menos de detalles en cada requerimiento

  • Se entregan todos los requerimientos. Este método se basa en el hecho de que el 64% de las características se usan poco o nada (según el estudio de Standish Group). Para poder entregar un 50% más rápido, se debería eliminar en promedio el 50% de cada requerimiento, e igualmente no dañaríamos el “núcleo” del software, el cual será usado la mayor parte del tiempo.
  • La desventaja es que se trata por igual a cada requerimiento, y es probable que recortemos demasiado en algunos requerimientos, y no lo suficiente en otros. Lo que nos lleva al método final…

Entregar todas los requerimientos con distinto nivel de detalle en cada requerimiento

  • Desarrollar por completo los requerimientos de mayor prioridad, mientras que los menos importantes se construyen sólo lo suficiente como para poder decir que funcionan bien.
  • Esto salva el problema del primer método ya que se entregan todos los requerimientos, y también supera los problemas del segundo método porque se entrega el máximo valor para los elementos de mayor prioridad.
  • Propuesta: ABMC y Reportes, de baja prioridad y a recortar funcionalidades.

En resumen, y tomando un ejemplo entonces…la semana que viene digamos que tenemos una entrega!!!, con ésta estamos justo en la mitad del proyecto:

  • Según la expectativa del usuario podemos determinar que de los requerimientos a entregar, no solo el usuario deseará evaluar funcionalidades sino también validaciones de datos y escenarios alternativos.
  • Según el análisis de los 3 metodos presentados, optamos por el 3 de manera que priorizaremos los requerimientos a entregar y en los que se encuentren en el tope de la lista, el tridente funcionalidades-validaciones-escenarios sera implementado en su totalidad; para los que se encuentren al final de la lista dicho tridente será mas relajado.

Espero haber sumado. Nos vemos, Gastón.

Muchos bichos, pocas balas

19 Ene

Lanzar una aplicación software a entorno de producción sin ser probada es como poner a vender una torta sin ni siquiera haberla probado al menos una vez.

Ahora bien, a diferencia de este ejemplo culinario, probar una torta es mucho mas sencillo (y rico!) que probar una aplicación. Tenemos probablemente cientos de escenarios posibles para validar. Por ello, el primer gran consejo es priorizar los casos de prueba a ejecutar. Ésto basicamente deberiamos realizarlo por dos motivos:

  1. No sobre eltiempo para poder testear todo.
  2. No conviene testear todo, ya que aqui tambien podemos aplicar la ley de Pareto: el 20% de los casos de prueba representa el 80% de los bugs de importancia que deberemos detectar.

Viendo estos dos puntos, entramos en una disyuntiva importante: ¿cuales son los casos de prueba que caen dentro del 20%? o lo que es lo mismo ¿que nos conviene testear?

Para responder esta pregunta se han definido varios tipos de heuristicas, las cuales buscan resumir en un grupo de palabras aquellas caracteristicas que deberemos fijar para priorizar la funcionalidad a testear.

Así, proponemos un ejercicio que parte de lo siguiente: en cada una de las siguientes categorias, asignar a cada funcionalidad del sistema, una puntuación según el grado de importancia de la misma respecto a la categoria. Las puntuaciones son:

  1. Poco importante que funcione perfectamente.
  2. Importante que funcione perfectamente.
  3. Muy importante que funcione perfectamente.

Como categorias a considerar, proponemos:

Negocio
Que tan importante es para el negocio.

Críticas tecnicamente
Segun que tan criticas son las funciones desde el punto de vista de los aspectos tecnicos que involucra.

Frecuencia de Uso
Que tan importante es, segun la frecuencia de uso.

Intensiva en recursos
Segun que tan demandante de recursos sea la funcionalidad.

Obligatorias
Segun que tan obligatorias son las funcionalidades pedidas por los interesados.

Aspectos legales
Segun si haya requerimiento legales que deba respetar.

La siguiente tabla refleja este análisis para unas funcionalidades tipicas. Se colocan las mismas y por cada una se define la importancia según las categorias anteriores. Obtenido el total de puntos por funcionalidad, nos resta ordenarlas por importancia y concentrarnos en testear aquellas que agrupen el 70-80% de importancia.


Como dato no menor, podemos obviamente agregar mas categorias para hacer este análisis mas exhaustivo.

Por ahora nada mas amigos, me voy con una sonrisa.

Nos vemos, Gastón

Post basado en: http://searchsoftwarequality.techtarget.com/answer/Prioritizing-software-testing-on-little-time

Creepeando el Scope

19 Nov

Un proyecto es un viaje que nos invita a recorrer diferentes etapas durante la producción de un producto o servicio y la correspondiente gestión de la producción. Durante estos caminos, deberemos cuidarnos de amenazas que pueden surgir. Para esto, deberemos primero aprender a reconocerlas y luego a disponer de un grupo de herramientas que nos permitan reaccionar y gestionar dichos riesgos.

Los proyectos, idealmente, comienzan por deseos de un grupo de entusiastas sponsores y usuarios en realizar o impulsar un grupo de actividades que conduzcan a lograr unos objetivos que permitan satisfacer alguna necesidad.

La base sobre la cual se sustenta un proyecto es el denominado Alcance del Proyecto (Project Scope). Esto es, ¿que vamos a hacer? ¿cuales son los objetivos que esperamos lograr con este proyecto?. Esta lista de objetivos deberia ajustarse para responder una nueva pregunta: ¿esto que QUEREMOS hacer, PODREMOS hacerlo teniendo en cuentas las restricciones de COSTOS, TIEMPOS, RECURSOS que tenemos impuestas?. Los requerimientos para los cuales me contesté que NO, entonces deberiamos sacarlos del alcance planificado.

Restricciones, bien bien, alli comienza el dilema. Al comenzar a definir el alcance, solemos definir una lista de los requerimientos (funcionales, no funcionales, etc) que el proyecto debe satisfacer. Este listado se confecciona y acuerda por un grupo de interesados entre los cuales estan los usuarios, sponsores y por otro lado el Director de Proyecto y el equipo técnico. Cuando este grupo de interesados define el alcance de forma sesgada, éste sufre consecuencias que afectarán el exito del proyecto. Estas consecuencias podemos resumirlas en las siguientes:

  • Requerimientos “Flacos”: las especificaciones no quedan claras en cuanto a que debe hacer el proyecto. Los tiempos avanzan, el equipo avanza cumpliendo lo que tiene claro pero dejando sin hacer los huecos funcionales que no fueron definidos. Aqui se avanza pero sin tener una clara perspectiva de que se esperar lograr.
  • Requerimientos “Gordos”: las especificaciones son excesivamente detalladas o contemplan aspectos extras que exceden la descripcion respecto a una verdadera necesidad del proyecto.
  • Requerimientos Dinamicos: Las especificaciones cambian constantemente sin que se pueda estabilizar la lista de requerimientos inicial y el detalle de cada uno de estos.
  • Requerimientos Innecesarios: Se incorporan requerimientos en pos de dotar al sistema de funcionalidades innecesarias para el proyecto. Aqui se busca embellecer los requerimientos con features que el cliente no desea.

Estos cuatro puntos representan posibles riesgos que afectan a la etapa de definición de requisitos y planificacion del alcance.

El punto 3 de las anomalias referidas a los requerimientos, se denomina Scope Creep. Este termino se refiere a los cambios descontrolados en el alcance de un proyecto que ya ha comenzado. El SC conduce no solo al retraso del proyecto sino tambien nos hace incurrir en mayores costos, a degradar la calidad en pos de poder cumplir con todo, y al desgano del equipo cuando las cosas no salen como fueron planeadas. El SC muchas veces es producto de una excesivo entusiasmo (o viveza) de los usuarios y sponsores que piden mas de lo que se acordó esperando que los proveedores puedan hacer mas de lo que dijeron que podrian.

El poder controlar el SC a veces viene con la experiencia que pueda tener un PM, pero no obstante, pudiendo detectar esta situacion, cualquier PM podria, al menos identificar que está ante ese problema y disponer de algunos tips para ponerse en guardia frente a la amenaza. Algunos de estos tips son:

De listado de requerimientos

1) Definir una linea base de requerimientos. Realizar un analisis completo de los requerimientos. Esto es importante ya que contra este analisis se evaluará si estamos corrompiendo el alcance o no. Aqui es importante definir una lista bastante estable de funcionalidades y cada una de ellas con el peso exacto (ni flacas ni gordas). Este documento sirve al PM para saber la cantidad de requerimientos acordados, la frecuencia con la cual aparecen los nuevos cambios y poder evaluar el impacto si se considera aceptarlos.

Del control de los requerimientos

2) Determinar un control de cambios solido. Definir un mecanismo para controlar (ojo, controlar no es negar por negar) los cambios que se desean realizar sobre la lista del punto anterior. Ese mecanismo permitirá tener una única puerta de entrada para los cambios. Dependiendo de los proyectos esta puerta puede ser giratoria o blindada (;-).

3) Asociar costos con cada cambio propuesto. Muchas veces los clientes piden cosas porque creen que no representan costo alguno. Si podemos darles a conocer, por cada cambio solicitado, cual es el costo del mismo (en materia de retraso del proyecto, inversion de dinero, etc), los clientes pensarán dos o mas veces antes de solicitar cambiar algo. En resumen, si logramos demostrarles como el cambio solicitado altera las restricciones impuestas o aprobadas por ellos, podrán analizar mas claramente si dicho cambio se justifica o no.

4) Encolar (no negar) los requerimientos. Puede que el cliente quiera igualmente incurrir en costos por el cambio que desea. Aqui, es mas conveniente recibir el cambio, priorizarlo y encolarlo segun la prioridad en la lista de requerimientos a implementar, habiendo antes el cliente entendido que el proyecto trabaja en fases y que pronto vendrá la correspondiente fase donde se desarrolle ese requerimiento.

5) No sea un “Yes man”. La importancia de decirle que “si” a un cliente es critica cuando estamos vendiendo un proyecto. Una vez acordado el inicio y comenzada la fase de desarrollo si continuamos con esa filosofia de decirle que “si” a todo, aunque agreguemos features al producto, estamos afectando a otras variables que intervienen en la ejecucion del proyecto, como son los tiempos y los costos. Aqui entonces, o no modificamos nada (o lo minimo y necesario) o el cliente acepta las consecuencias y aprueba las consecuencias.

6) Saber cuando hacer sonar la alarma: Es importante tambien notificar a managers y gerentes con informacion clave (que hace el cambio, costos, beneficios e impacto en el schedule). El objetivo aqui es lograr el conocimiento de los sponsors del proyecto para trabajar en definir si se acepta el cambio o no.

Del acuerdo de los requerimientos

7) Obtener el acuerdo por parte de los clientes. De alguna forma es importante obtener el consenso de los clientes para poder luego considerar el diseño e implementación de un requerimiento. Pero tambien es cierto que dichos clientes son reacios a colocar alguna firma que cierre la especificacion en un instante determinado ya que tampoco ellos pueden estar seguros de lo que estan solicitando. Para ello entonces deberemos buscar posibilidades para lograr dicho acuerdo sin necesidad de que nuestro cliente sienta que lo estamos hostigando para que nos cierre algo.

De la Gestion de los requerimientos

8 ) Implementar una buena herramienta de gestion de requerimientos. Estas herramientas ademas de permitir la gestion de la linea base de un proyecto, permiten que otros interesados (desarrolladores, analistas) accedan a los requerimientos y puedan consultarlos y analizarlos.

9) Estar siempre atento a la posibilidad de Scope Creep. Mantenerse alerta ante cada posibilidad de un cambio o agregado de feature. Estos son los tipicos eventos que pueden conducir al scope creep. Aunque uno sea el mejor project manager, puede que no pueda evitar el scope creep, simplemente porque existen condiciones que no pueden manejarse con los tips anteriores (o con ningun tip!). Ante esas situaciones tenemos o la posibilidad de irnos a otro proyecto o de continuar buscando minimizar los impactos negativos. El costado positivo de un proyecto con scope creep es que el PM aprende dia a dia como lidiar con los requerimientos fuera de control. Las lecciones aprendidas que pueda extraer de esos proyectos seran de muchisimo utilidad en futuros proyectos.

10) Considerar prácticas de Proyectos agiles. Los proyectos agiles permiten reducir el impacto del scope creep a partir del concepto de iteracion.

  • Proyectos tipicos: Especificacion funcional detallada al inicio, grandes documentos de requerimientos, cronograma y entregas cada 3 meses, 6 meses, etc.
  • Proyectos agiles : Especificacion funcional general  al inicio, especificacion detallada por iteracion, documentos mas pequeños, entregas cada 2 semanas.

Los proyectos agiles disminuyen la ansiedad del usuario ya que en cada iteracion se van entregando pequeñas porciones operativas del producto, las especificaciones son mas pequeñas y por lo tanto mas facil el acuerdo de que debe hacerse y en las ventanas de tiempo (las iteraciones) es factible freezar los requerimientos para que el cliente no los modifique.

En conclusion, los proyectos se planifican para cumplir con un alcance determinado. Si este alcance no esta estable y debe crecer o modificarse de forma frecuente, el no considerar el impacto en las restricciones iniciales conducirá al proyecto a resultados no deseados por los diferentes interesados.

Saludos,  Gastón

Basado en: http://www.gatherspace.com/static/scope_creep.html