archivo

Archivo de la etiqueta: Mary Poppendieck

El liderazgo en una organización, en un departamento o en un proyecto proporciona la fuerza y constancia necesaria para superar los obstáculos, adaptarse al cambio y conseguir la mejora continua. La fuerza y la constancia no son condiciones suficientes pero sí necesarias.

El liderazgo requiere creer en los objetivos que se han marcado. Es fundamental. Su efectividad requiere también de que el resto de personas implicadas (o una gran mayoría de ellas) crean también en que la dirección que se va a tomar es correcta, teniendo en cuenta que lo mismo no es la solución más cómoda y que espera una dura tormenta antes de que empiecen a salir de entre las nubes los primeros rayos de sol.

Por tanto, el liderazgo requiere la creación de nuevos lideres que se sumen a la causa y que ayuden con su impulso a conseguir los objetivos y conseguir nuevos adeptos a la causa.

Mary y Tom Poppendieck precisamente entienden el liderazgo de esa manera: “Una organización tiene que evaluar el liderazgo como la capacidad de desarrollar líderes” y tiene su razón de ser, ya que es muy difícil que una sola persona por mucho carisma, capacidad de trabajo e insistencia que tenga pueda provocar el cambio (sí que puede ser el detonante pero se requerirá de una intensidad superior a la que esa persona puede aguantar y gestionar).

La palabra líder se dice muy pronto y muy fácil, después, en las trincheras, todo es más complicado y ahí es realmente donde se demuestra esa capacidad tanto cuando hay problemas como cuando las cosas vienen mejor dadas.

La tentación, muchas veces motivada por las circunstancias, es obviar la mejora de la factura técnica del producto, para centrarnos en corregir errores y en incrementar las funcionalidades.

El usuario siente la calidad del software con lo que ve: cumplimiento de sus expectativas de funcionamiento y buen rendimiento y disponibilidad, por eso pondrá resistencia a invertir tiempo en reducir la deuda técnica.

No debemos olvidar que desarrollamos para el usuario y él es quien tiene la última palabra, lo cual no quita que le expongamos la ventaja que tiene la realización de este tipo de tareas, como una inversión que permita no solo incrementar la capacidad de trabajo que puede abordar el equipo, sino además, reducir la posibilidad de efectos colaterales que provoquen errores cuando y donde menos los esperamos.

De serie, un desarrollador debe tener en cuenta estas prácticas y tenerlo en cuenta a la hora de definir su velocidad. El tiempo que se puede dedicar a esto puede ser prácticamente ilimitado porque todo es susceptible de ser mejorado, por ese motivo, ese tiempo de más sobre las buenas prácticas de programación cotidiana es el que se tiene que discutir con el cliente.

Comenta Mary Poppendieck: “La refactorización continua no es opcional. Si se elige no refactorizar se elige no pagar la deuda técnica que con el tiempo demostrará que la posibilidad de fracaso aumenta”.

La clave es mantener la deuda técnica bajo control y esto requiere un esfuerzo desde la programación de base como de las tareas adicionales de refactorización, de acuerdo siempre con las necesidades de quién paga, el cual debe estar siempre informado de las consecuencias que tiene realizar desarrollos sobre un software de baja calidad.

Mary Poppendieck realiza la siguiente reflexión: “No tome decisiones irreversibles demasiado pronto, retrasa las decisiones de diseño todo lo que sea posible, de manera que cuando las tengas que tomar, lo hagas con la mejor información disponible para hacerlas correctamente”.

Tiene razón, pero lo que pide es difícil. Requiere que el Product Owner tenga una visión sólida del producto, conozca bien el negocio y tenga el apoyo por parte del equipo de desarrollo sobre qué funcionalidades una vez construidas son más costosas de modificar.

Poppendieck, lo que recomienda es que se desarrolle con intención, sabiendo lo que se hace, para de esta forma reducir el número de iteraciones. Aún así, la especulación a veces es inevitable porque el responsable funcional no tendrá claro siempre si la solución que propone es la mejor o qué reacción va a tener el conjunto de usuarios ante las mismas.

El objetivo es conseguir cada vez un mayor valor para el producto con una inversión ajustada a ese incremento. A veces tendremos más éxito que otras, porque equivocar nos equivocaremos ya que el desarrollo del producto es evolutivo y en él nos daremos cuenta no solo de nuevas funcionalidades que son necesarias, sino de algunas ya implementadas que son mejorables.

Por ello, siguiendo las recomendaciones de Poppendieck, el desarrollo debería comenzar por lo más prioritario y dentro de ello por lo que se tenga más claro en ese momento, si se tienen dudas sobre una funcionalidad y se prevé un coste de modificación alto (por sí misma o por su impacto sobre terceros desarrollos), mejor esperar, si se puede, un poco más.

Comenta Mary Poppendieck que: “Si quieres saber lo que el cliente quiere, dale lo que crees que quieren y escucha lo que te tienen que decir al respecto”.

Esa es la esencia del feedback: el usuario da una especificación, ejecutas según la interpretación que has hecho de la misma, obtienes un resultado y el usuario opina sobre el mismo, solicitando aquellos ajustes que consideres necesario.

En el caso de que desarrolles un producto y no te bases en especificaciones directas, el proceso es el mismo.

Recuerda que el sistema que desarrollas no es para ti. Tal vez las decisiones del usuario no te gusten, tal vez pienses que hay otras soluciones más adecuadas, si es así, exponlas, porque lo mismo ese punto de vista no se ha tenido en cuenta, pero no las impongas o manipules para que ese sea el camino elegido. Todos tenemos derecho a equivocarnos, pero más quien paga.

El objetivo es incrementar el valor del producto y la mejor forma de hacerlo es centrarnos en quiénes van a ser sus usuarios porque son ellos los que van a tener que convivir con él todos los días.

Se tiende a ir por el camino más corto que no es otro que conseguir facturación del cliente sea como sea: con funcionalidades que no necesita y/o en actividades que no generan valor. Esta cultura se ha consolidado en muchos proveedores de desarrollo de software, practicándola durante muchos años y no ha hecho otra cosa que hundir y desprestigiar nuestra profesión.

Sí, se ha ganado dinero con ella, pero la burbuja explotó hace años y ahora con la crisis económica nos está castigando con fuerza.

Se presiona para conseguir contratos, para conseguir beneficios, es normal, las empresas viven de eso, pero esa presión no debe justificar la elección del camino equivocado.

Soy de la opinión de que si se crea valor al cliente, si tiene retorno de la inversión, volverá a llamar a la puerta. Si en lugar de derrotas, los clientes contaran sus inversiones en software por victorias, no se lo pensarían tanto a la hora de tratar de conseguir ventajas mejorando o solicitando el desarrollo de nuevas aplicaciones.

Mary Poppendieck nos invita a que: “invirtamos el tiempo en lo que añada valor real al cliente”, creo que es un buen consejo.

Existe una infinidad de caminos que pueden dar lugar al producto final. Solo algunos de ellos permitirán conseguir uno que tenga éxito.

Recorrer cada camino tiene un coste y cada uno de ellos tiene un coste diferente.

Por tanto lo ideal es encontrar el camino que permitiéndote conseguir un producto final de éxito tenga el menor coste posible.

Eso es un ideal pero no olvidemos que lo realmente importante es el valor del producto y en consecuencia su capacidad de amortizar la inversión.

Como desarrolladores tenemos la obligación de tener la mente abierta, de pensar que existen más soluciones que la que tenemos en la cabeza y que la más adecuada lo mismo te la proporciona quien menos te lo esperas. En un proyecto no gana quien consigue llevar más soluciones al producto final sino quienes tienen toman la decisión de sumar para que el proyecto tenga éxito. No se trata de una carrera de egos sino de un trabajo en equipo.

En un desarrollo iterativo incremental, el resultado de la iteración muestra una solución concreta que puede ser buena o mala, que puede ser mejorable o no, pero es la que es. En base a la misma se puede tomar la decisión de seguir evolucionando el producto o realizar modificaciones sobre la misma. No hay nada que deba ser inamovible si nuestro objetivo es el valor del producto final (dentro de las restricciones con las que tengamos que convivir en el proyecto).

Mary y Tom Poppendieck realizan la siguiente reflexión sobre este tema: ” Ua iteración debería ser considerada como una demostración de una posible solución y no ser considerada como la única solución”.

No es malo, antes al contrario, es muy positivo tener buenos deseos, ya que supone una declaración de intenciones. El problema lo tenemos cuando las intenciones se quedan solo en palabras, algo que todos sabemos se produce con demasiada frecuencia.

Es fácil hablar y escribir, mucho más difícil actuar.

Para Mary Poppendieck: “Un enfoque disciplinado para la resolución de problemas hace que un equipo pase de los buenos deseos a los nuevos conocimientos a las contramedidas específicas y los resultados permanentes”.

Y es cierto que la actuación requiere disciplina pero también determinación, mucha determinación.

Muchos proyectos fracasan por la falta de determinación y disciplina, perdidos en un sinfín de reuniones, en papeles mareados entre las partes u olvidados como adjuntos en correos electrónicos y en discursos teóricos que pretenden conquistar el mundo pero que tienen menos fondo que una caja de cerillas.