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.