El conocimiento del negocio de un programador

Cuando se desarrolla una aplicación de tamaño medio/grande se produce muchas veces la siguiente situación:

1. Se dividen las tareas entre los programadores
2. Se terminan las tareas. Parece que esta todo
3. Se empieza a probar y el jefe se da con un fallo muy claro.
4. ...

¿Como puede ser que ningun programador se haya dado cuenta? El jefe se da cuenta que la realidad es que los programadores no tienen un conocimiento del negocio para darse cuenta de ese fallo, pero como es posible? la mayoria de programadores suelen llevar tanto tiempo como el jefe en el proyecto. ¿Como es posible que no conozcan mas el negocio? La respuesta es que gran parte del trabajo del jefe consiste en aprende el negocio y como la aplicación da respuesta a las necesidades del negocio mientras que toda la jornada laboral de un programador consiste en programar. Un programador no puedes saber tanto de negocio, necesidades de cliente, etc.. como un jefe ya que NO GASTA UN TIEMPO SIGNIFICATIVO EN ELLO por lo que es lógico que no tenga ese conocimiento.

Ahora lo normal es pensar, pues deberia tenerlo. Esto hay que pensarlo bien porque para que lo tenga hay que dedicar tiempo (que no podrá usar en programar) y ademas alguien (un jefe) tendrá que perder su tiempo en explciarlo.

¿Que se puede hacer? Cada caso requerirá su propia solución. A veces merecerá la pena que programador tenga el conocimiento y otras que sea simplemente el que fabrica las piezas y son otros los que encajan esas piezas.

La percepción exterior

Durante el desarrollo de una aplicación y a la hora de hacer entregas hay un factor que nunca se tiene en cuenta pero que es muy importante: La percepción exterior que da la aplicación. Da igual que "el interior" (Core, lo que no se ve pero es realmente complicado) este perfecto si la percepción que da la aplicación al ejecutarla causa sensaciones negativas como:

• Va muy lenta
• Ciertas partes no funcionan
• Hay casos de prueba que funcionan y otros no
• Etc...

provocará rechazo por parte del usuario final. Por ejemplo, un equipo desarrolla una aplicación web para que los usuarios puedan  darse de alta en un censo de un pueblo. La aplicación es simple y compleja. Simple porque de cara al usuario es solo un formulario de 10 campos que se rellenan y se pulsa un botón de enviar. Compleja porque en core usa tecnologias que hacen mas facil la navegación, se conecta con un web services que verifica la firma, hace una validacion con 2 bases de datos, optimiza busquedas para validacion de .... y mas cosas. Todo esto último se ha conseguido pero el dia de probar en producción se produce el gran problema, el responsable del cliente dice que toda (no solo la interfaz) es un desastre porque hay un campo donde no se pueden poner mayusculas.

Si llevas tiempo en el desarrollo de software te sonará seguro:"Esta aplicación en una mierda porque no deja poner mayusculas en este campo" y el programador piensa: " pero si eso es una tonteria, lo del web services era lo complejo".

Como evitar esto? Es una tonteria o es algo que puede hacer fracasar un proyecto?

En estos casos, todo el mundo tiene razon y todo el mundo esta equivocado.

• La interfaz al usuario hay que probarla hasta mas no poder. Es importante eliminar cualquier fallo en el que el usuario pueda decir:"esto es de sentido común".
• Si el principal objetivo de un programador es la interfaz entonces  las partes mas complicadas no estarán implementadas y si que la aplicación no valdrá para nada.

La mejor opción es poner una capa intermedia entre el desarrollo y el cliente:

• Un departamento de pruebas.
• Comerciales que deduzcan de forma lo mas exacta posible que es lo que quiere el cliente.
• Etc...

En cualquier caso, suponer que es lo "de sentido común" (o básico) para el cliente es un error. Los clientes suelen saber lo que quieren durante la marcha. Cuando ven algo sabe si les gusta o no. Lo mejor es planificar el desarrollo para que los cambios en la interfaz te afecten lo menos posible.