Un problema al que le faltan datos

Hace unos días leía en el blog de kybele consulting una entrada muy interesante sobre métodos de estimación software. En la entrada se hace referencia a unas transparencias en las que hay información con la que estoy de acuerdo, sin embargo, y probablemente sea un problema particular mío, todo eso me suena a pura teoría más propia de una asignura de aquella carrera que tanto me aburrió.

Estoy convencido de que mucha gente pensará que estoy equivocado, y es probable, sin embargo, creo que en cualquier método de estimación de proyectos software (incluidos productos) en el que no tengamos en cuenta a los recursos (al equipo), la incertidumbre será abundante. Muchas veces me veo obligado a planificar proyectos incluyendos costes y la sensación que tengo es de levantar el dedo y ver para qué lado sopla el viento. ¿Cuántas veces no se ha preparando una oferta para un concurso público haciendo ingeniería inversa? El dinero que hay es X, pues a partir de ahí defino mi oferta (planificación, recursos, tecnología, etc).

Una de las líneas de trabajo en los ecosistemas software es la base histórica de proyectos. Realizar una estimación teniendo en cuenta tus recursos (conocimientos, habilidades, especialización, etc) y una base histórica, sigue siendo predecir, pero lo cierto es que cada vez acertamos más. A continuación un breve listado de situaciones que hacen que la estimación se parezca a la realidad con la misma probabilidad que un niño de 3 años escriba en un post-it los números del euromillón:

  1. Optar por un marco tecnológico en el que no se tenga experiencia. Hace un “Hola mundo” no es tener experiencia.
  2. Que en el equipo definido no haya un líder tecnológico. Un líder tecnológico no es un jefe de proyecto.
  3. No disponer de un entorno de desarrollo flexible, cómodo y fácil de usar. Podemos llamarlo Ecosistema Software.
  4. Ausencia de metodología. Si es un proyecto pequeño y un equipo pequeño, el correo electrónico puede ser su ecosistema, pero en el resto de casos, mal vamos.
  5. Reacios a los cambios. Si no admites y pones trabas a que lo requisitos cambiarán, entonces tienes el riesgo de que el mal rollo aparezca.
  6. El proyecto tiene un tamaño que no puedes controlar. Muy simple, pasas de ejecutar proyectos de 3-5 personas durante 3-8 meses a 6-15 personas durante 12-18 meses. Los proyectos que se prolongan en el tiempo tienen ciertos aspectos que no aparecen en proyectos pequeños.
  7. Tu diseño está condicionado por el cliente y no te siente a gusto desde el comienzo. Mal empezamos porque tu crees que deberían de confiar en ti como proveedor de software y dejarte libertad.

Como en todas las listas que hago, siempre se podrían añadir más puntos. Lo dejo para quienes leen este espacio.

One thought on “Un problema al que le faltan datos

Leave a Reply

Your email address will not be published. Required fields are marked *