archivo

Archivos diarios: agosto 4, 2013

El desarrollo de software es una sucesión de éxitos y fracasos. El balance para cada uno de nosotros no es cero ya que los éxitos y los fracasos no terminan compensándose.

Cada uno de nosotros tiene un balance y en función de su capacidad de crítica se aproximará más a una situación real o a una imaginaria.

Sin embargo, nada es inmutable, tu balance hoy puede ser positivo y dentro de un tiempo tal vez sea negativo. Hoy puede ser negativo y tras algún tiempo convertirse en positivo.

No es un juego de azar, es tu trabajo, son tu actitud unido a tu aptitud las que terminan poniendo tu saldo de un color u otro.

Si tenemos empeño, afán por aprender de nuestros errores y deseo por seguir aprendiendo, conseguiremos éxitos, sin olvidar que el fracaso se asoma a la vuelta de la esquina, ya que pueden darse circunstancias sobrevenidas que comprometan los resultados de un proyecto o simplemente podemos equivocarnos, porque quien toma decisiones, quien actúa se expone a tener fallos y cuanto mayor sea tu responsabilidad mayor será el impacto de tus decisiones.

Sobre esto, me parece muy interesante la siguiente reflexión de Winston Churchill: “El exito no es final, el fracaso no es fatal: es el coraje para continuar lo que cuenta”.

Nuestro trabajo no es sencillo, dejando a un lado esos balances, dentro de un mismo proyecto pueden darse multitud de circunstancias positivas y negativas. Si te dejas vencer por las que son adversas o tienes una mala actitud cuando las cosas vienen de cara, lo más probable es que el proyecto no salga bien. Se trata, como dice Churchill, de seguir caminando, ya que quien resiste, gana, tal vez no ahora, pero nuestra oportunidad llegará.

Nos podemos encontrar con que los procesos de desarrollo de software y la normativa asociada a los mismos dentro de la organización, acotan tanto nuestras posibilidades a la hora de tomar decisiones o buscar alternativas que condicionan sobre manera el devenir del proyecto y no precisamente en positivo, porque restan capacidad de poder adaptarse a las múltiples contingencias que se pueden producir en el proyecto e implican, en muchos casos, un sobrecoste por la realización de actividades o actuaciones que no aportan un valor real.

Esta forma de entender el desarrollo de software, desde mi punto de vista, considera que las personas son el problema y no son la solución, ya que tratan de reducir al máximo su capacidad de actuación.

Es entendible y razonable que la organización quiera hacer uniformes algunos aspectos relacionados con el desarrollo con el objeto de tener un cierto conocimiento y control de lo que se está haciendo pero es mucho más discutible que trate de encorsetar a los desarrolladores de tal manera que, aunque tengan cierto margen de actuación, el camino esté tan marcado que tengas pocas posibilidades para poder maniobrar, aunque la misma sea necesaria para mantener el rumbo del proyecto.

Cuando hablamos de normas de desarrollo, al final, los que quieren hacer las cosas bien, no querrán dejar de lado las directrices de la organización, ¿por qué? pues porque aunque lo importante sea el producto, no podemos olvidar nuestro contexto laboral. Ante estas circunstancias, cuando sea necesario hacer una interpretación más flexible de los procedimientos o que se aplique una excepción, lo mejor es buscar un diálogo razonado con quiénes gestionan y controlan esos procesos, es muy posible que se consiga encontrar una solución, tal vez no satisfactoria al 100% pero por lo menos mejor que la situación de partida.

Lo ideal es que ante estas circunstancias los gestores de procesos sean capaces de reaccionar y hacer cambios en las normativas que permitan que las mismas sean cada vez más adecuadas a lo que los proyectos y la organización necesita, de esta forma, además, en un futuro no será necesario malgastar energía en los mismos asuntos una y otra vez.

¿Y si no se encuentra solución? Los proyectos están llenos de resistencias, esta será una más, con mayor o menor impacto en el desarrollo. ¿Qué podría ser evitable?, ¿qué es un fastidio tener que asumir eso? Sí, pero eso afecta no solo a los procesos o normativas, ya que también tenemos que asumir muchas veces decisiones del área usuaria con las cuales no estamos en absoluto de acuerdo y que condicionan considerablemente el desarrollo de software.