Dificultades de las empresas de TI para alcanzar la excelencia

LIB: Mary, ¿podría presentarse a nuestros lectores?

Mary: Comencé mi carrera como programadora. Trabajé durante 20 años en la Universidad de Wisconsin con equipos de control de procesos. Después, me convertí en gerente de TI en el área de fabricación de cintas de video, donde participé en la transformación del sistema de manufactura clásico al just-in-time. Decidimos adoptar un sistema pull, inventado por nosotros mismos en esa época, para mantener nuestra competitividad frente al mercado japonés. Con el tiempo, dejé 3M y decidí mirar el mercado. Decidí participar en un proyecto de software del gobierno llamado “Waterfall”, que fue un desastre. Entonces, alrededor de 2001 o 2002, comencé a estudiar el lean en el área de desarrollo de software, Tom se unió a mí y escribimos nuestro primer libro, “Lean Software Development”. La idea del libro era describir por qué la idea del proyecto no había sido muy buena y cómo el lean se aplica al área de desarrollo de software. Desde entonces, hemos escrito tres libros más.

LIB: ¿Qué beneficios han aportado los principios y las técnicas lean al área de ingeniería de software?

Mary: En cualquier área donde se desarrolla algo nuevo, el lean no se aplica como en la manufactura; sin embargo, es necesario aprender. Así, en el desarrollo de productos en general, y particularmente en el desarrollo de software, tengo que proponer alguna solución para un problema y, como ingeniera de software, tengo que pensar cuál es el problema que necesitamos resolver. Y si usted observa la forma en que el lean se aplicó en el desarrollo de software, que comenzó apenas a finales de la década de los 90, fue un poco diferente de la producción: tiene que ver con ir despacio, con postergar las decisiones hasta tener la mayor cantidad de información posible, tiene que ver con trabajar en lotes pequeños y, básicamente, tiene que ver con flujos de información en oposición a procesos de desarrollo. Y necesitamos hacer que esos flujos de información sean lo más fluidos y rápidos posible e innovar constantemente. Y también es necesario garantizar que construyamos algo con calidad. Hay una costumbre en el desarrollo, que creamos hace algún tiempo, que dice: “vamos a construir nuestro sistema y, después, vamos a reservar el 30 o 40% del proceso de desarrollo para probarlo”. Esto es completamente contrario al concepto de desarrollo lean de software, que dice: “vamos a construir el software y probarlo en todo momento”. Este tipo de principios son los que funcionan bien en el desarrollo de software.

LIB: En su opinión, ¿cómo debería un departamento u organización de TI comenzar a aplicar el pensamiento lean?

Mary: Prefiero hablar de una organización de TI en lugar de un departamento de TI. Y es por una buena razón: cuando yo era ingeniera y hacía sistemas de control de procesos, no formaba parte de un departamento de TI. De hecho, nunca he trabajado en un departamento de TI. Y siempre me desconciertan los departamentos de TI; quiero decir, no me desconcierta la ingeniería de software en general, sino el hecho de que el departamento de TI tenga pésimos resultados. Considere la idea del desarrollo tecnológico. Todo mejoró cuando los ejecutivos y gerentes sénior comenzaron a entender la tecnología. No se encuentran empresas así hasta finales de la década de los 90. Una empresa que debemos citar es Amazon. El departamento de TI de Amazon es revolucionario. Algo que realmente necesita saber sobre el lean es que se trata de entender el problema del cliente, y eso no es exactamente lo que hace un departamento de TI: piensa en sus colegas, que también son clientes, pero no los clientes del negocio. Lo que se necesita es entender el problema del negocio, del cliente del negocio, en lugar de pensar en sus colegas de la organización como sus clientes.

Tom: Algo que sucede en un departamento de TI es que las personas deben hacer lo que se les ordena, y ese no es un papel muy emocionante. La tendencia emergente es que las personas con competencia en áreas técnicas pasen a formar parte de algo que se llama la “clave de todas las estadísticas”, que es responsable de toda la experiencia del cliente, de todo lo que el producto ofrece al cliente final; esto incluye a personas que entienden el mercado, la tecnología, la entrega, el marketing de ventas, esos elementos. Si todos trabajan juntos para aportar valor al cliente externo –y la empresa se queda con una parte de eso–, ese es el paradigma que hoy domina en lo que llamamos TI.

Mary: Hay algunos CIO que entienden esto, y están llevando a sus empresas por el camino correcto para mejorar el negocio en sí y la experiencia del cliente.

LIB: ¿Cuáles son las dificultades que se encuentran cuando aplicamos el lean en el área de TI?

Mary: Hablemos de desarrollo de productos en lugar de TI, porque pienso en esa empresa que tiene capacidad técnica, que puede o no llamarse departamento de TI. Si usted quiere aplicar los principios lean, hay muchos aspectos del lean que son contraintuitivos. Pensábamos que, para tener una calidad alta, teníamos que ser muy lentos y deliberativos, para darnos tiempo de descubrir cuáles eran los defectos de nuestro software al final del proceso. Si usted quiere aplicar el pensamiento lean en el desarrollo de software, se dará cuenta de que hay algo equivocado en ese concepto. ¿Por qué buscamos los defectos solo al final del proceso, en lugar de buscarlos a medida que desarrollamos el software? Lo cierto sobre el lean, al menos en lo que se refiere a la ingeniería de software, es que necesitamos automatizar todo desde el principio para poder probar el software a medida que lo desarrollamos. Lo segundo que es contraintuitivo es postergar las decisiones lo máximo posible. Necesitamos crear software que sea modificable y que permita las pruebas inmediatamente después de los cambios. Así, no necesitábamos saberlo todo desde el principio, sino que postergábamos las decisiones lo máximo posible. Estos conceptos de facilidad para el cambio, de hacer experimentos en lugar de escribir requisitos y de descubrir lo que es útil a medida que el proceso evoluciona en lugar de saberlo todo desde el inicio son difíciles para personas que han pasado toda su carrera en procesos diferentes.

LIB: Hablando de su presentación en el Lean IT Summit, ¿puede contarnos de qué hablará?

Mary: Creemos que será sobre la diferencia entre la eficiencia del flujo y la eficiencia de los recursos. Hay un libro llamado “This is Lean”, que es uno de los más vendidos en Suecia. No es un libro sobre software, sino sobre el negocio. Explica que lo que se hace tiene que ser para garantizar la eficiencia: la eficiencia no se define asegurándose de que todos estén ocupados; todas esas personas con tanto trabajo por hacer no es eficiencia. Si usted observa el lean, tiene una noción muy clara de lo que es el flujo. El lean entiende que los lotes grandes crean mucha variación. Usemos una carretera como analogía: si usted llena una carretera de automóviles, ¿qué sucede? El tráfico se detiene. Entonces, este concepto de crear una congestión al mantener a todos ocupados es algo que los gerentes parecen no entender; dicen: “vamos a llenar a todos de trabajo; de esa forma, aprovecharemos mejor nuestros recursos”. Si usted sobrecarga a las personas con cosas por hacer, la consecuencia es el estrés, el cambio de una actividad a otra; es mucho mejor tener la cantidad adecuada de cosas por hacer en el momento adecuado. En el desarrollo de software –o en cualquier otro proceso–, si usted observa la unidad lenta y maximiza la velocidad a la que avanza por el flujo, eso es mucho mejor que mantener a todos ocupados. Piense en un hospital: ¿queremos garantizar que todos los médicos, todos los equipos de rayos X, todos los equipos costosos estén siempre ocupados mientras los pacientes esperan, o queremos tomar a un paciente de emergencias y moverlo por el sistema lo más rápido posible? En el lean, se ve al paciente como la unidad de flujo; en el otro paradigma, se ve al médico, que tiene que estar siempre ocupado. En el lean, decimos: “tendremos el mejor flujo, el mejor uso de todos nuestros recursos si no tenemos constantemente largas filas y lotes grandes, si logramos mover al paciente por el sistema lo más rápido posible”. Usted debe mirar el problema del paciente y resolverlo lo más rápido posible, en lugar de asegurarse de que todos estén ocupados. Debe mirar la unidad de flujo, el problema del cliente. Y, cuando lo hace, obtiene una mayor calidad y mejores soluciones.

Tom: El concepto de flujo está justo en el centro del pensamiento lean. Ha habido una convergencia interesante recientemente, en los últimos años, entre el pensamiento lean y el design thinking. Los diseñadores no hablan de flujo, hablan de fricción, que es un antiflujo. Creo que una muy buena alternativa para hablar de flujo es identificar las fuentes de fricción. El objetivo del diseñador, al diseñar un nuevo producto, es identificar dónde está la fricción. ¿Cuál es el problema que enfrenta el cliente? ¿Dónde se desperdicia tiempo? ¿Dónde se desperdician recursos? Encontrar soluciones potenciales para estos problemas es mucho más probable con el pensamiento lean que, por ejemplo, creando una hipótesis y probándola. Esa es la dirección hacia la que se encamina la TI. Si usted va hoy en día a conferencias sobre tecnología, notará que están muy estandarizadas en cuanto a procesos, prácticas y herramientas. El mercado del software está pasando de grandes modelos a algo como un sistema que permite que un pequeño grupo de personas preste un servicio muy rápidamente; tienen que encontrar interfaces cuidadosamente.