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.