Durante muchos años en esta profesión, siempre me he preguntado que esperan los clientes que recién comienzan a creer en los estándares y en la metodología; si, como lo leen, ¿ qué esperan obtener ?, no puedo evitar recordar a Alicia en el país de las maravillas cuando recién comienza a comprender en donde está, sencillamente cree que todo será maravilloso, pero todo esto, no es mas que un sueño.  Me explico…

El caso común (por no decir que de todos) es aquella típica reunión de arranque o acercamiento inicial de aquellos clientes que se acaban de dar cuenta que necesitan actualización tecnológica, nuevas aplicaciones o integración, tras 25 años de operación y sin inversiones mayores (en tecnología) en los últimos 10 o 15 años; contratan a 3 niños recién salidos de la universidad que traen unas ganas enormes de aplicarle ITIL y RUP hasta a sus vidas; con esto estos clientes crean unas expectativas enormes para si y para el resto del negocio, haciéndoles creer que todos los problemas serán resueltos en un par de meses…

Esto no es del todo malo, la mala noticia está en el ¿ cómo ?, pues «las cosas imposibles las hacemos rápido, pero para los milagros nos tardamos un poco mas», esto claro, si y solo si, partimos de una base realista de en donde estamos y para donde vamos.  Resulta imposible ir de una aplicación en Turbo Pascar 7.0 Stand Alone funcionando sobre windows 3.11 en un PC 386, a una aplicación desarrollada en Java, utilizando un BUS (escojan cualquiera, todos dan problemas) y distribuyendo modulos y funcionalidades por todas partes por donde el LDAP lo permita, basados en un manual de estándares que recién escribe uno de los niños y lo mejor de todo orientado a .NET.

Resulta super interesante, pues las exigencias van desde los nombres de los proyectos hasta el manejo de estructuras condicionales, pero no hay estándar alguno para el diseño de la arquitectura o peor aún, ni siquiera de los nombres dentro del LDAP (y esto es solo por mencionar un ejemplo).

Existen cosas mas allá de lo ideal, mas allá de ese mundo utópico que no termina de funcionar jamás, cosas que deben hacerse para poder transitar esa ruta que dirige al lugar a donde queremos llegar y es por un par de razones muy sencillas, el negocio no se puede parar a esperar por tecnología y es imposible correr cuando no se tienen piernas y mucho menos se ha caminado jamás.

En lo sucesivo, como una humilde sugerencia, recomiendo que cada vez que ud. piense en atar de manos a sus proveedores imponiéndoles un estándar o una metodología pídales su opinion y no solo como una formalidad, escúchelos, por algo les está contratando, de seguro sus experiencias anteriores le serán muy útiles a ud. para evitar errores que ya han visto en otros clientes, un «DeJavú» como lo llaman.

¿ Cuales son estos errores ?, pues son miles, para nombrar algunos: proyectos con dos técnicos y siete personas de pruebas, un lider de proyectos, un controlador, dos documentadores, etc, etc;  Plataformas en cluster para asegurar «alta disponibilidad», pero con nodos virtuales sobre un mismo hierro que tiene una sola fuente de poder y un solo disco duro;  «aplicaciones distribuidas» con manejo y optimización de los anchos de banda, pero los equipos en donde están la APP y la BD conectados con un cable cruzado entre ellos para no afectar el tráfico del Core Swicht; Roll Out masivos manuales que son verificados por una aplicación que revisa la instalacion la cual duro 5 meses en desarrollarse, ¿ no era mejor desarrollar un instalador  ?; y como estos un gran e increíble etc., todos ellos justificados por la «metodología» o al menos por la interpretación que se le da.

Existen puntos intermedios o metodologías y estándares mas Soft para quienes recién comienzan a arreglar su situación actual partiendo de un desastre, que no se recomiendan ni en la universidad, ni por los amantes de la metodología que nunca han visto nacer a una aplicación desde cero y llevarla al extremo de atender unos 500 mil hits diarios en cuestión de semanas, gente que aun no entiende el vertigo de trabajar sobre un proyecto que ya está en productivo, que no se puede parar por un diagrama, es decir, por alguien que no sabe que se pierden mas recursos y dinero esperando por un diagrama y en reuniones con 20 personas para mirarlo, que por un ajuste en caliente que luego puede ser documentado en la paz del escritorio mientras el negocio sigue fluyendo y llenando su caja.

Evaluar todas las opciones es parte de su labor, inclusive dejar a un lado la metodologías excesivamente demandantes, es ud. el que decide como quiere ser recordado, «como el gerente que dejo muchos dibujitos que no siven de nada» o «como el gerente que realmente resolvió los problemas y mejor aún, el que hizo del negocio un negocio mas dinámico y rentable»

Existen cientos de iniciativas, anímense a leer XP, CRUM, Agile, son un buen comienzo…

Ricardo Arispe
Gerente de Tecnología y Proyectos
Soluciones para T.I.
@rarispe

0
Comments

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

© 2024 Soluciones para T.I.