Estado real del proyecto.

A lo largo del desarrollo (sobre todo si es durante un periodo largo) algun stakeholder (normalmente algun jefe) querra conocer el estado del proyecto y en ese momento es dificil dar una respuesta sencilla ya que al avanzar muchos frentes a la vez no se puede especificar con claridad, pongamos un ejemplo en el que tenemos 4 funcionalidades que implementar (empleados, costes, informes y ventas) y cada funcionalidad esta en nivel distinto de desarrollo como muestra la grafica:

¿Cual el estado?

Una funcion que indica el grado de avance de todo

El mas retrasado

Etc.. Hay muchas posibilidades pero realmente nunca es cuestion de que eleccion usemos sino que es cuestion de como espera los stakeholders que le indiquemos la información. Este punto es muy importante porque ofrece mucha informacion:

• Sabemos cuales son las partes que tienen mas valor para los stakeholders.
• Necesitamos buscar un leguaje comun con los stakeholders.
• Se necesita un integrador que se preocupe no solo de poder definir el estado del proyecto, ademas se encargue de encajar todas las piezas que definen el proyecto.

Muchas veces tenemos casos como el siguiente:

• Todo empleados funcionando y costes esta parado porque no tiene una parte que depende de empleados. Pero si empleados esta todo acabado ¿que esta pasando?

En casos como este, es la figura del integrador en que entra en juego. Un integrador es la persona capaz de saber que costes podria estar terminado ya que sus depedencias estan resultas. Si al integrar se detecta un fallo es el integrador el que busca a los implicados y los coordina para que solucionen el problema.

Un integrador es la persona que puede decir el estado del proyecto.

La politica de la gestión de desarrollo

De las partes mas simples es facil hablar mientras que de lo mas complicado se suele confiar en una persona que sabe hacerlo. Por ejemplo, si un equipo tiene que definir si el color azul es mejor que el verde para el fondo de una pagina web nos podemos tirar horas debatiendo y opinara desde el becario hasta el jefe de proyecto pero si tenemos que hablar de la mejor solucion para la "arquitectura de comunicaciones" seguramente solo opinen dos personas del proyecto y la mayoria de personas de del desarrollo no diran nada y esperaran que otro lo solucione.

Es como la politica, la mayoria de gente quiere opinar y ver que su opinion se tiene en cuenta pero no van a ser ellos lo que van a gobernar. Lo dificil que lo haga otro.

Una solucion muy politica para mentener un buen ambiente de trabajo en e desarrollo es observar la mayoria de opiniones triviales que suele tener el equipo y aplicarlas ya que:

- No suelen tener gran impacto.
- Te permiten decidir lo realmente importante a los gestores del equipo.
- Da la sensacion a los miembros del equipo (que no es solo una sensacion es cierto) de que han puesto su granito de arena.

Mantener la coherencia en el estilo del desarrollo

Cuando se empieza un desarrollo de proyecto de software esta implícito que el grupo de programadores va a programar el software que se desea conseguir. Cuando el software es medianamente grande te das cuenta de que no vale con que el programador consiga terminar una tarea, ademas debe:

• Seguir las normas que se han establecido para programar.
• Seguir la arquitectura que se haya definido.
• Tomar la decision correcta ante una situación que aunque no este especificada expresamente se deduce a partir de los puntos anteriores. 

Si no se resuelven estos puntos entonces al final el software es un conjunto de miles de tareas cuyo conjunto no hacen lo que queríamos al planificarlo al principio.

Es imposible conseguir que un grupo de programadores programen igual pero ¿Como hacer que varios programadores sigan unas normas?

La mejor solucion consiste en tener un integrador en el equipo que compruebe que se siguen las normas y si no se siguen las normas se le indica al programador y lo apunta en una lista que ira rellenando de semana en semana. Cada semana se debe juntar con el equipo y repasar dicha lista e indicar lo que crea relevante. Estas charlas son la clave para ir formado al equipo en las normas y el estilo que deben seguir los programadores.

Como señalar los fallos

Durante el desarrollo del software, los programadores van cometiendo pequeños errores y grandes errores. Unos pueden ser grandes meteduras de pata y otras pequeñas tonterias pero todas van sumando fallos que hay que solucionar y que penalizan las entregas. Esto es asi y se debe tener en cuenta como riesgo en la planificacion del proyecto. Pero existe otro gran problema, los programadores normalmente no son conscientes de estos fallos y cuando llega la hora de las entregas y no se llega o la calidad del software no es buena entonces aparecen los enfados y frases como:

• Era imposible llegar.
• Como puede ser? yo le hecho todo bien.

Para solucionar este problema se debe:

• Tiene que haber un supervisor, jefe, integrador, etc... que detecte estos fallos y los ponga de manifiesto.
• Se le debe comunicar al equipo de forma adecuada.

En este ultimo punto quiero incidir, Cual es la forma correcta de comunicar los fallos? 

• Si se hace de forma continua e inmediata (cuando se detecta el fallo enseguida se indica) entonces geneneras en el programador las ganas de "devolvertela" (estara deseando que el supervisor se equivoque para echarselo en cara).
• Si se hace de forma aislada entonces pierdes el poder que da estar hablando en grupo y dejas que el programador se pueda "picar" e intentar defenderse con unñas y dientes aunque no tenga razon.

La forma correcta es tener una rutina de reuniones (una a la semana) donde el supervisor hable de asuntos tecnicos y cuando lo vea oportuno indicar  cosas como:

• Esta ultima entrega ha ido mal y yo creo que...
• Las metricas de calidad han bajador debido a...
• Normalmente usamos "esto" en el codigo y deberiamos usar "esto otro" 

Miedo a la integración

En muchas ocasiones, y sobre todo cuando el proyecto alcanza un tamaño grande, ante un nuevo desarrollo/solventar incidencia se implementa una parte completamente nueva aun sabiendo que ya hay una parte implementada que deberia ser modificada/ampliada para solucionar dicho desarrollo/incidencia. Esta situación pasa porque: 

• El programador quiere “ahorrase” el tener que conocer una lógica compleja.  
• No se han proporcionado las herramientas necesarias para adquirir el conocimiento de la parte a modificar/ampliar y la tarea se hace demasiado pesada. 

Este “miedo” tambien afecta a la parte funcional ya que en muchos casos se recurre a “Comentarios”, “Anexos”, etc.. En lugar de modificar el documento donde se indique la parte a modificar/ampliar. 

La única solución a este problema es identificar la necesidad de la redefinición y que es una tarea que debe ser teniada en cuenta en las planificaciones. No se debe considerar la redefinición/ampliación como un error. Habrá casos donde la redefinición/ampliación sera un fallo ya que no hacia falta pero en otros casos no seria un fallo y es parte del desarrollo del software. 

Problemas para dividir el trabajo

Cuando se piensa en la informática,  y en concreto en la programacion, lo primero que se piensa es que el programador está en cualquier sitio del mundo. Nada más alejado de la realidad, al programador se le quiere al lado del negocio y si se piensa en tener al programador alejado es por temas laborales( por conciliación familiar, teletrabajo, etc...).

Por qué se necesita al programador al lado del negocio? Los principales motivos son:

- No hay una figura de comprobador/integrador técnico que asegure que lo que hacen los programadores sea correcto. Este tarea se delega en el grupo de programadores.

- El negocio requiere continuos cambios y definición on-fly( en el momento) y tiene que aclararlo en persona.

A lo largo de la historia reciente de los productos que han revolucionado la informatico y/o el mundo ( Facebook, WhatsApp, wifi, Etc..) se  puede llegar a la conclusión de que todos eran grandes soluciones que caían por su propio peso y no eran grandes soluciones por lo complejo de su implementación. Este problema es lo mismo, lo único que se necesita es dar con la idea feliz que permita tener programadores en cualquier parte del mundo de manera eficaz.

No querer ver la realidad

Cuando se planifica con tiempo el desarrollo de un software y se mira hacia la implementación se pretende hacer de forma correcta y se crea el perfil de arquitecto de software pretendiendo que diseñe el software y lo haga tan bien que implementarlo sería solo la parte fácil.

Nada más lejos de la realidad. Puede que en un futuro este planteamiento sea una realidad pero ahora no lo es y nunca ha sido una realidad por mucho que nos empeñemos en no querer la realidad.

El no querer ver la realidad siempre es lo mismo. Todo el mundo ha estado en un proyecto donde se dice: este proyecto no ha quedado bien, al siguiente lo haremos mejor. Al siguiente se hace de forma distinta pero el resultado es más o menos el mismo y ya se empieza a decir: la culpa es de esta otra persona por esto o por lo otro.

Rindamonos a lo evidente. Al menos hasta que cambien las cosas y se establezcan métodos claros y que todos sigan para que la implementación sea lo más sencillo. Es cierto que se necesita un arquitecto de software pero el arquitecto también programa, se moja las manos y resuelve problemas de bajo nivel. Si hace este tipo de tareas entonces se ganará la confianza del grupo de desarrollo y del grupo de gerencia. Con esta piedra angular el desarrollo irá por buen camino.