archivo

Archivos diarios: febrero 3, 2011

Ya he comentado en alguna ocasión que cuando la cantidad de trabajo y frentes abiertos llega al límite de la capacidad de cada uno, cosa que sucede muy a menudo, hay que poner en marcha la técnica de tener el descontrol bajo control.

Esto pasa por asumir en primer lugar que no es posible tener todo bajo control y que eso no es culpa tuya. Salvo casos de proyectos unipersonales o de un tamaño no excesivamente grande y con suficiente dedicación, es algo que les va a suceder a todos los gestores de proyectos, lo reconozcan o no. Controlarlo todo implica conocer el negocio y la tecnología muy bien, tener presentes las obligaciones contractuales del trabajo, conocer al detalle lo que hace cada componente de tu equipo de trabajo, saber descifrar los pensamientos de tu equipo, de tus jefes y del cliente y un largo etcétera de variables que son las que dotan de complejidad a todo este proceso.

Por tanto, la dificultad de realizar un control absoluto del proceso de desarrollo se trata de un problema inherente a los proyectos. Si todo fuera mecánico, matemático, todos saldrían bien y todos sabemos que no es así.

La particularidad que añade las cargas de trabajo es que disminuye el grado de dedicación, por tanto si se gestionan una gran cantidad de proyectos, teniendo en cuenta además que hay algunos que necesitan más atención o requieren más trabajo que otros, es imposible que se pueda no ya controlar sino llegar a conocer con un cierto nivel de profundidad el sistema y su problemática por más tiempo que se dedique (alargar hasta la extenuación la jornada laboral puede funcionar a corto plazo, pero es imposible de mantener sin que nuestra salud lo acuse y también la calidad de nuestro trabajo).

Por tanto, la opción que nos queda es tener el descontrol bajo control que no es otra cosa que intentar llevar el tempo de los proyectos, qué necesidades y expectativas tienen los usuarios, cuál es el estado del sistema (en el caso de que trabajemos con mantenimientos), cuáles son los plazos generales, en qué momentos se esperan los entregables, cuál es el avance del proyecto, con qué recursos contamos cómo podemos obtener el máximo provecho de los mismos, etc… Con esto no se asegura e control absoluto de los trabajos, pero sí conseguiremos minimizar el riesgo de que sea el proyecto el que te controle a ti y te conviertas en su marioneta. En el momento en que eso sucede, el resto de proyectos que gestionas se ve afectado, ya que necesitarás dedicar mucho más tiempo del necesario y como es finito, hará que se incrementen el número de proyectos que te controlan y seguirá creciendo la bola de nieve.

Conocer el problema, conocer algunos ingredientes para solucionarlo no garantiza nada. En el pasado y en el presente he tenido/tengo proyectos que me controlan y en el futuro también los habrá. Tener en cuenta este detalle es importante, ya que de lo contrario te derrotará la situación. El objetivo es minimizar estas situaciones y cuando sucedan luchar contra el problema, es la única manera de que por lo menos la partida quede en tablas.

Anuncios

No descubro nada, no invento nada: Cuanto antes se detecten y corrigen los errores en el proceso de desarrollo de software menos costoso resulta. Reconstruir la aplicación o parte de ella una vez codificada o en medio de este proceso, puede resultar desastroso, además de resultar totalmente desmotivante para los programadores, que verán como semanas (o meses) de duro (y sordo) trabajo van directamente a la papelera.

Por este motivo, es conveniente desplazar (es importante, que se tenga en cuenta que se trata de repartir los esfuerzos de otra manera) buena parte del esfuerzo de los procesos previo a la construcción (análisis y diseño) a las etapas iniciales: elaboración del catálogo de requisitos, la identificación de subsistemas de análisis y la elaboración del modelo de casos de uso (tengo pendiente escribir un artículo, pidiéndole perdón 🙂 a los casos de uso, por haber dudado de ellos), utilizando prototipos (aunque sea a papel y boli) para que sirva de ayuda en todo este proceso.

Lo anterior es una estrategia, una declaración de intenciones, después se necesita usuarios que colaboren y un analista que consiga obtener de los mismos la máxima información posible de utilidad para el proceso de desarrollo.

Si se aborda directa o casi directamente la construcción del sistema de información, dejando el proceso de análisis a una cuantas entrevistas con el usuario y la elaboración del diseño físico de datos, es como hacer funambulismo, sin red en las proximidades de un huracán.