archivo

Archivos Mensuales: mayo 2013

Los detalles pueden parecer insignificantes. Pero la suma de pequeños detalles sí que terminan teniendo importancia.

Y ese es el problema de muchas organizaciones, que se centran en unos objetivos generales y enfocan su atención en conseguirlos, mirando solo hacia ellos y olvidando o dejando de lado, tareas, gestos, oportunidades, detalles al fin y al cabo, que tal vez no los considere importantes (otra cosa es que sí lo sean), pero que tarde o temprano terminan pasando factura.

Yamamoto Tsunetomo en el Hagakure consideraba que: “Si una alberga seguridad en sus cimientos, no se verá aquejado por pequeños detalles o asuntos imprevistos. Pero, al final, los detalles de todo asunto son importantes. El acierto o el error en nuestra forma de proceder se encuentra en los asuntos más triviales”.

Sobre unas bases sólidas preparadas para el cambio, los imprevistos hacen menos daño, pero su acumulación, junto a esos fallos y detalles que se consideran poco importantes y junto a esas decisiones incómodas que no se toman o se aplazan indefinidamente porque la situación actual permite no tener que tomarlas, pueden terminar haciendo la grieta lo suficientemente grande como para poner en riesgo que el barco siga a flote.

Watts Humphrey, presenta una visión pragmática de la innovación en la siguiente reflexión: “La innovación es el proceso de convertir las ideas en algo que se pueda fabricar y comercializar”.

La innovación comienza con una idea pero si no se ejecuta, no hay ningún cambio respecto a la posición de partida.

Si se ejecuta, has innovado, pero después puede pasar que no tenga repercusión comercial. A partir de ahí entra en juego lo que has tenido que invertir para materializar el concepto, los beneficios que has obtenido y la capacidad que tiene tu organización o tu, de tratar de sacar otros productos y/o de seguir intentando buscar mercado para el nuevo producto (tal vez la estrategia de venta no ha sido buena).

Dado que no la innovación no es tu monopolio, si tienes la idea, no la ejecutas (o no lo haces bien) u otro lo hace antes que tú (tal vez la idea no sea exactamente la misma o tan buena, pero es capaz de quitarte mercado), has perdido o tendrás que pelear mucho para remontar la partida. Tal vez tu producto termine siendo mejor, pero no siempre el mejor termina imponiéndose.

El trabajo no para, los proyectos en los que trabajamos siempre hacen que tengamos tareas pendientes. Surgen urgencias, para los jefes casi todo es crítico y lo que no lo era hace un tiempo lo es ahora.

Es como si estuviéramos en una rueda de un hamster y no pudiéramos parar, lo que nos obliga a estar continuamente mirando en el corto plazo, evitando que el fuego llegue a prendernos.

Llegar a esa situación es perjudicial para nosotros (también para la organización) y cuando se llega a ella hay que buscar soluciones.

En este tipo de contextos y fuera de él (en aquellos casos en los que una tarea no nos parece importante, aunque realmente lo sea) cobra mucha fuerza la siguiente cita de Bob C. Martin: “Despúes es igual a nunca”.

¿Quién no ha tratado de buscar más tiempo contestando un “después”, “más tarde”, “a corto o medio plazo”, “en unos meses”?, etc…, no hay más que escuchar a los políticos que cuando ven que sus previsiones no se van a cumplir siempre nos están emplazando al próximo semestre. No seré yo tampoco quién tire la primera piedra.

“- Hemos detectado que la aplicación ejecuta sentencias SQL muy pesadas que afectan al rendimiento de la base de datos”.
– Ahora mismo no podemos mirar eso ya que estamos tratando de cumplir con los compromisos del sprint”.

Ante ese ejemplo podemos adoptar diversas posturas: no dar importancia a lo que nos han comentado los administradores de base de datos o anotarlo como tarea a realizar (en la pila de producto o donde gestiones las tareas a realizar en un proyecto).

Anotar ya demuestra una cierta intención, otra cosa será buscar el momento adecuado, que llegará antes o después o tal vez nunca (porque no sea realmente tan crítico, porque existen otras prioridades o porque no tenemos medios).

Ambos enfoques tienen en común las personas y en ambos juega un papel esencial el responsable funcional, product owner, área usuaria o como lo queramos llamar, en función de como esté organizado el proyecto y la metodología o estrategia utilizada.

Da igual cómo trates de enfocarlo, da igual que tengas grandes técnicos ya que si el usuario no colabora lo más probable es que la partida esté perdida. Es cierto que queda algún as en la manga, como que haya en el equipo personas con un gran conocimiento del negocio y de la organización y/o que haya algún sistema previo o en otra organización que pueda servir de referencia y se acierte.

No obstante la realidad es que resulta muy complicado acertar de esa manera porque se está trabajando a ciegas, sin recibir un feedback adecuado que permita ir perfilando los resultados.

Generalmente se suele tirar hacia adelante y con las especificaciones que se han podido obtener tratar de conseguir unos resultados: el proveedor quiere facturar y el cliente justificar la inversión realizada (sobre todo cuando ya se ha invertido un porcentaje más o menos significativo del presupuesto).

En este contexto suelen perder los dos y si gana uno es en detrimento claro del otro.

Si gana el cliente es porque al final hay un producto que puede satisfacer sus expectativas y si se llega a eso, tras un inicio nefasto y si no se ha invertido más dinero es porque el proveedor ha terminado tragándose todo el problema, convirtiéndose el proyecto en un agujero sin fondo, que nunca acaba y que solo ocasiona pérdida tras pérdida.

Si gana el proveedor es porque todos asumen que lo importante es conseguir un producto final, quedando en un aspecto secundario que realmente satisfaga las expectativas. No digo que no se quieran obtener buenos resultados, solo quiero decir que llegado el momento, muchos implicados querrán salvar los muebles y verán como única salida llegar a entregar algo.

En estas situaciones, la mejor salida, si no se consigue revertir el problema de la falta de implicación del usuario y no se asume el coste (ya sea inyectando más presupuesto o reduciendo el alcance), es asumir lo que hay y cerrar el proyecto.

Poco importa el enfoque si el destinatario de la aplicación no pone el interés o la dedicación necesaria al servicio del proyecto.

Ya lo comenté en el artículo relacionado con el Desarrollo global del software. Soy partidario de que el equipo de desarrollo, responsables funcionales y en general, el conjunto de personas que participan en el día a día de un proyecto se encuentren lo más próximos posibles, si es en la misma sala, mejor.

Pero aún así es necesario tener la mente abierta y no descartar otras posibilidades que pueden ser de utilidad para el proyecto, teniendo en cuenta, además, de que la realidad que nos solemos encontrar es que los diferentes grupos de personas que participan en un proyecto no comparten ubicación física.

Independientemente de que crea (y eso es una opinión personal, que evidentemente puede diferir con la de muchos lectores) que el núcleo de cada equipo deba compartir espacio, sí que puede resultar de interés trabajar con determinadas personas que perfectamente pueden situarse en cualquier lugar del mundo y en las cuales confiamos en su trabajo y su compromiso y que se adecuarán a las necesidades que requiera el proyecto. Es cierto que con el mismo huso horario e idioma es más fácil, pero al final todo dependerá de la voluntad e interés de ambas partes en que la relación funcione.

Por ese motivo, resulta cada vez más común que determinadas empresas de desarrollo de software contraten a otras empresas más pequeñas o a freelancers para realizar determinadas partes de un desarrollo o como unos componentes más de un equipo de desarrollo más grande. Esto es ahora una tendencia y no para de crecer.

En un momento dado puede ser incluso una ventaja competitiva si con ello se ahorran costes, se contratan especialistas en tecnologías concretas y si permite que la organización crezca de manera sostenida (y no a impulso de proyectos concretos en un momento determinado del tiempo).

Es importante tener en cuenta que plantear una relación de este tipo requiere de confianza por lo que las referencias previas que se tengan sobre el freelance o sobre la empresa son importantes, confianza que después se deberá ver afianzada en los resultados que se obtengan.

Un factor a tener en cuenta también es que es importante que ambas partes encajen, es decir, lo mismo un desarrollador freelance hace estupendamente su trabajo pero no termina de encajar con la forma de trabajar o con el carácter de quien lo contrata.

No es posible dar una respuesta generalista ya que depende realmente de lo que impliquen esos plazos.

Si existe una imposición legal, la necesidad de informatizar o cambiar determinados aspectos de un proceso ya informatizado para poder responder o adelantarse a la competencia sí que tiene una gran relevancia los plazos, en caso contrario, los plazos, incluso siendo importantes deberían modularse también a las necesidades del producto (¿conviene, tal vez, esperar algo más de tiempo y poner en marcha un producto más maduro?) y a las contingencias que hayan podido ocurrir en el proyecto.

La gran ventaja que ofrecen las metodologías ágiles es que en cada iteración ofrecen una nueva versión del producto susceptible, en potencia, de pasarse a producción si así se decidiese. Hay que tener en cuenta que en determinados productos, se pueden tardar varias iteraciones en tener un núcleo mínimo que pueda ser totalmente funcional para ser utilizado en un entorno real, lo cual no quita que, ya sea en un entorno de demostración o incluso en producción, se pueda trabajar o prácticar sobre la versión con el objeto de obtener feedback lo más pronto posible.

Al plazo general del proyecto, se suman los plazos individuales de las iteraciones. Con el objeto de tener un ritmo sostenido de desarrollo, es fundamental que los sprints terminen en la fecha indicada, aunque haya algún compromiso que no se haya podido terminar por completo.

El problema de los plazos generales del proyecto lo tenemos en lo complicado que resulta alinearlo con la expectativa de lo que se pretende tener en el mismo y eso trasciende al hecho o no de tener versiones funcionales cada cierto tiempo, es decir, puede darse el caso de que no te sirva de mucho poner en marcha una versión dentro del plazo si la misma no se corresponde con las expectativas que había para ese momento del tiempo.

Pero tampoco se pueden pedir imposibles y si realmente los quieres, sufrirá la calidad del producto porque velocidades de desarrollo sostenidas en el tiempo muy por encima de lo que se puede producen ese efecto.

Cuando se trabajan con ese tipo de plazos es fundamental gestionar de manera adecuada las expectativas del área usuaria, ya que es muy posible que tenga que haber modificaciones del alcance y en más de una ocasión.

Es mucho mejor esa situación que el hecho de que el usuario o nosotros nos mintamos, mucho mejor entregar unos mínimos con calidad que un producto inestable, mucho mejor tratar de cumplir esos plazos que retrasarnos.

Ambas cosas. Una de las máximas de Steve Jobs era que “las funcionalidades esenciales de un sistema tenían que ser sencillas de utilizar por parte de los usuarios”, funcionalidad y usabilidad deben ir de la mano, si bien no siempre van al mismo ritmo, ya que generalmente la funcionalidad va por delante de la usabilidad y es en cierto modo lógico que así sea, porque si bien ambas se realimentan del feedback, hasta que no se va consolidando la funcionalidad, la usabilidad ocupa otro lugar en la escala de prioridades.

Lo anterior no quita que se deba desarrollar con intención la funcionalidad pensando en la usabilidad, si no se hace así, no solo se no se está sacando el máximo partido posible al esfuerzo que se está invirtiendo sino que puede darse el caso de que la funcionalidad tenga que cambiarse posteriormente para adaptarse a una usabilidad que no es posible conseguir con el enfoque inicial.

Esa intención se consigue trabajando con el usuario en la definición del sprint y tratando de aplicar todo nuestro conocimiento y experiencia para asesorarle, teniendo en cuenta que hay que tener la mente muy abierta porque no hay que olvidar que el sistema que estamos construyendo no es para nosotros sino para el usuario y que si el usuario, tras escucharnos, decide tomar un camino, hay que respetarlo por mucho que pensemos que se equivoca.

No son incompatibles decir que no y la agilidad, como tampoco es ágil decir a todo que sí. En el enfoque ágil se toman decisiones consensuadas, si bien, cada participante dentro de su ámbito de responsabilidad tiene la potestad de tomar sus decisiones dentro de las reglas del juego que se hayan establecido, es decir, un responsable funcional o product owner puede escuchar al equipo de desarrollo pero en última instancia es quien toma las decisiones sobre la línea de desarrollo y evolución del producto, o por ejemplo el equipo de desarrollo dentro del margen de maniobra que permitan ciertas restricciones tecnológicas es el que tiene la voz cantante en ese sentido.

Hay que tener en cuenta que se tendrán tantas percepciones diferentes de una situación o de un problema como personas intervengan en una toma de decisiones, a lo que hay que sumar también los intereses que existan: es razonable que un responsable funcional quiera que se asuma la mayor capacidad de trabajo posible con el objeto de avanzar más en los desarrollos y que el equipo de desarrollo quiera tener un margen de seguridad para tener más posibilidades de cumplir los objetivos a los que se han comprometido. Es razonable que un responsable funcional quiera determinadas funcionalidades o comportamientos que superan a la tecnología utilizada y que el equipo de desarrollo sea muy prudente a la hora de meterse por terrenos no explorados.

Para alcanzar acuerdos satisfactorios que es la situación real del proyecto en la que todos ganan (lo que no quiere decir que en cada decisión haya partes que se sientan más ganadoras que otras), hay un juego de síes y noes, unos razonamientos y una negociación. Esa debe ser la normal en el proyecto. ¿Qué a veces hay desgaste?, ¿qué a veces te puedes enfadar? Pues sí, pero este tipo de situaciones se terminan normalizando si tras todo esto hay una relación de confianza y respeto entre las partes.

En un proyecto de desarrollo de software la transparencia es sinónimo de liberación. Es cierto que se siente presión porque los responsables funcionales conocen la realidad del proyecto y no aquella que se le quiera, en un momento dado, vender, pero una vez que se asimila esta forma de trabajar, poder mirar a los ojos a los usuarios y que ellos confíen en tu trabajo crea un clima en el que, si bien no se asegura el éxito, sí que resulta mucho más efectivo.

No es cuestión de metodología, esto no va de eso, es cuestión de una actitud con respecto al proyecto y a los usuarios. Es cierto que ciertos enfoques como el ágil favorecen y a la vez necesitan este tipo de contextos pero en cualquier circunstancia es perfectamente aplicable.

Hacer visible los trabajos, hacer visibles los problemas, reconocer errores, de eso va esto, manteniendo una comunicación fluida con los usuarios y permitiendo que ellos mismos, sin necesidad de tu intervención, puedan obtener parte de esa información cuando ellos quieran. No se trata de microgestión, sino de abrir ventanas y que cuando quieran se asomen, la frecuencia con que lo hagan es cosa suya, si bien, no está de más, si notamos que no lo hacen las veces que debieran, recordarles que tienen esa posibilidad.

Un proyecto requiere la colaboración continua entre equipos y personas, sin confianza todo es más difícil, por lo que es necesario poner todos los medios que sean posibles para crearla y mantenerla (que es lo más complicado), la transparencia es una buena base para ello.

Transparencia absoluta y posibilidad de feedback dentro del sprint. Todo eso podemos conseguir si damos visibilidad al responsable funcional sobre el entorno de desarrollo.

Esto se puede hacer en dos niveles y dependerá del momento del proyecto si resulta conveniente hacerlo o no. En cualquier caso que el usuario elija. Un primer nivel es el entorno en el que se ve el día al día del desarrollo, en el que tendremos historias de usuario el sprint resueltas y otras que están en construcción. En un segundo nivel el entorno de integración en el que solo deberíamos tener historias de usuario resueltas.

Sobre esto puede haber opiniones para todos los gustos (y respeto todas), desde los que piensen que es contraproducente dar esta visibilidad, como los que crean que con que tengan acceso al entorno de integración es suficiente.

Solo con la posibilidad de obtener feedback que permita ajustar mejor determinados detalles ya estaría del todo justificado esta decisión. ¿Tiene sus riesgos? Claro que los hay, como puede ser el hecho de que el responsable funcional interfiera demasiado en el sprint, afecte al ritmo del equipo y por tanto al cumplimiento de los objetivos.

Esa interferencia puede ser provocada por su deseo de cambiar una historia de usuario en pleno sprint (una cosa es ajustar detalles y otra darle un enfoque sensiblemente diferente) o por sus nervios si no terminan de ver unos resultados de calidad (muchas veces esto es provocado por trabajar con un entorno inestable, por eso hay quienes defienden que visibilidad sí pero solo al entorno donde se muestren las historias de usuario completadas).

Ante esto, lo mejor es recordar al usuario cuáles son las reglas del juego y hacerlo cuantas veces sea preciso.

Si quiere cambiar una historia de usuario, mejor prepararla bien y que sea en el siguiente sprint, anulando por tanto esa tarea en el actual. Si piensa que no se van a cumplir con los compromisos del sprint se le dan las explicaciones que sean oportunas.