archivo

Archivos diarios: septiembre 1, 2012

La realidad es que el contexto cambia porque es imposible manejar todas las variables que influyen en él. Pensar que nada va a cambiar es engañarse y si no estás preparado para adaptarte al nuevo entorno corres el riesgo de que el cambio de contexto te pille a contrapié y en el mundo de los negocios es difícil que te den una segunda oportunidad porque tu competencia prefiere que no existas.

Más allá de la adaptación al cambio se encuentra tu posibilidad de influir en el cambio lo que te hace más fuerte de cara a la competencia porque no solo puedes ser un competidor duro sino que además eres capaz de mover la base sobre la que se sustentan.

Es posible que Tom Peters pensara en todo esto cuando realizó la siguiente reflexión: “Las mejores organizaciones no creen en la excelencia, solo en la mejora continua y en el cambio constante”.

Al final tenemos que tener un producto que se termine pasando a producción. Muchas veces olvidamos ese detalle cuando nos encontramos en el proceso de desarrollo sobre todo si trabajamos con enfoques clásicos o iterativos e incrementales de ciclo largo. También si aplicamos ciclos cortos pero en cada iteración el producto se implanta en un entorno de demostración o de preproducción.

Cuando perdemos de vista el hecho de que al final el producto debe llegar a utilizarse algún día es cuando el sistema empieza a llenarse de funcionalidades y complejidades que son prescindibles y que no solo hacen necesario un mayor esfuerzo en el proceso de desarrollo sino que van desplazando en el tiempo una versión del producto utilizable en un entorno de producción.

Así ve este asunto Joel Spolsky (traducción libre): “Poner el producto en producción es una funcionalidad (del mismo). Una funcionalidad muy importante. Tu producto debe tenerla”.

Cuando en la definición y puesta en práctica de un proceso se habla de todo menos del producto algo está fallando. Si en tu organización aplicáis procesos relacionados con el desarrollo de software, échale un vistazo a lo que dedica realmente a cuidar el producto.

Los procesos tienden a cuidarse a sí mismos. Si tenemos en cuenta que los procesos son instrumentos y no objetivos quiere decir que estamos cuidando los instrumentos y no lo que pretendemos conseguir haciendo uso de ellos, teniendo en cuenta que ningún proceso puede asegurar la calidad del software (por mucho que se diga que están precisamente para eso).

Los que definen y fiscalizan los procesos tienden a cuidar a los procesos, no tanto porque crean en ellos sino por protegerse a sí mismos convirtiendo a los procesos como un fin en el que los productos son solo una excusa para preservar su existencia.

Y si los procesos no funcionan se termina echando más leña al fuego: se extienden, se hacen más rígidos, la fiscalización se realiza con más celo, etc… porque se entiende que la culpa no es del proceso sino de las personas que lo aplican y como las personas fallan, ahí están los procesos para solucionarlo todo.

La solución a los procesos no es la ausencia de procesos. Como he comentado en más de una ocasión, unos procesos lo suficientemente flexibles, que admiten excepciones, donde su supervisión tiene en cuenta el día a día de lo que acontece en los proyectos de desarrollo de software es interesante porque proporciona una base común para armonizar ciertos aspectos en los trabajos. Los procesos pierden su utilidad y se convierten en una carga cuando cobran más importancia de la que deben tener y le quiere robar el papel de protagonista al producto.

Es frecuente quejarnos en los proyectos de situaciones o contextos en los que tenemos poca capacidad de cambiar nada. Es tanta la frustración que se llega a tener que tratamos infructuosamente una y otra vez de intentar que esas condiciones cambien lo que a su vez vuelve a generar todavía más frustración.

Es del todo lógico intentar buscar una solución a lo que entendemos que no funciona o a lo que nos genera esa resistencia que afecta al proyecto pero llegado el momento hay que asumir que tenemos que trabajar con ese contexto, si cambia más adelante bienvenido, pero ahora no queda otra que adaptarnos a esa circunstancia o que el proyecto se resienta invirtiendo esfuerzo que no va a producir resultados.

Es lo que hay. ¿Es resignación? Es posible, pero por encima de eso considero que es pragmatismo.