Adopta el plan de trabajo

Si existe el equivalente de la kryptonita para alguien que se dedique al desarrollo/programación de software es solicitarle que haga un plan de trabajo, y ya para ponerlo en verdadero jaque, que ejecute su actividades apegándose a ese plan.

Salvo que hayas tenido una o más asingaturas con esa rigurosidad en en tu formación, probablemente sólo estuviste expuesto a esta tortura en alguna variante de Administración donde se te pidió generar un plan de negocios o algo similar.

El plan de trabajo, no debería ser algo tan engorroso, mucho menos para la comunidad dedicada al desarrollo que valora las actividades definidas y ordenadas.

Cuando recibes un encargo, mientras vas escuchando/leyendo la solicitud ya estás dilucidando una serie de tareas que tendrás que ejecutar para llegar a buen puerto; incluso, al atender a tu interolucutora y esta menciona que determinadas definiciones las puedes validar con algún miembro de la organización en particular, y dependiendo de la relación que tengas con tal o la reputación de este, no puedes evitar gesticular una sonrisa o una expresión de desagrado.

En tu mente, una lista de actividades que habrá que realizar se está gestando, incluyendo el orden en que en ese momento consideras el mejor. Probablemente ya hayas detectado dependencias entre ellas, dependencias con terceros y algunos insumos con los que no cuentas, y como resultado de todo esto, también cuentas con un tiempo que estimas suficiente para concluir con los trabajos solicitados.

Entonces, ¿por qué somos tan rehacios a elaborar y seguir planes?

La principal razón, en mi opinión, es que no identificamos valor en ellos, y al carecer de él, no estamos en la disposición de invertir tiempo en elaborar algo que no aporta a la conclusión de nuestro trabajo (como la documentación [lee la crónica]).

Sin embargo, conforme asciendes en la jerarquía de la gestión (algo que a todos nos pasa) empezarás a toparte con estas preguntas:

• ¿Cuándo terminas?
• ¿Qué necesitas?
• ¿Requieres apoyo? ¿De cuántas personas, de qué perfil y por cuánto tiempo?
• ¿Cuentas con el equipo (dispositivos) suficientes?
• ¿Cuánto costará?
• Y muchas otras más.

Aunque tengas la respuesta a todas estas preguntas en tu mente, tienes que poder trasmitirlas a tus interlocutores y hacerlo en un lenguaje o medio que puedan entender ambas partes.

El plan de trabajo es un documento que tu cliente (interno o externo), tú y quienes te apoyan, entienden y acuerdan. El plan de trabajo te puede ayudar a responder esas preguntas en el momento y tiempo después. Ahí está el objetivo y el alcance, lo que se espera y el tiempo en el que se espera. Las responsabilidades de cada persona o con quién dirigirse si algo o alguien no está colaborando como se espera, las actividades y la persona responsable de ejecutarlas, y un cronograma.

Probablemente el cronograma es el que convierte al plan de trabajo en el enemigo a vencer.

Detestamos hacerlo, odiamos revisarlo, pero sobre todo, nos negamos categóricamente a compromoternos con él, y creo que ahí está la razón real del odio y la reticencia al plan. Es impensable comprometerse con algo que no se conoce o que abre espacio a las dudas.

Al elaborar el cronograma, trata de detallar tan granularmente como sea posible todo lo que tienes que hacer; no olvides, que tu trabajo no inicia con abrir un IDE y generar código, como tampoco termina cuando el programa compila o ha logrado concluir un ciclo de pruebas.

Tus tareas inician desde un entendimiento, una junta; ambientar tu equipo de trabajo, documentarte en algo que desconoces o profundizar en el tema, diseñar y documentar lo que se construirá. La etapa de construcción es la que tienes más presente, sin duda, pero también contempla tiempo para generar respaldos, actualizar repositorios de código, juntas de avance, revisión (Dailys), demostraciones, pruebas unitarias, pruebas de integración, pruebas con usuario. Estima un tiempo para hacer correcciones en caso de ser necesario (que surgirán inconvenientes que habrá que solventar), tiempo para compilar y empaquetar los binarios finales, configuración, instalación y despliegue en ambientes de testing o productivos, sesiones de capacitación, documentación de usuario y documentación técnica, actualización final de repositorios.

Tú conoces lo que debes hacer, no lo dejes al azar o a la memoria. Entre más detallada esté tu lista de tareas, la generación del cronograma será más sencilla. Tú podrás estar al tanto de tu avance y ver desde una etapa temprana si se avecina un problema, particularmente de fecha de entrega, tuya o de un tercero de quien dependes. Es más fácil, y menos costoso (en tiempo y recursos) atender un problema que se identifica con tiempo.

A este nivel detalle te aseguro que sí te podrás comprometer y acordar con quien corresponda las condiciones bajo las cuales refrendas ese compromiso. Tú y esa persona estarán en común acuerdo con esa planeación.

Contempla también que el plan de trabajo acordado, es eso, un plan, una idea de cómo debería desarrollarse el proceso con base en las condiciones dadas y esperadas. Los planes dudosamente ejecutan tal cual se vislumbraron. Quien diga que jamás ha cambiado un plan, y que todo ocurrió como se diseñó, miente. Por eso es importante que tengas las tareas programadas a futuro, para que puedas ajustar el plan en caso de ser necesario.

Pensarás que esto solo sirve para proyectos o trabajos en equipo o en empresa, pero no, generar un plan para un proyecto personal con su correspondiente cronograma te ayudará a ver si vas por buen camino o si debes cambiar algo en tu idea inicial. Al ir completando las actividades, el avance en tu cronograma lo verás reflejado en tu producto. Es una sensación reconfortante, créeme.

Ejercita la creación de planes y cronogramas con tus actividades cotidianas o con algo que deseas hacer, no tiene que ser laboral. Eventualmente tendrás más pericia en su elaboración y no lo sentirás como una carga, sino como lo que es en realidad: una herramienta.