archivo

Archivo de la etiqueta: proceso

El proceso no asegura nada, en el mejor de los casos, si se ajusta a las necesidades de un proyecto, te marca unas pautas que te pueden ayudar, pero nada más. Si tratas de aplicar un proceso a todos los proyectos creyendo que conseguirás el éxito en la mayoría, te estás equivocando y no lo digo yo, lo puede decir la mayoría de los profesionales del sector.

Cuando se pone por encima de todo la calidad del proceso provoca, aún sin querer, que la calidad o el valor del producto quede en un segundo plano (si lo más importante es la calidad del proceso pondrás a personas que se encarguen de vigilar eso y su objetivo será ese y no que los proyectos vayan hacia adelante), porque se entiende que si existe calidad en el proceso, es decir, si se cumplen con todas sus pautas, cualquier buen cocinero puede sacar adelante el proyecto.

Es importante el matiz del buen cocinero porque cuando la aplicación del proceso no produce los resultados esperados siempre se echa la culpa al desarrollador ya que seguramente sus entregables no son buenos o no se ha sido tan riguroso en la aplicación de tal o cual aspecto del proceso.

No se trata de que no existan procesos, ya que la organización necesitará que existan algunos para armonizar ciertos aspectos en los proyectos y para su propia gestión económica, de las personas, del conocimiento, etc… sino de tratar de buscar los mínimos imprescindibles para conseguir ese propósito, permitiendo que los equipos que participan en los proyectos puedan tener la suficiente flexibilidad para aplicar las prácticas que el proyecto necesita y de realizar los ajustes que se requieran a lo largo del proceso de desarrollo.

¿Qué es Scrum?, ¿un proceso o un marco de trabajo?, una cosa es lo que piense y otra lo que se hace realmente.

La agilidad es colaboración entre personas y capacidad de adaptación al contexto y al cambio, esto implica que en esencia y de partida no te debes “casar” con ninguna estrategia, metodología o práctica de desarrollo ya que debes seleccionar aquella que mejor se adapte a las condiciones y contexto del proyecto y cambiarla parcial o totalmente si hiciera falta por la propia evolución del proyecto (por la propia necesidad de adaptación al cambio).

Querer aplicar Scrum sí o sí no es ágil en esencia. Aplicarlo en contextos donde sí sea una estrategia favorable pero limitarte por la ortodoxia de las prácticas tampoco es ser ágil. Lo que es ágil es tener la mente abierta a elegir las prácticas que más pueden convenir al proyecto, adaptar aquellas otras que lo requieran y descartar las que no procedan.

La ortodoxia por encima de todo convertirá a Scrum en un proceso y precisamente no es eso lo que queremos. Por eso siempre insisto a las personas que se están iniciando en el agilismo en que no se limiten exclusivamente a leer o asistir a conferencias y cursos (que por otra parte serán interesantísimos y serán atajos para comprender conceptos y comportamientos que llevan tiempo y experiencia aprender y sobre todo asimilar) sino que experimenten desde las bases del Manifiesto Ágil.

Como concepto no, pero en la realidad tienen impacto en el sentido de que unas buenas normas pueden facilitar el proceso de desarrollo pero unas malas normas se pueden convertir en un obstáculo.

¿Cuáles son buenas?, ¿cuáles son malas? Depende de lo que realmente necesite la organización y de los beneficios reales que ofrezcan. Muchas veces se establecen normas y pese a que puedan tener ajustes puntuales para mejorarlas (o empeorarlas), en escasas ocasiones se hace un análisis objetivo de las ventajas que han proporcionado a la organización y a los proyectos, en su lugar se deja que siga siendo la marea la que continúe arrastrando el barco y se termina convirtiendo en una costumbre que lo mismo cuesta excesivo dinero, no solo por el coste de aplicación sino por los resultados que ofrece.

Cuando se establecen unas normas o unos procedimientos es importante tener en cuenta el contexto en el que se va a trabajar. No puedes exigir determinados procesos y/o entregables si tu economía no te lo permite o si la tipología de proyectos, clientes o proveedores requieren otro tipo de soluciones.

Por otro lado, resulta esencial contar con las personas que se van a encargar de seguir esas normas y procedimientos en el día a día porque son ellas las que están en las trincheras y si bien la organización puede necesitar determinado tipo de información o actuaciones para realizar tareas de gestión y de toma de decisiones, es importante contar con quienes conocen el contexto en que se llevan a cabo los proyectos porque ellos son los menos interesados en tirar ladrillos a su propio tejado.

Y siempre debe existir la posibilidad flexibilizar las normas o existir excepciones cuando el proyecto o la circunstancia lo aconseje, siempre y cuando esté debidamente justificado. Cuanto más excepciones se requieran sobre la norma, es lógico pensar que algo está fallando en la misma. Sin embargo, quienes velan por su cumplimiento tienden a pensar que el problema está en las personas.

Los procesos dan un orden, armonizan actuaciones. Sobre esta base no podemos decir que, en esencia, sean perjudiciales. De hecho pese a que he pasado del amor al desamor con respecto a ellos siempre comento que siguen siendo necesarios pero como background en el que tengan un núcleo mínimo, que sean flexibles y admitan excepciones justificadas.

Cuando se cree que el éxito está tras los procesos es cuando se cae en el error. De ser cierto que aseguran el éxito bastaría con seguir su receta para conseguir desarrollar productos software que satisfagan las expectativas de los usuarios. ¿Alguien cree que si fuera así de fácil existiría hoy día la crisis del software?.

No niego que determinados procesos puedan ser efectivos en condiciones muy específicas pero no creo que en procesos que se consideran martillos de oro o solucionadores universales para todo tipo de desarrollos en todo tipo de contextos.

Cuando un proceso no funciona (en enfoques de desarrollo de software dirigidos por procesos) siempre se le suele echar la culpa al desarrollador: “el proyecto ha ido mal porque no has seguido bien el proceso o porque no se han ejecutado adecuadamente los hitos” o a que el proceso no está lo suficientemente desarrollado lo que da lugar a que se entre en un mayor nivel de detalle y se convierta en una solución más rígida que, por supuesto, funcionará igual de mal o peor (que es lo más posible) que la versión anterior.

La mayoría de los procesos son ad-hoc, lo cual en sí no es malo ni bueno (generalmente las implementaciones de metodologías ágiles suelen ser ad-hoc) pero sí que se debe ser prudente por parte de quien o quienes lo han hecho de considerarlo soluciones universales por mucho que sean el resultado (o se venda así) de años de feedback en proyectos reales.

¿Por qué lo digo? Pues porque la mayoría nos hemos encontrado con las siguientes situaciones: Proyectos que han salido adelante cuando no se ha seguido a rajatabla un proceso que provocaba bloqueos y resistencia y proyectos que han fracasado o que no han tenido el éxito esperado precisamente por seguir procesos rígidos que no se adaptaban a la realidad de los mismos.

Es cierto que no es justo echarle toda la culpa a los procesos cuando algo sale mal (no podemos escondernos tras ellos) pero sí que es verdad que si te exigen trabajar de una manera y no existe flexibilidad tu margen de maniobra queda reducido y se trabaja mucho peor que si tuvieras los pies y las manos liberados.

En muchas ocasiones cambiar la dinámica de un proyecto o de una organización requiere realizar grandes cambios estructurales sin embargo hay casos donde se pueden producir mejoras sustanciales con la inclusión de cambios no tan significativos.

Tal vez la maquinaria tiene piezas muy buenas pero faltan y/o sobran algunas, lo que impide que el conjunto funcione de manera adecuada.

Comenta Peter Senge que: “Solo cambiando la forma en que interactuamos podemos compartir visiones, compartir conocimientos y se establecen nuevas capacidades para actuar de manera coordinada”.

La reflexión de Senge se centra en la comunicación y en los procesos que son piezas que pueden atrancar o engrasar la maquinaria si bien es extensible a otros aspectos de carácter organizativo, incluidas las personas.

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.

Una de las mayores críticas que se tiene hacia los agilistas es que se considera que están obsesionados por el proceso, hasta tal punto de contravenir el siguiente principio del Manifiesto Ágil: “Valorar a los individuos y su interacción, por encima de los procesos y las herramientas”.

No estoy de acuerdo con esa crítica porque hace una generalización que creo que no se ajusta a muchas realidades. Si bien tiene un trasfondo real y es el hecho de que se considera agilistas a muchas personas por el mero hecho de trabajar con metodologías ágiles y como he comentado ya en diferentes artículos: “la agilidad es cuestión de actitud y no de metodología“.

La aplicación de metodologías ágiles es una aproximación pero depende mucho del enfoque con el que se trabaje con las mismas y de quiénes intervengan en el proceso.

Si no entiendes o conoces el trasfondo de lo que significa ser ágil la respuesta no te la va a dar ninguna metodología y si te encierras en ella, probablemente estés dando pasos en el sentido equivocado.