archivo

Archivos Mensuales: mayo 2014

Siempre existe la posibilidad de que te toque la lotería (si la juegas) pero en el desarrollo de software lo mejor es no dejar cosas al azar.

Cuando de manera desestructurada “sueltas” a un conjunto de personas en un proyecto sin analizar si realmente tienen la capacidad para llevarlo a cabo, estás esperando prácticamente que el azar haga que las cosas vayan bien, para ello, sería necesario entre otras cosas que dicho grupo se autoorganizase de manera adecuada, fuera capaz de motivarse y ser más productivo y de tener la resistencia necesaria para hasta adquirir las habilidades requeridas (no solo técnicas) para sacar adelante el trabajo. Esa transformación es posible pero muy complicada.

Ese grupo, además, contará con muy poco apoyo de la organización, salvo que sus resultados sean lo suficientemente llamativos, ya que poco se puede esperar de quiénes han confiado de manera tan pobre en el proyecto y no le han dedicado lo que necesita.

En el caso de que ante tantos obstáculos se consiga el éxito hay algo de lo que no tendrá que preocuparse ese equipo y es el de levantarse temprano el día que repartan las medallas ya el día anterior los mismos que los pusieron en el disparadero se la habrán llevado todas.

La intención es la realización de acciones como resultado de una reflexión previa basada en hechos objetivos que pretende mejorar el producto (incrementar su valor) en cada iteración.

Conforme nos salimos de esta definición más nos acercamos al extremo opuesto, la prueba y error (no necesariamente malo porque habrá circunstancias donde se tenga que optar por esa estrategia).

La intención, por tanto, es tomar decisiones con una cierta base y si se acierta con ellas el ratio valor/número de iteraciones crecerá.

La intención se nutre del feedback, de nuestro background profesional y de nuestra interpretación del contexto actual y de su posible evolución.

La intención no supone conocer de antemano el éxito o el fracaso de la aplicación de las acciones, ya que de lo contrario estaríamos hablando de certezas, pero sí supone tratar de jugar con las mejores cartas ya que así existirán más posibilidades de acertar.

No contamos con presupuestos ilimitados y se quieren resultados acordes a la inversión realizada, más pronto que tarde, si no se desarrolla con intención, empezará a no existir un equilibrio entre coste y consecución de objetivos, conforme la distancia entre ambos se haga más grande más posibilidad hay de que existan conflictos entre usuarios y desarrolladores, entre cliente y proveedores, los cuales, a su vez crean resistencias que complicarán más, si cabe, el proyecto.

Aplicar prácticas teóricas fundadas en procesos y procedimientos que quedan muy bien en los libros (cuando vienen de libros) sin tener en cuenta cuál es la realidad de la organización, su contexto, de las personas que tienen que participar en los mismos, de la realidad económica existente, no traerán resultados acordes a la inversión realizada, no solo para implantarlas y controlarlas, que lo mismo no es el mayor gasto, sino por el hecho de cumplirlas, por el sobreesfuerzo que hay que realizar y por la reducción de la flexibilidad a la hora de afrontar un determinado proyecto.

¿Qué aportan realmente esos procesos? No todo va a ser negativo, probablemente algunos de ellos sean muy beneficiosos, pero, ¿y todos los demás?. Generalmente, en lugar de entrar en un proceso de mejora continua en el que se de valor a lo que resulta útil y se modifique, descarte o cambie el enfoque de lo que no funciona, se tiende a mantener una línea continuista con cambios poco significativos, ya que la respuesta ante la crítica o las quejas por los procesos, será no tenerlas en cuenta, creando una brecha cada vez más amplia entre quienes definen esos procesos y quienes los tienen que trabajar.

De esta forma se seguirá de espaldas ante la realidad porque no se debe ignorar a quién trabaja con esos procesos ya que nadie mejor que ellos saben si se adaptan o no lo que le toca vivir todos los días y al cumplimiento de los compromisos adquiridos.

No siempre van a tener razón los desarrolladores, a veces, no tienen en cuenta determinadas necesidades organizativas. No se trata, por tanto, de decir a todo que sí, sino de tratar de buscar soluciones consensuadas, de esta forma sí será posible buscar una alternativa rentable, sostenible y que genere menos desgaste, que se siga adaptando con el paso del tiempo a los cambios de contexto y necesidades.

El proceso no asegura nada, en el mejor de los casos, si se ajusta a las necesidades de un proyecto, te marca unas pautas que te pueden ayudar, pero nada más. Si tratas de aplicar un proceso a todos los proyectos creyendo que conseguirás el éxito en la mayoría, te estás equivocando y no lo digo yo, lo puede decir la mayoría de los profesionales del sector.

Cuando se pone por encima de todo la calidad del proceso provoca, aún sin querer, que la calidad o el valor del producto quede en un segundo plano (si lo más importante es la calidad del proceso pondrás a personas que se encarguen de vigilar eso y su objetivo será ese y no que los proyectos vayan hacia adelante), porque se entiende que si existe calidad en el proceso, es decir, si se cumplen con todas sus pautas, cualquier buen cocinero puede sacar adelante el proyecto.

Es importante el matiz del buen cocinero porque cuando la aplicación del proceso no produce los resultados esperados siempre se echa la culpa al desarrollador ya que seguramente sus entregables no son buenos o no se ha sido tan riguroso en la aplicación de tal o cual aspecto del proceso.

No se trata de que no existan procesos, ya que la organización necesitará que existan algunos para armonizar ciertos aspectos en los proyectos y para su propia gestión económica, de las personas, del conocimiento, etc… sino de tratar de buscar los mínimos imprescindibles para conseguir ese propósito, permitiendo que los equipos que participan en los proyectos puedan tener la suficiente flexibilidad para aplicar las prácticas que el proyecto necesita y de realizar los ajustes que se requieran a lo largo del proceso de desarrollo.

Es complicado tomar tanto a nivel personal como a nivel de una organización la decisión de cambiar porque todo cambio, aún necesario, no es sencillo, sabemos lo que cuesta asumir los errores y/o salir de la zona de confort. A veces también resulta difícil cambiar sobre todo cuando cuentas con pocas alternativas.

Pero hay algo todavía más complicado que eso, una vez tomada la decisión del cambio mantener en el tiempo la fuerza y consistencia necesaria para no volver a la situación anterior o dejarlo a medias. En muchos casos el impulso inicial termina al día, semana o mes siguiente (o al segundo siguiente de haberse tomado la decisión).

Para cambiar no basta con pulsar el interruptor sino que es necesario mantener el dedo encima el tiempo necesario para que el cambio realmente sea efectivo.

El cambio no es sencillo porque no sabes realmente qué te vas a encontrar por el camino pero, en ocasiones, no te queda otra posibilidad que asumir ese riesgo cuando si permaneces inmóvil en la situación actual ves que va a ser complicado cumplir tus objetivos.

C. S. Lewis realizó la siguiente reflexión sobre este tema: “El mero cambio no es crecimiento. El crecimiento es la síntesis del cambio y de la continuidad, y donde no hay continuidad, no hay crecimiento”.

En el mundo del desarrollo de software el cambio resulta necesario porque el contexto tecnológico, clientes y competencia entre otras múltiples variables cambian, también muchos de tus objetivos.

La escritora americana Madeleine L’Engle realizó la siguiente reflexión (traducción libre): “Nuestro talento por sí solo no vale nada, lo que cuenta es cómo lo utilizamos”.

Y es así, aptitud sin actitud es talento desaprovechado. De nada vale tener la capacidad de correr deprisa si no te quieres mover o correr deprisa sin tener ningún tipo de control y sin saber a dónde ir.

Además, en el mundo del desarrollo de software no se trabaja solo, por lo que tu aptitud se tiene que poner a servicio del colectivo con el objeto no solo de hacer que los demás trabajen mejor sino para que las aportaciones de tus compañeros te permitan conseguir mejores resultados.

Talentos individuales pueden conseguir grandes resultados, hay muchos ejemplos, pero todavía hay muchísimos más, sobre todo cuando centramos el enfoque en servicios de desarrollo de software, en los que el talento sin una orientación adecuada y sin un deseo de colaboración con el resto de personas que participan en el proyecto no consigue solventar los múltiples problemas de diversa índole que se presentan.

El talento es importante pero también lo es la capacidad de trabajo individual y en equipo, la capacidad de comunicación y la capacidad de poder discernir entre objetivos individuales y objetivos el colectivo, ambos compatibles pero que tiene cada uno su momento.

Conseguir una mejora del Cycle time cuya repercusión en los resultados sea mayor que la inversión económica realizada y sin pérdida de calidad en el resultado final debe ser un objetivo de todo sistema de estas características (sea Kanban o cualquier otro que utilice estrategias similares).

De hecho la aplicación de Kanban pretende de entrada detectar qué aspectos están afectando al Cycle time y posteriormente detectar de la manera más temprana posible esos cuellos de botella (pretende, por tanto, detectar resistencias y atacarlas con el objetivo de reducir su impacto).

No podemos olvidar que lo más importante siguen siendo las personas, su interacción, sus conocimientos y su capacidad, factores que influyen notablemente en el Cycle time, además de otros aspectos, como los medios disponibles y la tecnología.

Tal y como decía en el primer párrafo, la mejora del Cycle time no debe hacerse a expensas de la calidad del software o al menos debe sopesarse qué supone una cosa y qué supone otra. De nada vale entregar antes pero que el producto resultante sea peor, se llega antes, pero después se tendrá que invertir esfuerzo en dar una solución a los defectos o a reenfocar aspectos funcionales o no que se podían haber hecho mejor si se le hubiera dedicado una mayor atención.