archivo

Archivos diarios: enero 22, 2009

Leo una entrada en el Blog GENBETA en la que comenta que el presidente de la enciclopedia Britannica ha arremetido contra Wikipedia en un ataque de celos.

Se queja por un lado de que Google devuelva bien posicionada a Wikipedia en las búsquedas prácticamente de cualquier término y por otro que cómo es posible que la gente acceda a Wikipedia cuando su producto es de mayor calidad.

Sr. presidente de la enciclopedia Britannica: si usted quiere ganarse nuestra atención, haga un producto que la merezca y verá como poco a poco va ganando cuota de mercado. ¿Que nó es fácil competir contra un producto que lleva más tiempo en la red y con una comunidad de usuarios bastante robusta? Nadie dice que lo sea, en Internet nadie regala nada y si quieres la atención de la comunidad te la tendrás que ganar no con palabras, sino con algo que mejore a Wikipedia.

Nadie está salvo en momentos puntuales del año de tener más trabajo que tiempo material para hacerlo.

Es comprensible que las empresas tengan overbooking de trabajo ya que no pueden tener al personal parado sin tareas asignadas y tampoco pueden dejar pasar trenes que después lo mismo no vuelven a pasar y crecer sin garantías de poder mantener el volumen de facturación.

Ante estas situaciones existen muchas formas de actuar. Yo recomiendo la siguiente (dependerá mucho de la personalidad y actitud del cliente, pero entiendo que con clientes normales debe funcionar) que no es más que aplicar el sentido común.

En aquellos proyectos menos críticos (hay proyectos que por el motivo que sea tienen una fecha más o menos clara de entrada en funcionamiento y otros donde esa fecha no es algo crítico) negociar con el cliente un aplazamiento del plazo de entrega, mejor un producto entregado con calidad un mes después que un producto cogido con alfileres hecho deprisa y corriendo para cumplir la planificación temporal.

A los clientes nos interesan que el producto que se entrega tenga calidad, si tiene calidad, cumple los requisitos funcionales y no funcionales y el usuario está contento, todo retraso es asumible.

Eso sí, a todos los clientes nos gusta ver que el proyecto va avanzando aunque sea durante un plazo determinado de tiempo más lento, es decir, ese aplazamiento no se debe vender (ni se debe ejecutar) como una segregación del equipo de proyecto entre los diferentes proyectos de la empresa, sino que durante un tiempo se van a mantener unos servicios mínimos que van a seguir adelante con el proyecto y que van a producir resultados “tangibles” por el cliente. Como cliente os digo que ver que el proyecto avanza aunque sea poquito a poco es un alivio y además os quitará presión.

Eso sí, tampoco conviene negociar retrasos en todos los proyectos que tengáis con un cliente concreto, lo más justo es diversificar y como he comentado antes saber sobre qué proyectos es factible solicitar ese aplazamiento.

Por supuesto que si el proyecto está mal estimado temporalmente no dudéis en informar lo antes posible al cliente, ya sea porque el error sea vuestro o del cliente. Cuanto antes se ponga sobre la mesa ese problema menos quebraderos de cabeza os causará, os lo garantizo.

Si el proyecto no avanza por causas provocadas por terceros relacionados con el cliente, tampoco dudéis en indicarlo al cliente, ya que por un lado puede intentar solucionar el problema y por otro lado tendrá constancia de que existen circunstancias que pueden provocar o van a provocar un retraso en el proyecto.

Es mucho mejor solicitar un aplazamiento de la entrega del proyecto (eso sí, con tiempo) o informar de que el proyecto no ha sido bien estimado temporalmente que llegar la fecha de entrega e incumplirla.

Los clientes no mordemos y por regla general somos gente sensata, gente que estamos en el negocio, en el otro lado, pero en el negocio, que sabemos la dificultad de sacar adelante un proyecto de desarrollo de software y que por tanto ante explicaciones y situaciones coherentes, nuestra respuesta será coherente.