archivo

Archivos Mensuales: enero 2014

Para Peter Drucker: “No hay nada tan inútil como hacer eficientemente algo que no debería haberse hecho”.

El desperdicio de esfuerzo, en muchas ocasiones, tal vez la mayoría, realizado con la mejor de la intenciones, hace mucho daño a los proyectos de desarrollo de software.

Querer avanzar demasiado deprisa, desarrollando nuevas funcionalidades cuando hay otras que todavía no están maduras y que dependen entre sí, querer abarcar más de lo que se puede, trabajar con demasiadas hipótesis no validadas. Todo ello es susceptible y, de manera muy probable, de generar desperdicio.

Y no se trata de falta de interés, esfuerzo o competencia, sino de no saber administrar adecuadamente los tiempos, de no priorizar bien y de no saber decir que no.

Un enfoque iterativo incremental de ciclos cortos y el feedback que se obtiene a partir de ellos permite probar la efectividad de los enfoques de los usuarios (que inicialmente no son más que hipótesis sobre lo que quieren) y realizar ajustes que nos van acercando progresivamente a una solución que realmente satisface las expectativas del usuario.

En los enfoques clásicos las hipótesis no se compruebas hasta etapas finales del desarrollo en donde los presupuestos están casi agotados y en donde el tamaño del producto dificulta la realización de modificaciones. Menos dinero, más envergadura del producto, más deuda técnica, menos margen de maniobra.

Todos los que hemos trabajado con ciclos de vida en cascada y/o con contratos llave en mano hemos sufrido esa situación. Da igual lo bien que trates de hacer el análisis que siempre habrá funcionalidades que no se han definido correctamente, que ni siquiera se han definido o que son mejorables y, además, siempre existirán circunstancias a lo largo de la ejecución del proyecto que impliquen cambios de prioridades.

El conocimiento real del producto se va obteniendo conforme se va desarrollando, ¿por qué? pues porque se contrastan las hipótesis y con ello se va mejorando y adquiriendo nuevo conocimiento.

Está bien tener una visión de lo que se quiere pero el detalle se debe trabajar poco a poco, lo demás es correr un riesgo importante de desperdiciar esfuerzo y no nos podemos permitir ese lujo porque en el propio devenir del proyecto y del desarrollo del producto habrá esfuerzo que no proporcione un valor directo, ya que a veces la solución elegida para una determinada funcionalidad deberá cambiar de orientación o ser perfilada en diferentes iteraciones, algo que es normal en cualquier proyecto y que, por tanto, debe contar con suficiente respaldo presupuestario que, como no andará sobrado, es conveniente cuidarlo desde un principio.

Aunque la intención sea que sí la realidad es que no.

Se puede tratar de plasmarlo todo y por muy cuidadoso que se sea siempre habrá algún detalle que se escape. Y lo más importante de todo, cada persona que lea los requisitos podrá darle una interpretación diferente.

De hecho muchos líos que se montan en los proyectos son precisamente por eso, por interpretarse de manera distinta lo que se indica y por cubrir cada cual a su modo los huecos que no se han especificado de forma completa.

Por ese motivo, los requisitos, vistos como el traspaso de los mismos a un documento electrónico o digital es insuficiente si no vienen acompañados por un diálogo continuo entre desarrolladores, product owners, usuarios, etc…, por eso las historias de usuario están venciendo a los requisitos tradicionales ya que parten desde una perspectiva basada en la colaboración.

Pero no solo es eso, los requisitos parten como verdades absolutas, sin embargo, muchas de ellas van perdiendo fuerza conforme avanza la elaboración del producto, surgen nuevas necesidades, se redefinen prioridades y se descubre que diversas percepciones iniciales son incorrectas.

La novena actividad es la que se denomina: “Sé claro sobre lo que vas a proporcionar”.

En esta actividad se da un paso más en la gestión de las expectativas. En actividades anteriores se trabajó sobre las funcionalidades o sobre la tecnología, en este caso se pretende establecer el nivel de importancia, trascendencia y/o atención que se le debe dar al alcance, la inversión, los plazos y la calidad.

Además de esos parámetros principales, se pueden especificar otros que se consideren de interés para el proyecto.

La ficha que se obtiene como resultado de esta actividad es muy visual, tal y como se puede ver en la plantilla, de manera que se aprecia de forma muy clara, el nivel de importancia que se le da a cada uno de los parámetros.

Lo fácil es darle a todo el máximo nivel de importancia pero, como es lógico, esta actividad debe tratar de ajustar las expectativas a la realidad que va a tener el proyecto, es decir, puedes indicar que el alcance no es negociable, pero si sabes que va a existir una gran incertidumbre en el proyecto y/o no se tienen claro todavía determinados objetivos o cómo plasmar determinadas funcionalidades, tal vez sea conveniente modularlo y hacerlo más flexible.

Si, de verdad, se pretende realizar un proyecto con todos o algunos de los parámetros al máximo, algo que, ¿por qué no?, podría darse, se debe estar dispuesto a poner los medios necesarios para realizar el proyecto, siempre y cuando, el mismo pueda ser viable en esas condiciones.

Es decir, si los plazos son inamovibles, habría que estudiar si de entrada, los mismos son viables y qué se necesitaría para conseguir satisfacerlos.

La décima actividad es la que se denomina: “¿Cuánto va a durar esto?”.

De entrada puede considerarse una actividad parecida a la octava y en cierto modo lo es, solo que en este caso se trata de dar respuesta no solo a plazos sino también a costes y a las características que debe tener el equipo (tamaño, perfiles, habilidades, etc…), para cumplir los objetivos planteados.

En el caso de que las condiciones necesarias no se puedan cumplir se podría decidir la no realización del proyecto o bien, la necesidad de volver a actividades anteriores del Inception y replantear determinados objetivos y expectativas definidos.

La séptima actividad es la que se denomina: “¿Qué nos impide dormir?”.

Se trata de identificar los principales riesgos que puede tener el proyecto, es decir, aquellos que realmente nos preocupan, centrándonos en los que de alguna forma podemos manejar, gestionar o defendernos.

En este caso, se podría identificar como posibles riesgos, por ejemplo, que no exista un product owner que sea consciente del trabajo que debe realizar en el proyecto (o que siéndolo no se implique), que los procesos que se pretenden informatizar sean un caos en la actualidad, que el proyecto no tenga un respaldo económico suficiente, que los plazos sean demasiado rígidos, que el equipo de proyecto no disponga de personas con la suficiente experiencia y/o conocimientos en la tecnología, etc…

Como veis se pueden identificar riesgos que pueden ser atajados o gestionados antes de que el proyecto comience o que incluso hagan replantearse la viabilidad del mismo. Cualquier cosa mejor que iniciar un “Death March Project“.

La octava actividad es la que se denomina: “Estimar el tamaño”.

Se trata de establecer un orden de magnitud (deseable).

Dentro de ese esquema general se pueden establecer estimaciones parciales sobre determinadas actividades del proyecto, como por ejemplo, el tiempo en el que se espera tener la mínima versión viable del producto o determinados hitos de carácter funcional.

Con el resultado de esta actividad se podrá discutir si el tiempo necesario para obtener las diferentes versiones del producto resulta excesivo o no, si
se van a disponer de los medios necesarios durante todo ese tiempo, etc…

Puede darse el caso que, como consecuencia de esta actividad, sea necesario volver a otras anteriores para replantearse el alcance y/o la propuesta de solución planteada.

La quinta actividad es la que se denomina: “Conoce a tus vecinos”.

Se trata de identificar a los grupos, equipos o departamentos de personas que van a tener una vinculación con el proyecto que se va a desarrollar, como por ejemplo, usuarios del sistema, administradores de bases de datos, administradores de sistemas, administradores de comunicaciones, centro de atención a usuarios, etc…

El ejercicio, aunque simple, es bastante potente porque trata de poner sobre la mesa que para que un proyecto salga adelante se necesita de más gente que el propio núcleo del proyecto y que la participación de esas personas no será testimonial, independientemente de que algunas de sus actuaciones sean más o menos puntuales, debiéndose tener en cuenta las mismas en determinadas decisiones y mantenerlas informadas adecuadamente sobre la evolución de los trabajos (entrando más en detalle en aquellos aspectos que les afecten directamente).

La sexta actividad es la que se denomina: “Muestra la solución”.

Es la primera actividad en la que nos centramos en el cómo.

Básicamente se trata de dibujar un diagrama de despliegue (o similar) en el que se identifiquen posibles nodos físicos (o agrupación de ellos si se consideran infraestructuras cloud o de alta de disponibilidad) y servidores lógicos (web, aplicaciones, bases de datos, etc…).

Además se hará una reseña de las tecnologías que se prevén utilizar en la solución.

Todo a muy alto nivel.

En ese esquema o ficha que se obtendría como resultado de esta actividad, se podrían señalar explícitamente algunos aspectos de la infraestructura o de la tecnología sobre los que habría que tener especial cuidado o atención, pudiéndose indicar el motivo o también expresar cualquier aspecto de las mismas sobre los que en estos momentos existan dudas. También se podría indicar explícitamente algún elemento o tecnología que no se tendría en cuenta en la realización del proyecto, sobre todo si existe riesgo de que se produzca algún malentendido.

La cuarta actividad es la que se denomina: “Crear una lista lo que No es”.

La eficiencia va de la mano de la simplicidad y una variable que influye en la misma es la huída del desperdicio de esfuerzo, es decir, de aquellas funcionalidades que no son necesarias para conseguir el objetivo que estamos persiguiendo.

También permite protegernos de malos entendidos (al menos desde una perspectiva global del producto) ya que en este punto se discute qué no va a ser o a hacer el producto.

La técnica propone crear tres listas:

– Lista de funcionalidades que entran en el alcance.
– Lista de funcionalidades que no entran el alcance. Es la más importante de las tres, porque en ella se hace una primera criba.
– Lista de funcionalidades para las cuales no se ha decidido su inclusión en el alcance. Se trata de funcionalidades que si hubiera oportunidad (económica principalmente y plazos) se incluirían en el alcance pero que se consideran en este momento menos prioritarias y se dejan, a un lado, de momento.

En este momento, lo más normal es que las funcionalidades o historias de usuario sean de alto nivel. La pregunta importante que se debe resolver es si la no inclusión de una funcionalidad en la lista de funcionalidades que entran en el alcance rompe con la esencia del producto y objetivos que se pretenden conseguir.

Todavía no es el momento de entrar a confrontar lo que se quiere con la realidad presupuestaria y temporal pero sí que se debe tratar de hacer la lista con los pies en el suelo.