Hacer las cosas vs. Hacer las cosas bien

Cuando advierto que mis escritos van sin ánimo de polemizar, a estas alturas ya nadie me cree. De hecho si analizo mi blog incluso me convendría que algunas personas no supieran de su existencia, pero bueno.

Luego de este ínfimo espacio de meditación intrascendental voy al punto de hoy. En el ambiente informático hay varios conceptos absolutamente utópicos, entre ellos debo referirme al cumplimiento de plazos, a la ingeniería de proyectos (o derechamente a los procesos de ingeniería) y la delegación de responsabilidades.

Cumplimiento de plazos

¿Existe? Absolutamente discutible, empiezan los cuestionamientos: ¿A costa de que? ¿Realmente lo vale, ie: vale decir que cumplimos los plazos si el producto entregado anda "a la pata' y el combo" como se dice a la chilena?

Lo que normalmente objeto son las definiciones de los plazos y en esencia a los encargados en definirlos: los comerciales. Tristemente, sólo una minoría de los comerciales sabe realmente de los temas que trata, el resto especula, dice barbaridades o derechamente no tiene idea donde está parado, pero habitualmente es capaz de venderle un par de botas a un cojo, unos guantes de box a un manco y unos Ray Ban a un cíclope. La postura de la empresa: VENDER, si muere gente en el proceso, no importa, son recursos y los recursos son reemplazables.

Resultado: Reunión con el departamento de desarrollo donde "se le avisa", notemos la absoluta ausencia de algún tipo de consulta sobre factibilidad, que hay que tener listo un sistema para antes de ayer, que el prestigio de la empresa y una suma no despreciable (que normalmente se maneja oculta) está en juego, y que no hay plata para contratar apoyo externo.

Reunión Post-Reunión: Todos empiezan a buscar "culpables", que porqué nadie consultó sobre los plazos reales y factibles. Unos empiezan a pensar seriamente en mandar a la punta del cerro (no precisamente con esos términos tan diplomáticos) la pega y así sucesivamente.

Por si no lo notaron, siempre exagero en mis ejemplos, pero es con fines únicamente didácticos.

Pasado el tiempo estipulado, el jefe de proyecto se da cuenta (en realidad siempre lo supo, pero normalmente se queda callado) que ni cag..., perdón (tuve un desliz de honestidad), nunca en la vida se va a poder tener el producto listo en los plazos definidos, así que se reune con el o los comerciales para redefinir aquello que ya vendieron, y para analizar como van a cconvencer al cliente que en realidad no compró un Ferrari, sino una Citroneta con llantas Momo (frase prestada de don Max Caprile).

Finalmente el proyecto sale, pero a costa de muchas horas de estress, horas extra no siempre remuneradas (mal que mal no es culpa de la empresa definir mal los plazos, sino del equipo de ingeniería de no ser capaz de desarrollar a ritmos irreales), y obviamente con más de un par de semanas por sobre el tiempo inicialmente estipulado.

Conclusión: No me digan que no les queda claro...

Ingeniería de proyectos - Procesos de ingeniería

Aquellos que cursaron el ramo en su institución de estudios recordarán que un proyecto normalmente sigue al menos 3 etapas: análisis y diseño, implementación y desarrollo, qa y pruebas. Altamente probable que alguien más especializado me corrija y/o complemente. Sin embargo con los supuestos ya mencionados, y precisamente herencia de una mala definición "a priori" tenemos que normalmente la 1era etapa va de la mano y simultanea con la 2da, y la 3era si es que existe se hace como una fase beta casi paralela a la puesta en marcha. ¿Procesos de ingeniería? Ala XP (eXtreme Programming). Es una fórmula conocida, se sabe que funciona, se sabe que vende (eso dicen los comerciales y las jefaturas...), pero si el equipo basa su funcionamiento en un "Que funcione 1ero, después nos preocupamos de los detalles.", lo mínimo que vamos a esperar es que los "procesos de ingeniería" (muy entre comillas) tengan resultados
derechamente deficientes.

Esa así como nace POP, en contraposición a todas las metodologías conocidas. POP: Patch Oriented Programming. La ironía más grande es que aparentemente las grandes empresas consideran que las mantenciones son menos costozas que vender un producto decente. Pensándolo bien, es cierto, y tienen toda la razón, los parches, nuevas versiones, soporte y mantenciones son pagadas, y rememorando el objetivo 1ario de la empresa (vender), se vuelve obvio.

Conclusión: Me pregunto de que me sirvieron los al menos 5 años de arduo estudio y preocupación sobre como hacer las cosas bien, si al final en la práctica laboralmente te exigen que hagas las cosas rápido sin importar como.

Y así quieren obtener certificaciones... Es cierto, son procesos formales que muchas veces burocratizan los desarrollos, pero evitan una cantidad de problemas a futuro increibles, desde la documentación y el control de versiones, hasta mantenciones y futuros desarrollos.

Delegación de responsabilidades

Suele suceder en una empresa de mediano tamaño, que en vista y considerando que los recursos son un bien escaso (pero reemplazable), hay una tendencia a asumir que el carpintero no sólo es carpintero, sino gasfiter, albañil, pintor, electricista, cerrajero, jardinero, cocinero, ama de llaves, lavandero, barrendero, pastelero y hasta contador. Insisto en mi fe en la especialización, pastelero a tus pasteles, si eres carpintero puede que seas capaz de levantar una pared, puede incluso que te quede buena, pero te vas a demorar mucho más que un albañil de oficio, y si no te llegara a resultar, el derrumbe eventualmente va a tener proporciones cataclísmicas, y lo que es peor, va a ser TU culpa. Y no pq no hayas advertido que tu eres carpintero, sino pq siempre existió la presunción de que en realidad eras mucho más capaz y que sólo exigiéndote ibas a mostrar tu verdadero potencial. A veces funciona, y hay carpinteros que en realidad debieron ser arquitectos, pero se dedicaron a la carpintería.

Muy al margen, se lee bonito cuando escribo con ejemplos poco relacionados, aunque la recomendación viene demasiado de cerca.

Hay una suerte de enfermedad casi típica en los jefes de proyecto de esto de asumir cosas, lo que es peor, de presumir cosas, y lo que es AÚN peor, de pedirle peras al olmo. Pero esto se ve reflejado cuando toca el caso en que debes reemplazar a alguien.

• De partida asumes responsabilidades sobre las cuales no tienes tiempo para conocerlas de lleno, menos desde un principio.
  
• Te enfrentas a una manera casi totalmente ajena a la conocida (la propia) de como enfocar diversas problemáticas y responsabilidades. ¿Han tratado de depurar o mejorar código ajeno no estandarizado ni bien documentado? Háganse la idea.
• Normalmente heredas cachos, y obviamente tienes que sacarlos.
• Habitualmente tus prioridades pasan por un estado de re-(des)priorización, y aún siendo partícipe de uno o varios proyectos más, debes hacer que todos tengan sus actividades diarias al día. Por ende ningún proyecto ni tuyo, ni de los heredados, debe atrasarse. Obviamente si no lo consigues es tu culpa por ser ineficiente, no es debido a que tienes el doble de trabajo...
• No sólo heredas responsabilidades adicionales, sino que incluso a veces heredas culpas.

Y así un suma y sigue de consideraciones varias, productos de un proceso de delegación de responsabilidades que va atado a procesos de análisis y evaluación normalmente inexistentes.

Conclusión: La delegación de responsabilidades existe, pero no como delegación como debiera ser, ie: con un análisis previo, replanificación y todo aquello que se SUPONE debiera considerar, sino más bien como un sorteo: "Te has ganado este listado de cosas que antes hacía Fulanito, y tienes que hacerlas como si Fulanito aún estuviera haciéndolas. Que tengas buen día."

Es mi tácita manera de graficar, muy a grosso modo, un universo no desconocido, y mucho menos lejano. Hay un alto grado de ironía y exageración, absolutamente conciente de ello. Puede incluso que haya tocado aquella herida insanable de algunos jefes o empresas. Y por eso mismo espero ilusamente que el universo cambie. Pero asímismo, estoy conciente que difícilmente ocurrirá, ya que es poco probable que una empresa cambie su manera conocida y archiprobada de hacer las cosas, por la manera adecuada de hacerlas.