Es difícil que un desarrollador que haya trabajado en algún sistema de gestión no se haya enfrentado con esta situación.
Circuitos administrativos hay para todos los gustos. Tenemos los clásicos compras, producción, ventas, facturación, atención al cliente, liquidación de sueldos. También tenemos algunos más infrecuentes, pero de todas maneras muy comunes: presupuestos, importación, exportación, marketing...
Todos ellos han sido descritos, caracterizados y estandarizados extensivamente por la bibliografía de la administración de empresas. Algunos de ellos, por estar atravesados por restricciones legales, son muy parecidos en todos lados.
Pero el problema de las sutilezas existe siempre. Cada empresa tiene las suyas, a veces justificadas, a veces no. Y el momento de comprar un software que gestione el circuito será el de la dura negociación para determinar quién se adapta a quién (la empresa al software o viceversa) y en qué grado.
En Panqueque System II: Un caso de dependencia del cliente apuntaba al caso en el que el cliente requiere customizaciones de tal especificidad que termina quebrando al desarrollo en dos versiones (por lo menos). El problema es casi comercial: se cobran customizaciones pero el cliente domina hábilmente la negociación y termina con un software a medida.
Este caso es sutilmente diferente. Más que de un error comercial, estamos hablando de un vicio funcional.
Los analistas funcionales, en su contacto cotidiano con diferentes clientes, son caldo de cultivo para esas pequeñas variaciones orientadas a demostrarle a cada cliente que el software se adapta perfectamente a sus necesidades.
Tomadas individualmente cada una de estas variaciones parece inofensiva, fácil de implementar y con una relación costo-beneficio ampliamente favorable. El cliente siente que el producto le calza como un guante. Cada vez que durante la demostración él apunta a cuestiones como "ah, nosotros requerimos que el gerente apruebe el pago para los mayores a..." podemos responderle "eso es configurable aquí".
Finalmente, todo termina siendo configurable allí (en esa pantalla infernal con 200 opciones que se activan y desactivan unas a otras). Que si tal funcionalidad está desactivada tal pantalla no tendría que verse, que si el módulo tal no está activo los datos tendrían que mostrarse de tal manera o de tal otra... Que los vendedores a veces pueden y a veces no pueden, que los descuentos a veces son fijos o pueden ser variables o...
Cada una de estas variaciones aporta su granito de arena para hacer de la gestión de configuración un absoluto desastre.
Lo divertido es -esto le he visto ya en varias ocasiones- cuando la combinatoria de estas opciones a veces sutilmente incompatibles unas con otras, resulta en comportamientos completamente insospechados. O cuando para activar ésta se necesita activar aquélla y para activar aquélla necesito esta otra que requiere la primera... una especie de abrazo mortal.
Y ni hablar de cuando se pretende incorporar nueva funcionalidad. El desarrollador que esté a cargo del nuevo módulo o pantalla puede verse involucrado en uno de dos infiernos: o se encuentra con una larga lista de opciones y variaciones pre-existentes que está comprometido a implementar, o (esto es tal vez peor), no hay documentación clara sobre alguna o ninguna de ellas o de la relaciones entre todas y se va enterando sobre la marcha o durante el testing.
En el primer caso, se genera una sobrecarga tal que la más mínima funcionalidad agregada insume un número aparentemente desproporcionado de horas. Pero por lo menos esto puede estimarse. Es un problema, y es conocido. En el segundo caso -la falta de documentación-, el desarrollador se va enterando sobre la marcha, con la sensación de ir retrocediendo a cada paso. Si había estimado 4 horas, luego fueron 8 y luego 16 y luego...
¿Soluciones? Ninguna es categórica. Cuándo incorporar una variación que surge del circuito administrativo de un cliente en particular es siempre es una relación de costo-beneficio. Los beneficios son instantáneos y los costos a mediano y largo plazo.
¿Podemos decir que no? Dependerá de qué tan importante sea la "sutileza" para el cliente y de qué tan importante sea el cliente para la empresa. Lo que es imposible de explicar (de cara al cliente) es que de alguna manera la calidad del producto puede verse comprometida.
Desde lo técnico el nudo de la cuestión estará en crear una arquitectura en la cual se puedan establecer cambios de comportamiento en forma global, de manera tal que el programador no tenga que estar al tanto de estas variaciones al momento de codificar. Esto no siempre es posible, y si lo es, lo será sólo en cierta medida.
Y desde lo metodológico, la simplificación: no sólo implica hacer más simple el código existente, sino retirar lo que no es frecuentemente utilizado. Este punto es al que se le suele restar importancia. Un producto con algunos años y versiones sobre sus espaldas puede estar cargando con un sinfín de posibilidades que ya nadie utiliza.
De cualquier manera, lo importante no es evitar el infierno de preferencias, dado que éste infierno, si está controlado, puede ser el que incline la balanza hacia nuestro favor al momento de ganar clientes. Lo importante es que la parte comercial y funcional del proyecto o la empresa sea consciente de la forma en la que sus decisiones afectan al producto.
Varias veces el equipo de desarrollo se encuentra con que se han aprobado customizaciones u opciones sin ningún tipo de consulta previa. No es una cuestión de "querer estar en todo", pero... ¿Si no se ha consultado al área técnica, sobre qué bases se ha decidido que lo que se cobra o ingresa por la customización es mayor al costo actual y futuro de la misma?
Los artículos de la serie:
No hay comentarios.:
Publicar un comentario