El peligro de utilizar el dinero como motivador

Utilizar el dinero como motivador suele ser eficaz a corto plazo, a medio y largo plazo resulta fatal para tu departamento u organización.

¿Por qué? Pues porque lo excepcional se convierte en costumbre y al cabo del tiempo ya no será suficiente para motivar o no tendrá el mismo efecto. Además, en el momento en que falta ese ingreso se suele obtener el efecto contrario: reducción del rendimiento por falta de motivación.

De esta forma se crea en la cultura de que lo que realmente mueve a los profesionales de la organización es el dinero y no el interés por el trabajo que se realiza en la misma, el propio afán del desarrollador por mejorar o la pasión que puede sentir por su profesión.

Otro problema lo tenemos en que la persona tenderá a ir a por los objetivos que le permiten obtener la recompensa, dejando de lado otros que pueden ser igualmente importantes para la organización. La persona se convierte en cumplidor pero en cumplidor de lo que le interesa, de lo que le hace ganar más dinero.

Estoy hablando de recompensas sistemáticas y no de retribuciones justas. Soy de la opinión de que un profesional debe estar pagado acorde a sus méritos, conocimientos y experiencia (aunque raras veces se pague a los profesionales siguiendo esos criterios). Tampoco estoy en contra de las retribuciones variables siempre y cuando las mismas se realicen siguiendo criterios objetivos y estén al alcance del conjunto de empleados de la organización.

La transformación requiere cambios

La transformación, al adaptación al cambio, la aplicación de un nuevo enfoque, implica el abandono de un modelo, de una serie de prácticas, de una cierta manera de hacer las cosas.

No se trata de abandonarlo todo, no se trata de empezar de nuevo, sino de saber que el cambio solo viene a través del cambio y que, por tanto, no es posible alcanzarlo si en lugar de mirar adelante, no dejas de mirar atrás. Llévate en tu mochila todo tu conocimiento y experiencias y todo aquello que pienses que te puede resultar de utilidad en el viaje, pero ten en cuenta que su capacidad es limitada y que tendrás que renunciar o prescindir de prácticas o conductas antiguas para dar espacio a lo que viene a sustituirlas.

La agilidad requiere tener esa capacidad. En el proceso de adaptación al cambio tendrás que mirar dentro de ti, dentro de los proyectos en los que has participado y verás cosas que no te gustarán, de errores que cometiste y que te hacen ponerte las manos sobre la cara, debes entender que es parte del proceso y que nadie es infalible y debes comprender que han sido parte del camino que te ha llevado hasta aquí y que te han dado el suficiente conocimiento y madurez para ser mejor.

Frederick Brooks. La documentación y la visión global del sistema

Comenta Frederick Brooks en su libro «The Mythical Man Month» que: «La mayoría de la documentación falla en que se da muy poca visión global. Se describen los árboles, se comentan la corteza y las hojas pero no hay un mapa del bosque».

Estoy bastante de acuerdo con esa afirmación ya que resulta complejo obtener una visión global del sistema simplemente con la lectura de la documentación del proyecto porque como dice Brooks la información está segmentada y se describe con más o menos detalle cada uno de esos segmentos pero no el funcionamiento en conjunto de todos ellos.

Y todo esto en el caso de que haya alguien que revise la documentación de manera más o menos concienzuda, porque esa es otra, se pueden invertir innumerables horas de trabajo en tratar de hacerla con la mayor calidad posible, pero al final hay personas que tienen que leerla y entenderla y no suele haber gente con mucho tiempo y/o paciencia para iniciar sobre ella un proceso iterativo de revisión y mejora.

Esto es un problema importante cuando se desarrolla basado prácticamente en exclusividad en la documentación y no se suple esa carencia a través de la comunicación con personas que puedan ofrecer la información necesarias para cubrir los huecos en la misma lo que provoca generalmente problemas de coherencia en el sistema y aspectos funcionales a los que el desarrollador da una solución sin entender realmente qué lugar ocupa esa funcionalidad dentro del sistema.

La solución, como comento en el párrafo anterior, es la comunicación y además (y en lo posible) en explicar lo que tiene que hacer el sistema y las expectativas del usuario a quien no haya tenido la oportunidad de conocerlo, algo que generalmente (y desgraciadamente) no se suele hacer.

Desarrollo de software. Sprints, materia prima y área usuaria

Si se orienta el desarrollo a sprints (hay que tener en cuenta que el enfoque iterativo incremental es en sí un concepto más amplio) es, entre otros motivos, para conseguir un ritmo sostenible en el desarrollo.

Por eso cada sprint requiere tener preparada de antemano la materia prima, es decir, todos los inputs que necesita para poder ser completado, de lo contrario se tendrá que invertir tiempo en él para obtener esa materia prima, con el riesgo de producirse bloqueos por falta de esas entradas, lo que lo hará menos productivo y menos predecible en cuanto al cumplimiento de los compromisos.

Nos quejamos muchas veces y con razón de la falta de medios económicos para llevar a cabo el proyecto (acorde a las expectativas puestas en él y los plazos) y también de la falta de colaboración del área usuaria. Sobre esto último pocas veces nos paramos a pensar en los motivos que hacen que los usuarios no colaboren.

Uno de ellos puede ser precisamente la falta de medios para proporcionarnos la información y entregables que, una vez interpretados, conforman la materia prima de cada sprint. Es decir, muchas veces el product owner quiere pero no puede.

Se sobreentiende que quien contrata el trabajo ha tenido en cuenta esa carga de trabajo adicional (que en función del tipo de proyecto puede ser muy grande para las personas implicadas), sin embargo no es lo normal, ya que se piensa que con apoyos puntuales es suficiente, creyendo que el equipo de proyecto puede con todo y no, no puede, y si me apuráis, no debe, porque la carga de especificación del sistema debe recaer en el área usuaria.

Las consecuencias de esto es que determinadas tareas del sprint no estarán lo suficientemente definidas y eso hace mucho daño a esta dinámica de trabajo, tanto que nos deberíamos plantear, probablemente, objetivos menos ambiciosos.

Os indico a continuación algunas alternativas y aunque soy de la opinión de intentar reconducir la situación, no siempre va a ser posible:

– Adecuar la capacidad del equipo de proyecto a la carga del área usuaria. De nada vale tener una maquinaria capaz de producir x productos al día si solo entra material para producir x/4 productos.

– Plantear un enfoque iterativo incremental con fases de definición (con el nivel de detalle suficiente para el proyecto y la iteración) entre sprints. En este caso es más impredecible la duración de la fase de análisis pero más predecible la construcción.

– No plantear sprints propiamente dichos y aplicar estrategias de gestión del flujo de trabajo y del WIP (Work in progress), como por ejemplo, definiendo límites en el número de elementos terminados y no pasados a producción o dejando ese aspecto abierto y limitando el número de tareas en fase de análisis.

Desarrollo de software. Estrategias ágiles, implantación, formación

Cuando se quieren implantar estrategias ágiles de trabajo suele ser el resultado del impulso de una serie de personas que creen en ellas (otra cosa es que las entiendan, cosa que como he comentado es esencial para que a medio plazo no tengamos lo mismo que antes solo que con otros procesos, tal vez más apropiados a la naturaleza de los proyectos de desarrollo de software pero al fin y al cabo vistos exclusivamente como procesos y no como estrategias, herramientas o actitudes) y que se han preocupado de formarse por su cuenta (generalmente) o porque alguien en la organización ha tenido curiosidad y/o interés en que se formen en esto.

Todo cambio suele venir del impulso de una o varias personas, no se trata por tanto de una excepción, ¿dónde podemos encontrar el problema? Pues que la formación y el conocimiento se quede en ellas y en unas cuantas personas más que se encuentren próximas a ellas o hayan mostrado interés en esta dinámica de trabajo.

Esto no debe ser así, la implantación con efectividad de estrategias ágiles requiere que las personas que trabajan con ellas estén debidamente formadas para que puedan entender por qué se actúa de esa forma y para que ellos también puedan contribuir al correcto funcionamiento de las mismas y a su mejora. Si no lo hacemos se pierde eficiencia, el equipo está menos involucrado en la dinámica de trabajo (muchos pensarán que se trata de un capricho o de un juego) y se pierde la capacidad de que otras personas aporten su visión.

Se cree que con que unas cuantas personas estén formadas es suficiente y no es así. Es cierto que con algo hay que empezar pero tras el impulso inicial es fundamental que la formación y el conocimiento llegue al mayor número de personas posibles, priorizando aquellas que vayan a empezar a trabajar con este enfoque.

Bertrand Meyer. La complejidad es enemiga de la calidad del software

Comenta Bertrand Meyer que: «El único gran enemigo de fiabilidad (y tal vez de la calidad del software en general) es la complejidad», y tiene gran parte de razón.

La complejidad en sus dos vertientes: incluir funcionalidades no necesarias (o hacer más complejas funcionalidades que sí son necesarias) y descuidar la arquitectura y construcción del software haciendo el software mucho más complicado de evolucionar (mayor esfuerzo y mayor probabilidad de errores).

Tenemos que aprender a ser pragmáticos, a dejar de construir la casa por el tejado, a querer rizar el rizo sin ni siquiera tener el producto funcionando y todo ello sin olvidar que si no se construye software de calidad estamos poniendo resistencia y frenos a la capacidad de adaptación y evolución del sistema.

Una solución más compleja no tiene por qué ser mejor, una solución con más funcionalidades no tiene por qué ser mejor y una solución que esté a lo último en tecnología no tiene por qué ser mejor. Lo de menos es más, no es tampoco ciencia exacta, pero la verdad es que funciona más veces de lo que creemos.

Si desarrollas una solución demasiado compleja, al final pasa como con los mandos a distancia, muchos botones, muchas funciones, pero al final no utilizas ni el 10% de ellas.

Por otro lado, añadir complejidad de manera sistemática sin tener el producto en producción supone prácticamente comprar toda la taquilla para un más que probable fracaso y con poco margen de maniobra posterior, ya que tendremos un software mucho más voluminoso que mantener (y con una mayor deuda técnica ) y habrá menos recursos económicos para hacerlo.

Desarrollo de software. Sin implicación del cliente o área usuaria no hay nada que hacer

Contra esta situación no hay metodología o estrategia que la resista, sin buenas especificaciones el producto final se encontrará lejos de las expectativas del usuario, sin colaboración efectiva de un responsable del producto por parte del área usuaria no habrá un buen feedback ni una buena priorización en la línea de desarrollo de la aplicación, sin un usuario que esté accesible se producirán fases de bloqueo en el proyecto que en muchos casos (la mayoría) solo se resolverán tirando hacia adelante.

Y no es que no puedas hacer un buen análisis, ni siquiera vas a poder hacer una buena definición de sprint. ¿Qué pasa al final? El presupuesto se ha esfumado y el producto está todavía a medias o no hace lo que el usuario quiere, esto es igual a mucho desgaste y a pérdidas de dinero por ambas partes.

Es cierto que los desarrolladores hemos hecho mucho daño al negocio del desarrollo de software pero las personas que se han designado como responsables del producto por parte de los clientes también.

Y este problema lo tenemos tanto en enfoques clásicos como en enfoques ágiles de desarrollo de software porque en ambos casos necesitamos al usuario.

Un proyecto de desarrollo de software requiere que los responsables del producto estén muy implicados y con una alta dedicación al mismo, si la persona designada no puede dedicar ese tiempo necesario lo mejor es que delegue el día a día en otra persona dándole autonomía para la toma de decisiones (independientemente de que determinadas cuestiones las deba consultar).

Si no es posible de ninguna forma asegurar esa dedicación habría que pensarse muy seriamente por ambas partes si merece la pena afrontar el trabajo y si por el motivo que fuera se tuviera que llevar a cabo habría que explicar muy claramente los riesgos y las consecuencias de esta incertidumbre y falta de implicación en los costes finales.

Desarrollo de software. La documentación no debe sustituir a la comunicación

Cuando se elabora una documentación, como por ejemplo un catálogo de requisitos o una historia de usuario, se parte de una persona o grupo de personas que comunican en ese instante su visión del producto, de una funcionalidad o de una característica (se trata de una concepción abstracta por lo que ahí ya hay una diferencia entre lo que realmente necesitan y en lo que creen que necesitan), esa visión es transcrita por una persona o por un grupo de personas desde la interpretación que hacen de las mismas (por lo que también se pierde información), teniendo en cuenta que en el propio proceso de pasar esas ideas a lenguaje escrito también se pierden matices.

Esa documentación posteriormente es interpretada por las personas que la leen, por lo que, si nos ponemos a analizar, hay una diferencia (en unos casos más sensible que en otros) entre lo que se quiere y lo que se interpreta finalmente, y el documento, aunque deja constancia por escrito del trabajo que hay que realizar, es un elemento que introduce ruido sobre el objetivo final.

Por tanto, el documento no debe sustituir a la comunicación, sino que es en todo caso un instrumento en el que debe apoyarse la misma. Es un error pretender que los documentos sustituyan a la relación entre las personas porque de ser así, perdemos información, perdemos precisión y existirá desviaciones entre lo que se quiere y lo que se obtiene finalmente.

Todavía más duro resulta en contextos cambiantes o en productos que por sus características o complejidad requieran un feedback continuo del usuario, ya que resulta complicado dar una respuesta adecuada si tenemos que estar trabajando exclusivamente con pesados documentos que van de aquí para allá.

Simplifica primero, desarrolla después II

Algunos de los lectores habituales de este blog se preguntarán: «en un proyecto de desarrollo de software, ¿no tenemos que estar siempre atentos (alertas) a la necesidad de adaptarnos al cambio?, ¿no es la rápida capacidad de adaptación una ventaja competitiva?, ¿por qué haces un planteamiento tan rígido?».

Por este motivo me he decido a darle una segunda parte al artículo publicado ayer.

Una organización siempre tiene que estar atenta a la oportunidad y a los movimientos del mercado. Llegar antes que los demás, si se aprovecha adecuadamente, te puede hacer ganar mucho dinero. Llegar un poco tarde te puede convertir en algo insignificante.

Esto es evidente y en nada contradice con lo comentado ayer. ¿Qué quise decir? Algo tan simple como que el desarrollo de software no hace milagros y que la agilidad es efectividad e intención. Una cosa es que un proceso tenga que cambiar para adaptarse a un nuevo contexto o para adelantarse o coger ventaja a la competencia y que eso pueda suceder en cualquier momento (cuando surge la oportunidad) y otra que tengamos que partir con unas condiciones que se sabe que no llevan a ningún sitio.

Para competir tienes que funcionar bien, si organizativamente eres un desastre difícilmente puedes competir con alguien, salvo que tengas un gran producto y/o unos grandes clientes (que en ningún caso van a ser eternos).

El software debe ir después de ese trabajo de reingeniería y a partir de ahí crecer (y cambiar, si es necesario) juntos. Si lo haces antes puede suponer una resistencia ya que tienes que repartir el enfoque entre los cambios organizativos y el desarrollo de software (perderá siempre el proyecto) y el coste será mayor.

Desarrollo de software. La fase de testing en el tablero de Scrum o Kanban

La definición del flujo de trabajo es algo que está abierto y es lógico que así sea porque cada equipo de trabajo y cada proyecto tiene sus peculiaridades.

Es frecuente encontrarnos con tableros que no tienen una fase para el testing y suele ser provocado porque se entiende que de manera implícita se encuentra en la fase de realización, construcción, desarrollo o como se quiera llamar.

Conociéndonos como nos conocemos los desarrolladores y nuestras prácticas habituales de no probar de manera adecuada los componentes que construimos es una buena idea incluir una fase de testing de manera explícita. Es cierto que no te asegura nada (hacer testing requiere de disciplina y buenas prácticas) pero el simple hecho de considerarse una actividad y visualizarse es algo que tiene mucha fuerza.

Por ese motivo, aunque creas que la inclusión de esa fase no aporta nada, prueba a hacerlo y tras un tiempo, trata de sacar conclusiones de manera objetiva a través del número de defectos que se hayan conseguido solventar antes de alcanzar producción en comparación con los valores que estuvieras obteniendo hasta ahora, a partir de ahí ya tendrás todos los datos necesarios para continuar con estas prácticas de manera general, en proyectos o sprints concretos o tomar la decisión de, como hasta ahora, no incluirla.