El desarrollo de software en crisis.

Yo creo que en este momento el desarrollo de software se encuentra en crisis. Les quiero hacer una pregunta a mis compañeros que trabajan en el área a ver si es una perspectiva aislada, ¿cuándo fue la última que participaron en un proyecto que se entregó a tiempo?¿no recuerdan?¿alguna vez han trabajado en alguno que se haya terminado sin prorrogas o sin cambiar el cronograma inicial? supongamos que si, ahora respondamos esta pregunta un poco más complicada, ¿cuándo fue la última vez que participaron en un proyecto de software que costó lo que se planeó inicialmente? bueno tal vez muchos de ustedes ni se enteran cuanto cuesta un proyecto, ahora ¿el cliente ha recibido lo que pide en los proyectos en los que ustedes participan?¿si?¿después de cuantas iteraciones se logra cumplir las expectativas del cliente?  En Colombia nos acostumbramos a que los proyectos de software salgan mal; cuesten más de lo que se presupuesta, se demoren más de lo que se planea y que no se cumplan con las expectativas del cliente. 

El resultado es claro, cada vez menos empresas confian en el desarrollo a la medida y prefieren implementar soluciones ya construidas y contratar gente que las mantenga y el mercado de las empresas de tecnología se mueve cada vez más hacia el sector público, en donde las multas por incumplimientos, los retrasos y las condiciones leoninas muchas veces no alcanzan a compensar las ínfimas ganacias que prometen. 

¿la culpa de quien es entonces? Las actas post mortem de algunos de los proyectos de software son todas una tragicomedia de culpas mal repartidas, como estas revisiones se hacen sin la participación del cliente, ni de la mano de obra, la mayoría de las veces se concluye que la culpa de que todo salió mal es del cliente que no supo pedir las cosas (pese a que en el proyecto habían varios recursos levantando requerimientos) o que los requerimientos no se supieron plasmar en desarrollo (pese a tener toda una capa de negocios dedica al “análisis y diseño”). Tal vez el desarrollo del software es el único del mundo en el que descaradamente se le echa la culpa de los inconvenientes al cliente.

Que el cliente haya pedido mal las cosas no puede ser excusa de retraso en ningún momento durante el desarrollo de un proyecto. ¿de quien entonces? yo creo que la culpa es de nosotros los profesionales de la ingeniera de sistemas que no valoramos la importancia del desarrollo, la importancia de lo técnico y de la burocraticación de los proyectos de software. 

Quiero plasmarles la estructura del último proyecto de software en el que participé. El desarrollo se comenzó dos semanas tarde y el cronogrma ya ha sufrido dos prórrogas: 

estructura proyecto

Perdonarán mis habilidades en paint.

Como se podran dar cuenta la estructura es de lo más normal del mundo, es la estructura estándar de un proyecto de software. Arriba en la pirámide tenemos al gerente de protafolio, sus funciones son negociar con el cliente y con la empresa y garantizar el presupuesto y la gente, digamos que su función es clara y absolutamente necesaria pues sin ese manejo administrativo el proyecto no tendría norte. Debajo tenemos al gerente de proyecto y aquí las funciones ya empiezan a ser un poco difusas porque este “gerente” no tiene incidencia directa ni en los recursos que se usan ni en el dinero que cuestan, pero digamos que igual alguien tiene que hacer los cronogramas e informes de seguimiento, así el cronograma solo sea útil una semana y los seguimientos solo sirvan para explicar porque vamos retrasados. Debajo de él viene el líder técnico, una figura aun más complicada de descirbir, ¿qué hace un líder técnico que no pueda hacer el gerente de proyecto? bueno digamos que esta función la ha ido desplazando la figura del arquitecto y que podría justificarse si es que el gerente del proyecto por razones desconocidas e incomprensibles no quiere tratar con la sucia mano de obra. Debajo de este líder técnico hay otros líderes: de requerimientos, de análisis, de pruebas, de documentación, etc.  Pequeños latifundios de póder entre una capa y otra. ¿qué hacen que no pueda hacer un líder técnico o el mismo gerente de proyecto? bueno digamos que son los canales de comunicación entre los líderes y la mano de obra, pero ¿porqué nadie quiere tratar con la mano de obra? en fin, ya debajo de estas capas está la sucia mano de obra: los testers, los documentadores, los desarrolladores, etc. La gente con la que al juzgar por la estructura de los proyectos nadie quiere tratar. 

Como viajan las ideas.

9000 horas en paint.

Ahora, ¿dentro de este esquema por donde viaja la información de lo que quiere el cliente? veamos. Primero el comercial vende una idea (más fácil si licita pues la idea se conoce de antemano) que es comunicada al gerente de portafolio, este define los perfiles que necesitaría, la plata y los tiempos, esta idea luego viaja via documentos que nadie lee (al parecer) hacía el gerente de proyecto y empiezan las reuniones de levantamiento de requerimientos. Aqui las ideas iniciales mutan por otras más específicas y se plasman en documentos que viajan hacía el área de análisis y diseño y luego ahí si viajan hacía los desarrolladores que en últimas son los encargados de hacer realidad la idea que vendió el comercial. Luego empiezan los ires y venires con el área de pruebas, luego al software le hacen pruebas funcionales y empiezan las batallas entre lo que es una solicitud de cambio y lo que estaba definido, el líder de requerimientos dirá que “eso no lo pidio el cliente” y luego el cliente dirá “pero es que pensé que era obvio” y así sucesivamente hasta que el cansancio logre terminar con el proyecto. Perdónenme la expresión, ¿pero cómo HIJUEPUTAS queremos que un proyecto funcione bajo esta estructura? Claro, algunos dirán ¿pero por qué habría de estar mal esto si la empresa es CMMI nivel 5 y tiene certificados sus procesos de acuerdo al RUP?¿y qué tal que el RUP o los niveles de madurez que define el CMMI sean más bien dogmas que escapan a la realidad del software y la realidad de nuestra idiosincracia?¿no podría ser que estemos más preocupados por certificar procesos que por entregar software de calidad? 

¿cómo se podría cambiar todo este mierdero? sencillo: el desarrollador reemplace varios de los cargos de esa estructura. Respondamos algunas preguntas. ¿qué impide que un desarrollador, el que va a plasmar las ideas en la realidad, sea el mismo que levanta los requerimientos? no existe ninguna razón, repóndanme esta, ¿qué impide que sea el desarrollador quien realice el análisis de lo que en últimas él mismo va a realizar? esta es más complicada aún: ¿por qué para un proyecto es más importante la documentación que el software? Si no existieran tantas capas burocráticas la documentación que igual hoy nadie lee no le importaría a nadie, ¿la necesitan por alguna razón mística? perfecto dejemos entonces a los documentadores (pero sin el dichoso líder) y que cumplan esa funcionalidad paralelo al desarrollo. Si el desarrollador levanta requerimientos, realiza el análisis, prueba su software y valida con el cliente ¿para qué habría de necesitar un diagrama de casos de uso o uno de actividades? Si tuvieramos buenos desarrolladores multitarea, ¿no sobrarían casi todos esos perfiles que convierten el viaje de la idea inicial en un teléfono roto?

Este cambio de estructura no solo beneficiaria al cliente, pues sus solicitudes viajarian menos de una mano a otra, si no a las empresas mismas pues se reducirían costos no solo en perfiles inútiles si no también en tiempos muertos, pues porque mientras el proyecto está en su fase de requerimientos el desarrollador está actualizando su blog y aunque muchas empresas quisieran alcanzar una transversalidad de desarrollo (las famosas fábricas de software) es tarea imposible sincronizar proyectos para que alcancen su fases de desarrollo de forma tal que se puedan mover recursos de uno a otro proyecto sin impactar tiempos y costos. 

Claro para esto necesitariamos muy buenos desarrolladores, cosa que hoy es muy difìcil encontrar pues los profesionales con experiencia deciden abandonar lo técnico pues creen que es un ascenso (así muchas veces no ganen más plata) dejar de desarrollar y se terminan volviendo obsoletos para el desarrollo pero buenísimo en hacer documentos que nadie lee. La culpa también la tienen las universidades pues aun hoy están graduando profesionales en sistemas cuyo propósito en la vida es hacer documentos en Word pues no les gusta desarrollar, no les gusta la infraestructura y no les gustan las bases de datos. 

Salir de esta crisis parece tarea difícil, por lo pronto mucho se haría con cambiar el paradigma de que desarrollar es algo indigno o que dejar de desarrollar es un ascenso. Ya con el tiempo podemos esperar que las empresas que hoy empiezan con un nuevo paradigma, lejos del RUP y el CMMI, y centradas en el software empiecen a ganar mercado y consideren más atractivo un desarrollador senior que un especialista en arquitectura o en gerencia y que así mismo los salarios suban y el mercado se llene de clientes felices. Mientras tanto a escribir diatribas en sus tiempos muertos. 

Anuncios


Categorías:Opinión

5 respuestas

  1. Hacía rato que quería poner un comentario aquí pero he estado muy ocupado en proyectos de, adivine, desarrollo de software.
    Desde la primera vez que leí esta nota, no dejé de asentir y sonreir porque mi yo de hace muchos años sentió exactamente lo mismo y fue entonces cuando decidí mandar al carajo a todo el mundo y desde mi perspectiva de desarrollador asumí todos los roles “de ahí p’arriba” . Saqué un producto: Un Generador de Aplicaciones. Era la solución de soluciones. Lo desarrollé en Clipper y generaba librerías, ejecutables y archivos de datos CISAM o dBase. Estoy hablando de los 80’s cuando los PCs empezaban su expansión y las pantallas eran “character based”. AL terminar la primera versión (tarea que me llevó unos años) no me cabía el orgullo en el pecho. Lo usé en un par de proyectos pequeños en algunas entidades del gobierno y ONGs y funcionó de maravilla. El problema era que como “resolvía” los requerimientos aparentemente “tan fácil” no podía cobrar como se hace con los “grandes” proyectos. Más tarde canibalizaría mucho de ese código en el desarrolo de un sistema contable para un tercero, que llegó a tener bastante acogida. El tercero se llenó de más plata (ya tenía bastante) pero a mí no me sacó de pobre. Con el surgimiento del ambiente gráfico, consumí otro poco de años sacando una versión en VisualFox, pero para esa época ya no estaba tan convencido de poder asumir todos los roles y, me dí cuenta, que me había quedado mirándome el ombligo. Hay una regla de oro en cualquier actividad económica. El ingrediente indispensable de cualquier negocio, su requisito sine qua non, es EL CLIENTE. Por eso es que mis sueños de riqueza fallaron. El cliente de mi producto fui yo mismo…
    Pero en el fondo sigo siendo el mismo rebelde que aunque he estado en muchísimos proyectos y en todos los niveles, siempre trato de ponerme en los pantalones del cliente y antes de preguntarle qué quiere me figuro las respuestas a la preguntas que siempre les hago: ¿PARA QUE? y ¿POR QUE?
    Ahora bien lo cierto es que esas metodologías y composición de equipos de desarrollo que describe Emisario aquí son totalmente obsoletas. Desde el advenimiento de los lenguajes oo (object oriented) y funcionales; y de los manejadores de bases de datos con servicios de reporte y análisis incluidos e integrados con clientes a usuario final (como Excel), el desarrolo de software ha cambiado muchísimo en el primer mundo. La administración de proyectos (de cualquier clase no solo desarrollo de SW) evolucionó desde la primitiva cascada (waterfall), hacia la reingeniería, el TQM, el benchmarching, y actualmente va por los lados de lo que llaman AGILE en donde los requerimientos se atomizan en pequeñas porciones asumidas en carreritas (sprints) que no dejan espacio para los “descrestadores” ni mucho menos para los “lentificadores” de los proyectos. La documentación se le deja a gente especializada en esa labor ya no es responsabilidad de los programadores.
    La cosa es que si queremos aplicar nuevas metodologías de desarrollo (como AGILE y Scrum) y de análisis y diseño (como el RUP) y seguir con una organización a lo colombiano, es decir, llena de caciques y con pocos indios, no llegamos a ningún Pereira…

  2. Lo peor del tema es que en el sector gobierno los comerciales son expertos en comprometerse a programar en la luna con tal de ganarse un contrato y después cuando se enfrentan a multas y caducidades de contrato solo atinan a poner a todo el mundo a trabajar en jornadas ridículas para entregar algo y convencer al interventor que eso es lo que pidieron o ceder el contrato a alguien que finalmente tampoco va a poder con el trabajo.

    Lo cierto es que en nuestro país todos quieren ser Gerentes así sus funciones reales se asemejen mas a la de una secretaria-mensajera, para lo cual en honor a la verdad les sobra los 5 años de universidad.

  3. De acuerdo.. aunque las crisis son también en áreas de construcción, diseño, etc, aquí estamos acostumbrados a esos atrasos en varios ámbitos. Sera que los que podamos demos nuestro grano de arena para cambiar la cuestión.

  4. Don Emisario,

    Que bueno verlo preocupado por el tema.

    Yo diría que el desarrollo de software no está en crisis. Al contrario, está expandiéndose y mejorándose continuamente. Los problemas descritos en el artículo son más bien características de algunos proyectos de desarrollo de software.

    En todo caso me parece que siempre es bueno generar crítica en la industria para estimular nuevas alternativas y mejores soluciones.

    Saludos!

  5. Muy buen articulo, creo que desde que existe el desarrollo de software a estado en crisis, pero con esas ideas se olasma muy bien el por que de la crisis actual

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

A %d blogueros les gusta esto: