14. Calidad

Y el reloj avanza sin parar y ya es hora de entregar esa nueva versión del nuevo producto, el programa todavía no se encuentra listo, los minutos corren, los equipos de trabajo se encuentran produciendo líneas de código bajo presión, se empiezan a eliminar características deseables o no esenciales, se hace la entrega y resulta que los programadores tienen mucha ceguera de taller y hay más errores de los que esperábamos, los flujos que se probaron y se diseñaron son muy estrictos, tan así que el menor cambio hace que la aplicación falle.

La entrega al cliente es mala o se retrasa, se genera insatisfacción y además el esfuerzo extra de las últimas horas quemo a el equipo de trabajo, la cantidad de errores excesivos, hace que muchos pierdan la paciencia.

Y acabamos de perder un proyecto que pudo haber sido el proyecto mejor planeado.

Dentro de este mundo del código salvaje quiero platicar un mal habito que tenemos casi todos los programadores, una frase muy común llamada “trabajo mejor bajo presión”, que no es más que la justificación de “Se acabó el tiempo y tengo que codificar muy rápido”.

¿Realmente se acabó el tiempo?

Cuando nos encontramos del lado de la programación tenemos la tendencia a perdernos en un mar de líneas de código pensando en flujos y pensando que el tiempo siempre alcanza. Perdiendo muchas veces día a día productividad desviándonos en actividades fuera del producto original, al final ese esfuerzo extra tan común en el final de un proyecto se puede dar sin pensarlo.

¿Pero qué tan conveniente es? La respuesta es nada, no es conveniente, como humanos al estar cansados nuestra mente no reacciona igual comete más errores.

Es importante que todo el equipo sepa cómo se encuentra el estado de un proyecto, para poder hacer correcciones a tiempo, las correcciones no es trabajar más, la corrección es como encontrar la manera de dedicar el tiempo adecuado a cada actividad.

Un proyecto que se encuentre con errores tiene un costo mucho mayor a una entrega fuera de tiempo, ya que genera una mayor insatisfacción, puede ser hasta peligroso porque un flujo no probado puede causar que un sistema pierda información valiosa.

Nosotros somos los guardianes de la información, eso es para nosotros lo más importante, si la información se daña, perdemos realmente el fin por el que estamos aquí.

La imagen de la empresa, la imagen de nosotros mismos, se daña más con un producto de mala calidad, que con un producto en el que se habló a tiempo el estado del mismo y se aplicaron las medidas para que el producto sea satisfactorio para el cliente.

Terminar un proyecto no es entregar un código.

Terminar un proyecto es que el usuario se sienta bien con el programa, que lo sienta una extensión de él, y que cumpla una de las características más importantes por las que estamos aquí, simplificar las cosas hacer que el sistema sea tan sencillo que realmente permita al usuario dedicar su tiempo en otras actividades.

Un sistema debe ser de tal forma que un usuario debe saber que existe, usarlo pero sin que esto represente que se convierta en un dolor de cabeza.

Las nuevas generaciones no leen manuales, eso lo tenemos que tener en cuenta, por eso cada flujo debe ser confiable, fácil de entender y agradable en su hacer.

Saludos