archivo

Archivos Mensuales: febrero 2013

Incluso en situaciones de crisis y en donde parece que no hay vuelta atrás la confianza entre las personas implicadas en el proyecto es lo único que mantiene la nave a flote mientras todavía existe alguna posibilidad de solucionar los problemas.

La confianza agiliza todo. Si la relación entre las personas funciona todo es más fácil. Sin confianza solo queda la profesionalidad pero resulta mucho más inestable porque resulta muy complicado dejar a atrás los sentimientos y las sensaciones si tratas con alguien en quien no confías sobre todo si hay mar de fondo.

Se puede partir de relaciones en las que ya hay una experiencia previa y es el punto de partida para bien o para mal. Si es para bien es que se ha establecido en trabajos anteriores una relación de confianza, eso es positivo porque tendrás mucho camino andado ya que no tendrás que invertir tiempo en construirla y sí en mantenerla porque no olvides que la confianza una vez cimentada dura para siempre.

Es frágil y recomponerla una vez rota complicado que no imposible (hay que analizar por qué se ha roto ya que muchas veces se trata de malentendidos o situaciones en las que no se quería provocar de manera deliberada un prejuicio).

He aprendido mucho más de mis errores que de mis aciertos y no creáis que ha sido fácil porque para ello hay que asumir que uno se equivoca y que si algo sale mal hemos tenido responsabilidad, tal vez la máxima, de que haya salido así.

A todos nos gusta vernos guapos en el espejo por eso cuesta tanto asumir que hemos fallado, que nos hemos equivocado o que hemos fracasado.

Pero no hacer caso a la realidad no la cambia solo te condena a volver a repetir el mismo error más adelante y así una y otra vez.

Para levantarse hay que darse cuenta que nos hemos caído. Caerse se caen todos, no hay nadie infalible, nadie.

Asumir tus errores, aprender de ellos no garantiza que no vuelvas a equivocarte, somos seres humanos, pero al menos estás sobre aviso de lo que hiciste mal y de lo que te llevó a esos malos resultados.

Soy de la opinión de que tenemos miedo a la autocrítica no solo porque nos guste salir bien en la foto sino porque solemos ser muy duros con nosotros mismos una vez que decidimos dar ese paso, cuando eso te pase recuerda que esto se hace para levantarnos con más fuerza y no para quedar rotos en mil pedazos.

Norm Kerth lo resume todo en la siguiente reflexión (experto en retrospectivas en proyectos de desarrollo de software): “La autocrítica es dura pero creo que podemos aprender más de nuestros fallos que de nuestros éxitos”.

Comenta Pete McBreen que: “Con un ciclo corto de feedback es fácil aprender qué funciona y qué no”.

Los usuarios no tienen claro que es lo que quieren hasta fases muy avanzadas del proyecto. Al principio del mismo tienen ideas generales (por mucho que digan que lo tienen clarísimo ya que una cosa es la teoría y otra la realidad) relacionadas con el problema que quiere solucionar o con el proceso que quiere informatizar.

Si esperamos demasiado, si el paso a producción se eterniza o si el usuario no tiene posibilidad de trabajar con el sistema que se está desarrollando nos encontraremos con que su feedback vendrá muy tarde precisamente cuando el presupuesto esté prácticamente agotado y cuando el coste el cambio sea importante. No me invento nada, lo hemos vivido (y vivimos) prácticamente todos.

Hay que intentar conseguir ese feedback cuanto antes, tiene más intención si el sistema está en producción (aunque sea solo con una parte del sistema en funcionamiento) ya que ahí se puede apreciar el impacto real que tiene en el negocio, es decir, se puede ver qué ha funcionado y qué no.

Si son necesarias varias iteraciones para tener pasar el producto a producción (aunque sea parcialmente) utilicemos otras estrategias (que requerirán una colaboración y un compromiso fuerte del usuario) para obtener ese feedback al final de cada iteración.

Tu responsabilidad no es solo entregar un componente o un producto. Entregar puede ser algo “sencillo” (es evidente que hay un trabajo detrás que ha podido llevar consigo un esfuerzo y desgaste considerable sacarlo adelante), lo complicado es entregar algo con calidad y que satisfaga las expectativas que se tenían puestas en él y que pueda funcionar de manera adecuada en un entorno de producción.

Si nos centramos en entregar corremos el riesgo de olvidar que el objetivo en sí no es ese (si bien en algún momento hay que hacerlo) sino desarrollar un software de calidad y que tenga utilidad.

Es cierto que es importante entregar pronto para de esta forma tener cuanto antes el feedback del usuario pero esta entrega rápida debe ser acorde a unos objetivos acordes a la duración del sprint y a la velocidad que puede llevar el equipo de desarrolladores. Por tanto, entregar pronto no es incompatible (no lo debe ser) con entregar bien, es más, si no se entrega bien se rompe el ritmo de trabajo.

Vale, hemos entregado y hemos superado las expectativas funcionales, no funcionales y de calidad, ¿hemos terminado con ese segmento de software? No hasta que se hayan corregido las incidencias o bugs que se hayan detectado ya sea en la fase de testing o incluso en el entorno de producción. La responsabilidad debe llegar hasta ahí, debemos ser responsables del trabajo que hemos realizado tanto para bien como para mal.

¿No hay límite de tiempo? Sí que lo hay y es el período de garantía pactado para el producto. Tu tienes la responsabilidad de corregir las cosas que has hecho mal en ese período pero el cliente también debe tener la responsabilidad de hacer uso del producto. ¿Qué es lo que pasa muchas veces? Que la aplicación se entrega pero tarda mucho en ponerse en marcha.

Trabajamos en organizaciones y por desgracia deciden por nosotros hasta dónde podemos llegar, por lo que podemos entender que nuestra responsabilidad es corregir esos errores pero tener prohibido hacerlo por parte de quien nos paga. Esa responsabilidad de corregir errores en período de garantía no es cosa solo de desarrolladores también es de su organización sin embargo sus gestores (muchos de ellos desarrolladores) tienden a quitarse de en medio tras la entrega porque les supone un coste adicional que en la mayoría de los casos no tenían previsto en sus cuentas (pese a que son conscientes de que el producto no va a llegar perfecto a producción).

Pues amigo, hay que estar para lo bueno y para lo malo y asumir tus responsabilidades. Si no lo haces se pierde la confianza que hay depositada en tu organización o en ti y eso puede perjudicar más (mucho más) que el coste de asumir tus compromisos.

Una forma distinta de denominar un concepto antiguo como es el desarrollo de software desde diferentes ubicaciones en la que, potencialmente, no importa donde esté cada integrante del equipo de proyecto.

Engloba a las factorías de software en sus diferentes visiones: offshore, nearshore y onshore, pero también a proyectos en los que intervienen diferentes equipos de trabajo situados en ubicaciones distintas o un mismo equipo en el que parte de sus integrantes no se encuentra localizado en las oficinas de trabajo.

Se suele ensalzar las virtudes de este modelo, como la posibilidad de ahorrar costes o la polinización cruzada entre equipos de diferentes regiones o culturas que permite crecer a ambos con las aportaciones del otro. Y también la posibilidad de contar con colaboraciones de especialistas que se pueden encontrar en cualquier rincón del mundo.

Entre sus defectos se encuentra la dificultad de establecer encuentros cara a cara (y no me vale la videoconferencia, no es lo mismo, ya que es diferente mirar a los ojos de una persona que hacerlo a la imagen que de esa persona aparece en un monitor) y que la comunicación, en general, resulta más complicada (sobre todo si entran en juego diferentes husos horarios e idiomas).

¿Creo posible este modelo de funcionamiento? No es algo que yo deba creer o no porque es evidente que existe, de lo contrario las comunidades de desarrollo de productos de software libre no existirían y es más, fuera de ese ámbito, es casi de lo más habitual hoy día, lo que pasa es que como esa distribución del personal se encuentra generalmente dentro de la misma ciudad no reparamos en ello.

Es muy normal que el product owner esté en una localización, el responsable técnico del cliente en otro, que cuente con colaboradores que están en otro sitio y que el equipo de desarrollo realice sus trabajos desde otra ubicación. Entre ellos se definen unas reglas de funcionamiento que junto a las comunicaciones de toda índole: persona a persona, teléfono, mensajería instantánea, correo electrónico, etc…, así como de las herramientas de soporte al proceso de desarrollo, tratan de minimizar la distancia.

Pero por muchas reglas y por muchas herramientas que se definan o utilicen, son las personas las que harán que este modelo funcione o no, porque tienen que hacer por comunicarse, por entenderse, por interaccionar y por colaborar.

No obstante no debemos olvidar que pese a todo la distancia tiene un coste por muchos puentes que existan o se tiendan, lo que hay que valorar por tanto, en cada caso, en función del tipo de proyecto y las personas, cuál es la fórmula más rentable.

Cuando se documenta es necesario tener presente el período de caducidad del documento. Si hay documentos que se pretenden que sean la referencia del producto desde diferentes puntos de vista: funcional, operativo, arquitectura, diseño, etc… es importante tener en cuenta hasta dónde llega nuestra capacidad de ir manteniéndolos conforme el producto evoluciona.

Ser demasiado ambicioso implicará muy probablemente que buena parte de esa documentación deje de actualizarse y por tanto esté caducada a efectos prácticos (incluso se puede dar el caso de que la misma perjudique más que ayude). Sin embargo resulta difícil encontrarnos con casos en donde un documento se tache como caducado siendo la única referencia la fecha real de elaboración o aprobación del mismo (si es que efectivamente aparecen por alguna parte).

La documentación debe ser la realmente necesaria (que no es lo mismo que la teóricamente necesaria) y acorde a lo que podamos soportar. Sobre esa premisa cada cual dentro del enfoque que considere más adecuado para el proyecto que decida qué es lo que realmente necesita (salvo que existan procesos donde más allá que de un mínimo te impongan una serie de hitos documentales).

Creo que la siguiente reflexión de Bertrand Meyer (profesor universitario y autor francés, experto en programación orientada a objetos y creador del lenguaje Eiffel) resume el contenido de este artículo: “Hay una situación peor que no tener documentación y es tener documentación incorrecta”.

Interesante la reflexión que Martin Fowler realiza en su libro “Refactoring: Improving the Design of Existing Code” (traducción libre): “Al compilador no le preocupa que el código sea feo o limpio. Pero cuando cambiamos el sistema, hay una persona involucrada y ahí sí que importa. Un sistema mal diseñado es complicado de modificar”.

En última instancia somos las personas las que tenemos responsabilidad sobre la deuda técnica no hay nadie más entre nosotros y el código. Es cierto que podemos apoyarnos en generadores de código y en frameworks pero es decisión de la organización, del departamento o nuestra elegirlos y en muchos casos de su evolución. Son importantes en cuanto a que te evitan la realización de tareas mecánicas y en cuanto a que marcan un camino común en el desarrollo pero hay que tener en cuenta que es importante que el código generado sea de calidad porque es posible que en un futuro el equipo que se vaya a encargar de seguir evolucionando el producto no disponga de ese generador (desgraciadamente es algo que casi nunca se tiene en cuenta).

Hay software como Sonar que utilizado de manera conjunto con un software de integración continua nos permite conocer al día el estado de la deuda técnica pero se trata solo de métricas que nos pueden alertar de situaciones anómalas (o potencialmente anómalas) al final habrá una persona (no necesariamente un gestor ya que el programador también tiene mucho que ver en esto) que tomará la decisión de refactorizar o no determinadas partes de la aplicación.

Lo más recomendable es que la propia refactorización sea parte del proceso de desarrollo que surja como algo natural y que nos apoyemos en software para conocer si hay módulos en donde el trabajo de refactorizar no ha sido suficiente o no ha sido bueno.