¿Te suena lo de {tenemos que entrar en este cliente como sea} ? - Parte I

viernes, agosto 19, 2011 , , , 2 Comments

[ver Parte 2]

No he ido danzando de empresa en empresa, pero mi colaboración con muchas empresas me ha permitido ver cómo funcionan generalmente las PYME que venden servicios relacionados con el software.

Si se reflexiona acerca de cómo se contrata y se gestiona un proyecto, hay que fijarse si hay dos “objetivos” presentes desde el momento de la contratación hasta el cierre:

  • Vender el proyecto a cualquier precio
  • Terminar el proyecto a cualquier precio

Si la empresa tiene estos “objetivos” entre los del proyecto no va por buen camino y su línea de desarrollo de software penderá de un hilo mientras no los destierre de la cabeza de quien vende y quien hace.


El problema

Vender a cualquier precio: En sí mismo no es malo si se asumen las consecuencias de la venta. Cuantas veces no habremos escuchado lo de “Tenemos que entrar en ese cliente a cualquier precio”, vender el proyecto a precio de coste, incluso recortar las horas estimadas de un proyecto y conseguir la venta, pero al comenzar la construcción del proyecto resulta que se presiona al equipo de desarrollo para obtener beneficios por encima de lo vendido, incluso de lo estimado.

Si los precios de venta acordados (PVP) bajan hasta el precio de coste estimado o menos, hay que asumir desde el principio que los beneficios a obtener serán los estimados en el momento de la venta.

No se debe recortar la estimación inicial de un proyecto a menos que se tengan bases bien fundadas. Cualquier recorte indiscriminado o forzado de tiempo o recursos lleva asociado una pérdida potencial de beneficios.

Terminar el proyecto a cualquier precio: El seguimiento correcto del proyecto determinará la variación de las entregas. Si el proyecto tiene entregas definidas desde un inicio, estas variaciones hacen más mella en el proyecto que en aquellos en los que se define la siguiente entrega después entregar la anterior. Forzar que las entregas coincidan con las fechas estimadas nunca repercute a favor del proyecto. Es por eso que son estimadas.

Las entregas forzadas siempre llevarán parches y bugs, por no contar con los errores que pueden acarrear consecuencias graves para el negocio del cliente.

Cada vez que se dice “tenemos --- como sea” se está incurriendo en el auto-engaño y se está forzando al equipo a entregar algo con lo que no se ha comprometido, por lo que puede que no se entregue en la fecha esperada a pesar de hacer horas extras y hay un riesgo muy alto de afectar la calidad del producto final.

Una vez instalado el producto todos los fallos generados podrán ser corregidos por el equipo de desarrollo, pero aun así el cliente sentirá que no se ha realizado un desarrollo serio, que le han tomado el pelo o que le han robado su dinero.

¿Qué ganas eliminando el problema?

Estas dos formas de pensar sobre un proyecto están tan arraigados en tantas Pymes que es fácil encontrar quien piense así en cualquiera de los roles de la empresa: desde la gerencia hasta quien programa.

Eliminar esta forma de trabajar del ciclo de vida de un proyecto trae mejoras para muchos procesos en toda la empresa:

Los proyectos comienzan con una idea clara de los beneficios que se van a obtener
El equipo se siente más comprometido con las entregas.
Todos conocen (cliente y proveedor) qué se va a entregar y en qué fechas.
Se entrega un producto con calidad.
El cliente está más satisfecho con el producto.

Cada uno de estos puntos tiene más ventajas asociadas que no he puesto para no aburrir, pero que hacen obvia la necesidad de llegar a esa forma de trabajo. Os aseguro que una vez experimentada no hay vuelta atrás.

En la siguiente parte del post comento algunas pistas para eliminar "el problema", porque seguro que tú has escuchado lo de "hay que terminarlo como sea"... esa gran metodología que deriva en las 3Cs.

CNatra

Some say he’s half man half fish, others say he’s more of a seventy/thirty split. Either way he’s a fishy bastard.

2 comentarios: