Errores comunes en desarrollo software (I)

Ya iba para largo que no escribía, he tenido una semana bastante ajetreada, aunque las cosas al final no han acabado muy bien y es un tanto irónico que precisamente yo hable de lo que voy a tratar hoy, pero bueno, mejor dejemos estos temas de lado ya que no me gusta hablar de mis problemas por aquí, el enfoque de este blog siempre fue bien distinto.

Introducción

Steve McConnell, y ya con esta serie dejo en paz a este caballero, qué pesado me pongo con él, divide el desarrollo software en cuatro pilares básicos. La metáfora de pilar nos viene muy bien para entender que si uno de estos pilares falla, la estructura (el producto) se viene abajo, por tanto es fundamental cuidar todos con especial atención. Estos cuatro pilares, sin embargo, son independientes. Éstos son:

Personas: Tienen un efecto muy importante sobre la productividad y la calidad. Es fundamental, por ello, mejorar el potencial humano. Probablemente sea éste el factor más importante de todos.

Proceso: Visto desde el punto de vista técnico y de gestión. Un buen proceso evita tener que rehacer trabajo por no haber realizado anteriores tareas correctamente (ejemplo: rediseñar un producto por no haber captado correctamente los requisitos). Asegura, además, la calidad desde dos frentes: por uno garantiza la entrega de un producto satisfactorio para el cliente; por otro permite detectar problemas y errores lo antes posible. Conceptos fundamentales aquí son la gestión de riesgos, el aprovechamiento de los recursos disponibles, el aprendizaje de técnicas y modelos de desarrollo…

Producto: El tamaño y las características pueden reducir considerablemente el tiempo de entrega, si puedes elegir qué funcionalidad entregar antes.

Tecnología: Utilizar tecnologías más cómodas y avanzadas, teniendo en cuenta los riesgos que estas mismas conllevan.

Cuando se atienden debidamente las 4 dimensiones en su justa medida, podemos alcanzar sinergia.

Errores comunes en desarrollo software

A partir de la clasificación anteriormente explicada, se identifican los siguientes errores comunes a la hora de desarrollar software; todos ellos tienen que ver con alguno de los cuatro pilares:

En cuanto al factor humano,

1.- Baja motivación. Probablemente sea el factor más influyente de todos, en cuanto a productividad se refiere.

2.- Personal escasamente cualificado. Las capacidades individuales, así como la relación con el resto del equipo, influyen en la productividad casi tanto como el error anterior.

3.- Problemas entre los miembros del equipo no controlados. Escucha los problemas del equipo y atiéndelos debidamente; no hagas caso omiso a cualquier situación que pueda perjudicar el objetivo común.

4.- Heroicidades. Es mejor basarse en estimaciones realistas que en compromisos (commitments) imposibles de cumplir que a la hora de la verdad conllevan más riesgo.

5.- Añadir personal a un proyecto ya empezado. Si alguien piensa que agregar  gente  simplemente va a aumentar la productividad, está equivocado. Puede ser como echar gasolina al fuego. Añadir personal requiere una etapa de formación y aprendizaje más o menos larga, que al principio conlleva más gasto que beneficio y que solamente con el tiempo se logra un retorno de la inversión (ROI, Return Of Investment, que dicen los anglosajones).

6.- Oficinas ruidosas y abarrotadas. Afectan negativamente a la productividad.

7.- Tensiones entre programadores y clientes. Pobre comunicación, pobre entendimiento de los requerimientos del cliente, pobre diseño de la interfaz de usuario. Como consecuencia más catastrófica: no aceptación del producto.

Basta por hoy. Continuaremos en otra ocasión. Nos vemos, pues.


Referencias:

Steve McConnell: Rapid Development, Taming Wild Schedules

9 pensamientos en “Errores comunes en desarrollo software (I)

  1. En realidad los problemas que comentas pertenecen más a una metología de desarrollo en cascada que una ágil.
    Creo que SCRUM solito cura todos esos problemas, es decir, el problema de no “comprender los requisitos” parte de la base de que el usuario no tiene claro lo quiere desde el principio o que no es capaz de transmitirlo o incluso que el “analista” no lo capta correctaemnte.
    Si se hace una fase en la que se pregunta al usuario que quiere tener exactamente, al más mínimo detalle, como producto final en realidad se está preguntando por algo que no se sabe, lo cual conlleva a los demás problemas que se intentan curar con “gestión de riesgos” y demás sistemas de planificación que de momento no he visto funcionar.
    En cuanto al producto y a “entregar valor al cliente”, volvemos a lo mismo, si hay un backlog de producto, en este se indica cual es la epic que más valor dará al usuario, se hace un sprint y se calcula cual es la velocidad del equipo, y en base a esto ya se sabrá de manera realista que se puede dar al usuario para que este empiece a ver algo y empiece a dar feedback sobre el desarrollo.
    Por otro lado, hablando pura y exclusivamente de la planificación y la estimación, si esta es realizada con una “métrica” totalmente ajena a los que desarrollarán la aplicación será simplemente una mentira, con lo cual luego vendrán las prisas, las “heroicidades”, las tensiones y todo lo que hace a la gente miserable.

    Simplemente creo que se debe cambiar la forma de trabajar, yo ya he trabajado con cascada mucho tiempo y no volveré a hacerlo, prueba ágil y me comentas.

    Saludos

  2. Muy buen comentario.
    Actualmente trabajo en una empresa donde se utiliza SCRUM como metodología de desarrollo, y aunque sólo llevo 3 meses allí estoy muy satisfecho.

    El problema de la comprensión de requisitos yo creo que SCRUM lo soluciona por ser una metodología iterativa con entregas incrementales, es decir, cualquier metodología de este tipo, llámese SCRUM o lo que sea, aborda precisamente este problema y tiene más garantías de éxito en este aspecto.

    De todos modos cualquier metodología no es mágica por sí sola, hay que implementarla con cierta técnica y política, o incurriremos en los mismos errores que en una metodología en cascada o en cualquier otra. Es decir: estos errores son universales en ese sentido: si no se utiliza una metodología con criterio y con habilidad existe el riesgo del fracaso, independientemente del modelo que se siga. He aquí algunas causas.

  3. Por supuesto que no existen metodologías mágicas, el problema que yo veo es que si que esisten metodologías o “pensamientos” que hacen infinitamente más complicado hacer bien el trabajo.
    En cuanto a SCRUM, tambien ocurre mucho que se adopta “parcialmente”, es decir, hay gente que hace cascada pero con reuiones diarias de pie. Se mantienen las estimaciones a base de imposición de comercial (increíblemente son muchas las empresas en las que la estimación la hace un comercial) y se mantiene la distancia insalvable con el cliente, lo que deriva en el problema que mencionas de “proceso”.

    En realidad, casi todo lo que ves como un problema que deriva en el fracaso, lo veo más como el fracaso en si mismo, es decir, si tu personal está poco motivado, ya tu empresa ha fracasado en cuanto a que o bien han tratado a la gente como basura, o han utilizado metodolías maquiavélicas de gestión de personal o se las han arreglado para que la gente sea miserable (sin posibilidad de ascenso o teniendo que ascender para mejorar tu situación aunque te guste el trabajo que haces).
    Si tienes problemas entre los miembros del equipo, es porque fomentas la competitividad por sobre el cooperativismo como funcionamiento empresarial, con lo cual tendrás siempre a la gente matandose entre ellos porque todos quieren un aumento de sueldo, y si hay que pasar sobre el otro, pues se pasa.
    Si se dan las heroícidades ya has fracasado porque tus estimaciones son malísimas, tu personal se dedica a cualquier cosa menos al trabajo durante el horario laboral.
    Misma historia si agregas personas al proyecto, ya has fracasado nuevamente porque hay que entrenarlas, y esto ya venía de estimaciones en modo “comercial”, personal sin motivación, etc.
    En cuanto al personal poco cualificado, tres cuartos de lo mismo, si se busca gente barata y se hace una gestion de personal digna de consultora/carnica, donde contratan a un tío recien salido de la facultad como junior y lo venden al cliente como senior… pues. Suma a esto que los superiores apoltronados exigirán rendimiento al grito de “no te vas de aquí hasta que no termines esto” y tendrás gente poco motivada o héroes de una noche.

    Lamentablemente esto ya es algo que está muy inculcado en las empresas de informática, y personalmente creo que la única forma de eliminar estos problemas es atacando el problema de raíz y cambiando completamente el método de trabajo, donde esté la auto-gestión estará la gente realmente comprometida con lo que hace, esto motivará a la gente y al haber un feedback constante (como bien dices, el iterativo es lo que tiene) se podrán anticipar los problemas.

    Hace poco lo hablaba con un ex-jefe de los que trabajan aún en cascada más CMMI, fomentan la competencia a muerte bajo la excusa de “para ser competitivos en el mercado”, la separación de tareas (capa directiva-jefe de proyecto-analista-sistemas-programación como operarios) sin casi intercambiar información entre capas a menos que sea por documentos auditados y demás gaitas. Despues de mucho discutir llegamos ambos a la conclusión de que su modelo de funcionamiento se basaba en la desconfianza, es decir, él como jefe no confiaba en que nadie de los de abajo sea capaz de siquiera hacer su trabajo sin su supervisación, así que de auto-gestión ni hablar. Por supuesto esto es lo que transmitia a la gente, y por supuesto la gente actuaba en consecuencia.

    Es muy triste, pero ese es el “pensamiento” al llevar los proyectos en informática, y consecuentemente, dichos proyectos fracasan desde el principio, sin aportar valor más allá de la plusvalía (tiempo trabajado no remunerado) impuesta en la gran mayoría de las empresas: fracasan antes de comenzar.

    Saludos

  4. Impresionante tu comentario. Me ha gustado mucho. Tú de esto sabes un rato, ¿no?

    Realmente lo que dices es cierto: lo que enumero aquí son ya fracasos, no problemas que derivan en fracasos, porque, como dices, si cualquiera de estas cosas están ocurriendo en una organización es como para encender la bombilla roja y saltar las alarmas, gabinete de urgencia y a pensar soluciones…

    “se hace una gestion de personal digna de consultora/carnica, donde contratan a un tío recien salido de la facultad como junior y lo venden al cliente como senior…”

    Me ha llamado particularmente la atención esto que has dicho, ya que lo demás es archiconocido, pero esto es algo menos oído pero terriblemente cierto. Trabajé como becario en una empresa haciendo proyectos que costaban una pasta y que requerían un nivel de experiencia elevado (comprometiendo entre otras cosas riesgo de personas y seguridad nacional), proyecto desarrollado por becarios todavía calentitos recién sacados de la universidad (muchos sin siquiera haberse licenciado aún) e incluso ingenieros de otras especialidades. Como decía Alfredo de Hoces, vender bicicletas sin ruedas ni manillar como si fueran Porsches…

  5. Se dice menos porque la gente tiene su orgullo, y a una persona le cuesta mucho admitir que se equivoca o que no tiene suficiente experiencia para hacer tal o cual tarea.

    Fuckowsky también habla del “ejército de becarios”, otro de los acercamientos industriales erroneos a la creación de software, muchas empresas lo piensan así: si un albañil sin experiencia pone un 50% menos de ladrillos en el mismo tiempo que uno con 10 años de experiencia, pues un programador sin experiencia creará el 50% de clases que uno con 10 años experiencia, pero mucho más barato, así que en vez de contratar a 4 tíos buenos y curtidos, contratamos a 12 becarios sin experiencia por el mismo precio y tendremos un 50% más de velocidad aún, ¡¡¡un negocio redondo!!!

    Taylorísmo puro y duro. El problema es que el desarrollo/creación de software no es una actividad industrial, sino más bien artesana.

    Saludos

  6. Yo nunca tuve problema en reconocer si algo me venía grande o no tenía la formación adecuada para algo. Yo creo que ser honesto con uno mismo es importante, y si aun así te asignan algo que no puedes hacer el problema no lo tienes tú (o bueno, tú también: buscar otro empleo, pero no me refiero ahora a esto).

    Veo que has seguido las andanzas de Fuckowsky, sí señor XDD

  7. Me gustaría saber si todos estos problemas que comentas son aplicables al escasísimo éxito (en cuanto a calidad) que supone cualquier sistema operativo de Microsoft.

  8. Bueno, desconozco qué problemas puede tener o no Microsoft, de todos modos en Microsoft no ha sido todo tan malo: si te refieres a Windows Vista estoy de acuerdo; si te refieres a otro Sistema Operativo de Microsoft pues hombre, los ha habido bastante buenos (WindowsXP, Windows2000, Windows2003Server, WindowsNT) y malos (el resto).

    En principio lo que aquí explico es aplicable en general a cualquier organización que desarrolla software.

  9. El caso de M$ apunta más bien a exceso de burocracia, cuando una empresa crece mucho y se crean tantas capas de abstracción entre los codificadores y los “decition makers” que se puede tardar meses en decidir como tiene que ser una funcionalidad X, para muestra un botón: http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.html

    Es lo maravilloso de los sistemas estilo CMMI: tanta burrocrácia que nunca se decide nada porque nadie se atreve a tomar ninguna desición.

    Eso y su sistema de seguridad/paranoia hace las delicias de los open-sourcers que ya ni siquiera nos hace falta decir nada para criticar estos sistemas inoperantes😄

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s