archivo

Archivo de la etiqueta: personas

Este tipo de razonamientos se cae por su peso, cuando no son ni uno, ni dos, ni diez, los desarrolladores que no consiguen buenos resultados siguiendo esos procesos, ya que es difícil que en este juego haya un listo y n tontos. Tampoco creo que sea cosa de un tonto y n listos, se trata de ver qué es lo que aporta realmente al valor de los productos y a la organización la aplicación de determinadas normativas y qué coste tiene la aplicación de las mismas, ya que el mismo no solo repercute sobre quiénes vigilan el cumplimiento de los procesos sino que también impactan, sobre manera sobre los proyectos, sus costes y sus expectativas.

Muchas organizaciones han visto en la calidad procedimental una fuente de negocio y pese a unos resultados y unos costes discutibles, han logrado que sus ideas terminen, no sé cómo, cuajando. Tal vez sea por la falsa sensación de control y de cosas bien hechas que da tener un volumen ingente de documentación por proyecto más o menos organizada, independientemente de la utilidad real que tenga la misma pasado un cierto tiempo. Sin embargo, por más documentos que se apilen, la calidad del producto software no será mejor y si lo es no será debido a ellos.

Otro de los problemas que provocan quiénes piensan que la clave se encuentra en los procesos es que al considerar a las personas como un elemento secundario en todo esto, tienden a restar importancia a su cualificación y experiencia, centrándose más en la cantidad que en la calidad o lo que es lo mismo, a buscar el menor precio/hora posible, pese a que esto impacte de forma significativa en la productividad y la calidad del trabajo realizado.

Un argumento que suelen esgrimir los defensores de los procedimientos es que la solución alternativa es volver al caos. Y no es así, no se trata de elegir un extremo, sino de buscar el término medio que mejor venga a una organización y a un proyecto.

No se trata de no documentar, no se trata de no seguir procesos, sino de que realmente aporten valor al producto y a la organización, esto último tiene su peligro si no se interpreta adecuadamente, ya que el valor a la organización se ha utilizado precisamente para que los procesos tiendan a sobredocumentar proyectos con la excusa de que reducen la cautividad del proveedor y favorecen la mantenibilidad del producto.

Sin embargo, pese a todo, el problema de fondo se sitúa más allá del enfoque, sino en la importancia real que se le da al proceso de desarrollo sobre el producto software, que no es más, en esencia, que la importancia real que se le da a las personas en todo esto.

Cuando se mira más al procedimiento que a las personas no me extraña que se nos considere recursos porque da una idea de servicio a un fin distinto al que se pretende con el desarrollo de software (se sirve al proceso), que es conseguir un producto final que proporcione el mayor valor posible al usuario final (ahora hablo de valor, antes lo hice de calidad, al final de esta serie de artículos, los trataré de manera conjunta).

Independientemente de que haya determinados desarrollos, como por ejemplo, soluciones que se obtienen a través de configuración de productos base, donde el procedimiento puede tener gran interés (al fin y al cabo el producto ya existe), el desarrollo de software es una actividad intelectual que se lleva a cabo interactuando y colaborando con otras personas, tratando de eliminar fronteras entre ellas que creándolas de manera artificial.

Tenemos un producto que ha sido desarrollado con todos los entregables documentales que solicita el proceso, ¿debería ser un sistema fantástico? Sabemos que no es así o por lo menos que no es necesariamente así. Si todo fuera tan fácil como seguir una receta, no hubiera existido el concepto de crisis del software y la misma no hubiera llegado hasta nuestros días y no hubieran aparecido movimientos como el ágil que entienden que el desarrollo de software se basa en el producto y en las personas.

El desarrollo de software requiere un importante esfuerzo intelectual por parte de las personas que participan en él. La efectividad depende de que el talento y experiencia de cada persona esté enfocada en el trabajo, tarea o proyecto que mejor se adapte a esa capacidad y que, además, le motive.

Dado que no se trabaja solo, resulta muy importante que las personas que conforman los equipos encajen.

Obtener el máximo rendimiento de las personas no es tarea fácil, ya que son muchos los factores que pueden influir en el mismo, para empezar sus propias circunstancias.

Sabiendo que no es sencillo y que es utópico pensar que el 100% del tiempo se va a tener un rendimiento óptimo de las personas y de los equipos, sí que existen una serie de aspectos a tener en cuenta, porque el hecho de que sea difícil no significa que no se intente, es más, es necesario dedicar el esfuerzo necesario para intentar aproximarnos lo máximo posible a ese límite:

– Fomenta la autogestión de las equipos. Los que viven el día a día del proyecto saben mejor que nadie cómo deben organizarse, quién se organiza tiende a ser más responsable con el resultado de su trabajo. Eso no quiere decir que los desatiendas, ya que muchas veces desde fuera se ven cosas que no se ven desde dentro y porque hay información ya sea del cliente o de la propia organización que llega a través de ti. Por otro lado, si respetas el espacio de tu equipo, ellos respetarán el tuyo y las retrospectivas sobre el trabajo que se está realizando serán más provechosas.

– Intenta minimizar los cambios de contexto. El fraccionamiento de las personas en múltiples proyectos es ineficiente para las personas y para los proyectos. Hay determinados tipos de perfiles donde no queda más remedio, en ese caso, trata de ajustar la capacidad de trabajo que puede absorber a su límite real.

– Trata de evitar los parones en los proyectos. Esto es algo que no dependerá de ti en la mayoría de los casos, pero sí que puedes intervenir para tratar de prevenirlo. Esto requerirá una atención tanto al proyecto como a la información que te haga llegar tu equipo.

– Las personas no son robots, ni sus aptitudes son las más adecuadas para todos los contextos, por tanto, no les trates como máquinas, conoce sus puntos fuertes y sus puntos débiles, dedica tiempo a saber qué le motiva y con qué grupo de personas puede encajar mejor. Si existen diferentes alternativas, pregúntale cuál se le apetece más, a cuál cree que puede aportar más y por qué. No es lo mismo que tu empujes a una persona a dar un paso a que sea ella misma quién lo decida, ya que el nivel de implicación no será el mismo.

La organización debe tratar de no ser rígida en la promoción profesional, centrándose exclusivamente en promociones verticales y en un itinerario establecido. Las personas son diferentes, plantea diferentes itinerarios.

– Buscar el rendimiento óptimo de las personas basado en mecanismos de recompensa, no suele proporcionar buenos resultados a la larga porque en el momento en el que por el motivo que sea esas recompensan menguan o desaparecen, la motivación se irá con ellas.

Es importante premiar a quién lo hace bien y eliminar de la organización la idea del “nunca pasa nada” aunque se falle estrepitosamente en una serie de proyectos, pero orientarlo más que a un hecho concreto a una trayectoria (lo cual no quita que puedan existir logros excepcionales con recompensas también excepcionales), esto implica la existencia de una carrera profesional, en donde buenos resultados se terminen consolidando en tus ingresos.

– Adapta la cantidad de trabajo que puede asumir un equipo a su capacidad real, lo contrario da lugar a situaciones de bloqueo y de pérdida de calidad que influyen directamente en los resultados. Es posible que el overtime consiga solventar estas dificultades durante un tiempo, pero poco después, la cantidad de trabajo real que se pueda sacar será menor que con el horario normal (fruto del cansancio y de modular tus fuerzas a la jornada laboral), a lo que habrá que sumar el sobrecoste de una mayor deuda técnica y tasa de fallos.

– Siempre hay trabajo que hacer, si hay una persona o un grupo de personas desocupadas y te interesa mantenerlas en la organización, crea un proyecto o proyectos internos, haz que actúen de soporte en proyectos que estén en marcha (siempre y cuando su entrada no rompa el ritmo de trabajo) y/o realicen tareas de testing, utilízalos de apoyo para tareas comerciales, etc…

En estas circunstancias, además, se puede saber si una persona está motivada o no por seguir en la organización, ya que quien quiere trabajar, se inventará el trabajo y si le preguntas te expondrá muy probablemente diferentes alternativas en las que poder ayudar.

Lo peor que se puede hacer es dejar a estas personas sin hacer nada porque muy probablemente afectarán directa o indirectamente a las personas que sí están implicadas en proyectos.

Comparto la visión de Deming de que las personas son la clave para conseguir un determinado nivel de calidad en los resultados de una organización y su evolución continua: “la transformación sólo puede llevarse a cabo por las personas. Una empresa no puede comprar su camino hacia la calidad”.

Por eso, muchas iniciativas que tratan de que las organizaciones den un paso hacia adelante y evolucionen, fracasan, bien porque las personas que las impulsan, bien porque las personas que las tienen que ejecutar o bien por ambas, no están por la labor de hacer el esfuerzo necesario para pasar a una nueva fase en la que las cosas funcionan de otra manera y se obtienen otros resultados.

¿Y por qué? Tal vez nadie se ha esforzado en explicar los beneficios que tiene adaptarse al cambio y la necesidad de hacerlo cuando el contexto no te deja otra opción: o evolucionas o desapareces.

Por tanto, puedes hacer consultorías, planes estratégicos y cualquier otra actividad por el estilo, que si no empiezas a trabajar con las personas y a darle la importancia real que tienen, lo más probable es que no consigas nada o que los resultados no sean todo lo satisfactorios que se esperan y se necesitan.

El desarrollo de software es en términos generales desarrollo de software para personas realizado por personas. Esta relación o ley natural del desarrollo de software es vulnerada sistemáticamente por esas mismas personas y desde diferentes puntos de vista:

– Cuando se trata de orquestar los proyectos de desarrollo de software a través de procesos rígidos con el convencimiento de que si los procesos son buenos se minimiza el impacto de las personas en el resultado final del proyecto.

Esta concepción del desarrollo de software parte de una buena intención: tratar de conseguir repetibilidad en los resultados, sin embargo no se ajusta a la realidad existente en el desarrollo de software, donde las condiciones en que se realiza cada proyecto son diferentes y pueden cambiar repetidamente a lo largo de su ejecución.

Este modelo ha sido el dominante durante muchos años y lo sigue siendo en la actualidad, forzando soluciones y alternativas en los proyectos que no son las más adecuadas, poniendo por delante de las personas a procesos, procedimientos y metodologías.

– Cuando nuestros intereses, a nivel individual, de equipo de proyecto o de organización, nos ponen un muro con el resto de personas que colaboran con nosotros. En este caso solo estamos de cara ante nosotros mismos o a los que formen nuestro grupo o equipo, los demás quedan fuera y serán amigos, enemigos o la nada en función de si afectan o no a nuestros intereses.

– Cuando se trata a las personas como ganado. Cuando no se les reconoce su trabajo, cuando pasan de un proyecto a otro sin ser escuchados, cuando sienten que solo son un número. Es cierto que hay toda una gama de grises, pero también lo es que muchos desarrolladores se sienten así.

Se piensa que con un sueldo ya todo está justificado y no es así. Los trabajadores necesitan ser tratados como personas y tienen metas y objetivos como cualquier ser humano, quieren progresar, quieren recibir un trato justo y por eso no toleran la falta de justicia y la falta de objetividad.

– Cuando solo importan los beneficios. ¿Cuántos proyectos se venden sabiendo que va a ser muy complicado obtener rentabilidad? Muchísimos, demasiados. Esto está destrozando nuestro sector. Unos se encargan de vender cómo sea y otros de sacar rentabilidad como sea. En medio de todo eso, personas, tanto por parte del cliente como por parte del proveedor, que sin quererlo quedan encerradas en un campo de batalla porque en eso se convertirá el proyecto más pronto que tarde.

Los beneficios son la razón de ser de las empresas pero no lo legitima todo.

El factor humano en el desarrollo de software es esencial y marca la diferencia. Son personas las que desarrollan, son personas las que comunican las especificaciones, son personas los usuarios, son personas, en definitiva, todos los implicados en el proyecto.

Cualquier estrategia de desarrollo que no tenga en cuenta esto no está siendo realista.

Puedes intentar hacer repetibles determinados aspectos del proceso de desarrollo con el objeto de armonizar ciertas prácticas o ciertos elementos de control por parte de niveles superiores de la organización. Este proceso en background resulta beneficioso porque la organización debe tener una imagen general de cómo se trabaja y de los resultados que se van obteniendo. No soy partidario de exterminar los procesos sino de que los mismos se conviertan en herramientas para los desarrolladores y no al revés (y esto puede ser compatible con el deseo de la organización de homogeneizar ciertos aspectos de su funcionamiento).

Ahora bien, tratar de encorsetar todos los proyectos bajo un mismo paraguas metodológico limita los resultados, nos convierte en cumplidores de la metodología (¿Qué nos piden 10 items y de esta forma? Pues nada aquí los tienes, otra cosa es que sirvan realmente para algo?) e impactan en el resultado porque hay esfuerzo que de manera innecesaria se distrae en tareas que no aportan nada y más a largo plazo porque se habrá creado una excusa perfecta para justificar proyectos que no han ido bien: “pues yo he seguido toda la metodología paso a paso…”.

Está demostrado y no hay que recurrir a estudios de prestigiosas consultoras, que imponer tallas únicas lejos de solucionar los problemas del desarrollo de software los agudiza. Lo peor de todo se produce cuando fallando los procesos se sigue pensando que el problema se encuentra en que el proceso no tiene suficiente nivel de detalle y así sucesivamente, haciendo cada vez más pesados los procesos.

Hay que entender que una organización quiera conseguir una predecibilidad en los resultados que sea escalable al resto de proyectos de misma: “si aplico esta estrategia probablemente la mayoría de los proyectos conseguirán buenos resultados”, y de ahí la intención de conseguir esa repetibilidad a través de los procesos.

De esta forma el factor humano sería secundario, solo son piezas de una maquinaria, totalmente prescindibles e intercambiables en cada momento, porque se piensa que el valor principal lo aporta el proceso y no las personas.

El factor humano es el más impredecible, a través de procesos detallados se quiere minimizar su impacto, ya que se pretende que las personas sean meros instrumentos de los procesos y no al revés.

Sin embargo el desarrollo de software es el resultado del valor que cada persona aporta al proyecto, de si el responsable funcional colabora o no en el proyecto, de lo claro que tenga o no lo que quiere, de si los desarrolladores entienden bien las especificaciones, de si las llevan adecuadamente a cabo, etc… y todo eso en un contexto donde se interacciona con más personas, en donde las prioridades pueden cambiar, etc… No hay proceso que pueda sustituir ese trabajo, lo más que te podrá decir es que lo plasmes en tal o cual documento, pero eso no asegura, para nada, que el resultado sea de mayor o de menor calidad.

Ahí está la clave, las personas aportan valor al proyecto porque el desarrollo de software requiere un esfuerzo intelectual importante en todas sus áreas y por parte de todas las personas que participen en él. Y no todas las personas son igual de efectivas, impactando de manera muy sensible en los resultados el hecho de si se acierta o no con las personas y el equipo y si el mismo se ha gestionado de manera adecuada durante el proyecto.

Cuando los procesos por sí solos sean capaces de desarrollar software tal vez piense que su importancia es mayor que la de las personas pero mientras sean los seres humanos los que con su esfuerzo sacan adelante los proyectos para mi la prioridad la tienen ellos.

La creencia en que el proceso lo soluciona todo ha llevado a la definición de algunos que prácticamente no dejan margen de maniobra a los desarrolladores que se ven atados de pies y manos (en el caso de que además su cumplimiento sea obligatorio) a la hora de tomar decisiones, actitudes o estrategias que pueden ser más positivas para el proyecto en el que se está trabajando. En el desarrollo de software no hay llaves maestras, no hay verdades absolutas y mucho menos procesos que sirvan para todo y que sean una garantía infalible de éxito.

Las personas que participan en el proyecto requieren margen de maniobra para poder adoptar dentro de unas restricciones la solución más adecuada para su contexto actual.

Sobre este tema me gusta mucho la siguiente reflexión de Andy Hunt y Dave Thomas, “Cualquier proceso que intente reducir el desarrollo de software a algo que no requiera utilizar el cerebro normalmente da lugar a solo eso: un producto desarrollado por gente sin cerebro”.