Desarrollo de software. Desapego a las recetas

Es posible que a lo largo de tu experiencia en proyectos de desarrollo de software hayas encontrado una serie de estrategias, prácticas, fórmulas, comportamientos, etc… que suelen producir buenos resultados.

Esa experiencia acumulada es positiva siempre y cuando se tenga presente que no se tratan de soluciones mágicas que funcionan siempre, independientemente de cualquier proyecto y de cualquier contexto.

Si se cree que se ha descubierto la piedra filosofal del desarrollo de software se corre un riesgo importante porque se deja de lado un análisis en profundidad de la realidad del proyecto en el que hay que trabajar y por otro se empieza a dejar de escuchar a los demás porque, ¿para qué? si ya sé todo lo que tengo que hacer para que el proyecto vaya hacia adelante.

Esto no solo desmotiva a tu equipo sino que te pone una distancia con respecto a él porque al fin y al cabo llegas a la conclusión de que tu eres el director de orquesta y autor de la partitura y ellos solo ejecutan y por supuesto si la música suena mal será porque los músicos no la saben tocar bien y/o porque el público no era el adecuado.

Lo realmente importante es la capacidad de analizar la situación de un proyecto, que puede ser la inicial o cualquier momento de su desarrollo, y saber elegir la mejor estrategia posible que podrá coincidir o no con las que ya conoces. Si te encierras en tirar de manual estás acotando innecesariamente las posibilidades que se te ofrecen para aplicar una soluciones que se adaptan mejor al momento actual del proyecto.

Eso implica, a su vez, escuchar la opinión de terceras personas que aporten su conocimiento y experiencia.

Desarrollo de software. Sin miedo

Si quieres que un desarrollador autolimite su potencial solo tienes que crear un contexto en el que tenga miedo a equivocarse. En él tendrá menos autonomía, tomará más precauciones de las necesarias, buscará aprobación en la mayor parte de las decisiones que tenga que tomar y en consecuencia de lo anterior, no arriesgará.

Al no arriesgar tratará de optar por las soluciones que ya conoce en lugar de buscar otras que lo mismo permiten resolver el problema con más rapidez y solvencia.

A todo eso súmale que el temor y miedo paraliza por lo que la pérdida asociada de productividad se hará evidente más pronto que tarde.

¿Quieres realmente que tu equipo sea así?, ¿quieres un equipo que cuide más las formas que el fondo?, ¿quieres un equipo que no progrese?, ¿quieres un equipo que se termine aburriendo?.

Pues si quieres todo eso ya sabes lo que tienes que hacer. Ahora bien, piénsalo bien, porque no es sostenible y sus malos resultados te terminarán afectando, salvo que continuamente estés rotando personas para obtener de ellas lo que necesitas en ese momento, pero esto tampoco es infinito porque esas mismas personas terminarán igual de quemadas que las anteriores.

Soy totalmente contrario a ese modelo de gestión, también soy contrario a que no exista gestión (que no es lo mismo que autogestión). Recuerdo que se trata de trabajar con personas y que esa forma de tratar con ellas no es compatible con la búsqueda de un ambiente donde cada una de ellas pueda ofrecer el máximo de su potencial y pueda seguir evolucionando para convertirse en mejor profesional.

Desarrollo de software. ¿Son un obstáculo las normas?

Como concepto no, pero en la realidad tienen impacto en el sentido de que unas buenas normas pueden facilitar el proceso de desarrollo pero unas malas normas se pueden convertir en un obstáculo.

¿Cuáles son buenas?, ¿cuáles son malas? Depende de lo que realmente necesite la organización y de los beneficios reales que ofrezcan. Muchas veces se establecen normas y pese a que puedan tener ajustes puntuales para mejorarlas (o empeorarlas), en escasas ocasiones se hace un análisis objetivo de las ventajas que han proporcionado a la organización y a los proyectos, en su lugar se deja que siga siendo la marea la que continúe arrastrando el barco y se termina convirtiendo en una costumbre que lo mismo cuesta excesivo dinero, no solo por el coste de aplicación sino por los resultados que ofrece.

Cuando se establecen unas normas o unos procedimientos es importante tener en cuenta el contexto en el que se va a trabajar. No puedes exigir determinados procesos y/o entregables si tu economía no te lo permite o si la tipología de proyectos, clientes o proveedores requieren otro tipo de soluciones.

Por otro lado, resulta esencial contar con las personas que se van a encargar de seguir esas normas y procedimientos en el día a día porque son ellas las que están en las trincheras y si bien la organización puede necesitar determinado tipo de información o actuaciones para realizar tareas de gestión y de toma de decisiones, es importante contar con quienes conocen el contexto en que se llevan a cabo los proyectos porque ellos son los menos interesados en tirar ladrillos a su propio tejado.

Y siempre debe existir la posibilidad flexibilizar las normas o existir excepciones cuando el proyecto o la circunstancia lo aconseje, siempre y cuando esté debidamente justificado. Cuanto más excepciones se requieran sobre la norma, es lógico pensar que algo está fallando en la misma. Sin embargo, quienes velan por su cumplimiento tienden a pensar que el problema está en las personas.

Barry Boehm. Victor Basili. Arreglar los errores lo antes posible

La primera de las situaciones que Barry Boehm y Victor Basili citan en su artículo “Software Defect Reduction Top 10 List” en la revista IEEE Computer en enero de 2001, está muy en consonancia con el objetivo Lean de cero defectos y con una realidad que los que nos dedicamos a esta profesión conocemos y que sin embargo sigue siendo demasiado habitual: «Encontrar y arreglar un problema del software después de la entrega es a menuda 100 veces más caro que encontrarlo y arreglarlo durante las fases de toma de requisitos o diseño».

Encontrar un defecto en producción implica el tiempo necesario en corregirlo, la realización de una nueva entrega y el coste que tiene sobre el proceso productivo hasta que se corrige. No todos los defectos son iguales y, por tanto, su impacto puede ser desde prácticamente nulo hasta dejar sin funcionamiento una parte de la aplicación o provocar daños intangibles como una mala imagen ante los clientes.

Con lo que tenemos que quedarnos es que efectivamente se tiene que ser más riguroso en el proceso de desarrollo de manera que los programadores se habitúen a probar mejor el software que están desarrollando, siendo extensible esto a las personas que tengan una visión más global del producto conforme se van integrando los componentes.

Y esto no solo debe tenerse en cuenta en la construcción ya que se tiene que tratar que las especificaciones sean de la mayor calidad e intención posible, de manera que se consiga reducir el número de iteraciones necesarias para tener depurada una determinada funcionalidad.

Escapar de la llave en mano, ¿quién asume el riesgo?

Buena parte de la contratación del software está basada en acuerdo llave en mano en la que se pacta un precio cerrado para desarrollar un producto en base a unas especificaciones, por regla general, no muy detalladas de lo que se pretende hacer.

En muchos casos, el proyecto parte de una situación de Death March Project que dará lugar, si es que se consigue llegar, al menos, a ese punto, a un producto que no satisfará las necesidades y expectativas del usuario y en medio de todo eso se habrá producido un desgaste importante entre los diferentes implicados en el proyecto.

Los defensores de esta estrategia de contratación se centran en que el riesgo se traspasa al proveedor que es quien asume unas condiciones y como tal, debe cumplir lo pactado. Sin embargo es algo que termina volviéndose en contra también del cliente, que se debería conformar, con las especificaciones que dé en la fase de captura de requisitos, sin posibilidad de modificarlas posteriormente (la llave en mano y el desarrollo en cascada son compañeros de viaje).

¿Qué pasa? Pues que acertar a la primera es muy complicado y conforme vaya avanzando el desarrollo y los responsables funcionales vayan viendo partes del producto funcionando, surgirá la necesidad de realizar cambios sobre las especificaciones o incluso la necesidad de incrementar el alcance inicialmente previsto.

En ese momento entran en juego las negociaciones y dependerá de la voluntad de las partes que las mismas lleguen a un punto donde sea posible todavía entregar un producto que cumpla unas condiciones mínimas.

Desde mi punto de vista creo que, a pesar de ser legítima, una situación de partida en la que una de las partes trata de echar sobre la otra todo el riesgo no es positiva para un proyecto por sus propias características inherentes: incertidumbre, carácter evolutivo del desarrollo y las diferentes contingencias, casuísticas y problemas que suele haber en los mismos.

El overhead de no tener presupuesto

Cuando se quieren hacer más tareas que presupuesto en un proyecto se empieza a incrementar de manera desorbitada el tiempo dedicado a la gestión, el cual tiene un efecto paradójico, ya que se trata de gestionar para minimizar conflictos, modular expectativas, buscar soluciones a través de reducción de alcance, simplificación de soluciones, etc…, el cual suele tener un coste superior al beneficio que produce.

No digo que no se deban hacer, pero en muchos casos no van a solucionar el problema de fondo y finalmente lo que se obtendrá es un producto que no suele dejar satisfecho a nadie, en primer lugar a los usuarios/cliente que verán recortado el alcance esperado, con más defectos y con un código de peor calidad y en segundo lugar el proveedor que no solo verá desgastada su imagen con respecto al cliente (que tal vez pierda) sino que tendrá unos resultados económicos en el proyecto peores de lo esperado.

La solución pasa por alcanzar un nuevo acuerdo presupuestario sin que ello suponga que se deje de lado el análisis de por qué se ha llegado a esta situación: podría ir desde una estimación inicial incorrecta, mayor complejidad de la esperada, nuevos requerimientos, menos productividad de la deseable y la suma de algunos de estos factores junto a otros.

La documentación como justificación de los trabajos

Soy de la opinión de que la documentación en los proyectos no debe ser extensa, debe centrarse exclusivamente en lo que necesita el proyecto y la organización dentro de sus procesos internos y nada más.

A veces son los propios procesos organizativos los que extienden el número y el tamaño de los documentos, cuando eso sucede y el beneficio de esa actividad es inferior que la inversión que hay que realizar para llevarla a cabo es cuando hay que plantearse si efectivamente los procesos están bien definidos.

Hablo de beneficio en general no de un proyecto concreto, ya que las organizaciones deben tener una vista más panorámica, si bien resulta fundamental que cuando un proyecto requiera excepciones debidamente justificadas se deba ser lo suficientemente flexible.

¿Por qué a los niveles superiores de la organización les gusta tanto la documentación? Porque con documentación parece que hay un orden y que las cosas se hacen bien. ¿Cuántas veces se ha justificado el trabajo en un proyecto en base a la documentación por encima del valor real que tiene el producto? y eso es así porque cuando estás alejado del día a día de los proyectos y no se sabe de qué va realmente el mismo y las diferentes contingencias que se han producido durante el proceso de desarrollo, se entiende a evaluar por lo que se entiende (equivocadamente o no) y el peso de la documentación se suele entender como síntoma de que se ha trabajado (otra cosa es que sea más o menos efectivo y que la documentación tenga el nivel de calidad y actualización necesario para que realmente sea útil).

Procesos, más carga práctica y con una visión hacia otros departamentos

La imposición de procesos que no tienen en cuenta las personas y equipos que trabajan en la organización y tampoco a la propia naturaleza de los trabajos que se realizan está condenada al fracaso, independientemente de que consiga prevalecer en el tiempo.

La teoría debe servir a la práctica y no al revés. Lo teórico puede ser maravilloso en el papel pero si no se adapta a la realidad de la organización se puede convertir en un carga.

Si a esto le sumamos que en muchas organizaciones, cada departamento establece sus propias normas sin tener en cuenta los puntos en común que tienen con otros y sin una visión general de lo que es la organización, el problema lo único que hace es seguir creciendo.

Un ejemplo muy sencillo de esto lo encontramos en el establecimiento de procesos teóricos de gestión en los departamentos de desarrollo, sistemas y explotación de las organizaciones, los cuáles además no se han engarzado entre sí y en la práctica de su aplicación nadie hace por tratar de a través del diálogo de reducir la resistencia que producen unas normas que consideran cada departamento como estanco.

Cuando se trata de crear procedimientos se intenta en muchas ocasiones de ir hacia máximos en lugar de realizar una transición más suave que permita que los cambios se vayan introduciendo poco a poco conforme se vaya experimentado con los introducidos anteriormente y todo esto con la participación de otros agentes de la organización que puedan estar implicados o sean interesados del resultado del propio proceso.

Ser ágil por encima de aplicar Scrum

Es cierto que Scrum es la suma de sus prácticas debidamente ejecutadas en un proyecto. Por eso cuando trato de hablar sobre qué estrategias, prácticas o metodologías suelo aplicar en mis proyectos trato de indicar que, entre otras, utilizo algunas prácticas de Scrum.

Soy de la opinión de que cada organización y cada proyecto presenta sus peculiaridades y que cuanto más nos adaptemos a ellas más probabilidad existe de que el proyecto salga adelante. Por ese motivo no hay que cerrarse entre las cuatro paredes de una metodología, la agilidad implica ser flexible y esto supone que siempre hay que poner por encima la actitud ágil que cualquier estrategia que quieras aplicar.

No se trata de reinventar la rueda sino de aplicar en base a lo que conoces de la organización, del proyecto, de tu propio equipo, del cliente y en base a tu conocimiento y tu experiencia los ingredientes que consideras necesarios, ¿qué después habrá que seguir puliendo? pues lo más probable es que sea así ya que los proyectos no son lineales y lo que funciona hoy no tiene por que ser lo más adecuado mañana.

Lo personal y lo profesional

Decía Gandhi que: «Ojo por ojo, y el mundo acabará ciego».

En tu día a día profesional te encontrarás con situaciones en las que terceros, sean estos personas u organizaciones, te fastidian una tarea o un proyecto.

Mi recomendación, aunque sea difícil evitarlo, aunque tengas que contar hasta un millón, es que no lo tomes por la vía personal y lo entiendas siempre como algo profesional, de esta manera, además de afectarte menos como persona no te dejarás llevar por sentimientos que solo te llevarán a empeorar la situación.

La teoría es muy fácil, la práctica mucho más difícil. Para tratar de mitigar esa distancia, es conveniente reflexionar qué te ha aportado adoptar posturas en lo profesional en las que te has dejado llevar más por las emociones que por la razón y la objetividad.

Evidentemente todo tiene un límite, pero es mejor gestionarlo desde la reflexión que desde el impulso. Existen diferentes formas de poder resolver el conflicto, trata de ser inteligente y opta por aquella que sea más beneficiosa para el proyecto porque si finalmente termina con éxito esa realmente será tu victoria.