archivo

Archivos diarios: enero 26, 2012

Defiendo absolutamente la posibilidad de que en una organización se pueda progresar horizontalmente de manera que técnicos que disfruten con la programación y con la ingeniería del software puedan tener la oportunidad de conseguir mejores condiciones laborales si su desempeño, experiencia y conocimientos les hace merecedores de ello.

Lo anterior es absolutamente compatible con una carrera profesional de índole más técnica orientada a la arquitectura del software.

Es posible que a un programador solo lo puedas vender dentro de un umbral precio/hora (es el reverso tenebroso de los proyectos tipo taxímetro o bolsa de horas), pero en proyectos donde prestas un servicio tener a desarrolladores altamente cualificados, motivados y productivos puede ser la diferencia entre ganar o perder dinero.

Un apunte: No hablo de sobredimensionar la cualificación de los equipos, ya que eso puede jugar incluso en contra del proyecto ya que puede provocar en algunos casos (proyectos de complejidad medio o baja) pérdida de motivación y de rendimiento, lo que unido a mayores costes, puede hacer que el proyecto no sea tan rentable como cabría pensar y encima tienes ocupado en el mismo a gran parte del potencial de tu organización.

Cuando el coste/hora y no la productividad es la que marca los pasos, se pueden llegar a tomar decisiones poco comprensibles como que arquitectos software o analistas orgánicos centren su esfuerzo en definir arquitecturas, frameworks o diseños y dejen a un lado el día a día de la programación.

Todos sabemos como evoluciona el mundo del desarrollo de software y eso hace que ese tipo de decisiones se consideren un antipatrón, ya que cuanto más alejado esté un arquitecto de la realidad de la codificación, más alejadas se encontrarán sus soluciones de las necesidades que pueda tener el equipo de programadores y el proyecto.

La creatividad desmesurada que nos caracteriza puede provocar que el arquitecto elija soluciones más teóricas (cuando no experimentales) que prácticas, alejando al proyecto del objetivo de simplicidad máxima que cumpla las expectativas del usuario. Este defecto lo tiene cualquiera que realice análisis, diseños o arquitecturas y empeora sensiblemente cuando se está alejado del día a día de los proyectos (un analista que no trata con usuarios y con sus problemas, tenderá a hacer soluciones más complejas).

Nos encontraríamos ante una situación concreta del antipatrón “responsable ausente“. En este caso, el gestor a modo de sortilegio establece una líneas generales para el desarrollo del proyecto y desaparece, apareciendo solo cuando existen problemas en el proyecto y generalmente como reacción ante las quejas de uno o más stakeholders (antipatrón “gestión dirigida por disparos“).

Nadie es imprescindible, pero si cada uno desempeña su rol en el proyecto de manera adecuada existirán más posibilidades de que todo salga bien.