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.