Un Mc Software completo, por favor

Aunque el símil no es mío (ver Las Big Macs contra el chef desnudo), si que es cierto que podemos comparar, de alguna manera, el mundo de la cocina y el del software. ¿Qué preferís para comer, un Big Mac o alguna especialidad de la cocina tradicional? Aunque sobre gustos no hay nada escrito, parece que por calidad y por resultado siempre se escogería la obra de un cocinero a la de Ronald McDonald.

Recientemente me he encontrado con un cliente que, increíblemente, me dijo que preferiría que le hubiese cocinado una hamburguesa en lugar de haberle hecho el exquisito plato que le presenté a la entrega del proyecto (hablando metafóricamente, claro). Dejadme que os cuente la historia completa:

Resulta que una gran compañía que, evidentemente, no se dedica al software, decidió reducir su dependencia con respecto a sus proveedores de aplicaciones creando un sistema que resolviese sus necesidades y que quedara en su propiedad y les permitiera usarla en todas sus instalaciones sin tener que pagar a nadie más por el desarrollo. Planteándose cual sería la mejor manera de hacer software sin tener a nadie que supiese ni remotamente de qué se trataba, decidieron contratar a un jefe de proyecto que se introdujese en el equipo de desarrollo de una empresa de software y absorbiese todo el conocimiento mientras se desarrollaba la aplicación encargada.

En estas que nos encargaron a nosotros el proyecto con una fórmula inusual y algo surrealista: no era un proyecto cerrado, ya que el jefe de proyecto era suyo, pero tampoco era cesión de personal porque la responsabilidad del resultado era nuestra… Un concepto extraño y sin demasiada lógica, ya que si su jefe de proyecto influía en el desarrollo, como era su intención, el resultado variaría mucho y la responsabilidad del mismo sería menor para nuestra empresa; pero en fin, era un proyecto interesante y buscamos la manera de poder aplicar nuestros conocimientos de desarrollo y amoldarlos lo mejor posible a los caprichos del jefe impuesto sin reducir la calidad de los desarrollos.

Inicialmente intentamos seguir la filosofía de «inmersión parcial» intentando que el jefe externo revisara los documentos que generamos y aprobara los desarrollos proporcionándonos los requisitos y el conocimiento del negocio a la vez. Parecía una buena idea, pero por cambios estructurales en el cliente nuestro «jefe externo» no tenía tiempo ni siquiera para validar la documentación, se limitaba a pedir funcionalidades y a resolver nuestras dudas en cuanto a los requisitos… Esto nos permitió avanzar rápidamente y obtener una arquitectura moderna y eficiente – que seguramente no se le habría podido ocurrir al «jefe externo» al carecer de los conocimientos necesarios -.

En resumen, pasados 3/4 del proyecto obtuvimos unos resultados impresionantes e hicimos una demo para mostrar al cliente lo que estaba comprando. Pero nos encontramos con que el jefe externo decidió abandonar su compañía, en parte al darse cuenta de que no estaba lo suficientemente preparado para hacerse cargo del mantenimiento del producto que había obtenido (tampoco lo estaba para haberlo construido, pero en fin).

En las negociaciones con la empresa sobre el futuro del proyecto (ellos querían abandonarlo ahora que se habían quedado sin jefe de proyecto) conseguimos demostrarles que el sistema funcionaba, que la arquitectura elegida era la mejor y que sería una pérdida de tiempo y dinero abandonar algo que está en tan buen estado… Es decir, les enseñamos que habíamos cocinado como auténticos chefs y disponían de un plato delicioso.

Peeero… parece que la empresa quería un simple Big Mac. Según palabras de la persona que se hizo cargo, necesitaban que el sistema pudiese ser mantenido por una sola persona que contratarían próximamente y necesitaban que les dijésemos el perfil que debía tener… Y aquí llegó el problema. Para conseguir el mejor producto se utilizaron distintas tecnologías mezcladas en su justa medida (C, C++, Java, ..) ya que el sistema era complejo y se ejecutaba en distintas plataformas con distintas necesidades de rendimiento/visualización. El resultado era que el perfil que pudiese mantener esa aplicación o no existía o era demasiado caro… Por que es evidente que debería existir un equipo de trabajo para continuar la aplicación… No basta con un «hombre orquesta».
Para el cliente, el hecho de haber cocinado con el mejor chef y los mejores especialistas era un problema serio, ellos querrían un plato que lo pudiera cocinar cualquiera (en palabras de Joel Spolsky) «uno puede tener un coeficiente intelectual que raya entre «idiota» e «imbécil» (por usar los términos científicos) y aún así será capaz de producir Big Macs que son exactamente tan comunes como todas las otras Big Macs del mundo».

Según el nuevo jefe de proyecto «Necesitamos que nos proporcionen documentación de tal manera que cualquiera leyendo esa documentación pueda hacer modificaciones al producto»… (¿?)

Y aquí es donde entramos en el dilema, ya que es un proyecto pasado hay que aprender siempre, ¿debemos tomar esto como una lección para el futuro de nuestra empresa desarrolladora de software o debería ser una lección de estrategia para la empresa que no desarrolla software?

Mis conclusiones (personales, claro):

  1. Si deseas un Big Mac, pídelo en un Mc Donalds y si deseas hacer hamburguesas, contrata a cualquiera para que las haga, pero no le lleves a un restaurante decente a aprender cómo se hace comida.
  2. Entérate antes de si tu cliente quiere el mejor programa o sólo aquel que sea lo suficientemente simplón para que cualquiera pueda entenderlo independientemente de sus conocimientos técnicos.
  3. No aceptes jefes externos si no queda claro que la responsabilidad del resultado es suya y no aceptes proyectos cerrados si vienen con jefes externos que pretenden influir en el devenir del desarrollo.
  4. Si no te dedicas al software siempre serás dependiente de los que se dedican a ello. Si quieres ser menos dependiente, nunca obtendrás la misma calidad (tu equipo siempre será más pequeño y menos preparado que el suyo).
  5. Si tienes una cocina pequeña y sin horno nuca podrás hacer un pavo asado… Aprender a hacer el pavo pero no proporcionar el horno sigue dejándote en la misma posición que al principio pero con un pavo de más (horno = equipo, pavo=software)..

Y me quedo aquí, podría continuar, pero hay más lecciones que aprender todavía ya que no hemos terminado del todo con el proyecto, ya os las iré contando.

9 comentarios en “Un Mc Software completo, por favor

  1. Pingback: meneame.net

  2. Pingback: www.programame.net

  3. No se vosotros, pero yo llevo en esto 15 años y el caso de imponer jefes de proyectos a un equipo de desarrollo externo es super comun. A veces resulta y a veces no. Como todo depende de las personas, no de la organizacion.
    ¿ entonces, tu empresa ha perdido la oportunidad de meter cocineros en un cliente, bien subcontratado o bien cedido ?

  4. Hola Jorge,

    Mi problema no es que se impongan jefes de proyecto, esto, como dices, es normal. Lo que no es normal es que nos impongan el jefe de proyecto y nos tengamos que responsabilizar de los resultados (todos son consecuencia de sus decisiones en primer término).

    Es como si el entrenador de un equipo de futbol nunca tuviese la culpa del resultado del partido.

    Nuestra intención, como empresa, es hacer el catering de las fiestas importantes… Ya que supongo que con el cocinero de mc donalds que contratarán no les dará para más que el rancho de las cuadrillas.

  5. Por conocer «bastante bien» la tématica que tratas no entraré en muchos detalles. En primer lugar creo que es muy importante definir las responsabilidades de un proyecto antes de acometerlo, en especial si hay «bicho» (lease jefe de proyecto externo) de por medio. Creo que algunas veces las ganas de acometer un proyecto (de la índole que sea) nos hacer pecar de inocentes y meternos en un embolao dificil de salir. El caso que planteas se pasea entre el absurdo y el más espantoso de los rídiculos (que habitualmente suelen provenir de empresas grandes)… los proyectos cerrados deberían ser de plena responsabilidad y en caso contrario optar por una formula típica de outsourcing.

    En esencia estoy de acuerdo en lo que dices, pero creo que uno a veces tiene que ser consciente de si le están pidiendo un big mac o un solomillo con salsa de boletus… Creo que cualquier persona que está en este mundillo cuando se le plantea un proyecto nuevo (en especial si es interesante) trata de dar lo mejor de un mismo y a veces es necesario bajar el listón y ofrecer algo intermedio y «digerible»… un escalope milanesa tampoco es tan malo.

    Para mi desgracia en el trabajo me he de mover por los principios del RAMS (reliability, availability, maintainabilty and safety) que me obligan constantemente a bajarme de la burra state-of-art (que dirían los anglo-parlantes) y cocinar mucho escalope…

    En fin… espero charlar un día de esto con unas cañas…

  6. Eaammm solo una pregunta por q era necesario usar C++ y java¿¿ tenian q usar microcontroladores o acceder a algun hw en particular y de ser asi porq no usaron una API de java o de python q hiciera esto o hacer todo el proyecto en python ??? y no haz leido sobre KISS ? ? ?

  7. El c++ venia impuesto por el cliente, aunque no me parece una mala solución ya que permitía estar más cerca del hardware e integrarse mucho más rápido con código en C nativo para los controladores de software. No existen APIs de Java de tan bajo nivel (y requerirían la ejecución de una pesada máquina virtual en la máquina) y el tiempo de respuesta ante los eventos era crítico. Python tampoco es opción al ser un lenguaje interpretado.

Los comentarios están cerrados.