SCRUM como proceso base para implementar software, plantea algunas ceremonias, se orienta al valor haciendo primero lo mas importante y asumiendo el alcance como un ente variable, pero cuando la responsabilidad del diseño del producto se deja solo en manos del Product Owner, llevamos a los equipos de desarrollo nuevamente a la construcción de funcionalidades, preocupándose por mantener una velocidad estable en el tiempo y por cumplir los compromisos establecidos en las ceremonias.
Tradicionalmente hemos separado las fases de análisis y de diseño del software, percibiendo el análisis como la definición funcional o el comportamiento que el software tendrá en ejecución, y pensamos en el diseño como la estrategia tecnológica que nos permitirá implementar dichas funcionalidades. Muchas veces el Product Owner se dedica al análisis en conjunto con el negocio y el equipo de desarrollo al diseño y la implementación. Ha cambiado la forma como nos comunicamos pero seguimos estando separados.
La verdad es que el diseño de un producto va mas allá de la forma como se estructura el código fuente o de los servidores y maquinas donde será desplegado para servir las peticiones de los usuarios. Un software es un generador de capacidades de negocio y en este orden de ideas el diseño del producto incluye las funcionalidades que deberán ser implementadas en torno a conseguir el impacto que se requiere.
Un equipo de desarrollo de software podría ser mucho mas efectivo si trabaja de forma conjunta con el Product Owner, teniendo una clara visión de lo que se quiere lograr y apoyando al negocio en su definición. La verdad es que las personas del negocio no saben diseñar soluciones, ellos conocen a la perfección lo que hacen y lo que quieren lograr y a partir de estos deseos definen una serie de funcionalidades que en su opinión les permitirán conseguir eso que desean. Pero esas definiciones corren el riesgo de quedarse en simples funcionalidades que no articulen un verdadero producto.
Si nuestra posición como desarrolladores se centra en la codificación, en conocer mucho sobre lenguajes de programación, patrones de diseño, arquitectura y tecnología, entonces será suficiente recibir como insumos un conjunto de cosas por hacer. Pero si nuestro objetivo es la generación de nuevas capacidades de negocio, e impactar la calidad de vida de las personas haciendo su trabajo mas fácil a través de la adopción tecnológica, entonces debemos ir mucho mas allá, conocer los objetivos que quiere lograr nuestro cliente (Persona o empresa) y velar porque los productos que entreguemos sean de la calidad mas alta e impacten de la forma mas positiva en estos.
Para llegar a este punto debemos cambiar la forma como medimos el resultado de lo que hacemos. Normalmente el trabajo creativo no tiene un resultado tangible e inmediato como si lo puede ser la construcción de código fuente, pantallas y funcionalidades. El análisis creativo que conlleva a diseñar productos que impacten a los clientes incluso mas allá de lo que ellos mismos esperan, requiere dejar de producir de forma constante, a grandes cantidades y pasar a producir menos con mayor efectividad. Es decir el foco del equipo deja de ser la productividad y pasa a ser la efectividad en la generación de impacto.
Construir mas funcionalidades no se traduce en generar mas impacto, al contrario: Mayor cantidad de funcionalidades conlleva a tener mas código fuente, este a su vez incrementa la complejidad, lo que aumenta los tiempos de mantenimiento, reduciendo de esta manera la rapidez con la que se generan mas capacidades al software existente, llevando finalmente a tener negocios menos competitivos.
Mary y Tom Poppendieck en su libro The Lean Mind Set, hablan de esto en detalle y plantean lo siguiente: "Asking software developers to write more code is like asking authors to put more words in their books or to teachers to put more children in their class rooms. When creativity and learning are important, focusing on quantity makes none sense" Mary y Tom Poppendieck
En este orden de ideas preguntarse como las metodologías ágiles incrementarán la productividad de los desarrolladores puede ser absurdo, pues nuestro objetivo es desarrollar las funcionalidades esenciales que los usuarios amarán y no mas que eso.
La pregunta ahora es ¿Como las metodologías ágiles me ayudan a lograr equipos mas efectivos?
Referencia The Lean Mindset: Ask the Right Questions
1 comentario:
En mi opinión, una gran diferencia entre la efectividad y la productividad es que la segunda no necesariamente brinda las mejores soluciones de negocio que verdaderamente impacten en gran medida el proceso de una compañía. Adicionalmente, una gran productividad puede ser un proceso vicioso e, incluso, monótono que lleve a los desarrolladores a hacer lo mismo día trás día, limitando los desos de crear, investigar e innovar. Yo como desarrollador de software sueño con un desarrollo de software que se vea como una disciplina artística, en la cual podamos dejar volar nuestra imaginación y así poder lograr cosas cada vez más grandes y de mejor calidad. La motivación nos trasporta al éxito. Ser efectivos sencillamente es dar en el blanco en el momento preciso.
Publicar un comentario