Cuando todo fallo

El fin de año es una época para hacer balance de como ha ido el proyecto  desarrollo de software. Podemos pensar en todo lo que hemos hecho, en todas las decisiones que hemos tomado, en como hemos afrontado los problemas, etc..

si todo ha ido genial entonces hasta el próximo post.

Si todo no ha ido tan genial entonces sigue leyendo.

Ahora que se hace resumen, me doy cuenta de cosas, aspectos, decisiones, etc… (métodos en general) que debería haber sido de otra manera. Somos humanos y todo el mundo se puede equivocar. Lo realmente complicado de interpretar es que pasa con las cosas, aspectos, decisiones, etc… que fueron correctas en su momento, que ahora razonas y sigues pensado que fueron lo mejor que se podía hacer… pero aun asi fallaron o no fueron suficiente. Se pueden tomar de dos maneras:

• Puedes hacer lo mismo de otra manera. Aunque pienses que tu forma de hacer las cosas es la correcta puede que existan factores (como que tu equipo no asimila tus métodos o que tu proyecto software no tenga una arquitectura que se adapte a tus métodos) que lleven tus métodos al fracaso. Por lo que tendrás que adaptar tus métodos aunque no te parezca lo mas correcto,
• Puedes hacer otras cosas. Seguro que hay muchos métodos que no has probado y que pueden ser un revulsivo perfecto.

En general, probar otras cosas suele ser lo mejor. Sobre todo si el equipo de desarrollo ya ha manifestado ser contrario a tus métodos o ha mostrado indiferencia.  

Lo realmente util que son las cosas

En el desarrollo de proyectos de software hay muchas ideas de como deberian llevarse las cosas. Se pueden tomar muchas medidas:

- Reuniones todos los dias.

- Diseño, discrusion y rediseño.

- El jefe da de alta una tarea en algun sistema de gestion de tareas y un programador tiene que ir completando las horas con lo que haciendo.

- Se hace integracion continua.

- Se tiene un equipo de integracion y estandar de calidad.

-Etc..

Todas son buenas ideas y todas pueden llevar al exito en la gestión de equipo de desarrollo de software. Si alguien aplica todo esto (o algunas cosas) y llega al exito genial. Pero se puede aplicar esto (y mas cosas) y no tener exito. 

¿Que es el exito? el exito es conseguir los objetivos. Si el objetivo principal es tener lo que el cliente desea, el producto, en los plazos deseados pues se ha tenido exito. Si se tiene antes entonces has tenido mas exito. Si se tiene mas tarde has tenido menos existo. Si no lo tienes ha tiempo entoces no has tenido exito (has fallado).

Todas estas medidas (todas estas cosas) no se pueden aplicar solo porque sean buenas. Hay que tener siempre en cuenta las características de nuestro grupo de desarrollo:

- Si los programadores no estan contentos en generla (ganan poco dinero o algo asi) aprovecharan cualquier oportunidad en la que esten todos para quejarse. Por lo que una reunion no es una buena idea.

- Si los programadores no tienen iniciativa entonces no querran discutir un diseño. Quieren un diseño.

- Si el sistema de gestion no es dinamico y lleva poco tiempo usarlo entonces los programadores pensaran que es una perdida de tiempo o si los jefes dan de alta tareas en sistema de gestion y no son reflejos de lo que se esta haciendo en realidad entonces todos dejaran de usar la herramienta.

- Si no se usa la integracion continua para usar los datos que proporciona entonces al final se convierte en un mantenimiento que lleva mucho tiempo.

-Etc...

Hay que "leer al grupo". Habran cosas que se puedan implantar y funcionen. Pero habra otras donde habra que adaptarlas al grupo o no usarlas.

El conocimiento del negocio de un programador

Cuando se desarrolla una aplicación de tamaño medio/grande se produce muchas veces la siguiente situación:

1. Se dividen las tareas entre los programadores
2. Se terminan las tareas. Parece que esta todo
3. Se empieza a probar y el jefe se da con un fallo muy claro.
4. ...

¿Como puede ser que ningun programador se haya dado cuenta? El jefe se da cuenta que la realidad es que los programadores no tienen un conocimiento del negocio para darse cuenta de ese fallo, pero como es posible? la mayoria de programadores suelen llevar tanto tiempo como el jefe en el proyecto. ¿Como es posible que no conozcan mas el negocio? La respuesta es que gran parte del trabajo del jefe consiste en aprende el negocio y como la aplicación da respuesta a las necesidades del negocio mientras que toda la jornada laboral de un programador consiste en programar. Un programador no puedes saber tanto de negocio, necesidades de cliente, etc.. como un jefe ya que NO GASTA UN TIEMPO SIGNIFICATIVO EN ELLO por lo que es lógico que no tenga ese conocimiento.

Ahora lo normal es pensar, pues deberia tenerlo. Esto hay que pensarlo bien porque para que lo tenga hay que dedicar tiempo (que no podrá usar en programar) y ademas alguien (un jefe) tendrá que perder su tiempo en explciarlo.

¿Que se puede hacer? Cada caso requerirá su propia solución. A veces merecerá la pena que programador tenga el conocimiento y otras que sea simplemente el que fabrica las piezas y son otros los que encajan esas piezas.

La percepción exterior

Durante el desarrollo de una aplicación y a la hora de hacer entregas hay un factor que nunca se tiene en cuenta pero que es muy importante: La percepción exterior que da la aplicación. Da igual que "el interior" (Core, lo que no se ve pero es realmente complicado) este perfecto si la percepción que da la aplicación al ejecutarla causa sensaciones negativas como:

• Va muy lenta
• Ciertas partes no funcionan
• Hay casos de prueba que funcionan y otros no
• Etc...

provocará rechazo por parte del usuario final. Por ejemplo, un equipo desarrolla una aplicación web para que los usuarios puedan  darse de alta en un censo de un pueblo. La aplicación es simple y compleja. Simple porque de cara al usuario es solo un formulario de 10 campos que se rellenan y se pulsa un botón de enviar. Compleja porque en core usa tecnologias que hacen mas facil la navegación, se conecta con un web services que verifica la firma, hace una validacion con 2 bases de datos, optimiza busquedas para validacion de .... y mas cosas. Todo esto último se ha conseguido pero el dia de probar en producción se produce el gran problema, el responsable del cliente dice que toda (no solo la interfaz) es un desastre porque hay un campo donde no se pueden poner mayusculas.

Si llevas tiempo en el desarrollo de software te sonará seguro:"Esta aplicación en una mierda porque no deja poner mayusculas en este campo" y el programador piensa: " pero si eso es una tonteria, lo del web services era lo complejo".

Como evitar esto? Es una tonteria o es algo que puede hacer fracasar un proyecto?

En estos casos, todo el mundo tiene razon y todo el mundo esta equivocado.

• La interfaz al usuario hay que probarla hasta mas no poder. Es importante eliminar cualquier fallo en el que el usuario pueda decir:"esto es de sentido común".
• Si el principal objetivo de un programador es la interfaz entonces  las partes mas complicadas no estarán implementadas y si que la aplicación no valdrá para nada.

La mejor opción es poner una capa intermedia entre el desarrollo y el cliente:

• Un departamento de pruebas.
• Comerciales que deduzcan de forma lo mas exacta posible que es lo que quiere el cliente.
• Etc...

En cualquier caso, suponer que es lo "de sentido común" (o básico) para el cliente es un error. Los clientes suelen saber lo que quieren durante la marcha. Cuando ven algo sabe si les gusta o no. Lo mejor es planificar el desarrollo para que los cambios en la interfaz te afecten lo menos posible.

  

La oposicion al cambio

En el mundo del software (y supongo que de todos los trabajos en general) la mayoria de personas son reacias al cambio. Si es un subordinado te dira cosas como:"esto no lo comprendo", "asi no se como trabajar", "yo creo que asi es peor", etc... y si es un jefe se reira de ti o te tratara de forma condescendiente.

Ojo, el cambio no siempre es bueno. O si? es dificil determinarlo. Por lo general, se puede tomar como axioma que el cambio es bueno cuando se puede demostrar que algo no funciona. Pero cambiar algo que funciona... es peligroso.

Todo el mundo que ha trabajo en el mundo del software sabe que una idea que ha tenido siempre ha tenido mas retractores que apoyos (sobre todo en los superiores). La claves para conseguir cambio es:

- Tamaño. Si un cambio es muy grande lo tienes que dividir. Y esos cambios (que han de ser pequeños) han de conseguir una victoria lo mas rapido posible. Como no se muestre algun indicio de valor al cambio enseguida se echara para atras y restara credibilidad a los impulsores.

- Apoyos. Hay que buscar apoyos. De jefes, de subordinados, de iguales... de los que sean pero los cambios son como las politicas. Para el exito de un cambio es mas importante que parezca bueno que realmente sea bueno el cambio.

- Fuerza de voluntad. No hay que desanimarse porque el cambio no parezca servir. Y si realmente no es bueno eso no significa que los impulsores del cambio no puedan tener buenas ideas en el futuro.

- Presentacion. Este es posiblemente la clave mas importante para que un cambio tenga exito. Hay que presentar la idea bien y tiene que ser entendible para el publico al que va orientado.

Recordar las cosas

Cuando un lider del proyecto quiere comunicar un hecho de importancia que quiere que todo el equipo de desarrollo tenga en cuenta (por ejemplo; la fecha de entrega de la ultima version es el dia 30 del mes que viene)  realiza una accion para comunicarlo. Esta acción siempre la piensa como algo definitiva. Puede ser algo registrable (como mandar un correo con importancia alta) o algo mas grafico (como una reunion con todo el equipo). El lider piensa que, con esta acción, todo el equipo conoce ya el hecho de importancia, lo tendra en cuenta siempre y le dara el mismo valor que él. NADA MAS LEJOS DE LA REALIDAD.

El hecho que el lider ha expuesto es importante para el lider porque esta alineado directamente con su trabajo y es un hito para él pero si los miembros del equipo no tienen este hecho importante como un hito directo en su trabajo diario entonces tenderan a olvidarlo o no lo olvidaran pero no le daran el mismo valor al hecho importante que le da el lider (siguiendo con el ejemplo de la fecha de entrega, los programadores no le daran importancia a la fecha ya que los programadores solo ven importantes sus hitos, es decir la tarea de una semana que les ha tocado y como mucho la tarea siguiente pero no les importa tanto que el dia 30 se tenga que entregar la version).

La unica forma, real, de solucionar esto es tener reuniones periodicas con el equipo y comentar las tareas individuales de cada uno alineandolas con el hecho importante. Pero ojo, periodicas porque sino olvidaran el hecho importante.

Falta de horizonte

Un gran problema que tienen los programadores, ya sean jóvenes o viejos, es la falta de un objetivo. Es es una característica normal, no solo en programadores, el hecho de no tener muy claro que se quiere o si tenerlo pero no saber como conseguirlo y dejar pasar el tiempo hasta que surge algo que nos hace ponernos en el camino correcto.

Pero en esa espera pasan cosas curiosas y contradictorias; por ejemplo, todos sabemos que en un desarrollo, sobre todo si es largo, la programación se vuelve cíclica (desarrollos nuevos-pruebas-incidencias-desarrollos nuevos-pruebas-etc…) y esto hace que “siempre sea todo los mismo” (misma tecnología, mismos problemas, mismos procedimientos, etc..). Por lógica, cualquier cosa que se salga de la rutina debería ser bien recibida, al menos de primeras. Pues la experiencia me ha demostrado que no. Los programadores no quieren cosas nuevas, prefieren seguir en el ciclo que se ha convertido la programación del proyecto.