MUDA.-Despilfarro en el Desarrollo de Software

Published 15/9/2009 17:53 | Eduardo Obregón Gutierrez

La velocidad que en este momento tienen los negocios afecta directamente al desarrollo de software, porque lo que hoy es un buen negocio, en 5 meses puede dejar de serlo, por tanto cuando se solicita un desarrollo  es vital la velocidad con la que podamos responder.

Estamos viviendo un contexto, en el cual,  si prolongamos mucho el tiempo de desarrollo, es posible que cuando acabemos no haya negocio donde aplicarlo.

En esta batalla por la velocidad, pensando sobre lo que nos hace ir más lentos y por qué no decirlo,  hacernos más caros, nos damos cuenta que muchas veces gastamos recursos en cosas que el cliente no está dispuesto a pagar,  porque realmente no aporta ningún valor al producto.  Esto, dentro de lean manufacturing se denomina “Muda” (es la palabra que utilizan los japoneses para referirse al despilfarro, creo que en inglés es “waste”).

Se considera que son 7+1 los tipos de despilfarros que podemos identificar y evitar para poder ser más productivos y por lo tanto poder sobrevivir.

Os voy a poner ejemplos de cada tipo:

Sobreproducción: nos ponemos a desarrollar y añadimos funcionalidades que no son necesarias,  o no lo son en ese momento, o las hacemos cómo nosotros creemos que pueden valer.

Esperas: debemos eliminar todo tiempo que nos mantenga parados en la actividad¿oye fulanito cómo va lo de ruptura  de riesgo? Espera menganito acabo esto y lo miramos” (tiempo ocioso de menganito).

Otro ejemplo son las actualizaciones de herramientas, por ejemplo nosotros perdemos unos 40 minutos cada vez que actualizamos versión del DevExpress.

En inventario: ¿cuántos controles, formularios, funciones, etc. tenemos en nuestra solución que no utilizamos? Y en la BBDD, ¿cuántos procedimientos almacenados, funciones o vistas, ya no se usan? No podemos perder recursos en hacer cosas que no tengan una utilidad inmediata. Existen herramientas para hacer estas comprobaciones y debemos utilizarlas.

Sobreprocesamiento o procesamiento extra: complicar más las cosas de lo necesario, procesos que podrían ser más sencillos, los dejamos con más pasos de los que se necesitan.

De Corrección: nos ponemos a desarrollar y metemos en el código partes que se van a quitar,  o que requiere ser corregida, mil veces funciona y decimos “bueno, esto ya lo pondré  mejor luego”.

Transporte innecesario; por ejemplo en el envío de material y la devolución del feedback muchas veces no se ha planificado bien y supone un gasto importante.

Movimientos innecesarios; podríamos considerarlo al movimiento de personal, muchas veces es habla con fulanito y menganito, os reunís los tres 45 minutos mucha información y luego te enteras que ese modulo tiene que ser acorde a las instrucciones de un tercero porque ese proceso se quiere cambiar.

 

Capacidades de los empleados. En mi opinión es una de las más dolorosas, cuando tenemos a un trabajador desarrollando labores que requieren menos capacitación y se los deja en esas labores sin darlos la oportunidad de desarrollarse más y poder aportar más a la empresa.

En nuestra empresa, un chico que estaba en Desarrollo terminó siendo responsable en otro ámbito, gracias a que su jefe se dio cuenta de que podía aportar más.

Ahora reflexionemos un poco sobre el por qué de tanto despilfarro, algo que nos pesa como una losa a la hora de ser productivos, según Bill Curtis el principal problema es el RETRABAJO  y en mi opinión tiene toda la razón. ¿Cuántos módulos pasan por mil manos, se retocan y se vuelven a retocar. ¿Y todo esto dónde se reporta? ¿Recabamos suficiente información sobre los recursos que nos consume el retrabajar?¿Tenemos mediciones de todo esto?

En todas las profesiones, no sólo en la nuestra, da mucho miedo reportar a los superiores el tiempo del retrabajo y en cualquier parte de la pirámide jerárquica. Al desarrollador no le interesa que el jefe de proyecto sepa ese tiempo, pero al jefe de proyecto tampoco le interesa que lo sepa el gerente. ¿Y todo esto por qué? Porque nos afecta a la velocidad y al coste.

Conclusiones hasta aquí:

El retrabajoà Falta de transparenciaàDesconfianza de los superioresàDesmotivación del grupoàBaja el rendimiento.

Pero el retrabajo surge por algo, y si es él, el que en mi opinión genera la mayor parte del despilfarro, la pregunta es: ¿Qué provoca el tener que retrabajar?

Aquí ya puede que haya más controversia. Para mí está claro, lo esencial es que seguimos sin dedicarle tiempo al análisis y a pensar antes de hacer nada; no se debería meter ni una línea de código sin que haya unas instrucciones claras, precisas y en donde se hayan analizado todas las características.

Es mucho más caro hacer código que conlleve despilfarro,  que tardar más tiempo en pensar y analizar bien la situación.

Pensar es el trabajo más difícil que existe. Quizá esa sea la razón por la que haya tan pocas personas que lo practiquen.

Henry Ford (1863-1947) Industrial estadounidense.

 

¿Y sabéis por qué no dedicamos tiempo a pensar? Porque tenemos mucha prisa en acabar, porque hay mucha presión desde arriba y eso nos tiene que dejar de afectar, tenemos que ser fieles a una idea e ir con ella hasta el final. El hacer un software de alta calidad es el único camino en el mundo del desarrollo y eso lleva un tiempo y un coste determinado y tratar de disminuirlo con  presión es aumentarlo (Tercera ley de Newton o Ley de Acción y Reacción).

Habrá un segunda parte donde hablaremos en cómo gestionar la Muda.

Archivado en:
Comparte este post:

Comentarios

# Jesús Bosch said on September 15, 2009 9:25 PM:

pues menuda inversión más arriegada esto del software... supongo que por eso en este país solo se ponen ladrillos xD

# Juan Irigoyen said on September 15, 2009 9:34 PM:

Excelente post, me ha encantado...

Pd. Se que te voy a poner en un aprieto pero haya voy, no estaria mal que contases en un futuro post como las metodologías ágiles, en este caso Scrum, te pueden ayudar a resolver estos problemas, aunque como tu y yo sabemos, no la utilizemos tan bien como deberiamos...

Un saludo.

# el_mago8 said on September 15, 2009 11:19 PM:

Desconozco el mundo del software, pero desde luego, a nivel productivo erradicar estas mudas, dejar de producir por producir y establecer planes sostenibles que en ocasiones signifiquen "estar de brazos cruzados" son en muchos casos impensables por ciertas personas. La disciplina en el cambio y el "pensar en sencillo" son sin duda las dos claves para eliminar la muda.

# Eduardo Obregón Gutierrez said on September 16, 2009 6:21 PM:

Muchas gracias por vuestros comentarios, Juan recojo el guante scrum vs muda (proximamente).

el_mago8, está claro que son cambios de conceptos que, por lo que yo veo, ya hay personas que no van a cambiar y lo triste es que sus empresas tampoco.