archivo

Archivos diarios: octubre 19, 2011

El éxito conlleva mucho trabajo detrás pero también requiere asumir riesgos (de hecho invertir esfuerzo en conseguirlo es de por sí un riesgo, ya que lo mismo te has sacrificado para nada). Asumir riesgos implica convivir con la posibilidad de equivocarse, de fracasar y con la necesidad de volver a levantarse si caemos.

Sobre esto, Alan Curtis Kay realiza la siguiente reflexión: “Si no te equivocas al menos el 90% de las veces, es que no estás apuntando demasiado alto”.

Conseguir objetivos, obtener mejoras en tu desarrollo personal y profesional, todo ello implica convivir con la posibilidad de cometer errores, de soportar los problemas que pueden traer consigo y de aprender de los mismos.

Uno de los problemas del desarrollo de software es que el grado de criticidad de un error no es proporcional al tamaño o complejidad del sistema y tampoco lo es al propio “tamaño” del error. A veces, una incidencia provocada por una mala codificación de una serie de métodos o por una mala interpretación funcional no tiene importancia en el contexto de la aplicación y otra provocada por un mal cierre de una sentencia iterativa en un método puede tener un gran impacto.

A la hora de definir la estrategia de desarrollo de un sistema de información, en la cual también están incluidos los procesos de verificación y validación, es necesario conocer el grado de criticidad del proceso o procesos de negocio que se informatizan.

Proyectos diferentes requieren soluciones diferentes, si bien es necesario racionalizar esta aseveración ya que no podemos tener tantos procesos distintos como sistemas que se desarrollan ya que de lo contrario se complica la definición y aplicación de procesos con un ámbito de aplicación a nivel de la organización, el control de los diferentes procesos sean a nivel de proyecto o no y un aprovechamiento más óptimo de los recursos. Modelos de madurez o de gestión integral del proceso de desarrollo como puede ser CMMI tienen esto claro.

Una aplicación aparentemente simple puede gestionar datos clave para la organización, por lo que la variable de la criticidad debería estar por encima de la complejidad a la hora de seleccionar una metodología. Este es el enfoque por ejemplo de las metodologías Crystal.

No es algo que sea exclusivo del desarrollo de software. Resulta fundamental mantener el enfoque en los objetivos para llegar a conseguirlos. En el momento en que distraemos nuestra visión en lo que no importa (o importa menos) perdemos la perspectiva en lo que importa y dedicamos tiempo y esfuerzo a tareas que pudiendo ser más o menos interesantes no permiten avanzar, a través de las mismas, en la consecución de nuestras metas.

Esto en el desarrollo de software es complicado y todavía lo es más si estás trabajando en diferentes proyectos a la vez. Sin embargo que sea difícil o las circunstancias no acompañen no deben impedir en que nos centremos, en lo posible, en los objetivos que tengamos marcados tanto en conjunto como en los distintos proyectos individuales. En el momento en que bajemos los brazos o nos dejemos llevar por una deriva negativa en el proyecto lo que es muy complicado se convertirá en imposible y eso impactará en los resultados del proyecto.

En este artículo querría destacar unos de los aspectos que con más frecuencia provoca la pérdida del enfoque en los objetivos y no es otro que los bandazos funcionales de un sistema. ¿Qué quiero decir con bandazos funcionales? No me refiero a cambios funcionales en la aplicación algo que es inherente dentro de un proceso evolutivo como es el desarrollo de software sino a cambios en el alcance y a cambios funcionales bruscos y con relativa frecuencia.