archivo

Archivos diarios: marzo 3, 2012

Hay una cita de Steve Jobs que me parece rotunda: “Estoy tan orgulloso de lo que no hacemos como de lo que hacemos”.

Enfocar los esfuerzos hacia lo realmente importante, hacia aquellas tareas y proyectos que sabemos que podemos hacer bien, que nos pueden proporcionar un beneficio y eliminar todas aquellas que son una carga permitirá optimizar el rendimiento y los resultados.

Saber a qué decir que sí y saber a qué decir que no, es tan importante tanto a nivel de decisiones tácticas o estratégicas a nivel organizativo como dentro de un proyecto.

Eliminar lo intrascendente, lo que requiere un gran esfuerzo a cambio de resultados mediocres, permitirá que nos centremos en hacer mejor lo que realmente resulta importante.

Menos es más si sabemos donde orientar nuestra dedicación.

La programación defensiva es el resultado de la aplicación de una serie de técnicas que tienen como objetivo minimizar el número de errores que puede presentar un sistema de información, así como presentar una arquitectura y código que además de servir de soporte al objetivo anterior permita realizar un mantenimiento del sistema de la forma más limpia posible y minimizando o eliminando posibles efectos colaterales.

Aplicar esta técnica requiere incrementar notablemente el número de controles y comprobaciones que se realizan desde el código ya que se querrán dar respuesta al mayor número de casuísticas posibles, así como ser muy metódico en la aplicación de pruebas unitarias, pruebas de integración y pruebas de sistema desde etapas muy tempranas del desarrollo.

Todo lo anterior sin olvidarnos de las correspondientes pruebas de seguridad y pruebas de rendimiento.

Este testing será realizado tanto por el equipo de proyecto como por uno o varios equipos externos los cuales inclusos pueden estar especializados en un área concreta de testing.

De igual forma se requerirá que las especificaciones estén lo más cerradas y validadas posibles por el cliente o por el usuario, en este caso, el margen de error y la aproximación mediante la combinación feedback e iteraciones es mucho menor, por lo menos a nivel del producto en producción, donde deberá entrar con plenas garantías de acabado y funcionamiento.

También, el uso de componentes externos o de la delegación de competencias en terceros sistemas requerirá tener de los mismos unas garantías similares a la del sistema que se está desarrollando (toda cadena se rompe por el eslabón más débil).

En sistemas considerados críticos, donde se ponga en juego la vida o la integridad de las personas, así como aquellos que pueden afectar de manera sensible al funcionamiento de una organización y a su economía, la aplicación de este tipo de estrategias cobra especial sentido.

Es importante tener en cuenta que no solo es cuestión de técnicas, también es cuestión de un cambio de actitud cuando nos enfrentamos a este tipo de desarrollos, por eso es importante que un porcentaje elevado de personas que participan en estos proyectos tengan experiencia en los mismos, así como que ocupen todos los puestos críticos del proyecto.

Cuando en un proyecto hay personas que nunca mencionan el producto o los usuarios tenemos un problema.

Un problema porque si lo que estamos haciendo es un producto que van a utilizar usuarios y hay quienes nunca hablan ni de uno ni del otro es que se tiene el enfoque del proyecto en un lugar equivocado.

¿Cuáles son esos lugares equivocados? Principalmente los procesos y la contabilidad del proyecto.

El fin último de un proyecto no está ni en uno en el otro, ¿hay que tenerlos en cuenta? sí, pero no deben ser protagonistas. Los protagonistas son el producto y los usuarios, los demás tienen que ser actores secundarios.

Los procesos son un instrumento, una herramienta, una guía. Se trata de respetarlos porque armonizan actuaciones dentro de una organización y dentro de ese respeto se encuentra en no desvirtuarlos y precisamente una de las posibles causas de ello puede ser precisamente olvidarnos de lo que estamos haciendo y considerarlos un fin.

Realmente, salvo excepciones, los procesos deben mostrar flexibilidad para adaptarlos a las circunstancias, cuando en demasiados proyectos los procesos se presentan rígidos es que tenemos un problema en su definición y es necesario solucionarlo cuanto antes con el objeto de que no pierdan su utilidad y desvíe la atención del proyecto.

Se entiende que cuando una empresa realiza un servicio de desarrollo para terceros lo hace para ganar dinero, por lo que gestionar la contabilidad del proyecto es una actividad ordinaria dentro del mismo, ahora bien, cuando solo prestas atención a la pasta, dejas de prestar atención a aspectos tales como si el producto satisface las necesidades y expectativas del usuario y del cliente, si ambos están contentos, etc… Y si pierdes el enfoque en eso, terminará afectando todavía más a la contabilidad, tanto a la presente como a la futura.

En este negocio todos lo tenemos, cosas que hemos hecho de las cuales nos arrepentimos y proyectos que han fracasado. Realmente el problema no es equivocarse sino no aprender nada de ello.

Es cierto que a veces cuesta mirar atrás, sobre todo si dirigimos la mirada a lo que hemos hecho mal. Esto es así hasta que te das cuenta de que realmente no has hecho nada especial al resto, te has equivocado, como todo el mundo. Tu en unas cosas, otros en otras, pero el resultado es el mismo.

Para aprender de los errores hay que reconocer nuestra culpa en los mismos. Si pensamos que la culpa ha sido de otros o si hemos tenido mala suerte no se aprende nada porque no terminamos de reconocer que hemos hecho algo o muchas cosas mal.

En nuestra profesión convivimos con el error y con el fracaso, no somos infalibles, a veces tendremos más parte de culpa en un fracaso, otras veces menos, lo mismo sucederá con los éxitos.