El Proyecto Pearl - Patrones de Trabajo en Ditto A

406-S07
REV: 1 DE MARZO, 2004
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 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).
________________________________________________________________________________________________________________
El caso de LACC número 406-S07 es la versión en español del caso de 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 planilla 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.
This document is authorized for use only in Region Occidente's PCG 50 GDL course at ICAMI - Centro de Formacion Y Perfeccionamiento Directivo, from February 2018 to April 2019.
406-S07 El Proyecto PEARL: Patrones de Trabajo en Ditto (A)
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 color 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 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 herramientas: 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 en 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 mismo 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.
El Proyecto PEARL: Patrones de Trabajo en Ditto (A) 406-S07
(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 presentan 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 lanzamientote 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 software.1 Cuando le preguntaron por qué se
encontraba en la 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 decir algo así acá.” Otro
1 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 las distintas fases del proyecto.
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 de 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 de la mañana hasta las siete
de la 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 que
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 a 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; tenemois 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 oficina y hacer todo lo posible por terminar los
códigos.
Las Recompensas en Ditto

Para determinar los aumentos anuales al cierre del 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 determinaban 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 a “contribución promedio”, “poca carga de trabajo” y “aportes
mínimos.” Zeth comentó que uno de los un ingeniero estrella era “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 de 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 proximos” 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 valiosos 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
Gerente de Sistemas
• 7 ingenieros de sistemas
Gerente de Manufactura
Contralor
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.
Anexo 2 Organigrama del Equipo de Desarrollo de Software
Gerente de Software
(Zeth)
Laura Allan Paul John
Matt Max Stan

Sarah (entró en oct.) Kate (hasta ene.) George
Chris Andy Jerry
Jane
Ben Frank
Fuente: Leslie Perlow, Finding Time: How Corporations, Individuals, and Familes Can Benefit from New Work Practices
Anexo 3 Datos Demográficos de los Empleados del Grupo de Software de Ditto
Cargo Empleado (sexo) Estado Civil Hijos Menores de 18

Gerente de software 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
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

El Proyecto Pearl - Patrones de Trabajo en Ditto A

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

El Proyecto Pearl - Patrones de Trabajo en Ditto A

Uploaded by

Copyright:

Available Formats

406-S07

REV: 1 DE MARZO, 2004

El Proyecto PEARL: Patrones de Trabajo en Ditto (A)

Zeth se preocupaba mucho de que su grupo de ingenieros de software no fuera responsable de

Mientras el mercado de periféricos multifuncionales de bajo precio crecía y se reducía el

De todas maneras, PEARL ya iba a ingresar tarde en el mercado de periféricos multifuncionales,

El Grupo de Desarrollo de Software

Cuando la gerencia lanzó RUBY, había un error en mi código. De todas maneras,

El Estilo de Dirección de Zeth

No obstante, a pesar de su escepticismo, el ingeniero nunca ha planteado sus dudas a Zeth. En

Las Recompensas en Ditto

Se informaba a los ingenieros de su propio aumento y del rango de aumentos otorgados en

Anexo 1 Organigrama del Proyecto PEARL

Gerente de Producto (Milton)

Gerente Técnico de Producto

Gerente de Software (Zeth)

Gerente de Calidad y Efectividad Empresaria

Anexo 2 Organigrama del Equipo de Desarrollo de Software

Laura Allan Paul John

Matt Max Stan

Anexo 3 Datos Demográficos de los Empleados del Grupo de Software de Ditto

Cargo Empleado (sexo) Estado Civil Hijos Menores de 18

You might also like