archivo

Archivos Mensuales: marzo 2011

El día a día es el principal obstáculo para conseguir nuestros objetivos. Estar apagando fuegos nos hace perder nuestra perspectiva.

Dado que es prácticamente inevitable dejar a un lado los tareas que surgen en nuestros proyectos todos los días es necesario dejar un hueco para evaluar el grado de cumplimiento de las metas que te permiten llegar a tus objetivos, así como para simplemente recordar a dónde quieres llegar.

Para conseguir los objetivos es necesario tenerlos presentes siempre, independientemente de las circunstancias laborales o personales que te ocupen en cada momento.

Hilary Hinton “Zig” Ziglar es un conocido autor y conferenciante americano. Es autor de numerosas citas, de las cuales voy a seleccionar una de ellas:

“Es tu actitud y no tu aptitud, la que determina tu altitud”.

El talento sin actitud no es nada, es como tener una importante suma de dinero en el banco y no utilizarlo. Con unos niveles de aptitud que superen el umbral a partir del cual se pueda realizar adecuadamente una actividad profesional, una buena actitud puede hacer que personas que lo mismo tienen menos talento consigan unos resultados excepcionalmente mejores que otros que tienen mejores aptitudes y además tendrán un crecimiento que les permitirá reducir las distancias con quienes ya tienen un determinado nivel de talento e incluso superarlos.

En muchas ocasiones cuando hemos señalado un punto en un mapa hemos optado por poner un punto gordo, para señalar la posición aproximada de un elemento en el mismo, es decir, hemos buscado una solución basada en la generalización que si bien puede resultar de utilidad en algunos casos, puede resultar inútil y contraproducente en otros, ya que por ejemplo, la utilidad del punto gordo se reduce en función del tamaño del mismo y de la escala en que se dibujo.

Muchos gestores utilizan esta misma estrategia para tratar a sus recursos humanos, aplican el punto gordo, generalizan y aplican una determinada política a un conjunto de personas que ni por asomo han tenido un comportamiento similar en términos de productividad y resultados.

¿Qué circunstancias les hace aplicar el teorema del punto gordo? Principalmente el desconocimiento real de lo que hace cada cada persona y porque para ellos es lo más fácil, ya que creen que es justo tratar a todo el mundo por igual y eso lo es en algunos aspectos, pero no lo es en muchos otros.

Si te esfuerzas en el trabajo, aplicas estrategias para intentar se lo más productivo posible, obtienes resultados y sin embargo te tratan igual (o peor) que otros que no tienen ni tu compromiso, ni tu dedicación, ni tus logros, terminas tarde o temprano por desmoronarte y tiene consecuencias en tu trabajo (te cansas de hacer el canelo y se reduce tu productividad o directamente buscas otros horizontes profesionales) y/o en en ti mismo (aguantas tu nivel en el trabajo, a cambio de tener al angelito malo recordándote todos los días, ¿por qué narices te implicas si tu organización no lo hace contigo?).

Políticas generalistas van en contra de lo productividad y sin embargo son las más extendidas. Así nos va.

Por regla general, las empresas de desarrollo de software hacen uso de un determinado framework y de generadores de código, con el objetivo de estandarizar en cierta forma la construcción del sistema de información y solo incluyen variaciones sobre los mismos en proyectos concretos donde el cliente exige algún tipo de especificación distinta.

Si se quiere mejorar en productividad, el camino es ese (si bien, son necesarias muchas más variables para que la mejora de la productividad realmente sea efectiva).

Los generadores de código hacen repetible determinadas funcionalidades, como por ejemplo, la gestión de tablas maestras, la autenticación, etc… Por otro lado, aunque no se utilicen ese tipo de productos resulta aconsejable que salvo que se indique lo contrario por parte del cliente, se implementen determinadas funcionalidades de forma repetible entre un sistema de información y otro, así como dentro de un mismo sistema (no resulta lógico, salvo situaciones excepcionales, que la estrategia de diseño y construcción del mantenimiento de una tabla maestra sea distinta a la de otra).

Por este motivo, no resulta de utilidad invertir esfuerzo en el diseño de casos de uso, en repetir tanto el diagrama de casos de uso, como la descripción de los mismos, en elementos que van a tener un comportamiento similar, como por ejemplo, la gestión de tablas maestras. Eso dentro de un mismo proyecto, pero para proyectos donde se utilicen estrategias similares, bastará con tener dentro del proyecto base de la herramienta CASE la especificación de los casos de uso que pueden ser repetibles (y después realizar los ajustes que sean necesarios).

La clave de todo esto es racionalizar los esfuerzos de manera que se inviertan donde realmente merezca la pena.

En muchos casos resultará suficiente con dibujar el diagrama de casos de uso y realizar la descripción de los mismos a través de sus caminos principales y alternativos. Dado que, por regla general, este entregable no es común en los proyectos de desarrollo de software (pese a lo que aporta una vez que se llega a entender su utilidad), podemos estar más que satisfechos con tener este producto con dicho alcance.

Una especificación adicional a los mismos, es la especificación para cada caso de uso de una precondición y una postcondición. Es importante señalar que las mismas están a nivel de caso de uso y no a nivel de sus escenarios (camino principal y caminos alternativos).

Tanto la precondición como postcondición se especifican en lenguaje natural.

¿Qué es una precondición? Es el estado en el que se tiene que encontrar el sistema para que se pueda ejecutar el caso de uso. En muchos casos una precondición coincidirá con parte o con toda la postcondición de otro caso de uso.

¿Qué es un postcondición? Mientras queda claro que todo caso de uso tiene un único estado inicial, un caso de uso puede tener diferentes estados finales, potencialmente, tantos como caminos se definan en el mismo. Por tanto la postcondición de un caso de uso es un listado de todos los posibles estados finales en los que se encuentra el sistema tras la ejecución del caso de uso. Como la definición es en lenguaje natural, en muchos casos se opta por utilizar sentencias condicionales para especificar las condiciones que hacen que el estado final sea uno u otro.

¿Considero imprescindible la definición de precondiciones y postcondiciones? Desde mi punto de vista no lo es, aunque puede ser interesante su uso como elemento de depuración de los casos de uso (te hace pensar qué condiciones son necesarias para que el caso de uso se pueda llevar a cabo y cómo queda el sistema una vez que se haya realizado) y también para facilitar su comprensión.

Tendemos a evitar los obstáculos buscando el camino más sencillo para tratar de conseguir nuestro propósito. Supongo que cada cual tendrá su experiencia en esto, pero mi recomendación es que no te saltes a tu interlocutor salvo que no tengas otra posibilidad y además sea absolutamente necesario (hay veces que queremos conseguir algo que es prescindible o que existe otra alternativa que pueda resultar válida o satisfactoria).

Saltarse al interlocutor directo crea desconfianza no solo con esa persona, con quien probablemente además tengas que seguir trabajando en un futuro, sino con el resto de personas que estén al tanto de la situación ya que ellos pueden pensar que pueden ser los siguientes.

La confianza es para mi uno de los pilares en las relaciones laborales y profesionales, cuando se pierde, todo se complica y pasas a ser, en el mejor de los casos, simplemente uno más para esa persona que ha perdido la confianza en ti.

Existen muchas cosas que valoro de los integrantes de un equipo de proyecto:

– Que sean profesionales. Un profesional no abandona a su equipo, hace sobreesfuerzos en momentos puntuales para sacar el proyecto adelante en los plazos previstos y además intentar dar el mejor acabado posible a cada tarea que realiza.

– Que sepan trabajar en equipo.

– Que sepan mantener un buen ambiente entre ellos.

– Que sean comunicativos. Es decir, que sean capaces de compartir información, ya sea buena o mala para el devenir del proyecto con el equipo que forma parte de él, incluida la dirección del mismo.

– Que sean disciplinados con las instrucciones de la Dirección del Proyecto y de sus superiores y también con las normativas de calidad establecidas.

– Relacionada con la anterior: Que se minimicen las situaciones en las que haya que repetir dos veces la misma instrucción para que sea ejecutada.

– Que sean proactivos.

– Que tengan conocimientos técnicos en la arquitectura y tecnología con la que se va a desarrollar.

– Que tengan interés en entender la funcionalidad del sistema que tienen que desarrollar.

– Que tengan un trato profesional con el cliente, con los usuarios, etc…

Pero además de todas ellas, valoro muchísimo la capacidad de aportar al proyecto y al equipo de proyecto, conocimientos, habilidades, ideas, que van más allá de la situación en la que se encuentre el proyecto y de la información que se ha obtenido del mismo.

Si se contrata a una empresa para realizar un desarrollo y esta a su vez encomienda esa tarea a un equipo de proyecto, lo normal es que el Director de Proyecto por parte del cliente especifique cómo se debe desarrollar el proyecto a nivel metodológico y de calidad, los plazos, los ritmos, el resultado final que espera , etc, etc, etc… y que además realice un seguimiento y control del del mismo a todos los niveles y dinamice los distintos procesos de su desarrollo.

Sobre esas bases que establecen un marco de trabajo y de desarrollo, y se establece y se pone en marcha una dinámica de trabajo. La propuesta de valor del equipo de proyecto consiste en aportar soluciones a los problemas técnicos y funcionales que se vayan produciendo en el transcurso del proceso de desarrollo, en contraposición con esto está en que el equipo de proyectos en lugar de solucionar problemas los cree o bien que se limite en la mayoría de los casos a solicitar soluciones al cliente.