Método y Grupo deben converger

Sergio Scariolo era un gran entrenador antes de dirigir a la selección española. Cuando  llegó, intentó imponer su método de jugar a posesiones largas, método que le ha dado bastantes triunfos en otros equipos, sin embargo,  la selección, con un conjunto de grandes jugadores,  no ha funcionado con este método. Perdió contra Serbia y contra Turquía, y el seleccionador se dio cuenta que su método no producía un buen resultado aplicado a este grupo y tomó una decisión que muy pocas veces vamos a poder ver en el desarrollo de un proyecto: que el responsable coja su método que tantas veces ha funcionado y decida que ese método, en este grupo no vale.

                ¿Por qué este hecho es tan singular? En la tertulia deportiva que escuchaba cuando se me ocurrió este artículo, hablaban de vanidad y es posible que sea eso, tenemos que reconocer que tener éxito en un proyecto de desarrollo es muy complejo y hay que reconocer el mérito de quien lo ha conseguido. Pero tanto en los éxitos como en los fracasos hay que aprender a separar unos proyectos de otros, y pensar que no existe una solución global.

                Tenemos que aprender a acercar el método al grupo y el grupo al método, muchas veces hablas con  gente que está intentando implantar un método de trabajo nuevo y siempre te dicen lo mismo:”mientras sigan fulanito y menganito es imposible” entonces es cuando nos deberíamos plantear: ¿podemos prescindir de las personas que imposibilitan el desarrollo del método? muy pocas veces vamos a poder tomar una decisión tan drástica, por lo que es posible que debamos ver si el método se puede acercar a los trabajadores sin que pierda su esencia, y si la pierde es que el método simplemente no va a funcionar en ese grupo.

                En mi opinión, el problema son las personas enrocadas en una posición. Estas personas pueden ser jefes de proyectos emperrados en trabajar siempre con una metodología que les ha dado buen resultado en el pasado, o que siguiendo modas, se empeñan en implantarla, bien o mal. En el otro lado, existen trabajadores generalmente desmotivados y que no se encuentran nada involucrados en la empresa, por lo motivos que sean (generalmente económicos y funcionales) que también llevan años trabajando de una manera y no van a cambiar, pero no quieren cambiar porque el cambio les supone un esfuerzo extra que no están dispuestos a dar. Esta mezcla explosiva es la causante de muchos fracasos.

                ¿Qué deberíamos hacer?:

                Conoce tu grupo

Lo  primero es conocer a vuestro grupo, ¿podrías hacer ahora mismo una lista con el nombre de los trabajadores de vuestro grupo con sus puntos fuertes y sus debilidades? Porque para conocer a vuestro grupo, debéis conocer de qué pueden ser capaces y de qué no. Scariolo pensaba que conocía perfectamente a Gasol y compañía, pero realmente no sabía que no eran capaces de jugar a posesiones largas y eso es lo que les pasa a muchos jefes.

Moléstate en hablar con ellos, en conocer cómo se encuentran, que opinan, que visión tienen del método actual y del negocio en general, de sus habilidades y sus dificultades.

 

Si la vida te da limones, haz limonada

Todos somos buenos y malos en algo, pon a hacer a la gente cosas en las que pueden ser buenos. Puede que tengas personas muy trabajadoras pero nada brillantes, o personas muy brillantes pero nada trabajadoras.

Las tareas del método deben estar totalmente orientadas a las personas responsables de desarrollarlas. No podemos obviar este criterio a la hora de asignar las tareas y debemos asumir que no todos pueden hacer todo.

Todos nos sentimos mejor y estamos más contentos cuando hacemos bien nuestro trabajo.

Selecciona bien tu método

Ten claro el por qué vas a adoptar un método, que te va a aportar. ¿Tienes infraestructura humana para desarrollarlo?, el método puede ser buenísimo y dar unos resultados extraordinarios en empresas japonesas y americanas, pero, ¿tú puedes hacerlo funcionar en tu compañía? ¿Tu grupo actual va a poder funcionar con él?¿tú vas a cumplirlo? (recordad que Scariolo había alcanzado anteriormente muchos títulos con su método-http://es.wikipedia.org/wiki/Sergio_Scariolo-)

Da ejemplo

Durante la implantación del nuevo método tienes que dar ejemplo, porque en cualquier ocasión en la que seas observado sin cumplir alguna de las normas del método, va a suponer un motivo para que los miembros de tu grupo no lo cumplan y en sus reuniones se comente frases míticas como:”pero si en esto no cree ni él”, “eso no lo hagas,  que él no lo hace”, esto es fundamental porque si el responsable pierde credibilidad, el proyecto está avocado al fracaso.

Haz seguimiento

De nada valen las reuniones, las directrices, la formación, etc si luego el responsable o los responsables no se aseguran que se está cumpliendo el método, la tarea no acaba cuando ya se empieza a trabajar con un nuevo método. Es fundamental asegurarnos de que su uso tiene continuidad y realmente no se queda en una aceptación de buenas intenciones.

Hay que seguir vendiéndolo después de vendido

                No podemos pensar que porque ya se funcione con el método, ya está todo hecho, la gente debe de CREER en lo que está haciendo, e ir enseñando las beneficios que se vayan produciendo, haciéndoselos ver a los propios miembros del grupo.

El programa de radio donde escuche los datos del baloncesto se llama La Hora de Walter.

MUDA.-Despilfarro en el Desarrollo de Software

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.