Procesos, metodologías, flexibilidad

Los procesos y las metodologías delimitan un camino y eso de por sí restringe las posibilidades de actuación. Esto no es ni bueno ni malo de por sí, depende realmente de hasta dónde llegan esas restricciones y de las posibilidades que tenemos de hacer excepciones cuando el proyecto lo requiera.

Cuando un proceso o una metodología entran en un nivel de detalle alto nuestro margen de maniobra se reduce, si quien controla (en el caso de que haya alguien) el cumplimiento de la misma no permite excepciones nuestra frontera empieza y termina allí, esto podría ser interesante cuando tienes la mayor parte de los detalles de un proyecto bajo control pero sabemos que esas condiciones, prácticamente ideales, son complicadas de conseguir.

No se trata de elegir entre extremos sino de ser flexible ya que no siempre es problema de la rigidez de quién especifica los procesos, también es importante que nosotros seamos flexibles y entendamos que la organización también necesita gestionarse y que por ese motivo, a veces, se establecen ciertas premisas que aunque puedan no gustarnos los gestores entienden que son necesarias (aunque no por ello tienen que ser acertadas siempre).

Al final es cuestión de que todas las partes sean sensatas y no se posicionen en esquemas de funcionamiento que no se adapten a un contexto y a las necesidades del proyecto.

Procesos de desarrollo, teoría y realidad

Aplicar prácticas teóricas fundadas en procesos y procedimientos que quedan muy bien en los libros (cuando vienen de libros) sin tener en cuenta cuál es la realidad de la organización, su contexto, de las personas que tienen que participar en los mismos, de la realidad económica existente, no traerán resultados acordes a la inversión realizada, no solo para implantarlas y controlarlas, que lo mismo no es el mayor gasto, sino por el hecho de cumplirlas, por el sobreesfuerzo que hay que realizar y por la reducción de la flexibilidad a la hora de afrontar un determinado proyecto.

¿Qué aportan realmente esos procesos? No todo va a ser negativo, probablemente algunos de ellos sean muy beneficiosos, pero, ¿y todos los demás?. Generalmente, en lugar de entrar en un proceso de mejora continua en el que se de valor a lo que resulta útil y se modifique, descarte o cambie el enfoque de lo que no funciona, se tiende a mantener una línea continuista con cambios poco significativos, ya que la respuesta ante la crítica o las quejas por los procesos, será no tenerlas en cuenta, creando una brecha cada vez más amplia entre quienes definen esos procesos y quienes los tienen que trabajar.

De esta forma se seguirá de espaldas ante la realidad porque no se debe ignorar a quién trabaja con esos procesos ya que nadie mejor que ellos saben si se adaptan o no lo que le toca vivir todos los días y al cumplimiento de los compromisos adquiridos.

No siempre van a tener razón los desarrolladores, a veces, no tienen en cuenta determinadas necesidades organizativas. No se trata, por tanto, de decir a todo que sí, sino de tratar de buscar soluciones consensuadas, de esta forma sí será posible buscar una alternativa rentable, sostenible y que genere menos desgaste, que se siga adaptando con el paso del tiempo a los cambios de contexto y necesidades.

Robert C. Martin. Experiencia e inteligencia sobre procesos y herramientas

Los procesos y herramientas son instrumentos que utilizados de manera adecuada pueden ayudarnos a conseguir los objetivos. El problema lo tenemos cuando se cree que los objetivos se consiguen, sobre todo, por su aplicación, lo que provoca que pasen a la categoría de fines en lugar de la de instrumentos: «si cumplo con los procesos y hago un buen uso de las herramientas que lo acompañan el proyecto saldrá bien».

Si centras tu atención en el proceso pierdes tu enfoque en el producto y se tiende a ignorar el contexto. Todo ello por la idea de que la solución la proporciona el proceso y que eso está por encima de cualquier contingencia que se pueda producir.

Robert C. Martin realiza la siguiente reflexión: «El exceso de confianza en las herramientas y procedimientos y la falta de confianza en la inteligencia y en la experiencia son recetas para el desastre».

A veces es la propia organización la que empuja a los desarrolladores a centrarse en el proceso, independientemente de la importancia que ellos piensen que pueda tener en el desarrollo de software. Cuando esto ocurre habrá personas que por comodidad y también por pragmatismo (hacia ellos y no hacia el proyecto y el producto) caigan en la cultura del cumplimiento: «yo he seguido los procesos de manera escrupulosa, ahí tienes todos los entregables, si el proyecto no ha salido bien no soy el responsable».

Si el desarrollo de software fuera solo cuestión de procesos (ágiles o no) la mayoría de los proyectos no tendrían problemas y serían rentables tanto para clientes como para proveedores, ¿es esa la realidad?, se necesita algo más y eso lo ponen las personas que trabajan en ellos.

Alistair Cockburn. No existen las tallas únicas

Es cierto que pueden existir ciertas reglas o patrones que se repiten con una cierta asiduidad en los proyectos de desarrollo de software pero en muy pocas circunstancias se da el caso de que la receta aplicada en otro proyecto garantice el éxito en el que estás trabajando.

Sí que es bueno conocer esas experiencias, esas buenas prácticas, esos patrones, esos antipatrones, ese cuerpo de conocimiento pero sabiendo que se trata de herramientas que están a nuestra disposición si entendemos que son de utilidad para el proyecto (y no siempre lo serán).

Se trata de conocimientos y experiencias de terceros y si le vas sumando tu propia experiencia la caja de herramientas ofrecerá más posibilidades y será más precisa. No obstante y por encima de todo se encuentra nuestra capacidad de entender que cada proyecto es distinto y que cada situación puede requerir soluciones particulares.

Alguna vez he comentado en el blog que no entiendo muy bien esos casos en los que vienen empresas o consultoras a proponer la implantación de un conjunto de procesos o metodologías sin haberse preocupado en conocer las particularidades de la organización del posible cliente, como si tuvieran entre manos una talla única que encaja en todas las situaciones.

Me parece muy interesante la siguiente reflexión de Alistair Cockburn: «Si se sigue una metodología tal cual, tendrás una que se adapte a algún proyecto en el mundo, pero probablemente no el tuyo».

Simplifica primero, desarrolla después II

Algunos de los lectores habituales de este blog se preguntarán: «en un proyecto de desarrollo de software, ¿no tenemos que estar siempre atentos (alertas) a la necesidad de adaptarnos al cambio?, ¿no es la rápida capacidad de adaptación una ventaja competitiva?, ¿por qué haces un planteamiento tan rígido?».

Por este motivo me he decido a darle una segunda parte al artículo publicado ayer.

Una organización siempre tiene que estar atenta a la oportunidad y a los movimientos del mercado. Llegar antes que los demás, si se aprovecha adecuadamente, te puede hacer ganar mucho dinero. Llegar un poco tarde te puede convertir en algo insignificante.

Esto es evidente y en nada contradice con lo comentado ayer. ¿Qué quise decir? Algo tan simple como que el desarrollo de software no hace milagros y que la agilidad es efectividad e intención. Una cosa es que un proceso tenga que cambiar para adaptarse a un nuevo contexto o para adelantarse o coger ventaja a la competencia y que eso pueda suceder en cualquier momento (cuando surge la oportunidad) y otra que tengamos que partir con unas condiciones que se sabe que no llevan a ningún sitio.

Para competir tienes que funcionar bien, si organizativamente eres un desastre difícilmente puedes competir con alguien, salvo que tengas un gran producto y/o unos grandes clientes (que en ningún caso van a ser eternos).

El software debe ir después de ese trabajo de reingeniería y a partir de ahí crecer (y cambiar, si es necesario) juntos. Si lo haces antes puede suponer una resistencia ya que tienes que repartir el enfoque entre los cambios organizativos y el desarrollo de software (perderá siempre el proyecto) y el coste será mayor.

La huida de actividades que no aporten valor al producto

Nuestro objetivo y el del cliente debe ser tratar de conseguir el mayor valor posible para el producto, lo cual requiere que se haga un uso racional de la inversión ya que de esta forma tendremos la posibilidad de obtener un mayor rendimiento de las iteraciones.

Para eso es muy importante desarrollar con intención, lo que requiere una alta implicación de todos los stakeholders del proyecto, sobre todo del responsable funcional, de las personas que colaboran con él y del equipo de desarrollo.

Sin embargo, la falta de intención no es el único factor que puede hacer que no se extraiga el mayor aprovechamiento posible de la inversión, hay otro muy importante que son las actividades de proceso o metodología, ya sea incluidas por el propio equipo de desarrollo o por la organización, que generan entregables que no aportan un valor real al producto y al proyecto.

Este mal es muy común en organizaciones que entienden que la singularidad de los proyectos es algo secundario y que todos deben tener un cuerpo de procesos común. Esto es lo mismo que pretender que una misma talla de ropa sirva para todos los componentes de una familia.

Parto de la base de que la organización necesita armonizar determinadas actividades de los proyectos, requiere recibir unos inputs necesarios para su gestión y para mantener un cuerpo de conocimiento. Soy de la opinión de que la base deben ser unos mínimos, comunes a todos los proyectos, con la mentalidad abierta a crear excepciones si fuera necesario (teniendo en cuenta que la excepción no se debe convertir en la norma) y que a partir de ahí, sea el proyecto quien mande, alcanzándose acuerdos para ampliar esa base de procesos si todas las partes entienden que aporta valor.

El problema lo tenemos cuando no se parte de mínimos y cuando se intenta encorsetar el desarrollo con actividades, sean pocas o muchas, que no solo restan flexibilidad al proyecto sino que originan costes en tareas y entregables cuyos coste de realización (y mantenimiento) son superiores al valor que proporcionan al producto y a la organización.

Rex Black. Personas sobre procesos

Se podrán implantar procesos, ser fruto de un trabajo intensivo de análisis de la organización, de sus proyectos y contexto, pero ninguno de ellos tendrá la fuerza suficiente como para cambiar la actitud de las personas.

Es cierto que enfocarán los trabajos de una determinada manera y que de alguna manera pretenderán marcar un orden, sin embargo, quienes al final lo ejecutan son personas, no lo olvidemos. Además cuanto más se intente controlar a través de los procesos, serán menos flexibles a la vez de que se espera recabar una mayor cantidad de datos, muchos de ellos de utilidad dudosa.

Si se quiere establecer un determinado marco de trabajo, vale, siempre y cuando sea flexible, permita adaptarnos a las circunstancias específicas de cada proyecto, que tenga en cuenta que las personas están sobre los procesos, tal y como indica la siguiente reflexión de Rex Black (traducción libre): «Es más importante tener involucrada a las personas adecuadas que seguir el proceso de manera exacta».

Normativas, procedimientos y procesos inmovilistas

Si las normativas, procedimientos o procesos de desarrollo de software de tu organización no cambian o lo hacen en contadas ocasiones y en aspectos de poca trascendencia querrá decir, probablemente, que nos encontramos con alguna de las siguientes circunstancias:

1) Se ha descubierto un «martillo de oro» que permite que todos los desarrollos de la organización se realicen de la forma más efectiva posible independientemente de las características propias de cada proyecto.

2) No existe ningún tipo de intención y/o política de mejora continua y no por el hecho de que se haya encontrado esa llave que abre todas las puertas, sino porque se ha creado una cierta zona de seguridad sin analizar si realmente la misma aporta o no un valor a la altura de la inversión que hay que realizar en la misma tanto para su aseguramiento como para su aplicación (sobre todo).

Aunque pueda parecer sorprendente, cuando la normativa no cambia es porque hay un poco de ambas, por un lado se cree que se ha alcanzado una solución óptima para el contexto (es importante eso porque, muchas veces, cuando se analizan cambios, la defensa del inmovilismo se centrará en que las innovaciones no son válidas para el entorno de trabajo o la naturaleza de la organización) y por otro, el proceso está tan consolidado (que no es equivalente a obtener resultados) que apetece poco hacer cambios.

Ante estas circunstancias, podemos sospechar y lo más probable es que no nos equivoquemos es que unos procesos que no cambian se convierten con el paso del tiempo en obstáculos cada vez mayores porque los proyectos sí que viven en primera instancia la incertidumbre y los cambios de contextos y si se establecen límites artificiales, ajenos a esta realidad, se estará mermando la capacidad de las personas de poder hacer frente a ellos.

Procesos, mejora y adaptación al cambio

La palabra proceso nos crea la imagen mental de burocracia y esto es así no porque nos hayamos levantado de esa manera una mañana sino porque la mayoría de nosotros ha sufrido procesos de desarrollo de software que daban lugar a un mayor coste que a un beneficio real y que estaba lleno de hitos y entregables que se convertían en un obstáculo más que solventar en el ya de por sí complejo camino que son los proyectos de desarrollo de software.

Sin embargo, por mucho que no soportemos los procesos, muy probablemente aplicamos determinadas metodologías, estrategias o prácticas que en esencia también son procesos, lo que pasa es que como muchas de ellas para nosotros son automatismos o confiamos en sus resultados, no las vemos de esa forma.

¿Qué quiero decir con esto? Pues que tal vez el problema no se encuentra en el concepto sino en su definición e implementación, en la falta de una visión orientada a su mejora continua (si un proceso no sufre ajustes algo está pasando) y a la falta de flexibilidad que se ofrece a la hora de adaptarse a las particularidades concretas de cada proyecto.

Un proceso debe aportar, no restar. Si nos pone límites ficticios que dificultan nuestro margen de maniobra quiere decir que nuestros resultados en el proyecto estarán condicionados por impedimentos que perfectamente podrían haberse eliminado, ¿no es absurdo en estos casos abogar por la ortodoxia en lugar de la solución que más conviene?.

En los proyectos de desarrollo de software intervienen infinidad de variables y es el resultado de la colaboración de una serie de personas y no hay nada más impredecible que un ser humano, por ese motivo la definición de los procesos debe tener en cuenta esa circunstancia.

No se trata de acertar a la primera sino de tener capacidad de ir adaptándolo y mejorándolo con la experiencia y de dotar a su aplicación de la flexibilidad suficiente (incluyendo excepciones) para adaptarse lo máximo posible a las necesidades concretas que requiere el proyecto.

Desde las trincheras

No me cansaré de repetir que las personas encargadas de definir los procesos de desarrollo de software de una organización deben basarse en las especificaciones de las personas que están en el día a día de los proyectos y que conocen de primera mano cuáles son los principales problemas que se producen en el contexto de la organización porque, independientemente de que cada proyecto sea un mundo distinto, sí que es cierto que hay resistencias que de alguna u otra forma afectan a todos los proyectos por igual.

Los planteamientos teóricos quedan muy bien en los libros y en reuniones de planificación en donde todo parece encajar porque se trata simplemente de escribir sobre una hoja en blanco pero la realidad es muy distinta y la elección de unas malas políticas (o incluso buenas) aplicadas de manera restrictiva, sin tener en cuenta el contexto de la organización y de cada proyecto en sí puede tener (y tendrá) un impacto negativo en términos generales y en cada proyecto en particular.

Ese impacto se materializará en unos resultados más alejados del objetivo final que no es otro que satisfacer las necesidades y expectativas del usuario porque probablemente se hayan tenido que invertir esfuerzos en tareas que no aportan un valor real al producto, al proyecto y si nos ponemos a analizar, tampoco a la organización.

El impacto económico, por tanto, tendrá una doble vertiente, productos peor terminados y que afecten a la productividad de determinados procesos de negocio y unos mayores coste de desarrollo.