Archivo | Proyectos RSS feed for this section

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

Construyendo proyectos en el aire

1 Mar

Dicen que la agilidad es una de las nuevas características que se requieren en los equipos para afrontar los cambios que imponen los proyectos cada vez más dinámicos. Agilidad para adaptarse a los cambios de requerimientos, de tecnologías, de equipo, de contextos. En definitiva, agilidad para adaptarnos a aquellas idas y vueltas que el entorno exige y al cual deberemos seguir.

Si bien esto es real y válido dentro de la gestión de proyectos, existe otro tipo de agilidad que muchas organizaciones, empresas o equipos deben ejercitar como mecanismo para adaptarse a los cambios que ellas mismas imponen o generan (y posteriormente padecen!). Cambios que, más que provenir de una estrategia pensada y planificada tienen más relación con el propio desorden, el desconocimiento y no respeto por las técnicas y procesos, la incorrecta priorización de las tareas, los equipos ficticios, etc.

Para poder identificar aquellos escenarios que fomentan el ejercicio de este tipo de agilidad interna, les comento algunas situaciones que más de uno reconocerá como presentes en algún que otro proyecto (de software en este caso) en el cual haya participado:

Un día Otro día
Un gerente de proyectos dice:  Bien, vamos a implementar Scrum, protejamos los alcances de cada sprint, es una buena forma de ordenar las cosas… El mismo gerente de proyectos dice: Eso de Scrum, está bueno, pero ahora quiero que interrumpan todo lo que están haciendo y hagan esto. Mañana retomamos con el sprint activo.
Un gerente de proyectos dice: Necesitamos si o si estimar los nuevos requerimientos, consideremos todas las alternativas para disminuir los releases incompletos o con fallos, tomemos un tiempo para las pruebas, ordenemos las cosas… El mismo gerente de proyectos dice: ¿esos son tus esfuerzos? seguro que estimaron de más, acortemos el 10% por sobreestimacion y las pruebas no las hagamos tampoco, recortemos al 70% los tiempos…  ahora sí que llegamos!!!
Un programador dice: Las metodologías ágiles son el futuro, vamos a adaptarnos a los cambios, éstos suceden siempre y el cliente puede plantearlos… 

 

El mismo programador piensa: Otra vez cambiar eso!!!!??? Maldito usuario!!!  Tiene que firmar lo que pide, tiene que firmar lo que pide!
Un programador dice: Somos profesionales, usemos tecnología de punta, somos un equipo de una alta seniority El mismo programador dice: Bien, veo de hacerte esto que me pedís, pero necesito ponerme a estudiar un poco porque no es tan simple, hay que ver si se puede, no te puedo estimar un tiempo para esto, vamos viendo…
Un gerente general a un cliente le dice: Hacemos proyectos de calidad,  nuestros productos cumplen todos los requerimientos y los construimos con un alto nivel de estabilidad… El mismo gerente general a su equipo le dice: no probemos nada, el cliente no lo va a probar tampoco, eso sí muchachos, espero que el producto sea estable…
Una empresa vende que lo más importante en un proyecto es el equipo… La misma empresa vende como si sus empleados son todos Senior, trabajan como super Senior y les paga como si fueran Junior. 

 

Un integrante de un equipo dice: A ver, tenemos que trabajar como un equipo, sino este proyecto se nos cae, vamos!! El mismo integrante del equipo piensa: Éste me pide que le explique cada cosa, si no tiene ni idea de que hace acá….por favor…
Un líder dice: Nuestro equipo es sólido, están comprometidos, trabajan unidos… El mismo líder piensa: cuál era el nombre de este pibe? Y estos dos son perro y gato…
Un gerente de sistemas dice: nuestros productos son 100% estable, tenemos equipo para asegurar la calidad y confiabilidad de los entregables… EL mismo gerente dice ante el líder del equipo desarrollador: sé que ustedes desarrollan pero hicieron pruebas de stress no?

Conclusión

Dime como es tu práctica y te diré que tanto entendiste la teoría

Todas las frases anteriores son quizás exageradas, pero muy probables de presentarse en la realidad. Denotan el mismo síntoma: la no aplicación adecuada de prácticas probadas en la gestión de proyectos (sean de la industria que sean).

Del dicho al hecho hay un largo trecho dicen y es tal cual. La realización de proyectos exitosos es muy fácil en los papeles, pero en la práctica las cosas se relajan, se olvidan, se omiten, se anulan y hasta se reprimen.

Cada una de estas situaciones tiene que modificarse, es el agua que socava los cimientos, son los gusanos que se colaron en el cajón de manzanas y echan a perder, desde proyectos y hasta empresas completas.

Vean el siguiente video:

Así como dicha publicidad puede denotar algo positivo como ser una capacidad de adaptarse a los negocios, esta misma publicidad la puedo aplicar para analizar la agilidad interna: Así como hay empresas que construyen aviones en el aire, muchas veces construimos proyectos también en el aire…es decir, como vayan saliendo!!!: necesitamos acortar tiempos? resignemos calidad, necesitamos equipos competitivos ? reclutamos sin siquiera pensar en los roles de cada persona, y así muchos ejemplos mas.

Esta manera de gestionar un equipo, un proyecto, una empresa no es propia de algún tipo de mercado. A ella la conocen empresas privadas y organismos públicos, sean grandes o pequeños  Esta forma de gestionar tiene un muy alto riesgo para con el éxito de un proyecto: es jugar a la ruleta rusa, puesto que los riesgos que hay que enfrentar no solo vienen de afuera (que sería hasta lo más normal) sino que se gestan en el mismo seno interno y nunca sabemos cuando puede ser el momento en que se nos escape el tiro.

A modo de conclusión de este tema, los invito a que todos, desde el lugar que nos corresponda, hagamos mea culpa de nuestros aportes en situaciones como las descriptas y también a mejorar todo aquellos que vean que requiere mejora. Como dice un texto que alguna vez leí: Sé el cambio que tú quieres ver en el mundo. En este caso, yo lo adaptaría a: Haz el cambio que tu quieres ver en los proyectos. Basta de proyectos en el aire.

Espero haber sumado.

Saludos, Gastó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.

El nacimiento de un proyecto

4 Ene

Buenas, feliz 2011 para todos!!. Para arrancar este nuevo año con la mejor de las ondas, les traigo una cuota de humor que espero que les arranque alguna que otra risa o al menos una reflexión jeje. Alguna vez se preguntaron como nace un proyecto en una empresa? bueno, aqui les va una posible respuesta:

Programador al responsable técnico:

“Es imposible que nosotros podamos hacer este proyecto. Supone cambios de diseño y nadie en nuestro equipo sabe como está hecho el sistema, además nadie en nuestra compañía conoce el lenguaje con el que se ha escrito el programa. Así que, si asignamos a alguien a trabajar en él, no podrá hacer nada. Si me preguntas mi opinión personal te diré que nuestra compañía nunca debería de realizar este tipo de proyectos “.

Responsable técnico a Project Manager:

“Este proyecto implica un cambio de diseño. En la actualidad no contamos con gente con experiencia en este tipo de trabajo. También el lenguaje es desconocido para nosotros, así que tendremos que organizar algún tipo de formación y un periodo de adecuación si se aborda el proyecto. En mi opinión, debemos evitar aceptar este proyecto. “

Project Manager a Director de Informática:

“Este proyecto implica un cambio de diseño en el sistema y no tenemos mucha experiencia en esa área. Tampoco tenemos mucho personal capacitado en este lenguaje. Creo que podemos aceptar este proyecto pero deberíamos pedir un poco de más tiempo. “

Director de informática a Directivo senior:

“Este proyecto consiste en una reingeniería de la aplicación. Tenemos algunas personas que han trabajado en esta área y algunos que conocen el lenguaje y que pueden entrenar a otras personas. En mi opinión, podemos aceptar este proyecto pero con precaución. “

Directivo senior a Director General:

“Este proyecto va a demostrar a la industria nuestras capacidades en el rediseño de un sistema complejo. Tenemos todos los conocimientos necesarios y las personas necesarias para ejecutar este proyecto con éxito. Algunos de nuestros técnicos ya han empezado a dar formación en este ámbito a otras personas. Creo que no debemos dejar escapar este proyecto bajo ninguna circunstancia. “

Director General al Cliente:

“Este es el tipo de proyectos en los que nuestra compañía se especializa. Hemos realizado muchos proyectos de la misma naturaleza en grandes clientes. Confía en mí cuando digo que no podrías estar en mejores manos. Te doy mi palabra que podemos realizar este proyecto con éxito y en el marco de tiempo dado.

Nos vemos, Gastón!.

Palabras responsables

3 Dic

La comunicación es una de las disciplinas mas importantes a gestionar durante un proyecto (el PMBok posee todo un capítulo para este tema) . En un nuevo emprendimiento existen usuarios, equipos, líderes de equipo, directores de proyectos, sponsores y otros interesados que tienen cada uno sus expectativas y objetivos que esperan que sean cumplidos.

Es ahi entonces, cuando todos los actores anteriores, cada uno en el rol que le corresponde, comienzan a interactuar para empezar a hacer rodar la pelota y lograr alcanzar el éxito cuando suene el silbato final.

Pero no es fácil, el proceso de la comunicación es complejo pues uno como persona (antes que como sponsor, lider o parte de un equipo) ya tiene una tendencia a comunicar las cosas en forma ineficiente. Causas de esto son muchas: intereses, influencias, sentimientos, conflictos, prejuicios, etc.

Puntualmente, dentro de un equipo de trabajo, una vez definidos los canales de comunicacion entre todos los miembros, lo que debe fluir por ellos es información que sea válida, clara y útil para el desarrollo y conclusión de las diferentes actividades. Debemos elaborar y adueñarnos de la necesidad de comunicar con responsabilidad.

Les dejo una anécdota de Socrates que grafica este punto de la responsabilidad e invita a aplicarla en nuestros proyectos profesionales, y nuestro proyecto mayor: nuestra vida.

En la antigua Grecia, Sócrates fue famoso por su sabiduría y por el gran respeto que profesaba a todos. Un día un conocido se encontró con el gran filosofo y le dijo:
¿Sabes lo que escuche acerca de tu amigo?.
Espera un minuto -replico Sócrates-. Antes de decirme nada quisiera que pasaras un pequeño examen. Yo lo llamo el examen del triple filtro.
¿Triple filtro?
Correcto -continuó Sócrates-. Antes de que me hables sobre mi amigo, puede ser una buena idea filtrar tres veces lo que vas a decir. Es por eso que lo llamo el examen del triple filtro. El primer filtro es la verdad.
¿Estás absolutamente seguro de que lo que vas a decirme es cierto?
No -dijo el hombre-, realmente solo escuché sobre eso y….
Bien -dijo Sócrates-. Entonces realmente no sabes si es cierto o no.
Ahora permíteme aplicar el segundo filtro, el filtro de la bondad. ¿Es algo bueno lo que vas a decirme de mi amigo?
No, por el contrario…
Entonces, deseas decirme algo malo sobre él, pero no estás seguro de que sea cierto. Pero podría querer escucharlo porque queda un filtro: el filtro de la utilidad. ¿Me servirá de algo saber lo que vas a decirme de mi amigo?
No, la verdad que no.
Bien -concluyó Sócrates-, si lo que deseas decirme no es cierto, ni bueno, e incluso no me es útil, ¿para qué querría yo saberlo? !!!

Saludos, Gastón

Excusas…no!

24 Nov

El equipo es uno de los pilares fundamentales sobre los cuales se sustenta el éxito o fracaso de un proyecto. El óptimo encaje de cada pieza es un objetivo que todo PM busca conseguir pero que no siempre puede lograr. Motivos, sobran, lo cierto es que antes de poder optimizar algo deberemos lograr que funcione y para que funcione deberemos entender la dinámica por la cual atraviesa un equipo. El PMBok nos aporta luz respeto a este punto. En el capítulo 9 nos dice:

Segun una teoria, existen cincos etapas de desarrollo que los equipos pueden atravesar. Normalmente, estas etapas se presentan en orden. Sin embargo es frecuente que un equipo quede atascado en una etapa particular o retroceda a una etapa anterior. Ademas, en caso de proyectos cuyos miembros del equipo han trabajado juntos en el pasado, es posible que se salte una de las etapas.

  • Formación: El equipo se reúne y se informa acerca del proyecto y de cuáles son sus roles y responsabilidades formales. Los miembros actuan de manera independiente y no suficientemente abierta.
  • Turbulencia: El equipo comienza a abordar el trabajo del proyecto, las decisiones técnicas y el enfoque de dirección de Proyectos. Si no hay colaboración, el ambiente puede tornarse destructivo.
  • Normalización: Los miembros del equipo comienzan a trabajar en conjunto y adaptan sus comportamientos y hábitos de trabajo para apoyar al equipo. Los miembros comienzan a confiar uno en otros.
  • Desempeño: El equipo funciona como una unidad bien organizada. Enfrentan los problemas con eficacia y sin complicaciones.
  • Disolución: El equipo completa el trabajo y finaliza el proyecto.

Una vez formado el equipo, nuestro norte sera poder alcanzar rápidamente el estado de desempeño, donde todo fluirá de la forma mas óptima posible hasta que alcancemos el punto final exitoso donde debamos disolver el equipo.

Ahora bien, este nivel de desempeño es sinónimo de eficiencia y esta eficiencia se consigue con esfuerzo, esfuerzo para entregar día a día lo mejor de cada uno. Sabiendo que hay que dar una dura batalla, ¡quien nos impulsa a caminar ese largo camino? ¿quien nos mueve a empujar y empujar? ¿quien es el combustible de nuestra búsqueda constante de hacer las cosas mejor?. Mi respuesta esta en la motivacion. La motivacion son los estímulos que mueven a la persona a realizar determinadas acciones y persistir en ellas para su culminación (Wikipedia). Es el combustible que nos mueve a seguir estirando el brazo para poder alcanzar el escurridizo objetivo.

Este combustible, necesario para que una persona o un equipo alcance su nivel máximo de desempeño, puede nacer en diferentes necesidades: dinero, calidad de vida, bienes materiales, logro profesional, honor, ego, etc.

Pero, como todo combustible, muchas veces se nos acaba cuando vemos que las cosas son mas complicadas que lo que parecian, mas dificiles de lo que las habiamos planificado, mas lejano todo de lo que pensabamos tenerlo…y ahi me vienen a la mente dos pensamientos recurrentes que suelen darse y que muy bien el video que les dejo grafica: o quienes logran el éxito es porque siempre tuvieron todo fácil o uno está poniendo excusas para no levantarse y continuar. ¿Con cual se quedán ustedes?.

Saludos, Gastón.

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