Outsourcing o no outsourcing, los dilemas continúan

Lo llamamos «Subcontratación» en español, pero cuando pienso en subcontratación, pienso mas en hacer construir una nueva cocina en la casa, que en hacer desarrollar código en algún país exótico…


En fin, continuando con los dilemas de la semana, otra de las discusiones (a veces acaloradas) que tienen lugar cada vez mas en la empresa donde trabajo es que tan interesante es para nosotros «subcontrar» el desarrollo de código. La discusión viene y va con el tiempo, pero en estos días estamos empezando a planear la nueva versión de una aplicación bastante grande que tenemos construida para trabajar con SharePoint 2003; la nueva versión será hecha, por supuesto, para que trabaje con SharePoint 2007. No estamos hablando de una u otra WebPart, sino de una aplicación que contiene mas de diez NameSpaces, y que consta de innumerables paginas personalizadas, varias plantillas propias, un montón de WebParts y WebControls, y unos 60.000 renglones de código… es decir, algo grande de verdad…


La primera versión fue desarrollada completamente por nosotros en la empresa. La segunda versión (hace dos años), fue subcontratada con otra empresa fuera del país. Para esta segunda versión, nosotros solamente aportamos el diseño funcional y el apoyo en cuanto a conocimientos del producto; después de un par de meses, recibimos el software funcionando, pero cuando tuvimos que empezar a hacer modificaciones y mejoras, empezamos a ver que el diseño técnico no era precisamente algo para estar orgulloso: el Modelo de Objetos utilizado no es consecuente, la separación (especialmente) entre las capas de lógica y presentación no es tan buena como deseábamos, el sistema de WebServices simplemente no funciona… no quiero decir que es un desastre, pero podría ser mejor…


Ahora estamos planeando la versión 3, como decía, y estamos en el dilema de desarrollar todo en casa, o subcontratarlo. O un camino intermedio. Para desarrollar todo en casa, necesitamos utilizar todos los desarrolladores, arquitectos, etc. de que disponemos por un par de meses, lo que significa que no podemos hacer nada por y para los clientes que tenemos, o que podemos conseguir en este tiempo. La ventaja principal es que todo sucedería como queremos que suceda. Si lo subcontratamos, perdemos probablemente calidad, pero ganamos en tiempo y recursos propios, fuera de que probablemente será (mucho) mas barato.


Mi punto de vista, si es que a alguien le interesa, es precisamente el camino intermedio: nosotros hacemos el diseño funcional (de todas formas esta en nuestras manos) y el diseño técnico. El outsourcing hace el trabajo de programación; mejor dicho, nosotros estipulamos la arquitectura, el Modelo de Objetos, la comunicación de los diferentes objetos entre si y entre las diferentes capas, yendo tan lejos como, por ejemplo, generar los esqueletos de las clases necesarias. Y la compañía que subcontratamos «solamente» tiene que meter el código en las clases para que hagan lo que tienen que hacer. Y nosotros producimos nuestras propias clases de prueba (unit test, regressive test, compilation) de tal forma que cuando nos llegue una clase completamente programada, podamos ver inmediatamente si funciona como nosotros esperamos. Ventajas es que la parte técnica la mantenemos en nuestras manos. Desventajas es que no seria tan barato como un outsourcing «completo».


Un dilema mas para charlar largo y tendido…


Gustavo – http://www.gavd.net/servers


Escriba un Comentario que me haga reir…

Un comentario sobre “Outsourcing o no outsourcing, los dilemas continúan”

  1. Un señor queria vender su perro, y lo oferto en 1.000.000 de euros. Rapidamente recibio varias propuestas por ese monto, el problema era la forma de pago. Aca van varias de las que recibio:

    2 gatos de 500.000 euros cada uno.
    1 canario de 750.000 euros y un perrito de 250.000 euros.
    5 comadrejas de 200.000 euros cada una.

    etc etc etc.

    Es decir, la subcontratación no tiene ninguna magia, salvo la de creer que si alguien es mas eficiente en costo que otros, son, a igualdad de calidad, meras coyunturas de mercados que tarde o temprano se «arbitran». Pero en el mientras tanto pienso que vale la pena que cuando uno solicita la RFP a un proveedor, debe tener claro como este validad sus capacidades. Luego simplemente no hay sorpresas, ya que la especificación formal del problema no daria lugar a dudas donde estan las responsabilidades.

    Saludos,
    Anibal

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *