¿Por qué los desarrollos de proyectos son una pesadilla?

Los desarrollos de software suelen ser una pesadilla. ¿Quieres conocer la respuesta sencilla que se esconde detrás?

Quien haya vivido de cerca el desarrollo y posterior lanzamiento de un proyecto online lo tiene claro. Es una pesadilla. Hace poco escribí sobre una posible manera de coordinar de forma efectiva y básica un desarrollo de software. Mi propuesta evidentemente no te sirve si tienes proyectos grandes que requieren la coordinación de diferentes equipos. Aunque quieras hacer cosas más modestas siempre surgen imprevistos y ocurre lo de siempre: los planes al final nunca salen como previsto.

Pesadilla DesarrolloDerechos de foto de Fotolia

El conflicto entre el equipo técnico y el de marketing

La cuestión es. ¿Por qué es un tan complicado realizar un proyecto de desarrollo sin que surjan complicaciones? La razón más importante es que surgen cambios de forma constante. Un trabajo ya empezado se puede llegar a tirar a la basura o hay que invertir mucho más tiempo del previsto para efectuar la tarea planificada. Esto evidentemente es una pesadilla para los programadores a los que les gusta empezar por A y terminar por la Z (por lo menos los que yo conozco).

La culpa la tenemos típicamente la “gente de marketing y de negocios” a los que se les ocurre “oye, pues no estaría mal hacer esto y la otra cosa”. “Claro que no estaría mal pero… por qué no se te ha ocurrido esto hace 2 meses cuando tuvimos la primera reunión sobre el tema” es lo que podría pasarle por la cabeza de esta o forma parecida al responsable técnico de un desarrollo.

No tengo un perfil técnico pero con el tiempo desarrollas una intuición para las cosas que van a costar tiempo y esfuerzo o si se trata simplemente de pequeños ajustes. Está claro que no siempre aciertas pero muchas veces sí. Cuando te toca la gestión de un desarrollo tu rol tiene que ser la de mediación y filtro entre la parte técnica y la de negocios. Es totalmente comprensible que a un programador se le pongan los pelos de punta cuando escucha la frase “tengo una idea genial”.

Los cambios constantes y problemas imprevistos convierten los desarrollos de software en una pesadilla

La cuestión es. ¿Por qué surgen tantos cambios? Argumentando desde la parte de marketing puedo decir que es increíblemente difícil tener claro desde el principio lo que quieres exactamente. Siendo totalmente sincero esto requiere una disciplina que pocos tienen (por lo menos yo no). Aunque te pongas desde el principio e inviertas días y semanas para planificar y documentar desde cero los requerimientos, dudo que con el paso del tiempo no vayan surgiendo nuevas ideas. Siempre acabas dándote cuenta de que algunos conceptos igual no eran tan buenos como pensabas. Junto con esto se une el feedback de los programadores que requiere cambios porque surgen problemas que no estaban previstos.

No conozco a nadie que haya realizado un proyecto de desarrollo de software sin tener ningún tipo de incidencia. No soy fan de que hay que ejecutar un plan inicial para evitar retrasos. Si merece la pena hay que invertir más tiempo y ya está. Hay que tener claro que no se puede hacer todo de golpe. Es mejor dar muchos pequeños pasos que uno demasiado grande. Hay que aceptar el hecho de que los desarrollos son una pesadilla y punto. Los planes nunca salen.

Cuando llega el gran día de lanzamiento surgen los nervios porque quieres ver la reacción de la gente. Cruzas los dedos para que todo salga bien o que por lo menos no surjan más problemas de lo esperado. Ya queda poquito. Crucemos… :)

  1. Yo nunca he encargado un proyecto similar a nadie, pero he trabajado sobre muchas plataformas realizadas por programadores. Ahora mismo tengo una entre manos. Una aplicación sencilla de carga de datos, una base de datos enorme.
    Va como el puto culo.
    Pero el problema no es de ASI Soluciones, los constructores, sino de Telefónica Móviles España y su falta de orden interno.

    Toda esa base de datos podría resumirse en tres pequeñas pestañas de un modo efectivo y rápido, pero entonces miles de personas no recibirían la informacióm exactamente del modo en que ellos quieren, sino con palabras que no les gustan. De ese modo el programa consta de 19 sub-bases datos ¡¡no relacionadas entre sí!! cuyos valores son los mismos que en la pestaña 1, 2 y 3 pero escritos o representados de otro modo. Una auténtica pérdida de tiempo porque hace dos años nadie hizo una reunión con los diferentes departamentos a nivel nacional y les dijo “Todos vamos a operar con la misma BBDD, que será lo más simple y completa posible.

    Según se avanzó en el proyecto, los diferentes departamentos, al ver que los datos necesarios para su trabajo no les llegaban, se quejaron de manera consecutiva. De modo que se empezaron a abrir más bases de datos específicas para cada gestor, acabando con una herramienta muy pobre en la que nadie tiene acceso a todo y donde todo está repetido cuatro o cinco veces en bases de datos no coordinadas.

    Con la adesión de cada departamento, en vez de remodelar el programa y fusionar los datos, se amplía con otros nuevos, en una espiral de descontrol que encarece el producto final y limita el alcance de la empresa al mando. Y es Telefónica. Miedo me da el resto de sectores.

    Responder
  2. En esto no puedo estar más de acuerdo contigo Carlos, este es de los artículos que te tiembla el dedo para contestar porque te gustaría aporrear la cabeza de quien te trae por la calle de la amargura pero no puedes.

    Mi experiencia es de estar en todos lados, porque yo empecé desarrollando proyectos, y sé lo que es:
    - Modificar proyectos por nuevas ideas y hasta pararlas (a veces es necesario)
    - Mediar entre la parte de desarrollo y la de negocio (Sin duda la más dura, porque estar en medio nunca es bueno)
    - Definir la parte de negocio y marketing y encontrarte con problemas y trabas técnicas

    Los proyectos son una pesadilla, y es por eso sin duda que o cuentas con un equipo con talento y resolutivo o todo lo que has planificado se puede ir a la basura, además, cuanto más complejo es un proyecto, más posible es que aparece otra gran problema: ¡¡La desidia de los desarrollos largos!!

    Donde todo se empieza con gran ilusión y corrigiendo errores, solventando problemas técnicos y de usabilidad, pero a medida que se alarga la vida del proyecto y entran conflictos…ayyyy se acabaron las ganas de resolver problemas y sólo hay prisa por acabar…y da igual como.

    PD:Espero que Bundi siga bien…porque esa foto ¿hace presagiar problemas con IronBlogger ?

    Responder
  3. […] utiliza en sus entradas. La idea surgió porque honestamente este fin de semana estaré liado con estas cosas y quería saber cómo este hombre consigue decir tanto con tan […]

    Responder
  4. A grandes males, grandes remedios. Para eso, se ha desarrollado la metodología Scrum.

    Responder
  5. Nunca es sencillo llevar el desarrollo de ningún tipo, pero como bien indica Jerby existen metodologías de desarrollo la más famosa y usada la basada en Scrum (http://es.wikipedia.org/wiki/Scrum) hasta google la utiliza ;)
    Y como bien dice Marcos, muchas veces hay que parar ideas de última hora para poder sacar el proyecto a la luz, porque siempre llegan esos momentos tan delicados de:
    - He pensado que…
    - Y si hacemos que…
    - Esto no sería mejor si…
    - Ah! pero esto no hace…. yo creía que…
    Y al final en el departamento de desarrollo se oye la frase “putos creativos” jajajajaja
    En resumen buena planificación+metodología de trabajo = éxito

    Responder
  6. Para este tipo de cosas están las metodologías ágiles, como Scrum o Kaban, que se adaptan mejor al cambio y no requieren de tediosos análisis iniciales que luego nunca se cumplen. Te recomiendo que les eches un ojo, son muy interesantes.

    Responder
  7. Yo por mi parte estoy en un desarrollo de un proyecto y es cierto que es difícil llevar a cabo las dos cosas, porque siempre hay algún inconveniente en la programación, o qué se complica de hacer tal cosa y eso siempre conlleva un retraso, sin embargo por eso se debe contar con una metodología de trabajo.

    Responder
  8. 1.- siempre hay cambios, pero si quieres algo finalizado no incordies al desarrollador metiendo los cambios a mitad del camino.
    2.- prueba con metodologías ágiles, como scrum que te permite esos pasos pequeñitos que mencionas… Pero deja que termine el ciclo (quizá 1 o 2 semanas) antes de redirigir el proyecto.
    3.- habla con el desarrollador, de persona a persona. Él quiere darte el mejor producto, el que mas se parezca a tus necesidades. Es mejor hablar 2 horas que redactar un infumable documento de especificaciones.

    Responder
  9. Definitivamente el pequeño detalle de “el cliente siempre tiene la razon” termina por hacer chapuzas y cambiar cada 2 por 3 los requerimientos de los desarrollos.

    Responder

Deja un comentario

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