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.

Anuncios

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.