Inicio Make Text BiggerMake Text SmallerReset Text Size

Navegápolis publica actualmente en navegápolis.com.

Ir a navegapolis.com

Nuestros clientes no quieren programas
Valoración del artículo: / 25
MaloBueno 
02.03.2006
agujerosDicen que durante una reunión del consejo de administración de Black & Decker, su presidente interrumpió la exposición del departamento de marketing, diciendo con gravedad:
“Señores, han confundido el objetivo: Nuestros clientes no quieren taladros….
Nuestros clientes quieren agujeros”.

Muchas empresas de software creen que los clientes quieren programas. Hacer soft no es un fin en sí mismo, es un medio; y ganar dinero tampoco debería ser un fin, sino una consecuencia.
A mayor número de clientes satisfechos, y con mayor nivel de calidad en sus soluciones, mayor volumen de negocio y mayores expectativas de crecimiento.

El objetivo de la empresa no debería ser crear software, sino soluciones; y no debería hacer programas para ganar dinero, sino ganar dinero porque hace programas.

Las empresas que truecan las consecuencias por el fin, construyen culturas con mensajes erróneos.
Sus departamentos se alinean con un fin: ganar dinero, y cumplen los objetivos de facturación vendiendo “programas” (o lo que sea) sin pararse a analizar los problemas de los clientes.
Los gestores de los proyectos se centran en cumplir las fechas de entrega, asignando todos los programadores posibles a los proyectos retrasados.

Normalmente las fechas no encajan con las previsiones, y los programas no terminan de contentar a clientes que piden cambios por no tener lo que necesitan.
Al analizar la rentabilidad se ve que los retrasos aumentan los costes, y merman el beneficio esperado.
Los departamentos comerciales ponen a los programadores como culpables de estos retrasos, y ellos se defienden diciendo que negocio cierra agendas sin saber si se podrán cumplir.

Hace algunos meses fui testigo de cómo una empresa de software cerraba, tras muchos problemas, un proyecto con una desviación de agenda y presupuesto de un 400%.

Inicialmente se vendió como un sistema de gestión integral que debía estar funcionando en 6 meses. Era una operación con la que el departamento comercial conseguía dos objetivos: el de facturación trimestral, y la incorporación de un cliente importante a la cartera de la compañía.
Por eso, cuando el cliente dijo de cuándo dinero disponía, y la fecha en la que el sistema debía estar funcionando, la empresa de software le hizo un presupuesto con un cronograma que encajaba como un guante.
En 6 meses estaría todo terminado. En julio y agosto: obtención, análisis y especificación de requisitos, de septiembre a noviembre desarrollo, y en diciembre instalación y pruebas.
El 1 de enero funcionando. ¡Justo lo que el cliente quería!.

El departamento de ventas, con su mejor criterio consideró:
  • Se trata de una operación importante, y aunque es seguro que cuando los ingenieros vean las fechas se quejarán, bien merece la pena poner a los mejores programadores, y el número que sea necesario, para que esté en enero.
  • El presupuesto es posible que se quede algo estrecho, pero con esta operación, conseguiremos el contrato de las dos fases siguientes, y una buena cuenta.
En enero el programa no estuvo disponible, y lo que fue aún peor, el cliente, al iniciar su nuevo negocio descubrió que necesitaba funcionalidades que no se habían contemplado.
Las tareas de requisitos no se habían realizado para conocer las necesidades del negocio del cliente, sino para hacer el documento de requisitos, obligatorio según los procesos del departamento de  desarrollo.

Las deficiencias de los requisitos, y las modificaciones introducidas llevaron, en enero, a tirar todo el código y comenzar con un nuevo diseño de arquitectura y datos.
Tras un rosario de vicisitudes y trabajo en constante presión de fechas, el cliente, disgustado y cansado, validó finalmente el trabajo en abril ¡del año siguiente!.
Lo que inicialmente debía haber durado 6 meses se prolongó durante 22, y en la misma proporción, los costes del proyecto.

Tras los casi dos años de retrasos, el cliente quedó muy descontento con la empresa de software, cuya falta de profesionalidad le había obligado a demorar sus planes de negocio, y a introducir medidas de contingencia de última hora para realizar operaciones mensuales y otros procesos previstos en el sistema que constantemente retrasaba su fecha de implantación.

Las tensiones entre el departamento comercial, gestión de proyectos y programación tampoco resultaron agradables.

El único beneficio que se puede extraer de estas experiencias es emplearlas para aprender. Aunque en la realidad, las tiranteces que generan y las tensiones personales hacen difíciles los análisis objetivos, y frecuentemente no se llega más allá de achacar a las circunstancias y a la culpa de otros la responsabilidad.

Analizando este caso, y tantos otros similares… ¿dónde diríamos que se encuentra la responsabilidad?.
  • ¿En el departamento comercial?
  • ¿En la falta de comunicación entre desarrolladores y vendedores durante la estimación de proyecto?.
  • ¿En el trabajo deficiente o lento de los ingenieros?.
  • ¿En la gestión del proyecto?...
Estas suelen ser las líneas de análisis tras los fracasos de los proyectos; pero lo cierto es que los aludidos consideran que cumplieron bien su trabajo y alcanzaron sus objetivos.

El departamento comercial cerró el presupuesto del año satisfactoriamente y aumentó la cartera de clientes, y los programadores trabajaron denodadamente, alargando sus jornadas diarias de trabajo a fines de semana y horas extras.
Por estas razones, el equipo, e incluso los gestores de la empresa, que saben del interés y dedicación de su personal, concluyen reafirmándose una vez más en el convencimiento de que son “gajes” de nuestra profesión. Las cosas en este negocio suelen ser así y poco se puede hacer.

Pero… ¿Quién pensó en el cliente?.
¿Quién tenía como objetivo su éxito. ¿Conocer y analizar las necesidades de su negocio, y trabajar con él en el diseño e implantación de las soluciones?

La conclusión no es compleja: todo el personal hizo lo que debía hacer, y si hubiera que buscar un responsable, habría que dirigir la mirada hacia las instancias altas de dirección.
Los objetivos de los departamentos no estaban alineados entre sí, ni respondían a una estrategia coherente. Ninguno de ellos tenía como fin solucionar los problemas del cliente.

Orientación al cliente no es amabilidad, cortesía, o incluso servilismo.
Por supuesto que debe dispensar amabilidad y cortesía a su cliente, pero lo que además se espera de una empresa profesional de software es que haga suyo el problema del cliente.
Más allá incluso de lograr clientes satisfechos, se trata de conseguir clientes con éxito.
Que nuestro trabajo sea una de las razones del éxito de su negocio.

Posts relacionados:

 

Safe Creative

Trackback(0)
Comentarios (5)Add Comment
Necesitamos la perspectiva de sistema
escrito por Invitado, March 02, 2006
Aunque es fácil decirlo, el asunto lo entiendo como un ejemplo de falta de perspectiva "sistémica". Yengo al ejemplo del principio, en Black&Deker creo que se equivocan si piensan que el cliente quiere agujeros. El cliente quiere, pongamos por caso, un cuadro colgado en la pared de su despacho. El sistema es complejo, porque tiene que ver con el taladro, con las habilidades de quien taladra, con el agujero, con la pared, con el cuadro. Esta es la visión compleja, pero que desata nuevas posibilidades de negocio.
En tu caso, la habilidad está en generar suficiente equilibrio (inestable) dentro del equipo de proyecto cliente-proveedor.
Insisto, sé que es fácil soltar este rollo y luego hay que lidiar con la realidad, pero me parece un buen ejemplo el que comentas de falta de perspectiva del sistema global. Lo malo, muchas veces, es que la perspectiva de sistema desata las contradicciones de los diferentes agentes que intervienen en la solución.
...
escrito por Invitado, March 02, 2006
Por cierto, que soy #2, podr߭as dejar que firmemos los comentarios?

oscarm
www.abitofanapple.com
...
escrito por Invitado, March 02, 2006
Me parece que has dado en el clavo...

Tienes razón en que el cliente no quiere taladros. Incluso, como dicen en #1, el cliente no quiere agujeros. El problema es conseguir que el dependiente del Leroy Merlin lo sepa.

Muchos de los problemas que aparecen en la producción de proyectos de software (o de consultoría más o menos tecnológica) aparecen por los problemas de comunicación entre los distintos departamentos de la consultora/desarrolladora. Como dices, cada departamento dice que ha realizado bien su trabajo. El problema es que la suma de cada uno no es igual al trabajo total de la consultora/desarrolladora, según lo percibe el cliente.

Por ahí es por donde hay mucho trabajo que hacer...

oscarm
a bit of a apple
Re: oscarm
escrito por Invitado, March 02, 2006
Hola Oscar!

Claro que se pueden firmar los comentarios. Es una forma estupenda de conocernos. De hecho confieso que no conocia tu pgina hasta ahora mismo, y me parece muy buena (por mritos propios ya estᩡ en el blogroll de Navegapolis).
Lo que pasa es que como uso Mambo (me dio por ah), pues el mdulo para incorporar comentarios es Ako, (no conozco otro), y hasta la fecha no tienen campos para poner el nombre del remitente. Se supone que lo pondr�a si Navegapolis funcionara con usuarios registrados...

Pero por favor, firmarlo en el texto.
(Me he permitido hacerlo en tu comentario).

Un saludo y gracias por el comentario.

Juan Palacio.
Algunas preguntas
escrito por Invitado, March 02, 2006
Juan, después de haber vivido situaciones parecidas, enseguida me reconozco y no puedo estar más de acuerdo en tu análisis.

Por otra parte hay algo que me llama poderosamente la atención y es esta frase: "Las deficiencias de los requisitos, y las modificaciones introducidas llevaron, en enero, a tirar todo el código y comenzar con un nuevo diseño de arquitectura y datos".

Una situación así no la he vivido directamente, aunque la he visto a distancia: un compañero que se quedaba con su gente siempre los últimos mientras el resto del departamento se iba a casa.

¿Qué métodos y qué tecnologías se usaron en el primer y segundo sistema? ¿Qué lenguajes? ¿Qué otras herramientas (bases de datos, diagramas, entornos)? ¿Cuánta gente? Y sobre todo ¿quién tomó las decisiones técnicas tanto de hacer el primer sistema de esa forma como de tirarlo después? ¿Se encargó del segundo sistema el mismo responsable técnico que del primero?

Si bien estas preguntas pueden parecer triviales ante la evidencia de que el marrón fue fabricado a conciencia desde el exterior, cabe preguntarse si había una forma de defensa desde dentro del equipo informático. No es un dedo acusador, simplemente ocurre que cuando "te las ves venir" a veces puedes hacer algo, aunque sea untar vaselina.

Escribir comentario

busy
 
< Anterior   Siguiente >
Advertisement





Registrado en Safe Creative