Tomar el control

Babalum — Tue, 08 Aug 2006 17:05:27 +0000

Sigo con otro librobit extraido de “El paradigma – Todo lo que necesito saber sobre la empresa lo aprendí en Microsoft” de Julie Bick.

“Todo el mundo quiere ser bueno en su trabajo, pero sacar el máximo de su trabajo ya no significa simplemente completar las tareas a tiempo y dentro del presupuesto.

Para hacer un trabajo realmente destacado, debe pensar en la repercusión de su pieza del rompecabezas. Debe ir más allá del ámbito estricto de sus responsabilidades.

Y si algo no anda bien -tanto si le abruma la carga de trabajo como si se lamenta de tener un mal jefe-, deténgase un momento y piense la manera de tomar el control de la situación. “

En otras palabras, no esperes que nadie te resuelva tu situación. Está en tus manos encontrar la manera de realizar lo que deseas y apartar o esquivar los posibles obstáculos.

Publicado en babalum.wordpress.com

El libro está en Amazon en español y en inglés.

Ver libro en español en Amazon

Ver libro en inglés en Amazon

Todo proceso se puede mejorar

Babalum — Sat, 22 Jul 2006 13:44:52 +0000

Extraigo ésta pequeña joya del libro “La paradoja – Todo lo que necesito saber sobre la empresa lo aprendí en Microsoft” de Julie Bick en el que relata sus experiencias en Microsoft en los años 90. A juzgar por lo que describe Julie parece que en aquellos tiempos Microsoft todavía estaba llena de frescura, creatividad e innovación en todos los aspectos. Me refiero no sólo a los tecnológicos si no también a los aspectos de gestión.

Vamos allá.

Según escribe Julie, en aquellos tiempos una de las tareas más aburridas era la integración de todo el código escrito durante el día por todos los programadores de un equipo. Normalmente éste trabajo lo hacian programadores menos expertos o cualificados. Nadie deseaba hacerlo. Era aburrido y tedioso. Si los códigos no funcionaban debía encontrarse aquel que no funcionaba y depurarlo. Un día a algún manager se le ocurrió hacer los siguientes cambios.

El ensamblaje lo haría aquel programador que provocó el último error o problema.

Un simple cambio, probablemente impopular al principio, pero que al cabo del tiempo provocó los siguientes resultados:

1. El ensamblaje ya no lo hacían programadores de menos experiencia y contratados especialmente para ésta labor. Ahora se encargaban los mismos expertos, con la consecuente mejora en ese proceso.

2. La labor que nadie quería hacer estaba más compartida entre todos en vez de empobrecer el trabajo de uno sólo.

3. Dado que nadie quería ser el ensamblador del día, todos se esmeraban más en evitar errores o técnicas que pudieran provocar incompatibilidades.

4. Como que a todos, en algún o otro momento, les tocaba, buscaban estrategias para que la labor de ensamblaje durase lo menos posible. El resultado fué que con sus mayores conocimientos idearon procesos y sistemas de automatización de la tarea.