Arbitrariamente (como toda clasificación) y a muy grandes rasgos, podemos dividir el mar de equipos de desarrollo de software en dos corrientes principales: enfocados al producto y enfocados al cliente.
Los equipos enfocados al producto son responsables del desarrollo de uno o varios sistemas, siempre orientados a un mercado específico (si bien puede ser definido en forma más o menos amplia): sistemas contables, para la gestión de hospitales, comercios minoristas, logística o para el control de determinados dispositivos. El producto (o la familia de productos, entiéndase de aquí en más) requiere mantenimiento y constantemente se prueban e implementan nuevas funcionalidades y cambios para justificar los lanzamientos y generar ventas.
Del otro lado tenemos desarrollos enfocados hacia el cliente: profesionales independientes y equipos de desarrollo en consultoras y software factories de todo tipo y color que luchan por armar, mantener y ampliar una cartera de clientes a los que usualmente intentan vender de todo, si es software mejor. Algunas están también especializadas en un mercado en particular, pero vale la clasificación en tanto no vendan el mismo producto a varios clientes.
Y después hay grises, pero creo que la clasificación abarca a una amplia mayoría.
Hasta ahora he sido desarrollador de productos (aunque más de uno fue acaparado por algún cliente importante). Tenía formada una imagen bastante pobre acerca de la calidad de los productos y del trabajo en consultoras (sobre todo en las grandes, pero es una experiencia que por ahora no tengo), y crucé la línea cargado con no pocos prejuicios y temores. Pero bueno, hay que alejarse de las zonas de confort, dicen.
Han pasado ya casi cuatro meses desde el salto, puedo decir que por lo menos una de las consultoras (por suerte) no es como me la esperaba. Realmente las cosas no son ni mejores ni peores, simplemente distintas, y a esto iba, a hacer un contrapunto.
Los muertos se dejan atrás (aunque hay zombies indestructible).
La huella de toda consultora es un reguero de cadáveres más o menos malolientes: proyectos cuya calidad interna deja mucho que desear, si bien hacia afuera suelen verse bastante bien (que al cliente hay que cuidarlo). El aprendizaje se da de proyecto en proyecto y los primeros en implementar determinadas herramientas o tecnologías son víctimas fatales de la inexperiencia.
En cambio, cuando trabajamos en versiones incrementales del mismo producto, siempre sobre la base de código de la versión anterior, poco a poco la experiencia se materializa en todo el proyecto a través de revisiones y refactorizaciones. El equipo (si no es testarudo) no tarda en darse cuenta de que si se mueven las lápidas y se dejan las tumbas los muertos se convierten en fantasmas que nos acecharán eternamente. La única forma de sacárselos de encima es buscar el cadáver y darle cristiana sepultura.
A cierta distancia de la línea de entrega de un proyecto que se presentará, aprobará (y si te he visto no me acuerdo), es inútil refactorizar y solucionar definitivamente determinadas cuestiones. Llega un momento en el que el sistema “es así” y punto, y aunque (por lo menos para mí) es difícil de aceptar, hay que dar media vuelta y seguir adelante.
Cuando se trabaja sobre un producto toda refactorización es provechosa y bienvenida. Incluso en las reingenierías el código “del sistema viejo” es referencia para determinar detalles de implementación, por lo que cuanto más legible mejor. Así que es sencillo cuándo determinar cuándo es conveniente hacer una refactorización o resolver un problema de fondo: siempre.
En una consultora determinar a ojo cuándo se ha llegado ese punto de no retorno es muy difícil, y los errores en este sentido son frecuentes. Muchas veces las inevitables horas fuera de presupuesto que insumen las correcciones entre presentación y aprobación superan aquellas que hubiesen sido necesarias para la refactorización, y otras veces se van horas de refactorización en funcionalidades con pocos errores y cuya prolija implementación nunca será vuelta a ver.
En todo caso, y en esto he confirmado mis prejuicios, aunque la consultora en sí no pueda desprenderse de algunos muertos devenidos en zombies, la realidad es que desde el punto de vista de un desarrollador en particular es poco probable que una vez abandonado el proyecto se lo vea volver en la misma dirección.
Suficiente, creo, para una primera entrega. Seguimos en la próxima.
1 comentario:
Producto vs. Servicio
Como vos bien decís, cuando estás orientado a un producto, el producto se supone que es más importante que el cliente, porque es quien te trae más clientes. Entonces, se piensa en algo más mantenible
Cuando lo importante es el cliente (caso de las consultoras), lo que el cliente compra es el servicio.
Así que en este caso, es muy común la frase "Si funciona, no lo toques".
Es por eso que en estos casos, se intenta maximizar el beneficio, reduciendo las horas de trabajo aplicado.
Es por eso que si lo que se hace hoy, implicará más trabajo para mañana, al final de la rueda... mejor.
Tito Cozza
Publicar un comentario