archivo

Archivo de la etiqueta: alternativas de solución

Este antipatrón puede tener tres orígenes:

– El equipo de desarrollo opta por la opción más sencilla (en cuanto a asumir responsabilidades) de acatar la petición de desarrollo que se le ha descrito (con un cierto nivel de detalle que de alguna manera dirigiría la solución hacia un enfoque concreto de implementación), sin entrar en ningún análisis de alternativas de solución. “Me han dicho que haga X y yo hago X”. Típico en entornos en donde los gestores caen en el antipatrón “yes man“.

Es cierto que siempre se podrá utilizar la defensa de “yo he hecho lo que me han dicho”, pero eso puede provocar unos costes y un incremento en la complejidad de la aplicación que puede que no sean sostenibles (al cliente, es posible que no le haga mucha gracia saber que te has gastado una buena parte del presupuesto para implementar una funcionalidad, cuando todavía existen otras muchas por hacer).

Hay que tener en cuenta que el que realiza la solicitud probablemente no sepa las implicaciones que tiene lo que ha pedido y lo mismo considera válidas otras alternativas más simples.

No se trata de no hacer lo que nos piden, sino de buscar la solución más eficiente y productiva para todos.

– Se confía tanto en el criterio de alguien del equipo de proyecto, del área usuaria o el cliente que se decide aplicar la solución propuesta sin aplicar prácticamente ningún filtro sobre la misma.

– El director usuario o el cliente no atienden a razones, quieren lo que piden de una determinada manera y no quieren conocer otras alternativas (por más que se les insista).

En esta situación, lo mejor es dejarle muy claro al que lo ha pedido, los costes que tiene y el impacto en el producto (e incluso en el proyecto). Por tanto, todo por escrito, tanto la solicitud, como la previsión de costes e impacto (lo más probable es que en el futuro haya problemas y es necesario que quede delimitada la responsabilidad).

El desarrollo de software, dentro y fuera del ámbito de un proyecto es el resultado de una serie de decisiones que son llevadas a cabo por diferentes personas. Este proceso trata de formalizar la toma de decisiones en la búsqueda de la unificación de criterios.

En el nivel 3 de CMMI las áreas de proceso tienen un alcance organizacional por lo que tiene sentido que se trate también de armonizar y homogeneizar determinados tipos de decisiones alejando la misma de interpretaciones o varas de medir personales y traspasándolas a un entorno repetible y más objetivo.

Que se plantee un área de proceso de estas características no nos debe resultar extraño, ya que estamos acostumbrados a que un jefe de proyecto o un gerente tome una decisión y el de la mesa, despacho o sala de al lado, para un mismo asunto tome la contraria.

Pero, ¿hasta dónde llegar? Sobre el papel no hay limitaciones, por lo que podría extenderse hasta a decisiones de bajo nivel, sin embargo y desde mi punto de vista, no resultaría operativo ni ágil y desaprovecharía el talento de las personas. No obstante sí que tiene sentido para decisiones de más alto nivel, para intentar darle un enfoque más objetivo y dotarlas de un mayor nivel de transparencia, como por ejemplo, la selección de un proveedor, de un producto, de si se apuesta o no por presentarse a una determinada licitación pública, la selección de una arquitectura en un proyecto (cuando existen diversas posibilidades que podrían ser válidas), etc…

En este área de proceso, se definiría el alcance del mismo, los criterios y métodos/procedimientos de evaluación para cada una de las actividades o tareas que requirirían un proceso de análisis de la decisión, el procedimiento para identificar las posibles alternativas de solución, cómo realizar el proceso de evaluación de las mismas y de la selección de la más adecuada.