archivo

Archivos Mensuales: noviembre 2013

Cuando se trata de evolucionar un producto sin consolidar ese avance tenemos que plantearnos si efectivamente se trata de tierra ganada.

Una cosa es la experimentación, otra el desarrollo iterativo incremental o la incertidumbre y otras bien distinta es dar pasos rápidos que lo que van dejando atŕas es tierra quemada.

Experimentar es necesario, es una de las bases del desarrollo de software, realmente es lo que se hace cuando se implementa lo que creemos que hemos entendido de lo que cree que quiere el usuario. Esa diferencia se va paliando a través del feedback, salvo que se piense que se va a acertar a la primera, algo poco probable por muy buena voluntad que pongan las partes.

El desarrollo iterativo incremental refleja esa evolución del producto, tratando de consolidar lo ya realizado a la par de que se van incluyendo nuevas funcionalidades. No es tan importante el concepto como la aplicación de un enfoque adecuado, siendo recomendable pensar en pasar de estados más simples a otros más complejos.

La incertidumbre es lo que rodea al desarrollo de software y también a los negocios. Se está sometido a tantos factores que el contexto puede cambiar de manera lo suficientemente sensible como para que impacte en el proyecto. No se trata de huir de la incertidumbre sino de entenderla como algo inherente, por lo que se trata siempre de estar adaptado al cambio.

Dar pasos rápidos con el objeto de obtener un feedback necesario para obtener una orientación del producto es una buena estrategia. El problema es cuando se confunde ir rápido con la toma de atajos. A veces viene bien cogerlos pero cuando dejan de ser una excepción tenemos en un problema porque probablemente estemos sacrificando estabilidad y deuda técnica (capacidad, a fin de cuentas de adaptación al cambio) por más funcionalidad, que por otro lado hay que ver si es necesaria y que nos restará capacidad de maniobra en el caso de que sea necesario cambiar de enfoque.

Por todo eso, resulta necesario analizar si efectivamente los pasos que se van dando en el proyecto dejan tierra ganada.

Si eres el responsable de una determinada infraestructura tecnológica que sabes que funciona, en la que tienes un soporte de calidad y en la que cualquier incidencia de cierta gravedad (y a veces no hace falta ni eso) con la misma te puede costar tu puesto de trabajo o incluso problemas mayores, ¿te arriesgarías al cambio?.

Imagina que la decisión depende, al menos, en primera instancia de tí. Delante tuya tienes la posibilidad de ahorrar entre un 50 y un 75% los costes pero también tienes la incertidumbre de que se trata de una tecnología nueva. En ese momento puedes poner encima de una balanza el ahorro y en la otra el coste que tendría para tu organización un fallo de la nueva tecnología (que probablemente sea muy superior al ahorro) y el deterioro que sufriría tu carrera profesional. ¿Hacia que lado crees que se inclinará la balanza?.

Incluso si se decantase por el lado de la innovación, es muy posible que el siguiente paso sea exponer los cambios ante otro grupo de personas que solo ven y entienden de números, ¿en qué porcentaje de casos crees que decidirán asumir el riesgo?.

La innovación llega al mundo empresarial porque hay personas, ya sea el responsable de un departamento, un comité ejecutivo o un consejo de administración que deciden asumir riesgos. En aquellos casos en los que la relación coste/beneficio/riesgo sea favorable y evidente el viento soplará a favor, en aquellos otros casos donde la incertidumbre sea mayor el viento soplará en contra, a lo que se sumará probablemente el hecho de que los proveedores de la solución actual, viendo amenazada su posición, no te pondrán las cosas fáciles.

Es muy probable que te soliciten casos de éxito y referencias y eso requiere un cierto tiempo y una inversión importante porque esos primeros pilotos es posible que te cuesten dinero porque si el cliente tiene una cierta entidad minimizará su riesgo en el sentido de que no querrá hacer un desembolso importante por algo que lo mismo no implanta, comenzará con una implantación paulatina en áreas no críticas y/o que estén muy controladas, querrá un soporte de una calidad similar a la que tuviera ya contratada con su proveedor habitual de servicios y una corrección pŕacticamente inmediata de las incidencias.

Incluso podrás encontrarte con situaciones en las que incluso te soliciten determinado tipo de certificaciones antes de hacer el piloto y/o contratarte tu tecnología.

Pero también existirán posibles clientes que encuentren tu solución como una oportunidad o como una salida (ante, por ejemplo, la imposibilidad de mantener determinados costes), poniéndote las cosas más sencillas y siendo más tolerantes, teniendo en cuenta que el tiempo y las oportunidades no serán ilimitadas.

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.

El nivel de adaptación a un contexto es un arma de doble filo. Por un lado cuanto más adaptado estés y más explotes esa adaptación más capacidad tendrás, si haces las cosas bien, de tener un mayor nivel de efectividad, sin embargo, y por otro lado, tu capacidad de adaptación a otros entornos irá mermando conforme pase el tiempo porque empezarás a sacar conclusiones erróneas y pensar que has descubierto la piedra filosofal del desarrollo de software y que ya sabes que hacer para que todo proyecto tenga éxito, de esta forma, te irás cerrando en una forma de concebir el desarrollo de software y las relaciones con las personas e irás descuidando aspectos tales como la mejora continua y la formación.

Por ese motivo, personas que obtienen grandes resultados en un determinado contexto pueden fracasar en el momento en que varían las condiciones que dominan.

Por ejemplo, personas que pueden hacer una extraordinaria labor en contextos donde es fundamental tener grandes habilidades sociales pueden fracasar en contextos donde es necesario tener un mayor nivel técnico, y viceversa.

Se necesitará, por tanto, tiempo de adaptación y mientras eso sucede, tu tasa personal de errores y fracasos crecerá porque será a partir de ahí donde terminarás extrayendo el conocimiento necesario para crecer (si realmente asumes tus errores, los analizas y aprendes).

Pero un cambio de contexto no conlleva a hacer tábula rasa y que nada de lo aprendido te sirva, es más, ese fondo o bagaje profesional te servirá más de lo que piensas, el problema es que se trata de aplicar ese conocimiento de la misma manera independientemente del contexto, en lugar de ponerte a analizar cómo puedo aplicar lo que ya sé a estas nuevas circunstancias.

Mientras el producto no esté en producción y, por tanto, no empiecen a llegar incidencias con diferente grado de prioridad y en cualquier momento, puede resultar relativamente sencillo mantener un determinado nivel de predecibilidad en los sprints, de manera que salvo errores importantes en las estimaciones se ejecutarán la mayor parte de las historias de usuario o incluso todas ellas.

Sin embargo, en el momento en que empiezan a llegar incidencias, la cosa cambia. Si no tienes capacidad de “reserva” para afrontarlas tocará tomar determinadas decisiones y para ello nos podemos hacer una serie de preguntas:

– ¿Dejo las incidencias para el siguiente sprint?.

Dependerá de la urgencia de las mismas y de lo que queda para que finalice el sprint, habrá veces en que se pueda aplazar al siguiente sprint, otras en las que incluso se dejará para más adelante y otras donde la criticidad haga que tengas que ponerte con ellas nada más conocer de su existencia.

– ¿Anulo el sprint e inicio uno nuevo en el que ya tenga en cuenta estas incidencias que han llegado?.

En este caso dependerá del número de incidencias y de su complejidad (además, como es lógico de su criticidad). Si vamos a tener que dedicar gran parte de la capacidad a trabajar en ellas, mantener el sprint definido deja de tener sentido. ¿Es la solución definir un nuevo sprint? Sí, pero en situaciones de inestabilidad, tal vez lo mejor sea que tengamos más peso de Kanban que de Scrum.

– ¿Cambio alcance del sprint de manera que sustituyo la realización de determinadas historias de usuario a cambio de las incidencias?.

Puede ser bastante práctico pero dependerá de las incidencias que lleguen porque si terminan desvirtuando el sprint, tal vez lo mejor sea cambiar de enfoque.

– ¿Introduzco las incidencias como parte del alcance del sprint, retrasando la finalización del mismo?.

La respuesta es similar a la anterior y dependerá también del contexto y situación del proyecto, de las incidencias y de lo que pueda aportar a la productividad de los equipos y a la efectividad de los trabajos mantener inamovibles la fecha de finalización de lo sprints.

Lo que quiero que saquéis como conclusión es que no es posible formular una solución que valga para todo. Tenéis que analizar qué os conviene más y siempre con una mentalidad abierta, más allá de la ortodoxia de la aplicación de una determinada estrategia o metodología.

No obstante, puede ser interesante, aún no siendo tampoco una solución universal, dejar siempre capacidad libre del equipo para atender a estas incidencias, de manera que no sea necesario mover el alcance del sprint salvo situaciones de saturación. Esa capacidad variaría en función de la estabilidad del producto y de las implantaciones (y de su importancia) que se estén realizando en ese momento.

¿Y si no se usa esa capacidad? Esa capacidad sobrante se puede utilizar para muchas cosas, desde tareas propias de infraestructura, programación por pares, realizar actividades opcionales sobre determinadas historias de usuario, etc…

No solo se trata del síndrome de la última versión sino que también nos lo encontramos en cualquier evolución del software (o en un desarrollo desde cero) cuando desde un principio se quiere tener una primera versión operativa del producto con demasiadas funcionalidades (digo demasiadas y no todas).

En mi opinión, la primera versión operativa debe tender hacia el menor número de funcionalidades necesarias, buscar el pragmatismo y la simplicidad aún a costa de tener una versión que tal vez no termine de satisfacer completamente al usuario (hay que tener en cuenta que, en cualquier caso, la decisión sobre la línea de desarrollo del producto recae en el usuario y de él dependerá hasta que punto se deja asesorar y qué considera como mínimo imprescindible).

A partir de esa versión toca iterar y seguir evolucionando el producto, siempre con la simplicidad como referencia.

¿Por qué lo simple como referencia? Porque es más sencillo llegar así hacia una solución más compleja, gracias al feedback obtenido por los usuarios y por el aprendizaje que se va obteniendo a todos los niveles mientras se desarrolla el producto y también porque en el caso de descubrir que el enfoque no es adecuado se ha desperdiciado menos esfuerzo en tareas que se podían haber evitado.

Fracaso y éxito son dos caras de la misma moneda y el borde que los separa es muy fino.

El fracaso te puede llevar al éxito si se adquiere conocimiento a través de él y después lo sabemos aplicar y adaptar a un nuevo contexto y a un nuevo proyecto. A veces la transición entre el fracaso y el éxito es rápida como también lo puede ser la vuelta a atrás si los cimientos no son sólidos.

Con un conocimiento o aprendizaje consolidado (y nuestras heridas de guerra) estaremos cada vez más preparados y con más argumentos para afrontar con éxito un proyecto y tratar de que ese éxito pueda perdurar y extenderse a otros, teniendo en cuenta siempre que, aunque creamos haber encontrado una receta infalible, nada te asegura que en tu siguiente proyecto vayas a volver a fracasar.

Precisamente y conociendo lo anterior, se trata de acortar el tiempo para conocer si una determinada estrategia resulta adecuada o no, ya que de esta forma, si esa estrategia fracasa podemos tratar todavía, dentro del mismo proyecto, de aprovechar ese feedback para realizar los ajustes que sean necesarios.

Cuando más frecuente sea ese feedback, cuanto más se experimente (siempre con intención), más oportunidades tendremos de ir sumando conocimiento y aplicarlo dentro del margen de maniobra que nos permita la disponibilidad presupuestaria. Tendremos, por tanto, sumas de éxitos y fracasos dentro del mismo proyecto y podremos ajustar de mejor manera la cantidad de esfuerzo necesaria para saber si un determinado enfoque, estrategia o práctica realmente ofrece resultados positivos o no.

¿Qué finalmente se nos agotan los recursos económicos y fracasamos? Será necesario afrontarlo, nada es gratis y el conocimiento adquirido no ha sido una excepción, es probable que nos afecte a nuestra propia estima pero también a la confianza que terceros han depositado en nosotros, sin contar con el desgaste personal que habremos sufrido. Ante esa situación solo queda volverse a levantar e intentarlo de nuevo, tal vez en otra nueva organización, tal vez en otro nuevo proyecto y teniendo siempre presente lo que hemos sido capaces de aprender, con el objeto de que, todo el esfuerzo invertido anteriomente no sea en vano.

La idea que tienen los product owners o los responsables funcionales del software que quieren no es más que algo abstracto, es más, hasta que el producto empiece a materializarse y cobrar una cierta entidad es más acertado decir que su idea inicial es lo que creen que quieren porque hasta que no se empiece a experimentar no saldrán a la superficie comportamientos y funcionalidades deseados pero que estaban ocultos o el caso contrario, comportamientos y funcionalidades que se creían efectivos y útiles y que no son ninguna de esas dos cosas.

De ahí la conveniencia de aplicar desarrollo iterativo incremental y con más razón en aquellos casos donde el sistema se prevea complejo y/o los responsables funcionales no terminen de verlo claro.

Pero desarrollo iterativo incremental es una idea muy general, si definimos ciclos largos hemos fraccionado algo el problema pero probablemente será insuficiente y será mayor la cantidad de desperdicio generado.

También es cuestión de enfoque, mejor siempre partir de soluciones simples consolidadas y validadas para a partir de ahí crecer hacia otras más complejas.

¿Se trata de obtener una versión rápida a toda costa? Versión rápida a toda costa es algo demasiado general, sí que resulta interesante cuanto antes obtener un feedback del usuario pero también que el desperdicio generado sea el menor posible (por lo que los ciclos de desarrollo deben hacerse con intención, de no hacerse así estaremos haciendo desarrollo por permutación y eso tiene un coste importante) y que no perdamos de vista que para seguir generando nuevas versiones es necesario que las modificaciones a realizar sobre el producto se puedan hacer en unos plazos razonables, por lo que en el momento en el que la deuda técnica supere unos determinados umbrales perderemos esa capacidad de respuesta rápida o por lo menos no tan rápida, efectiva y económica como sería deseable.

Tal vez al principio consideres que lo más importante es desarrollar una versión aunque sea prototípica para verificar si el producto va por el camino deseado y que determinados factores como la calidad del código son secundarios. Al final es algo que tendrás que valorar tú en base al contexto en el que estás desarrollando.

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.

Para Miyamoto Musashi: “El resentimiento y la queja no son apropiadas ni para uno mismo ni para los demás”. Son negativas porque nos hacen perder mucha energía y tiempo, además de restarnos concentración y desviar nuestro enfoque a otros lugares o situaciones. Afectan directamente a nuestra productividad y a la calidad de nuestro trabajo.

Pero somos humanos, estamos llenos de emociones, resulta muy complicado ponerle freno al resentimiento o evitar la protesta cuando entendemos que hay una situación que no es justa.

¿Qué hacemos?, ¿es la solución guardarlo todo dentro? No lo es porque si lo haces terminarás minimizándote como persona y perdiendo confianza, lo que a su vez y a la larga dan lugar a otro tipo de problemas.

Lo primero que hay que hacer es evitar las reacciones en caliente porque nos restan objetividad y porque nuestra respuesta será de máxima intensidad y probablemente nos arrepintamos de eso. No es fácil. Quiero matizar que sí que se puede tratar el problema sobre la marcha, pero si sabes o eres consciente de que tratarlo en ese momento se puede escapar de las manos, lo mejor será esperar un poco.

En frío, habrá circunstancias que directamente dejemos de lado porque tras nuestra reflexión y con el paso del tiempo habrán perdido importancia. Otras no, incluso es posible que todavía nos molesten más.

El siguiente paso debería ser analizar la situación desde un punto de vista profesional (entendiendo lo que es nuestro negocio y nuestro entorno, porque de esta forma habremos situado el problema en su contexto adecuado) y pensar si existe alguna manera de darle una solución ya que lo mismo con una conversación o con un café es suficiente. Tratar de arreglarlo es lo mejor, porque en la mayoría de los casos se hace borrón y cuenta nueva.

Si no es posible arreglarlo y necesitas desahogarte, hazlo, pero ten prudencia con quien lo haces, no te vale todo el mundo, solo personas en las que confíes absolutamente. Y una vez hecho eso, trata de poner la situación en un segundo plano hasta que termine siendo insignificante, de manera que tu la controles a ella y no ella a ti. El tiempo es muy bueno para eso.