archivo

Archivos diarios: agosto 30, 2011

¿En cuántos líos nos hemos metido por no dedicar el tiempo suficiente a pensar en un problema o en una funcionalidad o por no decir que no? Y no lo digo por el hecho de tomar una decisión equivocada sino por el simple hecho de tomar alguna diferente a no abordar en un proyecto determinadas problemáticas y funcionalidades que se escapan de los objetivos principales del mismo.

Invertir esfuerzo en algo que no parece llevar a ningún sitio no parece sensato, sin embargo nuestro afán por ejecutar trabajo y dejar satisfecho a clientes y usuarios nos lleva a meternos por caminos que, a priori, tenemos fundadas sospechas de que no llevan a ningún sitio.

¿Es compatible esto con satisfacer las expectativas de usuario? Por supuesto que sí. De la misma manera que no podemos desarrollar un producto de espaldas al usuario, tampoco el usuario puede orientar el mismo sin tener en cuenta a los técnicos. Se trata de consensuar una solución factible en tiempo y presupuesto, que cumpla las expectativas del usuario (por lo que la opinión de los mismos, como es lógico es la que más peso tiene).

A veces será más sencillo alcanzar ese consenso, otras no y en las que no probablemente o el cliente o el proveedor (o ambos) tendrán que asumir las consecuencias económicas de un alcance que supera al esfuerzo previsto inicialmente.

No hace mucho leí una cita de autor desconocido que describe muy a las claras lo que supone la documentación en un desarrollo clásico o en cascada (podría ser extensible a otros tipos de ciclos de vida, pero en este es donde resulta más acusado su impacto), siempre y cuando se tenga expectativas diferentes de la misma a la que realmente debe tener, que no es otra que la de ser un instrumento para el proceso de desarrollo y no una serie de entregables que acompañan al producto pero que no se utilizan realmente.

La cita es la siguiente: “¿Por qué esperamos que la documentación describa con precisión un producto cuando la documentación se hizo en primer lugar?”.

Insisto mucho en la necesidad de no perder el enfoque en el que debe ser el objetivo real de cualquier proyecto de desarrollo de software que no es otro que satisfacer las expectativas del usuario. Tras ese objetivo hay otros muchos, unos más importantes (como por ejemplo una deuda técnica aceptable, que el proyecto salga en coste y plazos, etc…) y otros que lo son menos.

Habrá proyectos donde tengamos un mayor margen para la creatividad, incluso para la investigación, pero habrá otros donde no será posible. Eso es necesario entenderlo, a veces tendremos proyectos donde podremos aprender más (técnicamente porque en cada proyecto, incluso el más monótono, siempre se gana experiencia) y en otros donde nos tengamos que limitar a hacer nuestro trabajo.

Sobre este aspecto Joshua Bloch, ingeniero de software, empleado de Google y experto en Java (del que es autor de diversas funcionalidades de la plataforma, además de varios libros) realiza la siguiente reflexión: “Nos encanta los rompecabezas. Pero tenemos que atemperar este amor por el conocimiento con el hecho de que estamos resolviendo los problemas reales de personas reales”.

Un exceso de control en el trabajo realizado por tu equipo de proyecto no es bueno, pero no prestar ninguna atención casi que es peor.

Como suele suceder con casi todas las disciplinas la clave está en el equilibrio, hay que respetar los espacios y dar confianza al equipo pero sin perder la noción del estado real del proyecto y de la verificación de que se está cumpliendo el procedimiento y normas especificados en el proyecto.

Todos los equipos y no todos los proyectos son iguales por lo que esa situación de equilibrio será diferente en cada caso, habrá ocasiones donde sea necesario un mayor control y en otras uno menor.

Hacer un seguimiento del trabajo que se está haciendo implica tomar decisiones cuando las cosas no se están haciendo correctamente y hablar con el técnico o técnicos que se han desviado de la pauta marcada para que vuelvan a ellas. Este es principal problema de muchos jefes de proyecto, en muchos casos callar demasiado por no molestar a sus compañeros y en otros hablar más de la cuenta.

Esto es un trabajo, nos podemos llevar estupendamente con nuestros compañeros y muchos de ellos incluso considerarlo amigos, pero hay que entender que somos profesionales y como tal tenemos que comportarnos. No es profesional quedarse callado para no molestar a un amigo, como tampoco lo es tomar medidas desproporcionadas con respecto a un trabajo no adecuado.

Seymour Cray, conocido por su marca de supercomputadores realizó la siguiente reflexión al respecto: “El problema con los programadores es que nunca te das cuenta de que están haciendo hasta que es demasiado tarde”.

De la cita yo me quedo con la necesidad de supervisar el trabajo que se hace pero no con el hecho de que sea un problema de los programadores, ellos hacen su trabajo, otros perfiles deben hacer el suyo.

Archibald MacLeish es un escritor y poeta americano, ganador de tres premios Pulitzer.

La experiencia es el engranaje de nuestro conocimiento, la que hace que cobre sentido o no lo que hemos ido aprendiendo en nuestra etapa de formación (la cual, por qué no, puede extenderse a lo largo de toda nuestra trayectoria profesional).

La experiencia se consigue con el tiempo, pero el tiempo no corre de igual forma para todas las experiencias, ya que hay otras variables que tienen un mayor peso, como el tipo de trabajo que se ha desarrollado y las responsabilidades e implicación adquiridas en el mismo.

Nuestra evolución depende del partido que le vayamos sacando a la experiencia que no es más que la aplicación de nuestro conocimiento a nuestro trabajo y a nuestra vida.

Sobre la experiencia, este autor realiza una reflexión muy interesante: “Solo hay una cosa más dolorosa que aprender de la experiencia y es no aprender de ella”.