Por qué es mala idea que el software se desarrolle donde el cliente

Cada vez es más frecuente, sobre todo en grandes clientes, que el software a medida se construya en sus dependencias en vez de las del proveedor. ¿La causa? Mi teoría es que:

1. Por alguna razón a los clientes les resulta cómodo adquirir servicios en forma de outsourcing, y el desarrollo a medida en el cliente se parece bastante a eso. Sospecho que creen que, comparado con la venta de proyectos por objetivos, la negociación y la resolución de conflictos es más fácil en la modalidad compra de HH.
2. La cultura Agile, hoy en boga, promueve una interacción cercana y continua del equipo con el dueño del producto y del negocio. Más aún, el dueño del producto debiese ser parte del equipo. He escuchado a expertos y consultores de agilidad extremar este argumento y exigir que el equipo trabaje en el cliente.

¿Cuál es el problema de desarrollar en el cliente?

La empresa de software es más que algunos desarrolladores específicos

Reducir la capacidad de una empresa de software a las horas individuales que trabajan ciertos desarrolladores, es renunciar a la capacidad que tiene la empresa como equipo. El costo de esto es gigantesco. Por una parte, se priva al cliente de beneficiarse del resto de las capacidades de su proveedor. Por otra parte, la empresa desarrolladora pierde también la oportunidad de apoyarse en las personas que están trabajando en el cliente. El problema se agudiza cuando el cliente mezcla en un equipo personal de varios proveedores.

En mi experiencia personal en el Grupo Orand, si bien estoy orgulloso de la capacidad de cada uno de mis colegas, no puedo sino constatar que el equipo completo multiplica por diez la suma de sus capacidades individuales. Y eso me encanta.

El dueño del producto no tiene tiempo para acompañar en todo momento al equipo

La mayoría de las veces el dueño del producto (en el cliente) tiene poco tiempo para participar del trabajo del equipo. Con suerte puede asistir a la reunión diaria de coordinación (aka “daily meeting”). Esta interacción puede perfectamente realizarse como una reunión más, sin exigir presencia del equipo full-time. De hecho, en nuestros proyectos invitábamos al cliente(s) a nuestras oficinas para las reuniones diarias, demos y planificaciones. A veces se quedaban trabajando con nosotros en nuestros espacios. Y si no podían asistir presencialmente, participaban por Skype.

Negociar exclusivamente los proyectos por HH te lleva a perder oportunidades

Los desarrollos realizados donde el cliente, tienen muy arraigada una mecánica de negociación en base a HH. En la práctica he visto como se inhiben oportunidades de reusar código o de usar productos ya existentes del proveedor (o de otro proveedor). Existe la tendencia a que todo tiene que ser comprado en base a HH. Esto es particularmente marcado en los proyectos de gobierno que se realizan a través del Convenio Marco Perfiles de Desarrollo y Mantención de Sistemas. Dicho sea de paso, todavía no entiendo la lógica de usar convenios marcos para el desarrollo de software y, en general, para servicios profesionales que por definición no son commodities.

Desarrollar en el cliente difícilmente es más cómodo que en tu propio espacio de trabajo

En MITI queremos que Chile se convierta en el mejor lugar para desarrollar software. Esto significa enfrentarse permanentemente a nuevos desafíos, aprender, y disfrutar de un ambiente apropiado. Aunque hay excepciones, en general trabajar en el cliente es, en el mejor caso, tan cómodo como en tu empresa, y en el peor caso, un desastre cuando el cliente no tiene una cultura de cuidado del desarrollador. Incluso si estás cómodo, no hay como estar “en casa”. La segunda derivada es que es difícil que el profesional vea claramente una proyección de crecimiento en su empresa si trabaja a tiempo completo donde el cliente.

Aceptémoslo: “desarrollar en el cliente” y “outsourcing de personal” son la misma cosa

Reconozco que esto no es necesariamente bueno ni malo así que dejémoslo ahí.

¿Y cómo evitar los problemas anteriores?

No importa que metodología de desarrollo uses, creo que son pocos los casos que realmente justifican desarrollar en el cliente. Destaco aquellos proyectos donde la integración con otros sistemas es crítica y toda ayuda de los ingenieros del cliente es bienvenida. Pero en la mayoría de los casos, es mejor una alternativa como las siguientes:

1. Estructurar el proyecto en base a un equipo del proveedor, que trabaja con la metodología y cultura de la empresa de desarrollo y en sus dependencias. Dimensionar y negociar el proyecto en base al equipo o en base a objetivos, no HH.
2. Ideal si las personas relevantes del cliente se desplazan a las dependencias del proveedor siempre que sea necesario. Si eso no es posible, se pueden hacer reuniones puntuales donde el cliente, aunque sean frecuentes. Además, siempre se puede sacar ventaja de las nuevas formas de comunicación remota como la video-conferencia.
3. Si es necesario trabajar en el cliente, ser inflexible en el estándar de comodidad para tus desarrolladores.
4. Cuidado con la mentalidad “todo será construido in-house”. Si ya existen soluciones específicas para algún problema, deben ser evaluadas. El mundo camina a soluciones cada vez más potentes que hacen uso de tecnologías sofisticadas como inteligencia artificial, criptografía, usabilidad, por decir tres de muchas posibilidades, y para las cuales no es realista que puedan ser desarrolladas en el contexto de un proyecto.