L09 Memorandum Cero Defectos

Lectura # 9

Pág ina |1

Memorando de Microsoft: “Código de cero defectos”i Un memorando clave, fechado en 1989, motivó a los grupos de producto a tomar acciones correctivas. El memorando, titulado “Código de cero defectos” y escrito por Chris Mason, un gerente de desarrollo del grupo de Word, reflejaba el estado de los asuntos y el nuevo proceso que Microsoft habría de adoptar.

¿Cómo nació el Memorando de Microsoft: “Código de cero defectos”? En 1984 Microsoft decidió separar el pilotaje del desarrollo, luego de que las fallas en diferentes productos, ocasionaron quejas de fabricantes de hardware que empaquetaban sistemas operativos de Microsoft con sus PCS. Por ejemplo, la versión de BASIC que Microsoft envió al mercado con la PC de IBM, en 1981, daba una respuesta incorrecta cuando el usuario dividía .1 y otros números entre 10. Luego de este incidente, IBM insistió en que Microsoft mejorara sus procesos de desarrollo de software y control de calidad. Microsoft también tuvo otros problemas que no se hicieron públicos a principios de los ochenta, como una falla en el producto FORTRAN (un lenguaje técnico de programación), que echaba a perder información. Los clientes individuales también comenzaron a quejarse, acerca de problemas de calidad de los productos de aplicaciones Microsoft, que compraban en tiendas minoristas. Los gerentes por fin aceptaron la necesidad de introducir mejores prácticas de pilotaje interno y control de calidad. Esta idea encontró cierta resistencia, ya que la mayoría de los programadores e incluso algunos gerentes de alto nivel (como Ballmer), insistían en que los diseñadores debían probar sus propios productos, a veces con ayuda de estudiantes de preparatoria, secretarias y algunos contratistas externos. Microsoft hizo un esfuerzo especial al contratar a la empresa de consultoría Arthur Andersen, para pilotear su nueva versión de la hoja de cálculo para la Macintosh, antes de enviarla al mercado en enero de 1984. Pero una compañía externa, por lo general, no puede pilotear de manera adecuada un producto complejo de software. Una grave falla que destruía información, obligó a Microsoft a enviar una actualización del Multiplan de Mac a cerca de veinte mil compradores, a un costo de $10 dólares cada una dio un total de $200,000. Los gerentes de Microsoft concluyeron que no podían cumplir con los estándares de calidad más altos, sin establecer un grupo de pilotaje independiente, según el rumbo marcado por IBM y otras compañías, con mayor antigüedad e historial exitoso en el desarrollo de software. Dave Moore, director de desarrollo de Microsoft, recuerda este reconocimiento: sabíamos que no era posible tener éxito si Desarrollo seguía haciendo sus propios pilotajes. Necesitábamos un grupo separado que construyera las pruebas, llevara a cabo el pilotaje y diera alguna retroalimentación a desarrollo. Ese fue un parteaguas. Microsoft no imitó las técnicas de IBM, como la de crear grandes grupos que revisaran todos los elementos del software desde documentos de especificaciones hasta códigos y planes de piloteo o requerir que los ejecutivos avalaran las diversas etapas del desarrollo. Estas prácticas burocráticas son comunes en la producción de software para macrocomputadoras y aplicaciones militares, pero todavía son raras en el mundo de las PC. Microsoft tampoco comenzó a monitorear en detalle la manera en que los diseñadores y los probadores utilizaban su tiempo, como lo hacían IBM y algunas otras compañías (incluidas las fabricas de software japonesas). En lugar de ello, el personal de Microsoft seleccionó las que les parecieron buenas técnicas, como el grupo de piloteo separado y las pruebas automatizadas, así como revisiones de código para nuevo personal o componentes cruciales. Luego, las promovieron no como prácticas IBM (Esa no era la manera de lograr que se utilizaran en Microsoft, observa Moore), sino como métodos que funcionaban.

Gerencia de Proyectos basado en la Guía del PMBOK - 4ta edición

Lectura # 9

Pág ina |2

Pero, agrega Moore, Lo hicimos mal. Luego de que Microsoft expandiera sus nuevos grupos de piloteo entre 1984 y 1986, los diseñadores se volvieron perezosos, al pensar que podían aventar el código por encima del muro para que alguien lo probara. Olvidaron que los diseñadores encuentran más de sus propias fallas que los probadores, y que en primer lugar sólo los diseñadores prevén que sucedan errores. Mientras tanto, Microsoft envió al mercado el siguiente gran desastre en los anales de la compañía: Word 3.0 para la Macintosh, entregado en febrero de 1987, luego de haber sido prometida en julio de 1986 y con cerca de setecientas fallas varias de las cuales destruían datos o hacían caer el programa. Microsoft tuvo que enviar una actualización gratuita a los clientes a dos meses del lanzamiento original, lo que le costó más de un millón de dólares. En este momento era evidente, aun para los escépticos dentro de la compañía, que Microsoft tenía enormes dificultades con el manejo del desarrollo de productos, y que los grupos tenían que ser más ordenados en la satisfacción de los clientes. El propio Gates se hizo cargo de la división de aplicaciones, pero varios proyectos claves siguieron en el caos. Ninguna de las nuevas aplicaciones para Windows, a no ser Excel, mejoraba. Un programa de base de datos (denominado proyecto Omega, que evolucionó en Access), y un proyecto de aplicación administrativa para Windows tenían serios problemas. El proyecto Opus, más tarde renombrado como Word para Windows, provocó que los miembros del equipo acuñaran la frase hoy famosa de defectos infinitos. Describe una situación donde los probadores encuentran fallas con mayor velocidad a la que los arreglan los diseñadores, y en la cual, cada remedio conduce a una nueva falla; bajo estas condiciones, se hace imposible predecir el cronograma y la eventual fecha de envío al mercado. A veces esto ocurría en Microsoft, cuando quienes trabajaban como internos en el verano escribían código y luego regresaban a la universidad sin probar su trabajo por completo, o cuando los diseñadores se desplazaban de una característica o proyecto a otro, y tampoco piloteaban en forma plena su trabajo. Durante los periodos de integración y pilotaje tardíos y prolongados que Microsoft solía intentar, los diseñadores tenían que regresar a viejos códigos, cuyos detalles habían olvidado en gran parte o sus autores habían desaparecido. Al reescribir la mayor parte del código para arreglar las innumerables fallas, los diseñadores tendían a agregar tantos nuevos errores, como los que reparaban. En lugar de dejar que más proyectos se salieran de control, Gates decidió ir fuera de la compañía en busca de mayor experiencia práctica administrativa. En julio de 1988 trajo a Mike Maples, quien había estado en IBM durante 23 años, donde encabezaba la estrategia de software y la evaluación de negocios. También era un figura central en el desarrollo de OS/2 y Presentation Manager, uno de los primeros productos de interfaz gráfica para las PC de IBM. En forma paradójica, el personal de Microsoft a menudo criticaba a IBM por contratar demasiados programadores que no tenían mucha habilidad en el diseño y por utilizar un proceso de desarrollo que era demasiado secuencial y dividido en categorías. Los gerentes de Microsoft, también creían que IBM requería miles de personas, para hacer lo que Microsoft podía lograr con sólo algunos cientos de diseñadores de alto vuelo. Pero el talento de Maples parecía único, y Gates quería ver más procesos establecidos, para asegurarse de que Microsoft construyera y entregase sus productos, así como controlar su calidad de manera más efectiva. Un memorando clave, fechado en 1989, que resumía discusiones del retiro de mayo (que fue organizado por Dave Moore), motivó a los grupos de producto a tomar acciones correctivas. El memorando, titulado código de cero defectos y escrito por Chris Manson, un gerente de desarrollo del grupo Word, reflejaba el estado de los asuntos y el nuevo proceso que Microsoft habría de adoptar.

Gerencia de Proyectos basado en la Guía del PMBOK - 4ta edición

Lectura # 9

Pág ina |3

Para: Diseñadores de aplicación y probadores De: Chris Mason Fecha: 6/20/89 Tema: Código de cero defectos CC: Mike Maples, Steve Ballmer, gerentes y jefes de departamento de la Unidad de Aplicaciones de Negocios El 12 y 13 de mayo, los gerentes de desarrollo de aplicaciones llevaron a cabo un retiro, junto con algunos de los jefes de proyecto, Mike Maples y otros representantes de Aplicaciones y Lenguajes. Mi grupo de discusión investigó lo relativo a técnicas para escribir código sin defectos. Este memorando describe las conclusiones a las que llegamos….Hay muchas razones por las que nuestros productos parecen tener cada vez más fallas. Es un hecho que cada vez son más complejos, pero nosotros no hemos cambiado nuestros métodos para responder a esa complejidad….El objeto de enumerar nuestros problemas es darnos cuenta que son nuestros métodos, y no nuestro personal, los que provocan el fracaso….Nuestros métodos de calendarización y la cultura de Microsoft promueven que se haga el mínimo trabajo necesario en un requerimiento. Cuando éste funciona lo suficiente bien para demostrarse, lo consideramos hecho, todo mundo lo considera hecho y el requerimiento se elimina de la lista de pendientes. Se considera que las inevitables fallas que aparecen, meses más tarde, no tienen relación con esto….Cuando la calendarización está en riesgo de no ser cumplida, comenzamos a recortar esquinas….La razón por la cual la complejidad provoca fallas es que nosotros no entendemos cómo trabajan las piezas en conjunto. Esto es válido tanto para productos nuevos como para cambios en productos existentes… Literalmente, quiero decir: nuestra meta debe ser tener todos los días un producto funcional, casi listo para ser enviado al mercado.…Ya que ni los seres humanos están libres de fallas, aún, no importa lo que ustedes hagan, habrá fallas en el código. Cuando esto suceda, deben evaluar el problema y resolverlo de inmediato… Codificar es a lo que nos dedicamos la mayor parte del tiempo. Escribir fallas significa que fracasamos en nuestra principal actividad. Cientos de miles de individuos y compañías confían en nuestros productos; las fallas pueden causar mucho tiempo y dinero perdido. Es posible que una compañía quiebre debido a una falla en una hoja de cálculo, base de datos o procesador de texto. Tenemos que comenzar a tomar esto en serio.

i

Tomado del libro “El Secreto de Microsoft” por Michael A.Cusumano y Richard W. Selby – Editorial Prentice Hall – 1996, pág 39-43.

Gerencia de Proyectos basado en la Guía del PMBOK - 4ta edición