Personas o bits

Los desarrolladores de software, yo el primero, tendemos a centrarnos en cuestiones  técnicas, a pensar que este tipo de cuestiones son las de mayor importancia en la vida de los proyectos de desarrollo. Pero esto no es cierto. Voy a dedicar está columna a argumentar el porqué. La cuestión es muy interesante en mi opinión, porque quizás los desarrolladores y la industria del software han estado equivocando donde deben poner su foco de atención.

Pensemos en las típicas estadísticas que a menudo leemos sobre los motivos por los que los proyectos fallan. Nunca cuestiones o dificultades técnicas ocupan los primeros lugares. Otro síntoma claro de que la tecnología no es el factor clave es el hecho evidente de que existen proyectos exitosos y sonoros fracasos desarrollados en todas la tecnologías y lenguajes de programación.

Uno de los autoengaños, en los que solemos caer los desarrolladores, yo el primero, es preocuparnos demasiado por las herramientas o las tecnologías, sobre todo por las nuevas. A menudo se encuentra a los desarrolladores discutiendo sobre tal o cual herramienta, o nuevo lenguaje… Es normal, los fabricantes de esas herramientas promueven ese debate prometiendo mejoras en la productividad que debemos reconocer rara vez son tales y que, si se producen, nunca llegan a lo prometido. ¿Alguien puede citar alguna herramienta que mejorase radicalmente su productividad? No hablo de usar un potente IDE frente a usar simple editor de texto, sino de usar la versión actual de un potente IDE frente a usar la versión anterior. Pensándolo en frio, creo que es evidente que si bien es cierto que las herramientas mejoran nuestra productividad, estas mejoras no son radicales sino que se producen de manera muy distribuida en el tiempo. En resumen, las herramientas evolucionan pero no revolucionan de manera puntual nuestra manera de hacer software. Esto no quiere decir que debamos desdeñar las mejoras que puedan surgir de utilizar las mejores herramientas, sino que las mejoras que debemos esperar en este aspecto del desarrollo de software son pequeñas. Lo aquí comentado se aplica, punto por punto, también a las tecnologías. ¿Alguien piensa que es mucho más fácil desarrollar una aplicación distribuida con WCF que con Remoting o Web Service o incluso que con DCOM?. No, la dificultad no está relacionada con las herramientas a usar sino con la complejidad del problema a resolver.

Otro punto que tendemos a olvidar es que las tecnologías y herramientas, antes de que tengamos la oportunidad de que nos ayuden tenemos que aprender a utilizarlas y este proceso, a menudo, minimiza las mejoras que podemos esperar.

Con lo que he comentado anteriormente no quiero decir que no haya que buscar y seleccionar nuevas herramientas o tecnologías y aprender a utilizarlas, sino que no debemos creer que vayan a cambiar radicalmente nuestra capacidad o la de nuestro equipo a la hora de crear software y sacar adelante nuestros proyectos.

Las metodologías son otra de las áreas que prometen grandes mejoras en el desarrollo de software y en este caso, creo, que bien implementadas, las metodologías, sobre todo aquellas centradas en ayudar al desarrollador, obtienen grandes resultados. El problema es que implementar bien una metodología es un proceso extremadamente difícil, complejo, costoso y largo en el que muchas empresas o equipos de desarrollo fallan en repetidas ocasiones. ¿Cuantos de vosotros habéis sufrido un intento fallido de implementar una metodología? Estoy seguro que muchos. ¿Cuántos de vosotros tenéis teóricamente una metodología y realmente lucháis para que nos os entorpezca? Pocos equipos de desarrollo tienen una metodología y entre los que la tienen, pocos están plenamente satisfechos con ella. Resumiendo, usar una metodología adecuada puede mejorar en mucho nuestra productividad, pero es muy difícil cerrar el triangulo mágico de encontrar una metodología adecuada, implantarla con éxito y lograr que ayude a los desarrolladores. Esta última, es condición necesaria para que perdure y se extienda a otros proyectos de nuestra empresa. Solo una metodología que ayude a los desarrolladores y que mejore su vida profesional día a día tiene alguna oportunidad de perdurar. El motivo es claro, todos somos reacios al cambio, y mucho más reacios somos a aquellos cambios que no se revelan rápida y claramente como ayudas. Es también evidente que el rol más numeroso en los proyectos de desarrollo es el de desarrollador, mucho más numeroso que el de jefe de proyecto, gerente y demás puestos ‘de responsabilidad’, y por tanto cualitativamente, de quien más resistencia encontramos cuando una metodología no ayuda, es, precisamente de los desarrolladores. No deja de ser paradójico, además, que a menudo se escuche poco o nada la opinión de los desarrolladores a la hora de seleccionar e implantar una metodología.

Bien, hemos comentado que a pesar de lo que tendemos a pensar, las herramientas, las tecnologías y las metodologías no tienen un impacto radical en mejorar como hacemos software. Aunque tienen su importancia. También es claro que en el mundo competitivo en el que nos movemos cuando hablamos de desarrollo de software necesitamos mejorar día a día. Ahora os preguntaréis, si lo esencial en el desarrollo de software no es, según defiendo en este artículo, las herramientas, las tecnologías y las metodologías, ¿qué es lo esencial?: las personas y sus interacciones.

El factor más importante en el desarrollo de software es la calidad de los desarrolladores que llevan a cabo el trabajo. Nada puede suplir este factor. A pesar de los muchos intentos que en la industria del software se han hecho por hacernos creer lo contario. Un equipo de ‘juniors’, es un equipo poco capaz, lo dirija quien lo dirija, use las herramientas que use y aplique la metodología que aplique. Nada puede suplir la experiencia y la maestría de los desarrolladores. Es curioso como cuando se habla de este tema, todo el mundo asiente, pero si embargo luego todo el mundo lo olvida con facilidad. A menudo se trata a los desarrolladores como piezas intercambiables o metodologías con amplia aceptación como CMMI se olvidan de incluir el factor humano en la ecuación centrándose únicamente en el proceso. Como si un excelente proceso permitiese realizar desarrollos excelentes sin desarrolladores excelentes. La realidad es que desarrolladores excelentes pueden lleva a cabo desarrollos excelentes con metodologías mediocremente implantadas o incluso sin metodología explicita alguna. ¿Si todos asentimos cuando alguien clama que las personas es el principal factor por qué nos olvidamos de este factor con tanta facilidad?. Quizá sea porque es el factor sobre el que más difícil es actuar. Pero no por eso debemos dejar de actuar.

Un hecho que la industria del software lleva obviando durante gran parte de su historia es que los buenos desarrolladores son extremadamente baratos. Existen numerosísimos estudios que ‘demuestran’ que la diferencia de rendimiento, se mida como se mida, entre los mejores y los peores programadores es de alrededor de ¡treinta veces!. Ahora os propongo un juego, pensad en el mejor desarrollador y el peor con que hayáis trabajado. Pensad en su rendimiento, y decidme si no se cumple lo anterior. Ahora pensad en su sueldo, ¿alguien cree que la diferencia era de alrededor de treinta veces?. La conclusión es clara, la relación rendimiento sueldo no es lineal, luego, proporcionalmente los desarrolladores cuanto mejores y más experimentados son más baratos resultan. Entonces, ¿por qué sigue habiendo proyectos plagados de gente sin experiencia?.

Las personas cuentan mucho, pero aun cuentan más cuando juntamos varias. Cuando lo que se comparan son equipos y no personas individuales, la diferencia es todavía más apabullante. El rendimiento que puede alcanzar un equipo bien engrasado es espectacular. El problema es que solo quien ha estado en alguna ocasión en uno de esos equipos puede saber de lo que hablo. Pero creedme, nada puede impulsar más vuestros desarrollos que logra que el equipo de desarrollo funcione como un reloj. De hecho, nuestro principal cometido como gestores de proyectos es sin duda, construir el ambiente en el que nuestro equipo pueda realizar su trabajo en condiciones óptimas (ver la viñeta de Dilbert adjunta). El resto aunque es importante es menos importante.

Supongo que más de uno os estaréis preguntando porque os cuento todo esto. La idea que tengo es dedicar algunas entregas de este espacio que tan amablemente me ha cedido dotNetMania a desgranar lo que se esconde bajo cada uno de los puntos que constituyen el manifiesto ágil, cimiento sobre el que se fundamentan todas las metodologías ágiles. Todo lo que os he contado en esta entrega se corresponde con el principio que dice: ‘Individuos e interacciones sobre procesos y herramientas’. ¿No os parece que todo lo dicho tiene sentido y que sin embargo es algo que llevamos obviando mucho tiempo?. ¿De qué pensáis vosotros que va el desarrollo de software, de personas o de bits?.

Publicado anteriormente en la columna de opinión de la revista dotNetMania. La viñeta de Dilbert no aparecio en el artículo original.

12 comentarios sobre “Personas o bits”

  1. Hola Rodrigo!,

    Pienso que los proyectos de software van de personas que desarrollan sobre bits, lo esencial es el factor humano. Sin embargo, en muchas universidades, los docentes de ing, del software, suelen sobre valorar a las metodologías, y menospreciar la labor de los desarrolladores, diciendo que el desarrollo es secundario, y lo puede hacer cualquiera. Este tipo de casos también está presente en las “cabezas” de muchos jefes de proyectos, es por eso que este tipo de situaciones suelen ser una de las causas por las que un proyecto falla.

    Comparto con usted lo que menciona: “El factor más importante en el desarrollo de software es la calidad de los desarrolladores que llevan a cabo el trabajo”. Le doy toda la razón, excelente!.

    Saludos!,

    Percy Reyes,

  2. Rodrigo,

    Quizás es un problema de los informáticos pero normalmente solemos valorar las cosas en terminos binarios, donde algo es bueno o es malo sin ningún tipo de termino intermedio.

    Soy de la opinión de que todas las opiniones son ciertas 🙂 y si me lo permitís ahí va la mia.

    En un proyecto software hay muchas cosas a parte del desarrollo en si mismo. Existe una gestión financiera, una gestión de las expectativas del cliente donde se incluyen la gestión de los requisitos, ofertas, etc.

    Por otro lado existe labores paralelas al desarrollo y que se dan en todas las fases como la gestión de riesgos, cambios de alcance, monitorización del avance y un largo etc.

    Básicamente del esfuerzo total de un proyecto creo que se dice que el desarrollo no supone más del 40% del mismo.

    Dicho esto en lo que creo que estaremos basicamente de acuerdo, podemos ver que hay tareas dentro de un proyecto que un desarrollador por muy bueno que sea no tiene porque saber hacer bien, como por ejemplo llevar correctamente el plan finaciero, negociar un cambio de alcance y demás, y estas son cosas tan criticas para que un proyecto salga bien, como que en las pruebas haya pocos errores de codificación o que el diseño sea un portento de ingeniería.

    De ahí que aun estando de acuerdo con lo que dice Rodrigo de que hay que poner foco en las personas, discrepo en que la solución pase por poner foco en los programadores.

    Es como decir que las metodologias para construir edificios deben poner foco en los albañiles porque son más numerosos. Siguiendo el ejemplo si el arquitecto comete un error en el plano ese error va a ser mucho mas costoso al final que el hecho de que un albañil haga mal una pared.

    Lo mismo en el caso de un programa, costará mas un error en la captura de los requisitos o una malinterpretación de las necesidades del cliente que el hecho de que se cometa un error codificando.

    Bueno por no enrrollarme dando vueltas a lo mismo, mi opinión pasa por no ser excluyente en lo que ha metodologias se refiere, no hace falta decir que CMMi es una mierda o SCRUM es lo mejor, quizas existan partes del ciclo de vida de un proyecto donde aplicar procesos de CMMi mejoran el resultado, por ejemplo aplicado el proceso de RM y RD a la captura de requisitos y otras fases donde SCRUM facilite la labor de todos y produzca rápidos resultados.

    Mi consejo es que no seamos binarios, ya que como decía Aristóteles la virtud está en el termino medio.

    Acabo diciendo, buen Post Rodrigo

  3. Hola Rodrigo,
    Cuantas veces repetidas cosas de este tipo, y qué poco caso se les hace también a veces, quizá demasiadas).

    Generalmente consultores, gestores y gente de calidad se ciñen a aplicar las “formas” de los modelos, pasando de puntillas (o pasando del todo) del “fondo” que hay detrás.
    Presuponiendo que una talla única vale para todos, y: o que siempre el conocimiento radica en los procesos, y las personas los ayudan a ejecutarse; o al contrario, que el conocimiento radica en las personas y los procesos son rutinas que les facilitan su trabajo.

    Y suele pasar que quien es de la religión A lo es siempre y para todos los proyectos en todas las empresa, y quien es de B lo mismo.

    El sentido común, y un conocimiento técnico del software, aunque sea genérico, ayuda mucho.

    Enhorabuena por el blog!
    Un saludo.
    Juan Palacio.

  4. Rodrigo:
    ¡Cualquiera diría que has leído Peopleware!
    Coincidiendo contigo en los más importante, el valor de las personas frente a la tecnología, creo que el mayor valor a la “calidad de los desarrolladores” dejas fuera a otros que, desde mi opinión, gozan del mismo puesto en el ranking: project manager, administrador de base de datos, arquitecto de sistemas, analista, … y es que una cadena es tan débil como su eslabón más débil. Por esto motivo, permíteme añadir al cometido de los project manager, no solo la imprescindible tarea que mencionas: crear un entorno de trabajo que facilite el éxito del proyecto, también seleccionar a su equipo – ¡acaso no lo hacen los entrenadores en cualquier deporte!, ¿por qué no en este?

    Finalmente decir que al dar importancia a la experiencia y conocimiento de los desarrolladores también se le da a la tecnología, valor que en muchos casos se le quita al asumir que cualquiera, junior o recién llegado a la misma, puede manejarla adecuadamente. Programar, al igual que cualquier otro arte, tiene sus técnicas y requiere de práctica.

    Excelente artículo e imprescindible reflexión.

  5. Angel, comparto totalmente lo que dices de que dar importancia a la experiecia y conocimiento de los desarrolladores es darsela a la tecnología, en incluso a los procesos, por que sobre este es el dominio de conocimiento de estos. Nunca lo había visto desde esta optica. Interesante reflexión.

    Solo un matiz sobre tu comentario, cuando hablo de desarrolladores hablo en el sentido más amplio del termino, incluyendo todos los roles implicados, no solo los que ‘pican’ código.

  6. Excelente Post

    Soy nuevo recien egresado en el ambito de la Programacion, desarrollo de manera individual, ya he tenido varios proyectos. Tengo problemas en escoger una metodologia que realmente me ayude. dadas las caracteristicas, cual me recomiendan seguir?

    Saludos

  7. Daniel, en mi modesta opinión, un desarrollador individual no necesita una metodología para nada. Lo que necesita es formarse una buena base de principios que guien su trabajo como desarrollador (http://geeks.ms/blogs/rcorral/archive/2006/10/05/Grandes-principios-del-desarrollo-de-Software.aspx)

    En cualquier caso, sin elegir una metodología en concreto, siempre viene muy bien conocer las metodologías más importantes por dos motivos: para adoptar aquellas ideas que consideres interesantes y por si algún día te interesa trabajar con un equipo de desarrollo.

    Un saludo!!!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *