HARVARD BUSINESS SCHOOL
El Proyecto PEARL: Patrones de Trabajo en Ditto (A) Eran las cinco y media de la tarde. El gerente de desarrollo de software del equipo de desarrollo del producto PEARL en Ditto, Inc., Zeth Daniels, acababa de repasar las tareas pendientes con su equipo de ingenieros de software. Al final del día, le gustaba asegurarse de lo que había hecho el equipo ese día para no tener sorpresas en la reunión de la mañana siguiente. El equipo de desarrollo del producto PEARL se reunía todos los días a las ocho y media de la mañana en la “Reunión del Amanecer’” para informarse mutuamente sobre el avance del proyecto y los problemas que enfrentaba cada área. El gerente de producto, Milton Smith, quería asegurarse de que el equipo se esforzara al máximo para lanzar el producto a tiempo. Zeth se preocupaba mucho de que su grupo de ingenieros de software no fuera responsable de retraso alguno en el cronograma del producto. El producto PEARL era crucial para la división y en última instancia, para la compañía. La alta gerencia monitoreaba de cerca el proyecto. Zeth sabía que el éxito del software de PEARL le daría exposición a él y a su equipo frente al CEO de Ditto. Se trataba de su oportunidad para destacarse como gerente. De la misma manera, también era consciente de que, si su grupo no entregaba el software a tiempo, toda la compañía lo sabría – y recordaría. Zeth deseaba ocupar la vicepresidencia de la división y el éxito del proyecto PEARL constituiría un paso importante para alcanzar ese cargo.
El caso de LACC número 406-S07 es la versión en español del caso HBS número 9-404-055. Los casos de HBS se desarrollan únicamente para su discusión en clase. No es el objetivo de los casos servir de avales, fuentes de datos primarios, o ejemplos de una administración buena o deficiente. Copyright 2005 President and Fellows of Harvard College. No se permitirá la reproducción, almacenaje, uso en plantilla de cálculo o transmisión en forma alguna: electrónica, mecánica, fotocopiado, grabación u otro procedimiento, sin permiso de Harvard Business School.
El Proyecto PEARL Ditto, Inc., fabricante de impresoras de alto volumen y otros periféricos de computadoras, tales como scanners, cámaras y proyectores digitales, contaba con una dotación de 100.000 empleados en todo el mundo. Históricamente la fortaleza de Ditto radicaba en sus sofisticados periféricos para redes, en especial impresoras láser de alto volumen. OPAL, su primera impresora de alto volumen, había sido la impresora láser monocromática de alto volumen de mayor venta de la historia. Luego, Ditto ingresó en el mercado de imágenes de color a través del lanzamiento exitoso de SAPPHIRE, producto que consolidó el liderazgo de Ditto en el mercado de impresoras color de mayor precio y sofisticación. Sin embargo, su éxito inicial para conseguir una amplia base de clientes en el área de las artes gráficas y la impresión comercial (talleres de impresión) le había impedido ver las oportunidades que se presentaban en el creciente mercado de periféricos para pequeñas empresas y oficinas residenciales (SOHO, por sus siglas en inglés). En la actualidad, Ditto intentaba reposicionar sus líneas de productos para ingresar en este mercado de periféricos menos sofisticados. La reorganización corporativa desarrollada dos años antes había agrupado todos los productos de imágenes a color de Ditto, incluyendo tanto impresoras como scanners, en la División Color, una de las seis divisiones de la nueva infraestructura corporativa. El producto más reciente de la División Color era RUBY, una impresora láser de alto volumen, que había llegado muy tarde al mercado debido a que su proceso de desarrollo se había retrasado demasiado. Por esta razón, la división perdía dinero. PEARL sería el siguiente producto de importancia de la división color. Representaría el primer periférico multifunción (MFP, por sus siglas en inglés) de Ditto, ya que incorporaría un scanner y una impresora láser a color. Los periféricos multifunción, que constituían una de las principales áreas de crecimiento de los productos de imágenes, incluían por lo menos dos de las siguientes herramienta fotocopiadora, fax, impresora y scanner. Mientras el mercado de periféricos multifuncionales de bajo precio crecía y se reducía el mercado de periféricos monofuncionales de alto precio, la gerencia de Ditto esperaba que el producto PEARL no sólo resultara rentable sino que sirviera para posicionar la compañía en este nuevo mercado. Habían planes para continuar el proceso iniciado por PEARL con una familia completa de productos. Los gerentes de la división y de la compañía creían que el futuro de la División Color dependía del éxito de PEARL en el mercado. Como señaló uno de ellos, “Si no lo logran, se derrumbará toda la división:”
De todas maneras, PEARL ya iba a ingresar tarde el mercado de periféricos multifuncionales, pues dos compañías competidoras ya habían lanzado productos similares. De hecho, se esperaba que saliera una nueva versión de uno de ellos al tiempo que se producía el lanzamiento de PEARL En Ditto tenían la sensación de ir detrás en la “carrera”. La presión que pesaba sobre el equipo de desarrollo de PEARL era aún mayor debido a la novedad de la tecnología involucrada en la creación de PEARL. Esta tecnología difería completamente de la que manejaban usualmente los ingenieros de software. Además, la mayoría de los ingenieros de software carecían de muchas de las habilidades necesarias para realizar su trabajo. Las limitaciones de tiempo y presupuesto les habían impedido adquirir la capacitación inicial necesaria, por lo que se veían obligados a aprender a medida que avanzaban en el proyecto. A diario, se enfrentaban a una escarpada curva de aprendizaje que reducía su productividad. Estas presiones se sumaban a la preocupación general de la compañía por completar sus proyectos dentro de los plazos preestablecidos -preocupación que había llevado, incluso, al presidente de Ditto a convocar a un investigador para que analizara los patrones de trabajo existentes.
El Grupo de Desarrollo de Software El equipo del producto PEARL estaba formado por 46 personas y era dirigido por Milton Smith y sus ocho colaboradores directos. (Ver el organigrama del equipo del proyecto que se presenta en el Anexo 1) Zeth conducía el equipo de ingenieros de desarrollo de software que trabajaba en el producto PEARL. Contaba con tres líderes de equipo, 12 ingenieros y un colaborador independiente. (Ver el organigrama del equipo de desarrollo de software que se presenta en el Anexo 2) El equipo de Zeth representaba más de un tercio de la dotación total del equipo de producto porque el desarrollo de muchos de los componentes del producto estaba a cargo de proveedores externos para acelerar el proceso. El equipo de Zeth contaba con amplia formación y experiencia. Sus miembros tenían una antigüedad promedio en la compañía de siete años. Ninguno de ellos llevaba menos de tres años y medio en Ditto, y todos tenían una vasta experiencia en el desarrollo de software. Todos los integrantes del equipo contaban con licenciaturas en ciencias o ingeniería. La mitad tenía títulos de
master en informática o en áreas afines, y cuatro de ellos estaban actualmente completando sus postgrados fuera del horario de trabajo. La mayoría se había graduado en universidades locales (ver los datos demográficos del grupo de desarrollo de software que se representa en el Anexo 3). Al principio del proyecto, Zeth le había explicado a cada uno de los tres líderes de proyecto las responsabilidades de sus correspondientes equipos, A su vez, cada uno de los líderes de proyecto le habían entregado una lista de entregas (funciones que debían ser codificadas) a sus ingenieros, junto con las fechas en las estas entregas debían estar terminadas. Los 12 ingenieros de software tenían libertad para organizar su agenda de trabajo, siempre que cumplieran con las entregas y fechas correspondientes. También podían abordar sus entregas de la manera que consideraran más efectiva. De hecho, los ingenieros se identificaban con sus entregas. Uno de ellos explicó: Cuando la gerencia lanzó RUBY, había un error en mi código. De todas maneras, tomaron la decisión de lanzarlo. Para ellos, no valía la pena perder tiempo en resolver el problema. Por mi parte, tendré que vivir con esa mancha en mi reputación. Siempre se me identificará con el defecto de ese producto. Desde entonces, trato de no entregar mi código sin antes asegurarme de que no contiene ningún error, aunque retrase el proyecto.
Demostrando Compromiso Los ingenieros sentían que era crucial mostrarse comprometido con las entregas asignadas a cada uno en las fechas claves de presentación del software1. Cuando le preguntaron por qué se encontraba en oficina a pesar de estar evidentemente enferma, una ingeniera respondió: “Se trata de una importante fecha de entrega y, aunque estoy plenamente consciente de que el equipo no va a estar listo y yo no voy a alcanzar a terminar, vine para dejar claro que me tomo en serio esta fecha.” La demostración del compromiso personal solía implicar dejar de lado planes de fines de semana y vacaciones. Como explicó un ingeniero, “Uno siente que es un flojo si le dice a la gente que no va a trabajar el sábado o que no quiere quedarse trabajando hasta la noche. Se trata de algo que, sencillamente, no se puede hacer. Uno siempre lo piensa dos veces antes de La fecha de presentación marcaba la fecha en que los ingenieros debían entregar ciertas tareas completas (líneas de código), compiladas en un disco, a un grupo de pruebas y a otros grupos designados en el equipo de producto. Los grupos designados para recibir las tareas dependían de distintas fases del proyecto. 1
decir algo así acá.” Otro ingeniero explicó: “Uno sólo puede negarse algunas veces. Hay que tener mucho cuidado para decir que no y, cuando uno lo hace, tiene que ser por una buena razón.” El sólo hecho de plantear una preferencia de horario para una reunión podía resultar incómodo. Cuando Zeth mencionó que el grupo de software se reuniría con el gerente de producto un sábado, asumió que todo el equipo asistiría a la reunión. Se limitó a preguntar si el grupo prefería en la mañana o en la tarde. Un ingeniero respondió que prefería que la reunión tuviera lugar por la tarde. Zeth bromeó: “Cierto, tienes que cuidar al bebé durante la mañana.” El ingeniero se mostró visiblemente incómodo. “Así es”, contestó, pero, de inmediato, agregó: “pero no se preocupen; puedo contratar una niñera.” Zeth sugirió que el grupo de software fuera el primero en reunirse con el gerente de producto, ya que, de esa manera, se asegurarían de que la reunión comenzara a la hora establecida y no tendrían que esperar su turno toda la tarde. El grupo estuvo acuerdo y se fijó la reunión a las ocho de la mañana. Zeth mostraba la misma disposición para anteponer el trabajo por encima de todo lo demás que esperaba del resto del grupo. Normalmente, trabajaba desde las seis la mañana hasta las siete tarde, los cinco días de la semana, además de, por lo menos, seis horas tanto el sábado como el domingo. Comentó: “Nadie trabaja más que yo.” Zeth solía mencionar a su equipo la hora a la había llegado a la oficina y entonces señalaba que ninguno de ellos había llegado aún. Él era claro: “Jamás les pediría que hicieran algo que no estuviera dispuesto a hacer yo.”
El Estilo de Dirección de Zeth Zeth supervisaba el trabajo de todo el grupo de ingenieros de software. Cada uno de los tres líderes de equipo de proyecto era responsable, a su vez, de la producción e integración de los códigos desarrollados por los cuatro ingenieros a quienes dirigía. Sin embargo, cuando Zeth no se encontraba en alguna reunión, dedicaba gran parte de su tiempo a recorrer el sector para conversar con los ingenieros. El estilo de dirección activo y práctico de Zeth despertaba reacciones encontradas. Por ejemplo, cuando faltaban diez días y el equipo estaba desesperado por cumplir con la fecha de entrega de una pieza importante del software, dos ingenieros se quedaron casi toda la noche en la oficina para resolver una falla que había aparecido. Zeth también se quedó en la oficina. Según uno de los ingenieros, “Debió haberse ido su casa. Tenerlo
constantemente a nuestras espaldas, mirándonos, no nos ayuda a terminar el trabajo... Trabajamos mejor cuando nos dejan solos... Los gerentes no lo entienden. Se la pasan alrededor nuestro y preguntan cómo nos pueden ayudar. Lo único que logran es distraernos. Nos ayudarían mucho más si no trataran de ayudar tanto.” Sin embargo, los ingenieros del equipo de Zeth lo describían como un gerente trabajador y confiable. Si bien no siempre estaban de acuerdo con lo que hacía o les pedía, solían cumplir con sus solicitudes. Por ejemplo, una noche Zeth llamó a uno de sus ingenieros a su casa para preguntarle a qué hora llegaría a la oficina a la mañana siguiente. El ingeniero relató: Probablemente, no hubiera ido antes de las nueve de la mañana, pero, luego del llamado de Zeth, me preocupé de estar allí a las siete. Me dijo: “Quiero asegurarme de que tengamos los códigos listos para entregar en la Reunión del Amanecer (la reunión de revisión diaria del avance del equipo)”, que tiene lugar a las ocho y media de la mañana, “porque quiero entrar en la reunión y decir: ‘Se equivocan; tenemos las entregas terminadas.’”Zeth siempre supone que todo va a salir bien. Y nada sale del todo bien, en especial cuando uno trata de apurar las cosas y terminarlas muy rápido. Entonces, siempre todo sale como la [insulto] y hay que hacerlo de nuevo. Creo que no se da cuenta de eso. Zeth supuso que si yo llegaba a la oficina bien temprano y le entregaba el código a John para que hiciera los PROMs y los cargábamos en la máquina, entonces estarían funcionando y él podría ir a la reunión de las ocho y media y anunciar: “Acá están las entregas.” Pero lo que pasó en realidad fue que no los tuvimos funcionando hasta eso de las once y media, más o menos. Yo sabía que jamás los tendríamos listos antes de las ocho y media. Hubiera sido un milagro. No obstante, a pesar de su escepticismo, el ingeniero nunca ha planteado sus dudas a Zeth, En cambio, se limitó a cumplir con llegar temprano a la oficia y hacer todo lo posible por terminar los códigos,
Las Recompensas en Ditto Para determinar los aumentos anuales al cierre el año calendario, Zeth, su jefe y varios gerentes de ingeniería de software realizaron reuniones confidenciales para calificar a los ingenieros de software de la división. Nadie fuera de esas reuniones vio la lista con las calificaciones, pero el ranking deteminaba qué aumentos recibiría cada uno ese año. La lista incluía los nombres de
todos los ingenieros de software de la división, en orden de mérito, con un comentario que explicaba su calificación. Max Green encabezaba el ranking y el comentario que acompañaba a su nombre decía: “Trabaja 80-100 horas por semana y su desempeño es excelente.” El comentario junto al segundo nombre de la lista también señalaba que ese ingeniero trabajaba muchas horas. Las observaciones junto a los nombres de los diez ingenieros con mejores calificaciones eran muy similares: “Trabaja día y noche” o “Trabaja 80 horas por semana.” Por el contrario, los comentarios junto a los últimos nombres de la lista hacían mención “contribución promedio”, “poca carga de trabajo” y “aportes mínimos. “Zeth comentó que uno de los ingenieros era una estrella” alguien que no quiere irse a su casa a la noche.” El 10% de los ingenieros con las mejores calificaciones recibió un aumento del 6%; el 70% de los ingenieros con las siguientes calificaciones recibió un aumento del 3% y el 20% restante, que había recibido las peores calificaciones, no recibía aumento alguno. De los 12 ingenieros que integraban el equipo del proyecto PEARL, 2 recibieron un aumento del 6%; 7 recibieron un aumento del 3%, y 1 no recibió aumento. Los dos ingenieros restantes habían empatado justo en la calificación que representaba el corte entre el aumento del 6% y el de 3%. Los gerentes que participaban en la asignación de aumentos sólo podían otorgar un aumento más del 6%. Por lo tanto, decidieron dividir un aumento del 3% y uno del 6% entre los dos ingenieros. De esta manera, ambos recibieron un aumento del 4,5%. Se informaba a los ingenieros de su propio aumento y del rango de aumentos otorgados en toda la división.
Despidos En el medio del desarrollo del proyecto PEARL, Ditto anunció que planeaba despedir a miles de personas en el curso de los dos años siguientes. Se trataba de la primera gran ola de despidos en la historia de la compañía. La primera ronda despidos no incluyó a ninguno de los integrantes del grupo de software de Zeth y sólo a cuatro de los 46 miembros del equipo de producto. Sin embargo, los despidos afectaron la actitud de todos los integrantes del equipo. Los ingenieros expresaron su enojo con la compañía y su reticencia a sacrificarse por una empresa que despedía a compañeros de trabajo mientras la empresa registraba ganancias. Al mismo tiempo, los ingenieros que habían conservado su trabajo manifestaban que “se sentían afortunados” y “privilegiados”. La mayoría temía “ser los próximos” y creía que esta situación de inseguridad laboral los obligaba a trabajar más duro aún para proteger sus empleos. Incluso Max Green, a pesar de saber que era un ingeniero estrella, admitía que “aún
los mejores ingenieros deben preocuparse en esta situación.” Bajo estas difíciles condiciones de mercado, Zeth sentía que la mayoría de los integrantes de su grupo trabajaba muy duro. Aún así, no estaba seguro de que el grupo estuviera haciendo todo lo necesario para que el software de PEARL estuviera listo y probado a tiempo. Era muy consciente de la meta de su gerente de acortar el ciclo de producción; además, el tener un investigador externo monitoreando el trabajo de su grupo constituía un recordatorio constante. De hecho, los superiores de Zeth habían decidido que, durante el desarrollo del producto, el investigador debía observar el accionar del equipo del proyecto PEARL, con especial atención al grupo de desarrollo de software de Zeth. Dos de las personas incluidas en el estudio eran de los mejores ingenieros del grupo de Zeth: Laura Barr, una de las líderes de equipo de proyecto con mejores calificaciones, y Max Green, ampliamente considerado como un ingeniero estrella. Zeth se preguntaba qué podría detectar el investigador que pudiese resultar valioso para mejorar la efectividad de su equipo a fin de asegurar el cumplimiento del cronograma de lanzamiento del producto.
Anexo 1 Organigrama del Proyecto PEARL
Gerente de Producto (Milton)
Gerente Técnico de Producto * Gerente de hardware * 6 ingenieros mecánicos
Gerente de Software (Zeth) * 3 líderes de equipo de proyecto * 1 colaborador independiente * 12 ingenieros de software Gerente de Lanzamiento * 2 subordinados directos Gerente de Marketing * 7 ingenieros de sistemas Gerente de Manufactura * 3 subordinados directos Controlador Gerente de Calidad y Efectividad Empresaria
Fuente: Leslie Perlow, Finding Time: How Corporations, Individuals, and Families Can Benefit from New Work Practices (Ithaca, N.Y.Cornell University Press), p.11.
Anexo2 Organigrama del Proyecto PEARL
Gerente de Software (Zeth)
Laura
Allan
Paul
Matt
Max
Stan
Sarah (entró en oct.)
Kate (hasta ene.)
George
Chris
Andy
Jerry
Jane
Ben
Frank
John
Fuente: Leslie Perlow, Finding Time: How Corporations, Individuals, and Families Can Benefit from New Work Practices (Ithaca, N.Y.Cornell University Press), p.12.
10
Anexo 3 Datos Demográficos de los Empleados del Grupo de Software de Ditto Cargo
Empleado (sexo)
Estado Civil
Hijos menores de 18
Zeth (masc.)
Casado
3
Colaborador independiente
John (masc.)
Casado
1
Líder de equipo de proyecto
Allan (masc.)
Casado
1
Líder de equipo de proyecto
Laura (fem.)
Casada
3
Líder de equipo de proyecto
Paul (masc.)
Casado
4
Ingeniero
Matt (masc.)
Casado
1
Ingeniero
Max (masc.)
Soltero
-
Ingeniero
Andy (masc.)
Soltero
-
Ingeniera
Jane (fem.)
Casada
1
Ingeniera
Sarah (fem.)
Casada
1
Ingeniero
Stan (masc.)
Casado
-
Ingeniero
Chris (masc.)
Casado
2
Gerente de software
Ingeniera
Kate (fem.)
Casada
3
Ingeniero
George (masc.)
Casado
4
Ingeniero
Ben (masc.)
Soltero
-
Ingeniero
Jerry (masc.)
Soltero
-
Ingeniero
Frank (masc.)
Soltero
-
Fuente: Leslie Perlow, Finding Time: How Corporations, Individuals, and Families Can Benefit from New Work Practices (Ithaca, N.Y.Cornell University Press), p.50.
11
