archivo

Archivos diarios: abril 9, 2011

En muchos de mis artículos hago referencia al respeto. El motivo es que a lo largo de mi trayectoria profesional he podido comprobar que es fundamental para mejorar como persona y como profesional.

Estos son algunos aspectos que considero interesantes de cuidar en nuestro día a día laboral, para crear o mantener el respeto que se tiene hacia nosotros:

1) Por regla general consideramos que nuestro trabajo es el más importante, urgente, crítico y complejo. Es conveniente entender que esto también lo piensa tu compañero, por tanto no intentes imponer el tuyo sobre el de los demás sin que existan causas objetivas que lo justifiquen.

2) Trata bien a la gente. Trata a los demás como quieras que te traten.

3) Reconoce tus errores y no tengas reparo en pedir disculpas.

4) Sé equitativo, si trabajas con diferentes equipos de trabajo, no exijas a uno trabajos, comportamientos y rendimiento que no le exijas a los otros.

5) Comparte el éxito y también el fracaso.

6) Si puedes echar una mano a tus compañeros y a los componentes de tus equipos de trabajo en tareas que no son propiamente tuyas y tienes tiempo y conocimiento para hacerlo, hazlo.

7) El respeto requiere respetar, es complicado que te respete alguien al que no respetas.

El ciclo de vida en cascada necesita de condiciones óptimas para producir buenos resultados, por ese motivo el número de proyectos de desarrollo de software que se han desarrollado y se desarrollan siguiendo esta estrategia sufren en sus carnes los preceptos de la crisis del software:

– Incumplimiento sistemático de los plazos de entrega.
– Desajuste entre el presupuesto inicial estimado y el presupuesto final del proyecto.
– Baja calidad del producto final: Incumplimiento de especificaciones y dificultad de mantenimiento.

Como es lógico, este tipo de impactos crece en función del tamaño y la complejidad del proyecto, así como de la inestabilidad de los procesos que se informatizan y de la organización que los sustenta.

¿Por qué? La respuesta es simple:

– Se realizan análisis extensos que por muy bien que se hagan requieren una importante capacidad de abstracción por parte de los usuarios.

– La extensión de los análisis y el diseño provoca que se necesite tiempo suficiente por parte del área usuaria y del cliente para realizar la revisión de los entregables.

– Al desarrollarse el sistema o gran parte del mismo de una sola vez, desde el momento en que se especifican los requisitos hasta que se obtienen los primeros resultados ha pasado el tiempo suficiente para que:

1) Existan cambios en los procesos que se han informatizado. Esto requerirá ajustes a lo largo del proceso de desarrollo que en muchas ocasiones se darán tan al final que dará lugar a productos limitados en funcionalidad y con inestabilidad.

2) Cambio en la prioridades en la organización. Antes era importante sacar adelante este sistema e invertir tiempo y dinero en él, ahora las prioridades son otras y eso puede provocar una menor atención al proyecto y un proceso de implantación más complejo.

3) Cambio en los directores usuarios y en los usuarios que han participado en el proceso de definición del sistema: Lo que parecía tener importancia para uno, para otro puede que no lo tenga, lo que le gusta a uno, será diferente para otro.

4) Cambio en la dirección técnica del proyecto.

5) Cambios en las directrices técnicas y/o de arquitectura en el departamento TIC del cliente.

Es necesario huir de los ciclos de vida en cascada puros, así se ha desarrollado de manera tradicional y eso hace que esté muy extendido. Los proyectos de desarrollo de software requieren otro enfoque, más real, más apropiado a la infinidad de contingencias que se producen a lo largo del desarrollo.

El principio de Pareto y los ciclos de vida iterativos e incrementales van de la mano.

Si con un 20% del esfuerzo se pueden alcanzar el 80% de los objetivos de un proyecto y se ha demostrado que funciona en numerosos casos, estamos ante la base para pensar que un sistema desarrollado siguiendo una metodología iterativa e incremental puede salir hacia adelante, ya que con las primeras iteraciones se podría llegar a tener un sistema donde sus principales y más críticos aspectos funcionales estén en funcionamiento y de forma aceptable. Después tocará ir añadiendo más utilidades e incluyendo mejoras a lo ya desarrollado.

Hay que tener en cuenta que lo comentado en el párrafo anterior requiere de situaciones ideales: que no existan contratiempos, proyecto bien dirigido, equipo de proyecto con actitud y aptitud, usuarios que colaboren y se impliquen, pocos errores y detectados lo antes posible, unos buenos procesos de acompañamiento al desarrollo, la selección de una metodología adecuada, etc…, no obstante y aún sabiendo que pocos proyectos de desarrollo se realizan en circunstancias ideales, el camino a seguir para que los proyectos salgan cada vez mejor y alejemos el fantasma de la crisis del software es la utilización de metodologías donde el desarrollo sea iterativo e incremental.

Todos nosotros contamos con una capacidad de trabajo y energía para cada jornada, no siempre es la misma porque no todos los días son iguales.

Son muchos los factores que pueden afectar a nuestro rendimiento pero una de ellos es, sin duda, la carga de trabajo que llevamos acumuladas. Si el día anterior eché doce horas, tendrá consecuencias en el rendimiento que tenga hoy, si hoy echo otras doce, tendrá consecuencias en el rendimiento que tenga mañana y serán mayores que las que tuve hoy.

Si ese esfuerzo se acumula en el tiempo la capacidad productiva de los trabajadores afectados disminuirá y no solo eso, muchos de ellos terminarán buscándose otros horizontes profesionales ya que una carga excesiva de trabajo sostenida en el tiempo tendrá consecuencias en la vida personal de cada uno. Tal vez si la recompensa económica o de desarrollo profesional es proporcional al esfuerzo realizado se consiga aguantar más sin que la productividad se resienta considerablemente, teniendo en cuenta que eso será a cambio de importantes sacrificios personales. Lo que pasa es que no todo el mundo está dispuesto a afrontar esos sacrificios y lo que es más común, difícilmente te encuentras con organizaciones que premian en proporción a tu esfuerzo y compromiso y todavía es más difícil conseguir esa proporcionalidad si además te encuentras en los niveles inferiores de la jerarquía.

Es razonable que existan períodos de tiempo donde existan picos de trabajo y que por muy productivo que se sea se necesiten echar más horas. Eso es asumible (aunque injusto si no se premia al trabajador en el caso de que ese sobreesfuerzo haya traído beneficios de algún tipo para la organización), lo que no es asumible es que se viva en un continuo pico de trabajo.

Las jornadas laborales deben ser racionales, no por echar más horas se produce más. El efecto es que se distribuye la energía entre el número de horas que hay que tener la mente en el trabajo o que estás ligado al trabajo (lo mismo tienes una jornada de ocho horas, pero el tiempo de comida entre la jornada de mañana y tarde hace que estés al ligado diez u once horas).

Quien es productivo y quiere serlo, pondrá los medios para conseguir los mejores resultados posibles en el tiempo disponible para hacerlo. Quien no lo es, casi que da igual el tipo de jornada laboral que haya o el número de horas que trabaje. No se trata de cantidad sino de calidad.

Todo requiere un tiempo, solo que la mayoría de las veces no sabemos cuánto se necesita. No conocerlo da lugar a que se abandone antes de tiempo o que la impaciencia provoque que se modifique la planificación realizada para conseguir los objetivos que nos habíamos marcado.

No se trata de esperar indefinidamente ya que no siempre se alcanza lo que se quiere pero sí de analizar el por qué de las causas que han podido provocar que en el tiempo X que llevamos o que nos habíamos fijado para alcanzar nuestras metas, no hayamos logrado nuestros objetivos. Tras ese análisis se puede decidir si continuar con nuestra estrategia o variándola, redefinir los objetivos o abandonarlos y pensar en otro tipo de retos.

Lo más importante de todo es tener la conciencia de que todo requiere un tiempo de gestación, en el cual mediante la aplicación de una serie de acciones que hemos llevado a cabo en el mismo y teniendo siempre presente lo que queremos, se alcanzarán o no (porque nos hemos podido equivocar) los objetivos.

Lo que no se puede pretender es que todo se consiga de la noche a la mañana, hay que tener paciencia y trabajar de manera adecuada.

Si se conoce a un proveedor o se tiene experiencia en el desarrollo de proyectos con él, se conocerán las virtudes y defectos de algunos de sus técnicos. Esto puede provocar que cuando se vaya a abordar un nuevo proyecto exista la tentación de decir con quién quieres trabajar.

Es normal que se quieran abordar proyectos con personas en las que confías, pero no hay que olvidar que no se trata de designar a personas de tu organización, sino que lo pretendes es designar a personal del proveedor en el proyecto y eso tiene sus riesgos.

El principal de ellos es que si alguno o varios de los técnicos que has seleccionado no funcionan de manera adecuada en el proyecto, ¿qué responsabilidad le puedes pedir al proveedor cuándo has sido tú quién los ha designado?. De esta manera el proveedor cuanta con todas las cartas para justificar muchas actuaciones que hayan ido mal en el proyecto y eso pone al cliente en posición de desventaja en posibles negociaciones que discurran a lo largo del proceso de desarrollo.

Sí que puedo entender que se recomiende que tal o cuál técnico participe en un proyecto orientado a bolsa de horas pero en los servicios con presupuesto cerrado es conveniente que sea el proveedor el que elija los técnicos ya que si corre riesgos y se le van a pedir responsabilidades en el caso de que las cosas vayan mal, es importante que tenga libertad para poder organizar su equipo de trabajo.

Es posible que el proveedor presente diversos Currículums y te permita elegir. En este caso, estaríamos en la situación en la que el proveedor es el que elige el equipo de trabajo, ya que él ha sido el que ha realizado la criba previa y entiende que los diversos técnicos que ha elegido pueden llevar a cabo el proyecto de manera adecuada (y también acorde a los intereses del proveedor).