archivo

Archivos Mensuales: enero 2014

Para Peter Drucker: “El emprendedor siempre busca el cambio, responde a él y lo explota como una oportunidad”, es curioso, porque precisamente es ese cambio el que asusta a la mayor parte de los gestores.

Asusta porque en la situación actual se sientes cómodos, se encuentran en su zona de seguridad, y eso es así, por mucho que los números empiecen a indicar que si se sigue actuando de la misma manera, la organización se va a ver más y más perjudicada.

La solución no es esperar a que amaine el temporal porque con independencia del contexto económico en el que nos encontremos, las condiciones, las reglas del juego varían: aparecen nuevas necesidades por parte de los consumidores, surge nueva competencia perfectamente adaptada al contexto actual (y con capacidad de poder adaptarse a cambio) a la que hay que sumar a la competencia tradicional que ha sabido reaccionar y ajustarse a la nueva situación.

Porque como también decía Peter Drucker: “La única cosa que sabemos sobre el futuro es que será diferente”.

Ante esa situación, no resulta recomendable centrarse en un negocio, cliente o producto exitoso, es decir, sí, sácale todo el partido que puedas pero no te olvides que si no sigues trabajando en innovación, en entender qué quiere el mercado y si tu organización no está estructurada para adaptarse al cambio que, sin duda, aparecerá, todo lo que hoy es ventaja, mañana no te servirá para nada.

Me ha parecido muy interesante la siguiente reflexión de Michael Bolton: “Los tests que se han diseñado para confirmar una teoría predominante tienden a no revelar información nueva”, y es precisamente por eso, porque se centran en confirmar una hipótesis, sin entrar a estudiar otros aspectos que podrían resultar relevantes.

De hecho, muchos desarrolladores creen que han realizado un testing suficiente y después a las primeras de cambio otra persona, generalmente con más conocimiento funcional, que hace uso de las funcionalidades detecta defectos en poco tiempo, ¿por qué? Su conocimiento del negocio y de las expectativas del usuario es parcial y muchas veces ese testing se centra en aspectos de bajo nivel cuando la solución hace aguas a un nivel más alto.

Esto se extiende al plan de pruebas, entregable muy típico en contextos en los que un equipo independiente realiza un QC (control de la calidad), ¿realmente se confía en que pasando el plan de pruebas el sistema está libre de defectos?, y no solo por el hecho de que muchos de ellos son complicados de detectar, sino porque el plan de pruebas se centra en una visión concreta, en una teoría predominante por parte de la persona o personas que han colaborado en su elaboración. Sí, tal vez confirmemos que la teoría se cumple, pero si dejamos el testing en ese punto, muy probablemente estemos dejando escapar defectos que pueden tener un impacto importante cuando lleguen a producción.

Es por ese motivo que el testing debe ser considerado desde diferentes puntos de vista, en el que se combinen testing automático y manual, en el que intervengan diferentes personas, diferentes perfiles, en el que lo “reglado” se combine con lo exploratorio y en el que se tenga muy claro, qué nivel de defectos puede permitirse el producto y cuánto se está dispuesto a invertir para conseguirlo.

Partamos de una base cierta, cuanto más próximo se corrija un defecto desde el punto en que se originó menor será su impacto y menos costosa será su corrección.

Ante eso, podríamos tomar la decisión de que todo defecto se corrija en el momento en que se detecte y hacerla extensiva a todo el conjunto de desarrolladores.

De hecho esa práctica es acertada, si bien, habrá veces donde tocará decidir.

Supongamos que se detectan una serie de defectos en el proceso de paso a producción de un producto y que las vueltas a atrás son costosas, en tiempo y en esfuerzo, ¿decidimos siempre dar marcha a atrás?, pues depende, tocará evaluar el impacto del defecto y el coste que tiene volver a hacer una nueva entrega (que nadie garantiza que sea limpia y que no lleve consigo nuevos defectos), de esta forma, habrá veces que convenga seguir hacia adelante (lo cual no significa ignorar los defectos detectados) y otras en donde la versión no alcance el mínimo necesario para llegar a producción.

La decisión de si el defecto se debe corregir o no debe quedar en manos del responsable de definir la línea de desarrollo del producto que no es otro que el Product Owner, el cual debe asesorarse por personal técnico con el objeto de obtener información suficiente para tomar la decisión que mejor convenga al producto.

Para Donald Norman: “Los objetos bien diseñados son fáciles de interpretar y de comprender ya que contienen pistas visibles de su funcionamiento”.

Un código fácil de leer y de entender en entornos altamente colaborativos como son los equipos de trabajo ágiles resulta esencial. También lo es para otros tipos de enfoques.

No es sencillo, se requiere tiempo, conocimientos y experiencia, también nos podemos apoyar con herramientas que nos ayuden a aplicar buenas prácticas y también se requiere ser sistemático y creer en los beneficios que aporta hacer el trabajo de esta manera, de lo contrario se te pondrá muy en cuesta arriba refactorizar, tanto tanto, que no lo harás.

Hacer esto bien requiere dedicarle el tiempo que necesita, cuando estamos en proyectos ligados a plazos y los recursos disponibles son muy limitados, se convierte en objetivo ejecutar todo el trabajo posible y se deja de lado la calidad del código ya que en esos momentos conceptos como la deuda técnica no se encuentran entre las prioridades del desarrollador. Es cierto que es contraproducente ya que una deuda técnica elevada hace más pesado el proceso de desarrollo pero cuando el fuego te está llegando a los pies solo piensas en correr.

Por ese motivo creo mucho más en el valor del software que en las agendas, un buen software requiere del tiempo y de las personas necesarias para hacerlo, sin equilibrio la calidad del software sufre (también la cuenta de resultados del proyecto).