La programación no debe ser una actividad mecánica

Puedes trabajar con factorías de software siguiendo el modelo que más pueda convenir: Offshore, Nearshore, Onshore y conforme exista más distancia entre los equipos que tratan las especificaciones y el equipo que las desarrolla más mecánico se convierte el trabajo del equipo de programadores: “toma las especificaciones, te las modelo y desarrolla según la arquitectura y framework pactado”.

Es posible que esa distancia la puedan reducir los equipos de trabajo aplicando distintos tipos de técnicas y herramientas porque como he dicho en otras ocasiones el impacto de la distancia depende mucho de la actitud de todas las partes. Sin embargo cuando por encima de los técnicos, hay jefes de proyecto o gerentes “contables” la actitud (si existe) queda difuminada y se entra en un peligroso modelo de trabajo basado en el antipatrón “arrojar al otro lado del muro”.

Como bien dice un amigo, no hacen falta factorías de software para caer en ese antipatrón, te puede pasar perfectamente con el proveedor incluso compartiendo oficina.

En el momento en que se entra en ese juego la programación desgraciadamente se convierte en una actividad mecánica: el programador se limita a ejecutar tareas, conociendo solo el sistema que se desarrolla a bajo nivel. Con esto perdemos el feedback del programador tanto a nivel técnico: tal vez sean recomendables ciertos cambios en la arquitectura o el framework para adaptarlos mejor a la naturaleza del software que se desarrolla, como funcional: Esto no termina de ser coherente con otros módulos del sistema y es necesario que las especificiones sean más claras o que se estudie esa falta de consistencia con el usuario.

En un proyecto todos suman, los programadores por supuesto también (y mucho). Todas las personas que están en el proyecto están capacitadas para aportar ideas y soluciones, tengan el rol que tengan, a veces estarán acertadas y otras se equivocarán pero lo que no podemos hacer es dejar de escuchar sus opiniones porque estaremos despreciando toda la capacidad y talento de los componentes de nuestro equipo.

Anuncios
2 comentarios
  1. Germán dijo:

    Hola,
    me parece muy acertado este post, ya que es algo en lo que he estado pensando desde hace mucho tiempo.

    ¿Tiene sentido tener una factoría de Software? ¿es extrapolable el desarrollo software al desarrollo de cualquier producto industrial?

    Desde mi punto de vista el desarrollo de software está más cercano a una actividad creativa (una obra de arte) que a una actividad mecánica (fabricar un coche a partir de unas especificaciones), y la razón es porque hay infinitas formas de hacerlo. Es decir, para fabricar un Audi A4, solo hay una forma de hacerlo y es seguir las especificaciones, fabricar las piezas y unirlas (independientemente del operario que lo realice), luego el cliente se compra el A6 o no le guste o no le guste.

    Para el desarrollo de un software a medida, existen multitud de formas de hacerlo, ya que depende de muchísimos factores: cliente, tecnología, servidores, organización….etc… y aunque tuviéramos todas las piezas perfectamente especificadas, siempre habrá algo de “arte” a la hora de implementar estas especificaciones.

    En mi modesta opinión, las factorías de software solo tendrían sentido si estuviéramos hablando de un mantenimiento de un producto concreto (ni siquiera la creación del mismo), y la razón es porque dar una especificación cerrada de un software a medida es prácticamente imposible de realizar, el cliente al principio solo tiene una remota idea de lo que quiere. Necesita ver las primeras versiones, ver evolucionar el sistema y sobre todo madurar la idea inicial para adaptarla realmente a sus necesidades.

    Un Saludo

    • jummp dijo:

      Al final depende mucho de cómo se organice o enfoque el trabajo, pero es evidente que todo se hace más complicado cuanto menos interacción y comunicación existe entre las personas que trabajan en un determinado proyecto.

      En el momento en que el procedimiento de trabajo u otras limitaciones como puede ser el idioma afectan a esa colaboración efectiva entre personas, el modelo empieza a resentirse.

      Fíjate que no hablo de distancia porque aunque piense que es muy importante que el núcleo del equipo esté muy próximo, sí que creo posible que el modelo pueda funcionar con determinadas personas del equipo situadas en localizaciones fuera de la zona en la que se está desarrollando el trabajo, siempre y cuando se pongan los medios y la actitud necesaria para que el equipo siga siendo un equipo y la comunicación sea fluida.

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: