archivo

Archivos diarios: enero 9, 2012

También por el suelo… o en la papelera.

A este antipatrón se llega por la no asunción de sus responsabilidades por parte del área usuaria a la hora de definir las especificaciones del sistema, priorizar trabajos, responder dudas y realizar feedback.

Si se deja que el equipo de proyecto cubra los huecos en los requisitos el sistema solo cumplirá las expectativas del usuario por casualidad (es cierto que si se tiene en el equipo especialistas en el negocio se reduce el margen de error, pero no hay que olvidar que somos desarrolladores y nuestra visión es siempre de desarrollador, no de usuario).

Si el área usuaria no colabora tendremos una serie de requisitos (unos más completos que otros) y probablemente no exista una priorización de los mismos o la misma sea muy generalista, el efecto es como si tuviéramos una serie de requisitos en post-it esparcidos por una pared, sin orden ni concierto.

Cuando el área usuaria deja de colaborar o no lo hace de manera adecuada, hay que levantar la mano y escalar el problema a nivel directivo de los stakeholders ya que no se puede hacer un proyecto de espalda a los usuarios pese a que estos se la den al mismo.

Si no se pone remedio al final liberaremos un producto que rechazarán total o parcialmente los usuarios, que ahora sí, reclamarán aquel requisito que no se realizó, los que no se interpretaron de manera adecuada (algo que es tan malo como el propio hecho de que no harán feedback ni prestarán más atención que la simple advertencia de su no implementación, de aquellas funcionalidades no incorporadas en la versión liberada de la aplicación) y por qué se ha priorizado tal funcionalidad y no tal otra.

Por supuesto, no lo dudéis, todas las miradas se dirigirán a la parte más débil, el equipo de desarrollo.

No siempre vamos a tener la oportunidad de trabajar con tecnologías conocidas, pese a que siempre que sea posible resulta lo más recomendable ya que siempre será más fácil ofrecer resultados de calidad si estamos cualificados y experimentados en una determinada materia.

Sin embargo, puede resultar interesante aceptar determinados tipos de trabajos, ya sea porque el cliente y/o por la tecnología.

Ante esta situación se plantea la cuestión de cómo llevar a cabo la formación del equipo de personas que va a trabajar en el proyecto (o incluso ampliarlo a otras, aunque en principio no vayan a trabajar en él).

Este antipatrón hace referencia a determinadas malas prácticas que se realizan en este contexto (como he comentado, en algún artículo, como por ejemplo, “Desarrollo de software. Buenas prácticas y antipatrones“, lo que puede resultar algo positivo o negativo en general puede resultar todo lo contrario en una circunstancia determinada, lo importante es tener en cuenta esta información que procede de la experiencia y analizar si en tu contexto resulta adecuada o no):

– Contratar una formación sin haber precisado con cierta exactitud la materia sobre la que se desea la misma. Esto puede provocar que la formación no se enfoque de manera adecuada, tratando aspectos que no son necesarios en el proyecto o dejando fuera aspectos fundamentales.

– Contratar una formación sin tener referencias del formador, ya que lo mismo su nivel de conocimiento no es el adecuado a la naturaleza de la formación a impartir.

– Formar al equipo de proyecto completo de una sola vez.

Sobre esta última mala práctica se considera que lo ideal es formar a a pocos miembros del equipo y que estos sean los que trasladen la formación al resto de componentes.

Existen ocasiones donde tenemos que tomar decisiones en entornos complejos y de presión y en donde las variables necesarias para tomarla no resultan sencillas de recopilar, cuantificar o comprender.

En lugar de intentar tomar una decisión con los datos disponibles y basado en el conocimiento y experiencia de nuestros colaboradores y el nuestro, se trata de justificar la misma en base a unos factores presuntamente objetivos que probablemente se han obtenido siguiendo criterios subjetivos y con un esfuerzo innecesario del equipo de trabajo.

En un proyecto de desarrollo de software las decisiones son continuas, por lo que podemos imaginar los problemas que nos traerá la continua indecisión hasta que se obtienen los datos que se creen necesarios para la misma (teniendo en cuenta además que en muchos casos los mismos serán de una fiabilidad dudosa): muchas de las decisiones se tomarán a destiempo provocando bloqueos en el proyecto, tendremos a personal invirtiendo buena parte de su tiempo proporcionándonos los datos que necesitamos, etc…

Este antipatrón se puede relacionar con el del caballero de tres cabezas, solo que en este caso, la situación de indecisión continua no tiene por qué ser provocada por el estado de presión actual del proyecto y/o de tus superiores, sino que en la mayoría de los casos será el resultado de la falta de confianza del gestor.

Siempre me gustó mucho esta cita: “Si no tienes un buen sistema, asegúrate de que tienes buenos usuarios”.

He visto sistemas abominables que tienen un alto nivel de uso pese a las quejas de los usuarios, las cuales se convierten muchas veces en loas cuando se intenta sustituir por una nueva solución.

También he visto sistemas con un nivel de ejecución muy bueno que sin embargo han terminado en el limbo de las aplicaciones.

Los usuarios son uno de los factores clave para que el proyecto llegue a buen puerto y también para que sea un fracaso, condicionándolo por su aportación adecuada o no en el proceso de desarrollo y por su actitud tras la puesta en marcha.

La falta de confianza siempre resulta un problema porque no te permite trabajar de una manera ágil, ya que tendrás miedo en tomar decisiones y en ejecutar determinadas tareas.

Esa falta de confianza dentro de un equipo de proyecto da lugar a este antipatrón en el cual, antes de dar cualquier paso buscaremos la aceptación del cliente y/o del área usuaria, incluso para tareas que son obvias y/o de trámite y que no requeriría la participación de personal externo al equipo de proyecto.

También es cierto que esa falta de confianza también puede ser provocada desde fuera, ya sea desde el cliente y/o por los gestores de su propia organización por un exceso de control en los trabajos realizados y por medidas desproporcionadas en caso de decisiones o acciones erróneas.

A veces, también se alcanza este antipatrón de manera absolutamente voluntaria, es decir, busco la aprobación de todo lo que hago por lo que traslado la responsabilidad a un tercero.

Además de la falta de agilidad y continuidad en el trabajo que provoca este antipatrón, provoca esfuerzos innecesarios en stakeholders que tendrá como consecuencia, además del tiempo que pierden, interrupciones al no poder contestar siempre en un plazo razonable y pérdida de confianza en la capacidad del equipo de proyecto.

Está claro que hay dos extremos, el antipatrón “los clientes son idiotas” y éste y que por tanto, la solución se encontrará generalmente en un punto medio que no será otro que el más adecuado a la naturaleza del proyecto en el que estemos trabajando y al del grupo de personas que participan en el mismo.

Aunque sea de manera muy lenta, está cambiando el modelo de muchas empresas de desarrollo de software en las cuales el objetivo no es exclusivamente obtener beneficio caiga quien caiga, sino que el objetivo es obtenerlo a través de unos trabajos realizados con calidad que satisfagan las expectativas del cliente.

En esto ha tenido mucho que ver el hecho de que los clientes estén cansados de invertir cantidades importantes en desarrollo de software para obtener unos retornos de la inversión más que dudosos (que a su vez se dificultan por el hecho de tener que estar invirtiendo continuamente dinero en los mantenimientos de los sistemas de información) y por otra que los propios empleados de las empresas de desarrollo de software estén cansados de participar en proyectos en los que ellos mismos son conscientes que el trabajo que se está realizando no es el adecuado ya que se anteponen criterios económicos al cumplimiento de las expectativas del usuario, incluso en situaciones donde la obtención de un beneficio más que suficiente en el proyecto no requería de la adopción de ese tipo de medidas perjudiciales.

Por este último motivo están proliferando empresas de desarrollo de software pequeñas que resultan competitivas en determinados segmentos de mercado y que en el cara a cara y en las distancias cortas pueden competir incluso con gigantes del sector.

Está cambiando el modelo y las organizaciones que no lo vean y se adapten lo van a pasar muy mal. Curiosamente para muchas de ellas la situación de crisis actual les ha servido de temporal bote salvavidas, ya que la reducción de presupuestos en desarrollo y mantenimiento de sistemas de información les ha permitido justificar una política de precios en sus ofertas muy por debajo del precio del mercado y con riesgo, conocido, de Death March Project, lo que después además les ha servido de excusa para justificar la calidad de sus desarrollos y las peticiones de ampliación en el importe de lo inicialmente contratado.

Sin embargo, todo tiene un límite y estas organizaciones más pronto que tarde terminarán derrumbándose ante la pérdida de sus actuales clientes y de otros potenciales.

El cambio de modelo hacia uno orientado a cumplir las expectativas del cliente está ahí, tal vez no te afecte hoy, tal vez tampoco mañana, pero lo que es seguro es que te afectará, por lo que la única pregunta posible al respecto no es si te afectará, sino cuándo.