archivo

Archivo de la etiqueta: usuario

En esa situación ideal de tener al personal que trabaja en un proyecto repartido entre varios y poder balancearlos en función de la carga de trabajo existente, los tiempos de espera no presentan mucho problema. Sin embargo, todos sabemos que es muy complicado (que no imposible), llegar a encontrarnos con algo así.

En los ciclo de vida clásicos, tal vez sea más sencillo encontrar ese equilibrio, porque por mucha agenda que haya, todos sabemos lo que suele pasar: El análisis, la construcción o ambos tienden a durar más de lo que se esperaba.

En los enfoques ágiles los tiempos de espera atacan directamente a la línea de flotación del propio planteamiento del proyecto porque rompe el ritmo y afecta al cumplimiento de los compromisos. Por otro lado, sabemos que no es productivo tener a personas compartidas entre proyectos que no tienen nada que ver entre sí y que lo mismo no es tan fácil o rápido recuperarlas cuando el proyecto vuelva a arrancar.

Por otro lado, resulta esencial que al comienzo de una iteración se tenga todo lo necesario para realizarla, soy muy pesado con este tema, porque he vivido en primera persona lo perjudicial que resulta no empezar con todo lo necesario porque resta flexibilidad a la hora de afrontar los trabajos y porque llegado un punto no se podrán cumplir con los compromisos adquiridos y os aseguro que nos lo demandarán y exigirán de igual forma que si hubiéramos recibido todo lo necesario al principio.

Por el bien del proyecto a veces será necesario romper esa regla pero esas excepciones debemos tratar que se conviertan en norma, porque no solo es responsabilidad de los desarrolladores que se cumplan los compromisos.

Llegar a producción da miedo. El área usuaria siempre tendrá el “síndrome de la última versión” y, por tanto, querrá incluir toda la funcionalidad que puedan y pondrán los umbrales de aceptación muy altos.

A los desarrolladores también les entra el pánico porque por muchas pruebas que se hayan realizado al producto es en producción donde se pasa el examen final, todo lo anterior son exámenes parciales que si bien hay que superarlos no tienen más trascendencia (y no con ello quiero quitale importancia) que crisis puntuales en el proceso de desarrollo.

Si hay presión en el desarrollo, no es comparable con la que se recibe si el producto llega a producción y es un desastre.

Esta situación puede eternizar el paso a producción en muchos proyectos de desarrollo de software.

Ante esto hay que reflexionar (usuarios y desarrolladores) sobre las características del sistema de información que vamos a poner en producción, si se trata del software de una central nuclear o un software crítico que puede poner en riesgo vidas humanas, la salud de las personas, el medio ambiente o la continuidad de la organización se puede entender que toda precaución es poca, pero fuera de ese círculo (que es la inmensa mayoría de los sistemas que se desarrollan) hay que evaluar el coste real que implica retrasar sistemáticamente un paso a producción por el intento de alcanzar una perfección que nunca se va a conseguir.

Ya lo dice Kent Beck: “No estar en producción es gastar dinero sin hacer dinero”.

Es importante diferenciar entre reconocer la necesidad y crearla. Lo primero es positivo, lo segundo solo es interesante si tu misión es vender productos o servicios.

En el desarrollo de software menos suele significar más e incrementar la complejidad de un sistema por incorporarle necesidades que no son reales no da buenos resultados.

Reconocer la necesidad es tener la capacidad de interpretar las expectativas del usuario. Es muy complicado conseguirlo a la primera, requiere su tiempo, se necesita conocer al usuario, a su negocio, realizar varias iteraciones y a partir de ahí empezar a crecer.

Una conocida cita de Charles Eames dice lo siguiente: “El reconocimiento de la necesidad es la primera condición para el diseño”.

La clave, por tanto, es la intención. Una cosa es que el universo de expectativas tarde en conocerse (e interpretarse) y otra es que desde un primer momento no intentemos hacerlo lo mejor posible con la información que tengamos. Si no se tiene suficiente información para acometer un desarrollo, aunque sea una primera iteración, lo mejor es esperar a adquirir algo más de conocimiento para empezar a reconocer cuáles son esas necesidades.

Os recomiendo la lectura del artículo: “Preparando el primer sprint“.

No digo nada nuevo si os comento que las mejores especificaciones de los usuarios van surgiendo conforme se va avanzando en el proyecto y se les empieza a despejar la niebla que se extiende por su visión de lo que debe ser el sistema de información.

En un enfoque clásico, pretender acertar desde una fase de análisis que se encuentra muy lejos del momento en que se va a poner el producto en producción es casi una quimera por mucho que se haya trabajado con prototipos y los desarrolladores conozcan bien al negocio y a los usuarios.

¿Cómo mantener una agenda de plazos y presupuesto si me cambian los requisitos? No se puede salvo que termines reventando al equipo y/o recortando el alcance (y calidad) del sistema de información y aún así probablemente te termines desviando en ambos.

Si nos quedamos con las especificaciones iniciales no se puede esperar un producto con un mayor valor que el que nos ofrecen las mismas porque estamos limitando el valor al no permitir cambios propiciados por el feedback usuario.

Por tanto, no solo nos estamos encontrando con una estrategia de desarrollo de software que se aleja de la realidad de los proyectos sino que, además, su orientación a la agenda, ofrece menos flexibilidad para incorporar valor al producto a lo largo del proceso de desarrollo.

Trabajamos para eso, para desarrollar software que funciona. Pero, ¿de qué se trata eso de que el software funcione?. Cada uno tenemos diferentes perspectivas de las cosas, esta no iba a ser una excepción, por lo que para cada uno el listón puede estar a diferente altura y no necesariamente (dependerá del momento del proyecto, del contexto, de las características del sistema de información, etc…) unos tienen que estar siempre equivocados y otros estar en lo cierto.

Siguiendo un enfoque iterativo incremental vamos a ir liberando diferentes versiones del producto hasta obtener una “versión final” (lo pongo entre comillas porque el software es generalmente objeto de una continua evolución por lo que se puede hablar de versiones finalistas de un proyecto más que versiones finales de un sistema de información).

Independientemente de que desde el primer momento intentemos liberar el mejor software posible (desarrollo con intención) es razonable pensar que en las primeras iteraciones de una aplicación el listón no esté tan alto, sobre todo en aquellos casos donde esas iteraciones no llegan a un entorno de producción o de llegar su uso está limitado a su evaluación y porque la incertidumbre y falta de acoplamiento (al proyecto y entre las personas) en los momentos iniciales hace que se falle más de la cuenta (desarrolladores y usuarios).

No se trata de relajarnos en las primeras iteraciones, no quiero decir eso, sino de entender que no todos los momentos del proyecto son iguales (ni todas las circunstancias). No hay minutos prescindibles en un proyecto porque lo perdido no se recupera y por ese motivo siempre soy partidario de ir con intención siempre sin olvidar y, eso es lo que quiero dejar patente, que como en toda carrera de larga distancia hay que saber regular (y que todas las carreras son diferentes).

Un software que funciona debe satisfacer las expectativas del usuario. Si no satisface sus expectativas tenemos un producto que hace cosas pero no tal y como las quiere el usuario. No se trata de términos absolutos sino que tenemos que tener en cuenta los umbrales, es decir, la liberación de una nueva versión puede que no deje totalmente satisfecho al usuario pero sí supere sus umbrales de satisfacción. Nuestro objetivo será que la “versión final” esté más cerca de la total satisfacción del usuario que de su umbral superior pero eso requerirá mucho trabajo, voluntad por parte de los usuarios para darnos su feedback y diferentes evoluciones del sistema.

Un software que funciona no debe quedarse solo con la parte visible del iceberg. La deuda técnica cuenta y mucho. El usuario no la ve, no la valorará y sin embargo condicionará la mantenibilidad del producto y la disponibilidad del sistema ante futuras evoluciones del mismo. Es posible que haya clientes que no la tengan en cuenta, en cualquier caso soy de la opinión de que los proveedores deben marcar unos estándares de calidad para los sistemas que desarrollan, como elemento diferencial respecto a los que no lo hacen.

Más allá de la deuda técnica se encuentra la mantenibilidad (un concepto más general). Un software que funciona debe ser lo más fácilmente de mantener posible (dentro del contexto en el que se ha realizado el proyecto) y eso va más allá de la deuda técnica pudiendo contemplar elementos documentales si así fuera preciso.

Un software que funciona debe tener también en cuenta aspectos no funcionales. Algunos de ellos están en la parte visible del iceberg (aunque tal vez en la parte de atrás, la que no se ve a simple vista o la que requiere más tiempo para ser descubierta) como por ejemplo el rendimiento o la disponibilidad y otros en la parte no visible como por ejemplo la seguridad.

Una de las labores más complicadas de un gestor de proyectos en aquellos casos en los que existen múltiples equipos de trabajo que pueden pertenecer incluso a proveedores diferentes (tampoco resulta sencillo hasta en aquellos casos en los que existe un solo equipo formado por pocos desarrolladores) es que todos comprendan cuáles son los objetivos y las restricciones que existen para alcanzarlos.

Resulta especialmente complicado sobre todo en aquellos equipos que están desarrollando funcionalidades o herramientas complementarias al núcleo el sistema, en primer lugar porque la atención del gestor estará más orientada a la línea principal de desarrollo del producto así como a eliminar o paliar las posibles resistencias que puedan existir en cualquiera de las distintas líneas y en segundo lugar porque, por el mismo motivo, se encontrarán a distancia del product owner y de los directores usuarios y contemplarán desde más lejos sus expectativas y su presión.

Hay proyectos donde el trabajo de estos equipos secundarios es igualmente secundario pero en otros casos el resultado de su trabajo puede ser esencial para el funcionamiento y/o para la puesta en marcha del sistema. Tanto en un caso como en otro (aunque por supuesto mucho más en el segundo) es necesario que esos equipos mantengan el enfoque y la tensión en el proyecto, de la misma forma que lo hacen aquellos equipos que están peleando con las partes más críticas del sistema.

Como decía, esto no es fácil, ya que resultaría fundamental que el product owner y los directores usuarios les expresasen directamente y de forma constante (continua) sus expectativas y eso es algo que resulta complicado en proyectos con una cierta envergadura. Ahora bien, si no es posible llegar a eso cualquier aproximación ya supone un avance. Si el equipo no termina de asimilar la situación, el gestor de proyectos debe actuar y en estos casos es mejor un falso positivo (pensar que el equipo no es consciente de la situación e insistir) que creer que se ha asimilado y no actuar.

Cuantas más personas se suban al barco más posibilidades hay de sacar el proyecto adelante, sin olvidar que hay que procurar que quien suba no vuelva a bajar (de ahí la importancia de las actividades necesarias para que los equipos y los desarrolladores mantengan el enfoque en el proyecto).

Existen requisitos que tardan en salir a la luz. A veces el usuario lo da por entendidos, en otros casos se da cuenta más tarde o bien se trata de ajustes sobre alguno de los ya especificados.

Es complicado traducir la imagen abstracta del sistema de información que el usuario tiene en la cabeza que en la mayoría de los casos está como cubierta con niebla y que solo se empieza a ver con claridad cuando nos aproximamos a ella (conforme el usuario tenga más claro el producto final con el que se va a encontrar).

Es importante sacar cuanto antes estos requisitos ocultos a la superficie porque a su vez pueden sacar a la luz otros requisitos ocultos y porque pueden tener importancia en el resultado final del producto. Para ello es importante aplicar enfoques iterativos incrementales para que en cada iteración el usuario esté más cerca del producto final y empiece a ver con mayor nitidez determinados aspectos del producto que está esperando así como aplicar otras estrategias o instrumentos como puede ser el prototipado.

Si el usuario no solicita cambios sobre las especificaciones iniciales es una señal de alarma ya que lo más probable es que no haya dedicado suficiente atención a la especificación de los requisitos, a la revisión de los mismos o a las diferentes iteraciones del producto que se están liberando. ¿Es posible que se haya acertado a la primera? Sí, es posible pero yo por si acaso pondría un intensa luz parpadeante de color rojo como alarma.