Este artículo ha sido consultado en 425 ocasiones.
El problema del "Outsourcing"
Outsourcing es un término que se ha vuelto cada vez más popular, sin embargo, al hablar de delegación de responsabilidades tecnológicas, es un tipo de asociación mal comprendida entre las empresas. En el típico caso de lo que se suele llamar “outsourcing “ encontramos a un joven y animoso consultor que hace poco ha salido de la universidad y ha abierto su negocio, este consultor ha sido llamado por una renombrada empresa para hacer una aplicación. El jefe de sección de la empresa le detalla cómo y que características desea que tenga el programa, también le informa que en cuatro días desea presentar el proyecto al director de área. Lleno de entusiasmo el joven consultor regresa a su oficina y por tres días prepara su presentación en PowerPoint y las tablas para la base de datos. Allí, en la soledad de su oficina y ya entrada la noche, le abraza la certeza de que es posible crear un programa que satisfaga plenamente a su cliente.
Luego de presentar el proyecto de la aplicación al director de área se le dice que su cotización está un poco alta, que no hay dinero, que quizás el próximo año. El consultor, que ya siente que el proyecto es suyo, hace un esfuerzo y recorta el proyecto y los costos en un mes. Así, se desarrollará la aplicación en tres meses. Al otro día, muy alegre después de firmar el contrato, se pone a revisar currículums en línea para buscar dos desarrolladores “expertos”. Por otra parte, el jefe de sección y el director de área, se felicitan mutuamente por haber conseguido a un chico tan listo y dedicado ¡y por tan poco dinero! De inmediato se lo hacen saber a todos para que el director general se entere.
Luego de un par de meses la aplicación ni siquiera va a la mitad. Como el consultor sabe muy bien que no va a acabar en el tiempo acordado, pide una recalendarización pero la empresa se lo niega. El consultor empieza a poner de su bolsillo para la nómina y a estar todo el día detrás de los desarrolladores apurándolos y les recuerda que el solicito gente que supiera trabajar “bajo presión”. Las relaciones, que al principio eran todo sonrisas, ahora son tirantes o francamente hostiles. El consultor está furioso con los desarrolladores por no terminar, los desarrolladores están iracundos con el consultor porque sienten que fue él, el que se dejo embaucar por la empresa, la empresa está molesta con el consultor pues este les prometió un completo y magnífico programa y lo que ven es algo simplón y hecho a las carreras. El jefe de sección, que inició todo el embrollo, está haciendo el ridículo. Luego de otro mes, la empresa acepta pagar tres quincenas más pero ya van más de ocho y todavía no empieza las fase de pruebas del programa. Al séptimo mes, los desarrolladores desertan, pues llevan un mes sin cobrar, el consultor (aconsejado por su abogado), entrega lo que sea para dar por cumplido el contrato y no seguir perdiendo dinero.
He visto repetirse esta frustrante rutina docenas y docenas de veces. A mí mismo me ha pasado pues alguna vez también fui un consultor inexperto. Un par de amigos y yo llamamos a esta rutina el “gemoxazo” pues fue con esta empresa (Gemox) donde vivimos la cruda experiencia de un desarrollo que al principio parecía ideal se convirtió en pocas semanas en una pesadilla y un sangradero de dinero que casi nos hizo quebrar. Ahora, entre cerveza y cerveza, podemos recordarlo entre risas, pero en su momento nos causó gran desazón.
Cada vez que entró a OCC, CiberTrabajos, Bumerang o cualquier otro sitio de ofertas de empleo leo algo como:
“Experto en Java, EJB, Oracle, Unix, SQL Server, tres años de experiencia comprobable. Proyecto por tres meses. Acostumbrado a trabajar bajo presión. 1,500 dólares mensuales. Pago por honorarios.”
No creo que ningún “Experto en Java” este dispuesto a trabajar por 1,500 dólares mensuales. Mucho menos en México donde los impuesto por honorarios son cerca del 22% del sueldo. Pero, aún más importante, es evidente que ningún proyecto que dure tres meses puede ser un proyecto serio y bien planeado. Si algo he aprendido en seis años de experiencia es que el tiempo mínimo que se tarda un programa en diseñarse, codificarse, probarse e implementarse es de al menos ocho meses. Si tu eres desarrollador no tomes este tipo de ofertas, creéme, al final saldrás perdiendo dinero. En particular si dice “Acostumbrado a trabajar bajo presión” no envíes tu CV a esa empresa pues evidentemente no sabe trabajar. Estoy de acuerdo en uno debe comprometerse a entregar un buen resultado en una fecha precisa, incluso estoy de acuerdo en que, bajo ciertas circunstancias, uno debe quedarse hasta tarde en la oficina varias veces al año. Pero cuando el estar bajo presión es algo de todos los días uno debe hacer un alto pues alguien está haciendo mal las cosas. “Aquí trabajamos bajo presión” es una frase que muchos gerentes pronuncian con orgullo pues mantienen la falsa creencia de que le presión implica altos estándares, pero no es así. Tanto los programadores de Google, como el área Office de Microsoft como Ximian de Novell nunca trabajan bajo presión y pos si mismas producen tanto dinero como un país pequeño. Tienen tiempos de entrega generosos pues su exigencia no es acabar rápido sino entregar un producto competitivo de alta calidad.
Pero volvamos al punto. Muchos directivos cuando piensan en outsourcing creen que este esquema es atractivo pues tendrán personal calificado sin necesidad de contratarlo de una manera permanente. Este es un error común y muy grave pues le cuesta millones de dólares a las empresas todos los años. Una vez fui contratado para desarrollar una aplicación en Java, como trabajo mejor en casa lo hice todo con Tomcat en el pequeño servidor que tengo en el clóset pero al concluir, fui a pasarlo al Websphere que ellos tenían en un AS400. Mientras creaba la instancia y copiaba las clases noté que había cuatro directorios en cuyo interior había muchas páginas JSP y servlets pero no estaban dados de alta, preguntando al jefe de redes me dijo que eran desarrollos que “no habían funcionado” y que nunca se habían usado pues todo mundo huyó antes de la implementación. Por el tamaño de esos proyectos calculé que la empresa debió gastar cerca de 250 mil dólares por esos programas que nunca se iban a usar: otros casos del gemoxazo. Para la empresa, gastar esos 250 mil dólares fue como haberlos tirado por el inodoro pues no recibieron nada a cambio.
El outsourcing no es valioso por el hecho de ahorrarse un dinero en contratar gente sino porque hace a la empresa más esbelta, eficiente y dinámica al recortar su burocracia y, sobre todo, le permite concentrarse al 100% en su actividad de mercado. Si su empresa vende dulces o maquinaria pesada usted no quiere que los directivos estén pensado en sistemas de computación, la calefacción o los impuestos sino en cómo vender más dulces o maquinaria pesada. Entonces contrata un buró fiscal para que le de outsourcing con los impuestos, también al aspecto inmobiliario, y de mantenimiento le aplica un modelo de este tipo. Eso es lo atractivo del outsourcing. El outsourcing se define como “La delegación de procesos derivados a agentes externos en un plazo que va de los dos a los diez años”. Lo que hacen la gran mayoría de los desarrolladores en México no es outsourcing sino un práctica que podemos denominar “Desarrollo por proyecto” o (DPP) y que casi siempre conduce al gemoxazo.
Uno de las consecuencias más perjudiciales del esquema DPP es que todo el conocimiento que se genera al hacer un programa se pierde para siempre. La mayoría de los programas intentan automatizar uno o varios procesos de la empresa, para lograr esto el equipo de desarrollo debe conocer a profundidad como funcionan estos procesos y como se relacionan con otras partes para hacer el programa. En muchas corporaciones, no es algo raro encontrar que los programadores poseen una clara visión general de los procesos internos que incluso directores administrativos no tienen. En el DPP, una vez que el equipo termina el programa generalmente se desintegra y todo ese valioso conocimiento se pierde manera irremediable. Bajo el DPP los programas quedan siempre en le versión 0.1, y todo mundo sabe (o debería saber) que un programa empieza a mostrar verdadera estabilidad y potencia a partir de la versión 0.3.
Todos somos culpables de este estado de cosas, las empresas, por intentar basar su desarrollo tecnológico en pequeños proyectos DPP, las empresas de consultoría por aceptar los ridículos esquemas y los desarrolladores por no explicitar a nuestros patrones que las fases de diseño y pruebas siempre se contemplan como parte del tiempo dedicado a la codificación. Pero sobre todo somos culpables, porque en nuestra vida vemos los gemoxazos como algo normal.
Última actualización: 2007-04-29 10:56:59-05
