archivo

Archivo de la etiqueta: control

Lo he dicho en numerosas ocasiones y sigo pensando lo mismo: pensar que se puede controlar un proyecto es una forma de engañarnos. Pero una cosa es eso y otra es dejar que sea el proyecto el que te controle a ti. Entre ambos extremos hay muchos matices.

Para poder tener algo controlado implica que se pueden dominar los factores externos y prever las reacciones de las personas. Eso no lo vas a conseguir casi nunca. Lo que sí puedes hacer es analizar el enfoque que más le conviene, realizar ajustes o cambiar si es necesario, evaluar riesgos, analizar la situación y los resultados con los usuarios o con el cliente para obtener feedback, adaptar la carga de trabajo a lo que el equipo y el área usuaria pueden asumir y reajustar posibles plazos, costes y alcance.

¿Te asegura eso el control? No, pero sí es una lanzadera para adaptarte al cambio y a las necesidades del proyecto, pero, ¿solo con eso?, es más efectivo (mucho más) si todas las partes aceptan este esquema de trabajo y si las resistencias al cambio: rigidez de los procesos y deuda técnica, no suponen un porcentaje significativo del esfuerzo.

El camino no es la microgestión porque lo único que se obtiene a través de ella es el rastro de miguitas de pan o la traza del proyecto pero no aporta soluciones.

Una reacción frecuente por parte de los gestores, ya sea de la parte usuaria o del equipo de desarrollo, cuando aparecen problemas es tratar de ejercer un mayor control sobre el proyecto.

Esto puede tener efectos beneficiosos o perjudiciales en función de cómo realmente se enfoque ese control y si se toman o no decisiones para resolver los problemas reales que tiene el proyecto.

Creo en la autogestión pero por mucho que creamos en ella depende al final de al actitud de las personas que forman parte del equipo y del grado en que terceras personas que pueden ser otros gestores o no influyan en el día a día del equipo.

Si el equipo no es capaz de autogestionarse es necesario tratar de conseguir un orden con el objeto de que el equipo funcione de nuevo de manera adecuada e incluso sea capaz de autogestionarse. Las actuaciones deberán ir dirigidas a dar un orden y criterio a los trabajos y también a tratar de resolver los problemas que han provocado que el equipo no funcione como tal y/o hayan provocado que se llegue a esta situación.

Se trata por tanto de un mayor control orientado a buscar un equilibrio que permita volver a una situación de normalidad en la cual ya no sea necesario esa intensidad en el control.

El tiempo que se tarda en recuperar el equilibrio dependerá del caos que exista en el proyecto y los problemas en las relaciones entre cliente y proveeedor por lo que en muchas ocasiones no se consigue volver a una situación de normalidad y se requiere una alta implicación del gestor.

Evidentemente llegada a esa situación el gestor deberá hacer autocrítica porque si se llega a ese nivel de caos y contaminación en el proyecto es porque no ha sabido leer el estado en el que se encontraba y/o porque no ha tomado las decisiones adecuadas en el momento o momentos en que era preciso.

Pero una cosa es ejercer un mayor control y otra su exceso porque tal vez se consiga dar un cierto orden a los trabajos pero puede provocar que los desarrolladores se bloqueen y teman equivocarse lo que afectará a su productividad y a la búsqueda de soluciones que vayan más allá de su zona de seguridad.

Muy típico en situaciones donde no se conoce realmente lo que se quiere en el proyecto y en aquellos casos donde se acepta prácticamente todo lo que pide el cliente sin medir las consecuencias.

Consiste en no tener un control del alcance del proyecto, ya sea porque no se ha analizado de manera adecuada determinados requisitos, porque no se deja de aceptar requisitos o porque no se le dedica suficiente atención a esta tarea.

Un proyecto debe tener un alcance y si no se conoce, mal empezamos, porque cuando se han definido un presupuesto y unos plazos supongo que no habrá sido por el resultado de un juego de dados. Es importante tener en cuenta que no es lo mismo saber qué se quiere, que no saber cómo se quiere, circunstancia esta última que requiere un proceso de feedback continuo con el usuario.

En cuanto a aceptar todo lo que pide el cliente o el usuario es una medida que si bien puede evitar desgaste en etapas iniciales del proyecto, al final todo se vuelve en contra cuando la bola se haya hecho tan grande que no la puedas controlar.

La falta de control sobre los proyectos, equipos de trabajo, calidad del servicio, etc… que de manera generalizada existe en el nivel uno es un reflejo de lo que pasa en, tal vez, demasiadas organizaciones dedicadas al desarrollo de software y que perjudica de manera considerable a los proyectos y en consecuencia al cliente, al proveedor, a los destinatarios finales del servicio y en definitiva al negocio del desarrollo de software, negocio que si seguimos sin cuidar no conseguirá la evolución que requiere para ser considerada una disciplina al nivel de las otras ingenierías.

Los procesos no son solo para empresas grandes también son válidos para entidades de cualquier tamaño. Si nuestra vida diaria está llena de procesos, propios y ajenos, ¿por qué darles de lado en el desarrollo de software?.

Es cierto que cada proyecto de desarrollo de software es distinto ya que siempre cambian algunas de las variables que condicionan el mismo, no obstante, eso no debe ser un obstáculo para intentar implantar procesos, ya sean generales en la organización o propios para el proyecto que permitan tener un cierto control sobre lo que se está haciendo y la posible evolución que puede tener.

Y no es cuestión de que CMMI proponga la implantación de procesos en determinadas áreas que permitan conseguir estos objetivos sino que es cuestión de sentido común. Por tanto, guste o no guste CMMI, se compartan o no sus fundamentos, es evidente que sin una organización real, sin unos mecanismos de gestión adecuados, estamos condenando a los proyectos a una situación en las que los problemas, las crisis, llegarán demasiado tarde a quienes tienen que tomar decisiones, al no existir mecanismos de medición de diferentes métricas objetivo no se tendrá referencia para poder mejorar, etc…

Con esto quiero decir que CMMI recomienda un modelo, que puede ser válido como otros, pero que compartirá con ellos la necesidad de aplicar procesos repetibles, estrategias comunes, en diferentes áreas de la gestión y de los proyectos individuales.

El segundo nivel de CMMI pretende dar un primer paso respecto a la situación de anarquía inicial, en la que no existen procesos o si existen no se aplican o controlan. En este nivel se entiende que para aplicar estrategias de nivel organizativo es necesario crear primero una cultura orientada al proceso y para ello plantea como estrategia que por los menos los mismos se implanten a nivel de proyecto.

Bastará, por tanto, con las procesos se definan a nivel de proyecto, pudiendo ser distintos entre unos y otros. Lo importante es que existan mecanismos de gestión, control y supervisión, que sean distintos entre los diferentes proyectos no es esencial, ya que se habrá conseguido un avance significativo respecto al nivel anterior al existir mecanismos que permiten obtener información del estado del proyecto, de su avance, de sus posibles desviaciones, de los posibles problemas que pueden existir.

Conseguir lo anterior, no es poco y los beneficios son evidentes, pero sobre todo hay uno que considero muy importante y es que por lo menos a nivel de ámbito de proyecto se sepa cómo actuar en cada caso y no tener que estar preguntando cómo se hace esto, como se pide lo otro o un escenario todavía peor en el que cada uno por su cuenta decida qué hacer.

En los próximos artículo sobre la materia se realizará un repaso a los diferentes procesos que se tienen que implantar de manera adecuada para considerar que una organización tiene un nivel dos de madurez.

El nivel 1 de CMMI se considera nivel inicial porque hace referencia a la ausencia de procesos o en el caso de que existan a la ausencia de control, seguimiento y/o cumplimiento de los mismos.

Una organización dedicada al desarrollo de software que se encuentre en este nivel se entiende que no tiene un control real sobre los proyectos en los que está trabajando: no se conoce realmente el grado de ejecución de los mismos, no hay control de plazos, no hay control de los costes económicos, no existe una motivación para la toma de determinadas decisiones, etc…

Estamos ante una situación en la que cada proyecto es quien maneja las riendas y no la organización quien las lleva, por tanto, si ya es complicado intentar conseguir un comportamiento predecible en un proyecto de desarrollo de software, todavía lo es más cuando no existe un control sobre el mismo y predomina la reacción ante las circunstancias que van aconteciendo a la acción.

Este nivel se caracteriza, por tanto, por el comportamiento impredecible de los proyectos por la ausencia de procesos definidos o por el no cumplimiento de los mismos (que viene a ser lo mismo) de manera que cada equipo de proyecto o incluso cada desarrollador sigue su propia estrategia o metodología, como una decisión personal o de grupo, pero no siguiendo unas directrices a nivel organizativo.

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.

En una empresa de desarrollo de software, una de las primeros aspectos que debe poner en marcha es el control del coste de los proyectos: imputación de horas de cada uno de los participantes en el proyecto (de esta forma se obtiene el número de horas consumidas por perfil) y la imputación de terceros costes al proyecto (gastos de viajes, tickets de aparcamiento, comidas, etc…).

Esta información junto el presupuesto económico del proyecto (importe por el cual te han contratado el trabajo) y las cantidades facturadas al cliente, debe permitir a los gestores del proyecto ver la situación económica del mismo y junto con la visión del cronograma o Gantt determinar el estado real del proyecto.

Se deben poner los medios para que la visión del estado económico del proyecto se pueda obtener de la forma más rápida rápida y automática posible para los gestores del mismo.