archivo

Archivos Mensuales: diciembre 2013

Comenta Mary Poppendieck que: “Si quieres saber lo que el cliente quiere, dale lo que crees que quieren y escucha lo que te tienen que decir al respecto”.

Esa es la esencia del feedback: el usuario da una especificación, ejecutas según la interpretación que has hecho de la misma, obtienes un resultado y el usuario opina sobre el mismo, solicitando aquellos ajustes que consideres necesario.

En el caso de que desarrolles un producto y no te bases en especificaciones directas, el proceso es el mismo.

Recuerda que el sistema que desarrollas no es para ti. Tal vez las decisiones del usuario no te gusten, tal vez pienses que hay otras soluciones más adecuadas, si es así, exponlas, porque lo mismo ese punto de vista no se ha tenido en cuenta, pero no las impongas o manipules para que ese sea el camino elegido. Todos tenemos derecho a equivocarnos, pero más quien paga.

El objetivo es incrementar el valor del producto y la mejor forma de hacerlo es centrarnos en quiénes van a ser sus usuarios porque son ellos los que van a tener que convivir con él todos los días.

Como vengo haciendo al final de estos tres últimos años, os pongo la lista de los 25 artículos más visitados desde que empecé con el blog. Os pongo los enlaces de acceso, por si os interesa leer alguno.

1.- Desarrollo de software. El analista funcional y el analista orgánico.
2.- Desarrollo de software. Ciclo de vida RUP (Rational Unified Process).
3.- Mantenimiento adaptativo.
4.- Las precondiciones y postcondiciones en los casos de uso.
5.- Ciclo de vida clásico o en cascada.
6.- Orientación al producto.
7.- La importancia de un buen análisis funcional.
8.- Mantenimiento correctivo y mantenimiento evolutivo.
9.- Ciclo de vida iterativo incremental.
10.- Delimitar el alcance del proyecto.
11.- Ahora más que nunca hay que mirar al software libre.
12.- Testing de caja gris (Grey box testing).
13.- Ciclo de vida por prototipos.
14.- LCOM4 y la falta de cohesión en las clases.
15.- Reducción de tiempos muertos.
16.- El papel de los usuarios en un proyecto de desarrollo de software.
17.- Tarjetas CRC.
18.- Empresas de desarrollo de software: ¿estructura vertical u horizontal?.
19.- Ciclo de vida en espiral.
20.- La crisis del software.
21.- La autonomía y la motivación.
22.- Desarrollo de software. Programación extrema (eXtreme Programming: XP).
23.- Testing de caja blanca.
24.- Pruebas de regresión.
25.- Mantenimiento perfectivo.

Si queréis consultar las listas de los tres últimos años:

Los 25 artículos más leídos de mi blog.
Los 25 artículos más leídos de mi blog II.
Los 25 artículos más leídos de mi blog III.

Querer automatizar el caso, “flujos de trabajo indisciplinados” como indica Larry Bernsteian, es perder tiempo, dinero y requiere un importante desgaste personal para llevarlo a cabo.

Tal vez se consiga poner en producción un producto pero el coste posterior que tiene su explotación y mantenimiento será muy importante porque llegado el momento las diferentes áreas usuarias afectadas querrán que el sistema funcione como ellos entienden que debe hacerlo, con una visión localista y no con una visión global, necesaria para un sistema que pretende ofrecer una solución de carácter horizontal.

Dado que en este tipo de circunstancias los responsables funcionales no impondrán un criterio, se ejecutarán muchos cambios en el sistema sin haber pasado un filtro que determine si realmente la modificación era necesaria y si llevarla a cabo afecta al funcionamiento de algún área usuaria que, cuando descubra que se han hecho esos cambios, entrará en rebeldía, solicitando que se vuelva a la situación anterior, que se le de una solución local o dejarán de utilizar la aplicación.

El sistema, cada vez tendrá más hilos y tuberías, estará lleno de excepciones y casos particulares, será mucho más grande y complejo y por tanto, su evolución y capacidad de adaptación al cambio será costosa y lenta.

Sabiendo que todo eso va a pasar, lo mejor es no abordar el desarrollo del sistema hasta que los procesos que se pretenden informatizar hayan quedado definidos adecuadamente y existan unos mecanismos que velen por su cumplimiento y mejora continua.

Para Bill Langley: “El plan de proyecto perfecto es posible si uno primeros documentos es una lista de todas las incógnitas”.

Quien no es consciente de eso realmente no es consciente de la realidad de un proyecto de desarrollo de software, ni.

Tampoco serán conscientes de que el objetivo final es conseguir el mayor valor posible del producto dentro del contexto en el que se ha desarrollado porque lo mismo el plan inicial impone restricciones que suponen una limitación o una resistencia si no se adapta a la realidad que nos estamos encontrando en el proyecto.

Y no solo se trata de que el contexto cambie y/o imponga una atmósfera diferente a la esperada, sino que también estamos las personas y no somos infalibles, los desarrolladores no lo son, los usuarios tampoco. Nos vamos a equivocar y por mucho que se pretenda prever eso, será muy complicado acertar cuándo, cuánto y cómo.

El equipo de proyecto debe aprender del negocio, de esta manera será mucho más efectivo. Saber para que sirve y la finalidad del producto en general y de las funcionalidades en las que trabajan en particular, permitirá abordar las tareas de manera más efectiva, con mayor perspectiva y hacer un testing mejor (es posible que el algoritmo parezca que funciona pero que después el resultado sea una barbaridad, el desarrollador si no entiende del negocio lo terminará dando probablemente por válido, integrándose en el producto y llegando también, en demasiadas ocasiones, a producción).

Esto rompe la línea tradicional de que el analista sea el único experto en el negocio. Tal vez sea quién más sepa pero, por supuesto, nunca debería ser el único, y en cualquier caso, la diferencia entre sus conocimientos y el resto debe tender a disminuir con el paso del tiempo.

No se trata de ninguna pérdida de tiempo, al contrario, los resultados demostrarán que este tipo de políticas es beneficiosa.

¿Se debe documentar ese conocimiento? Lo importante realmente es establecer unos mecanismos que permitan que el conocimiento llegue y que además se pueda constrastar su comprensión. El medio, si se consigue ese objetivo, será el que consideres más conveniente, efectivo y que requiera un menor esfuerzo.

Para Gordon Bell (traducción libre): “Todo gran desastre computacional es consecuencia de tomar demasiadas ideas y ponerlas en un solo lugar”.

O lo que es lo mismo, consecuencia de buscar soluciones demasiado complejas sin pasar por otras soluciones intermedias más simples y/o sin pasar por un proceso previo de filtrado que trate, tal vez, de ser menos ambicioso en alcance a cambio de un enfoque más realista y efectivo.

Tener un amplio abanico de ideas donde elegir es una situación preferible a la escasez de las mismas pero siempre y cuando se gestionen con moderación, a eso se refiere Gordon Bell con su cita.

Si se toman muchas de ellas de una sola vez, sin reflexionar suficientemente sobre las mismas (o incluso haciendo esa reflexión) corremos el riesgo de desperdiciar esfuerzo ya que es posible que la hipótesis o visión de partida sobre determinados aspectos del producto sea equivocada y nos haga tirar una gran cantidad de trabajo que se podía haber evitado realizar si se hubiera optado por un desarrollo centrado en lo realmente relevante.

Se hace testing para detectar defectos, por tanto, tendrán éxito cuando cumplen su propósito. Esta es la visión de Boris Beizer en la siguiente reflexión: “Un test que revela un bug ha sido exitoso, no al revés”.

Podemos centrar el testing en secciones del código o en funcionalidades donde existe menos probabilidad de que existan defectos y probablemente no estemos aprovechando de manera adecuada el esfuerzo o, al menos, no con la rentabilidad que supondría enfocarlo de manera adecuada.

Una versión de lo anterior es hacer un testing “cómodo” para cubrir el expediente, sin entrar en tareas de mayor profundidad.

La función del testing es encontrar errores, dado que los desarrolladores no somos infalibles, si no se detectan defectos deberíamos plantearnos si efectivamente el testing que estamos haciendo está siendo efectivo, sobre todo si después comprobamos cómo van llegando a producción en una proporción muy superior a la que debería ser y/o a la inversión realizada.

Se tiende a ir por el camino más corto que no es otro que conseguir facturación del cliente sea como sea: con funcionalidades que no necesita y/o en actividades que no generan valor. Esta cultura se ha consolidado en muchos proveedores de desarrollo de software, practicándola durante muchos años y no ha hecho otra cosa que hundir y desprestigiar nuestra profesión.

Sí, se ha ganado dinero con ella, pero la burbuja explotó hace años y ahora con la crisis económica nos está castigando con fuerza.

Se presiona para conseguir contratos, para conseguir beneficios, es normal, las empresas viven de eso, pero esa presión no debe justificar la elección del camino equivocado.

Soy de la opinión de que si se crea valor al cliente, si tiene retorno de la inversión, volverá a llamar a la puerta. Si en lugar de derrotas, los clientes contaran sus inversiones en software por victorias, no se lo pensarían tanto a la hora de tratar de conseguir ventajas mejorando o solicitando el desarrollo de nuevas aplicaciones.

Mary Poppendieck nos invita a que: “invirtamos el tiempo en lo que añada valor real al cliente”, creo que es un buen consejo.

Se pueden enumerar decenas y decenas de posibles situaciones que se pueden producir en un proyecto y que se podrían considerar riesgos, pero hay una que casi podríamos considerarla unánimemente cómo el principal factor de riesgo en un proyecto y es la falta de implicación del área usuaria.

Sin ellos no hay visión de las expectativas de producto por más que el equipo de proyecto cuente con personas con visión y experiencia sobre el negocio, porque una cosa es el proceso de negocio que se quiere informatizar y otra es cómo le gustaría al usuario verla ejecutada. Es posible que se acierte sin el usuario pero es más mucho más probable que se falle.

¿Y por qué el usuario no se implica?

– Se ha designado un responsable funcional o product owner que no quiere asumir sus responsabilidades o el trabajo que implica el mismo y la dirección del área usuaria no hace nada por arreglar esta situación.

– Puede darse el caso de que quiera hacer ese trabajo pero no se le han dado instrucciones precisas sobre qué tareas de las que tiene que atender son más prioritarias, por lo que tenderá a hacer las propias de su trabajo ordinario.

– También puede producirse el hecho de que sean sus propios jefes los que les obliguen a atender otras prioridades.

– Al área usuaria o al departamento TIC se les vendió un proyecto que pretendía cubrir una necesidad no existente y como tal, llegado el momento, se prefiere atender otras necesidades o trabajos más urgentes.

– El área usuaria apostó por el desarrollo ya que era una apuesta personal por parte de la dirección del área afectada y en un momento dado se produce un relevo en la misma que considera que existen otras prioridades.

– El área usuario y/o el responsable funcional se desaniman al no desarrollarse el proyecto según sus expectativas. Esto no quiere decir que se estén haciendo las cosas mal (que es posible) sino que no se han sabido gestionar sus expectativas,.

Causas puede haber muchas, pero el camino siempre debería ser el mismo en el caso de que se produzca esta situación y es que si no se consigue enderezar, lo mejor para todos es que se llegue a un acuerdo para dar por finalizado el proyecto y resolver el contrato (cuando proceda).

Decía el actor americano Bill Cosby que: “No sé cuál es la clave del éxito pero la clave del fracaso es intentar agradar a todo el mundo”.

Podrás empeñarte en tomar decisiones que gusten a todo el mundo o que no molesten a nadie, a veces conseguirás ese objetivo, pero en la mayoría de los casos habrá alguien que no esté de acuerdo con algo.

Y eso pese a que has filtrado tus actuaciones de manera que no has aplicado la estrategia idónea sino una edulcorada que será menos efectiva, por lo que al final es posible que no tengas ni una cosa (la finalidad que perseguías con tu actuación) ni la otra (que todo el mundo esté conforme con las decisiones que has tomado).

Se trata de ser pragmático. A veces la solución edulcorada será más positiva (que no más efectiva) y en otras ocasiones será un gran error. Hay que analizar todas las perspectivas posibles, desde el convencimiento de que no somos infalibles y que entre los extremos del vale todo y no vale nada encontraremos una solución adecuada.