Regla N°15 de la Ingeniería de Software: Haz que las cosas sucedan

"... En la guerra puede haber cambios de circunstancias ante las cuales el general debe reaccionar. Decir que debe esperar las órdenes del soberano para decidir es como esperar las órdenes para apagar un fuego. Antes de que lleguen las órdenes pertinentes, todo estará reducido a cenizas." Sun Tzu, el arte de la guerra.

Una de las cosas que más afectan al éxito del desarrollo de un sistema es la pasividad y falta de proactividad. Esto es, principalmente, quedarse esperando a que las cosas pasen por si solas.

Muchas veces existen escenarios de incertidumbre en que no queda claro que es lo tenemos que hacer en cuanto al sistema que se está construyendo, esto puede ser por muchos motivos, puede ser una falta de visibilidad del objetivo real o que no se nos ha comunicado apropiadamente.

Pero es necesario comprender que mientras el sistema no esté finalizado (satisfaga las necesidades del cliente), hay tareas pendientes que hay que resolver y es responsabilidad de cada integrante del equipo conocer cuáles son y conseguir se lleve a cabo. Es responsabilidad de cada uno hacer que las cosas sucedan.

Los escenarios por los se puede caer en la pasividad son, entre otros, los siguientes:

• No existe una fecha de finalización del proyecto. Esto provoca que no se dé la suficientemente importancia a acabar el proyecto, siendo laxos con los compromisos y avanzando de manera inadecuada e irregular.
  
  
  Toda tarea debe tener una fecha. Cada vez que surja una tarea, ponle una fecha, si no puedes ponerle una en ese momento, ponle una fecha para volver a revisar la tarea, pero nunca dejes nada sin que este establecido una tiempo para ser atendido.
  
  
• No existe un objetivo claro. Esto provoca que no se sepa que es lo que hay que hacer y por lo tanto no se hada nada relevante, agregando módulos al sistema o quitándolos sin sentido alguno. Es necesario tener unos objetivos definidos, cerrados y limitados.
  
  
• No existen unas tareas claras. Dicho de otra forma se tiene un objetivo, pero no se ha analizado claramente y no se sabe cómo llegar a él, con lo que se va dando tumbos, realizando código (u otras tareas), sin saber muy bien como llega a buen puerto. Es necesario trazar una ruta para poder conseguir nuestros objetivos, dividir el problema en pasos y recorrerlos uno a uno.
  
  
  
• No hacer una tarea por estar esperando un correo o una llamada. No hagas eso, nunca van a llegar en el tiempo adecuado y el resultado es que no vas a hacer nada. Finalmente el trabajo de las personas no es responder correos, así que no estarán pendientes para contestarte o lo harán cuando acaben sus tareas, o incluso si son bien organizados tendrán un día, o una hora al específica para contestar todos los correos. Mi recomendación es que mandes un correo, y después llames por teléfono para avisar que mandaste cierta información por correo. Sobretodo que establezcas un tiempo prudencial determinado y concreto para obtener respuesta a ese correo, y que además la persona receptora sea consciente de dicho tiempo, si no se ha cumplido vuelve a llamarla. Es mucho mejor ser molesto, que no hacer tu trabajo.
  
  
• Diferentes áreas, diferentes intereses. Este problema es muy común, dos áreas involucradas tienen responsabilidades diferentes con respecto al proyecto, esto es un problema de difícil solución y tiene que ver con que no se percibe que un sistema incompleto no le sirve a ninguna de las dos áreas (es del famoso caso de "No es el lado de mi barco el que se hunde"), es necesario aumentar la comunicación entre áreas, para llegar a un mutuo acuerdo, a veces solo es un mero problema de comunicación.
  
  
  
  

  
  
• Plantear un problema sin la solución. Es necesario que cuando tengamos un problema, intentemos buscar una solución antes de delegárselo a otra área. Es importante presentar los problemas junto con las soluciones
  
  
• Para cada solución tiene un problema o más. Es un caso curioso, cuando se dan soluciones a un problema, inmediatamente surgen nuevos problemas que invalidan la propuesta, de forma que al final ninguna acción es tomada, nada se hace. Hay que considerar que ninguna solución resuelve completamente un problema, pero es mejor tener una solución que haga algo a no tener nada en producción.

Ahora bien, ¿Puedes tomar decisiones desde cualquier puesto? Si, por que si realmente no tuvieras que tomar decisiones en tu puesto, sería más fácil reemplazarte con algún tipo de proceso automatizado, si no es el caso, es que tus decisiones afectan a tu trabajo y a la forma de desarrollarse de este, y puedes influir en el éxito del proyecto.