Uno de los temas que distinguen a las organizaciones y a los países es la actitud. En lo que pude interpretar en la encuesta de esta semana, creo que respecto al tema de calidad en el software existe una percepción diferente respecto a si es posible lograr calidad en el software entre los tomadores de decisiones y la gente que realiza la actividad (desarrolladores, administradores de proyecto, diseñadores, analistas, UX/Diseño).
Esto lo podemos ver en la siguiente gráfica:
Las opiniones están divididas en el tema, es decir, los directivos consideran que es posible y los que ejecutan consideran que no es posible. Lo bueno es que los estudiantes si piensan que es posible.
Para muchos el tema de la calidad de las soluciones es de estructura, para mí (dentro de mi estructura mental y experiencia – y por lo visto también de nuestros lectores) el tema son de métodos de trabajo, las prácticas y las reglas (escritas o no) que rigen nuestro comportamiento en las organizaciones (y claro que también aplica a los países). Les siguen en importancia de acuerdo a la opinión de los lectores la especificación de requerimientos y la falta de conocimientos del dominio del problema a resolver (es decir del contexto del problema).
Esto lo podemos ver en la siguiente gráfica:
El 21.43% que indican que la principal causa de la calidad del software es el método de trabajo.
Desmenuzando esto, tomando como base 100 a los directivos, un 30.77% de ellos piensa que es el método de trabajo, el 23.08% opina que es la falta de conocimiento del dominio del problema a resolver con la solución, el 15.38 piensa que es la especificación pobre de conocimientos y el 7.69% piensa que es la falta de conocimiento de las metas del negocio/cliente.
Mientras que los desarrolladores de software en esta muestra, simple y sencillamente no consideran al método de trabajo como un factor, sino las fechas de entrega impuestas por el usuario.
Lo que ven los desarrolladores de software como principal causa son las fechas de entrega impuestas por el usuario (33%) de los desarrolladores citaron esto como principal factor que incide negativamente en el software de calidad. Y empatadas con 16.67% la pobre especificación de requerimientos, falta de pruebas, falta de conocimiento del dominio del problema a resolver y factores humanos
Un 28.57% de administradores de proyectos ven como principal causa la especificación de requerimientos.
Los arquitectos la ven como el 33.33% tal y como se muestra en la siguiente gráfica:
El reto es que desde su perspectiva, cada uno de los jugadores tiene razón.
El trabajo en equipo, desgraciadamente no es sinónimo de colaboración ni de cooperación, lo que sí es que la coordinación es una de las funciones de la administración (Pronóstico, planeación, organización, comando, coordinación y control). Lo que percibo es que cada área ve el problema desde su trinchera y no se llega a un enfoque holístico (cada quien está centrado en su pedazo del problema), con reglas que muchas veces no ayudan a que se haga el trabajo (The Progress Principle).
Las organizaciones tienen como base la división del trabajo, además de los roles y jerarquías y están basadas en las diferencias. En esta era del talento, creo que ese modelo ya es obsoleto (no soy el único, pensadores como Gary Hamel en estrategia expresa siempre que puede este tema y el ya fallecido Watts Humphrey gurú de la calidad en software en su libro Leadership, TeamWork and Trust – Building a Competitive Software Capability también lo expresó, aunque para mí CMMI genera algunas ineficiencias).
Es decir en las organizaciones, todos tenemos un papel que jugar y una responsabilidad en ella. Sin embargo el objetivo de todos en la organización debe estar alineado y todos debemos buscarlo (sobre todo si pensamos en la calidad del desarrollo de software).
La coordinación entre áreas es crítica para poder lograr el objetivo, cumplir el propósito, satisfacer la misión y caminar hacia la visión y en el tema de desarrollo de software no debería ser diferente, sin embargo ponemos reglas que terminan no ayudando en el logro de los objetivos y entre más grande la organización más reglas existen).
El tema complicado es que en ocasiones no jugamos “futbol total”, solo queremos saber y hacer bien nuestra posición y “tan,tan”, se acabó el cuento y además no pensamos en lo que las otras posiciones requieren para meter el gol, hablando en términos futbolísticos, en ocasiones nomás le pegamos a la bola (por cierto, aunque el fútbol total lo popularizó Holanda y el director técnico que lo llevó a su máximo es Pep Guardiola, el concepto lo inventaron en Hungría).
En el desarrollo de software se conjugan varios factores que complican el desempeño del equipo. Existen piezas interconectadas y el resultado o el producto lo experimentamos, no lo tocamos. En pocas palabras es un servicio. Y las alternativas que tenemos son pocas por lo que nos acostumbramos al software de mala calidad.
Servicio al que nos hemos acostumbrado en forma de licencias, cargos por mantenimiento y claro, defectos en el software. Los defectos cuestan, pero también existen industrias que dependen de ellos (como la de la seguridad de la información).
La calidad es relativa, no es absoluta y como la belleza y el valor, está en los ojos del que lo ve.
En mercadotecnia de servicios además de las 4 P’s tradicionales (Product, Place, Price & Promotion), manejamos 3 P’s adicionales (People, Process y Physical Evidence), estas últimas tres son las que determinan la calidad del servicio.
Considero que no hemos trabajado para entender el proceso de desarrollo de software y a los que participan, colaboran y ejecutan las actividades dentro del proceso. Tampoco hemos dedicado esfuerzos para hacerlos mejores. Es decir, es entender al talento.
Son pocas las organizaciones que tratan de entender al talento, cuáles son sus motivaciones y sus fortalezas, que los mueve, que los apasiona y cómo alinear todas estas variables. No crean, no es la única industria, por ejemplo, la salud va por donde mismo y a mi juicio también la de la educación.
Queremos que todo sea estándar y que nos comportemos como fábricas, pero el talento no es así. No soy romántico respecto al talento. El talento es una ente con vida propia y el talento es tan diverso como los individuos que existimos. Existen libros que nos pueden iluminar al respecto (por ejemplo The Progress Principle), sin embargo nos encanta ser intuitivos y líricos. Y para muchos los procesos los vemos como “burocracia”, y esto sucede cuando el proceso se sirve a sí mismo y no genera valor.
Queremos que la división del trabajo aplique para el software utilizando los métodos tradicionales de “cascada”. Establecemos indicadores que hacen que surjan conflictos (yo les digo “indicadores perversos”) y si no nos coordinamos, utilizamos con el talento el viejo y obsoleto “comando y control” o su equivalente en lenguaje coloquial “zanahoria y garrote”. Este método funciona muy bien para actividades físicas, pero con el talento produce resultados inversamente proporcionales, de acuerdo a los estudios (ver figura 4.1 del libro Leadership, Teamwork and trust de Humphrey).
Al final del dia el propósito se pierde y la alineación del individuo, su actividad y la organización y no apuntan hacia donde mismo.
Por otra parte, nos enamoramos de la solución y no del problema. Nos enamoramos de las herramientas y no del proceso. Nos enamoramos del destino y no de la travesía.
Entender el talento que desarrolla, administra, diseña y analiza los problemas para ofrecer una solución de software es trabajo que hemos dejado a un lado pero que ya no podemos posponer. El identificar el problema, es el verdadero reto. El aprender a aprender y a resolver los problemas es más importante que la herramienta misma, la cooperación es clave y los métodos y prácticas de trabajo deben fomentar la cooperación, no el aislamiento.
Esta misma semana tuve la oportunidad de ver este video en TED: Yves Morieux: A medida que el trabajo se hace más complejos, 6 reglas para simplificar (12 minutos)
Me parece que va por el camino de lo que estoy comentando en este editorial y como resumen les comparto las 6 reglas para simplificar que propone Morieux:
Como concluye el video, “Estas reglas tienen muchas implicaciones en diseño organizacional, debes dejar de dibujar cajas, líneas punteadas, líneas continuas. Tienes que poner atención en la interacción. También tiene muchas implicaciones en las políticas financieras y prácticas de recursos humanos que usamos. Es posible administrar la complejidad, la nueva complejidad del negocio sin hacerse complicado. Creas más valor a menor costo. Simultáneamente mejoras el rendimiento y la satisfacción en el trabajo al haber removido la causa raíz común que afectan a ambas, la complicación. La verdadera batalla no es contra la competencia, la verdadera batalla es contra nosotros mismos, contra nuestra burocracia, nuestras complicaciones.”
Se puede desarrollar software de calidad a la primera, definitivamente se puede, todo es cosa de que todos los que participamos en el proceso pensemos y actuemos para que se pueda, cooperemos, colaboremos y nos coordinemos y en esto me refiero a absolutamente todos, aunque la calidad sea relativa.
Que tengan un muy buen fin de semana.
Referencias:
