Necesidades de un producto de software internacional
9, 08 de 2005-06-08 de 2005
¿Que es lo que necesita un producto de software internacional?
En mi empresa se han decidido a lanzar su producto en el extranjero. Quieren empezar por México. Yo veo que un producto de software comercializable a nivel internacional tiene unos requisitos de partida que un producto nacional no tiene.
En mi empresa se han decidido a lanzar su producto en el extranjero. Quieren empezar por México. Yo veo que un producto de software comercializable a nivel internacional tiene unos requisitos de partida que un producto nacional no tiene.
- Interoperativodad con los sistemas del area de negocio existentes en las zonas de comercialización.
- Localización: Tanto de la presencia en internet como del producto. Lo cual incluye:
- Idioma
- Cultura: Por ejemplo, en China el rojo es el color de la muerte y tiene otras connotaciones que aquí no tiene.
- Particularidades del negocio en la zona: Un programa de diseño urbanístico no seguirá las mismas reglas de negocio en Panamá que en España.
- Usabilidad: Tienes que ser más usable que los demás para tener ventaja competitiva.
- En la cresta de la ola tecnológica ofreciendo algo que los demás no tengan y que quede en boca de todos.
- Flexibilidad: El producto tiene que ser adaptable a cada mercado sin que mantenerlo sea un infierno. De ello depende mucho la arquitectura del mismo.
Yo puedo ofrecer la perspectiva de cliente, versión gran multinacional con presencia en 30+ países. A ver si soy clara:
- En mi empresa la única manera de poder implantar un producto de software común para todo el mundo ha sido a base de unificar procesos de trabajo. Y si esto ha supuesto, siguiendo tu ejemplo, que Panamá se ve obligada a hacer la planeación urbana como Barcelona, y aunque esto tenga un claro (y obvio) impacto negativo en el negocio de esa sucursal de la empresa, pues los altos directivos dicen: "pos bueno, pos fale, pos m'alegro". Es decir, por el "bien común" o cumplimiento de la estrategia dictada desde arriba, se sacrifican muchas áreas de negocio/geografías. ¡Y qué pasa! Bueno, si el negocio se hunde, se hunde sin más remedio. Pero si se medio trampea la situación, pues resulta que estas estrategias globales y estos rollouts como "enablers" de procesos unificadores (aunque no óptimos) y de las políticas de buen gobierno (governance) son lo que mola hoy en día entre los brokers de Wall Street, y el precio de la acción va para arriba.
- En estas implantaciones se utilizan por narices paquetes comprados (aunque a China se le muestren terroríficas pantallas rojas), no me preguntes por qué. Nosotros ahora mismo tenemos un sistema front office cojonudo (flexible, parametrizable, escalable) desarrollado en España y que se adapta bastante bien a (por hablar de lo evaluado ya) el resto de nuestras operaciones en el norte de Europa, y ¿qué han decidido nuestros estrategas? Pues implantar un paquete comercial que no se ajusta nada bien a las necesidades. Las grandes empresas tienen fobia a depender de sus empleados (que no sean altos directivos) pero no les importa jugársela dependiendo de otras empresas proveedoras de servicio/producto. Aunque en la práctica todos sabemos que eso de que la proveedora de servicio es una caja negra es un cuento. Sigues dependiendo de las personas, de las personas empleadas por la empresa de servicios, con lo cual es peor, porque ni siquiera está en tus manos el retener a estas personas valiosas.
Ya me he quedado a gusto....... el comentario no ha sido demasiado técnico, pero esto es lo que hay en las multinacionales grandes.
¡Saludos!
Qué sabe tu empresa de México si nunca han besado a un Xoloitzcuintle? :P
Bueno, ya en serio, escogieron un país fácil en cuanto a lo del idioma, pero pues como quiera probablemente el esfuerzo para hacer la localización sea muy similar al de cualquier otro, a fin de cuentas, la infraestructura en el software para eso es básicamente la misma para 2+ idiomas (al menos que sean muy brillantes y vayan a cargar cada etiqueta con condicionales...).
Mi experiencia, mayormente técnica, con eso de las localizaciones en mi antiguo empleo:
* Teníamos información de debug que nos alertaba cada vez que una etiqueta no se encontraba
* Hint: Usen un wrapper para atrapar las excepciones para cuando no se encuentren las etiquetas.
* Otro hint: Usen algún sistema de logging (como log4j), si es que no usan alguno, para estar rastreando más fácilmente las etiquetas faltantes. A nuestro equipo de QA le encantaba usar nuestros logs en nuestra contra.
* Teníamos que echar unos divertidísimos rounds con los diseñadores gráficos para evitar lo más posible poner gráficos con texto dentro de nuestras aplicaciones web.
* Teníamos gente que dedicaba gran parte de su tiempo a que estuvieran actualizados los archivos en dónde se incluían los diferentes lenguajes.
* Definan de quién es la responsabilidad de proporcionales la terminología correcta a utilizar en el software. A los jefes les encanta responsabilizar a los pobres desarrolladores.
* Teníamos gente que hablaba cada uno de los idiomas que ocupabamos para traducir la terminología del software para la localización.
* Y más reciente, para la clase de usabilidad me di cuenta que era necesario también localizar los mnemónicos...
Eso es lo que de momento se me ocurre, pero pues de seguro hay muchas consideraciones más.
Ok. Pero eso no se puede aplicar a todos los ámbitos. Hablamos de aplicaciones de escritorio para diseño de ingeniería civil. Los palabros técnicos que emplean en mexico, la normativa de construcción, el modo de trabajar, etc... No tienen nada que ver. El problema reside en que si la aplicación es modular puedes componentizar las reglas de negocio de la misma y hacer, por ejemplo, que toda la normativa sobre curvaturas máximas en autopistas se encuentre en un único componente.
No estamos hablando únicamente de colores e idiomas.
Igual con esto que os comento os he guiado un poco más.