Joel on Software

Joel on Software   La Opinión de Joel sobre qué es Software

 

Otros artículos de "Joel on Software" en Español

Otros artículos de "Joel on Software" en Inglés

Envíele un Email al autor (solo en Inglés)

 

Dos Historias


Por Joel Spolsky
Traducido por Esther Robles
Editado por Jerry Elizondo
19 de marzo, 2000

Os quiero contar dos historias sobre mi carrera, que pienso que son ejemplos clásicos de la diferencia que existe entre compañías tecnológicas que están bien organizadas, y de otras que son desastres.  Todo esto sucede por la diferencia que existe cuando se confía en los empleados y se les deja libremente a la hora de hacer tareas.  En el otro lado de la moneda se les puede tratar como meros empleados de hamburguesería que necesitan ser controlados cada instante, para evitar que deambulen y saboteen el lugar.

Durante mi primer asignación, trabajando para Microsoft, se me encomendó la concepción de una estrategia para un nuevo lenguaje de macro para Excel.  Al poco tiempo tenía el primer borrador de las especificaciones de “Excel Basic” (el cual evolucionó en Visual Basic para Aplicaciones, pero eso es otra historia.)  De algún modo, mi especificación llegó a los oídos de un grupo misterioso de gente en Microsoft llamado el grupo de “Arquitectura de la Aplicación”.  Este grupo se debió de inquietar y pensar que de alguna manera ellos eran los responsables de tareas como las estrategias de macro lenguajes, y por ese motivo demandaron ver mi especificación.

Pregunté por ahí: ¿quién conoce al grupo de la Arquitectura de la Aplicación? Nadie parecía pensar que era un grupo serio.  Descubrí que era un grupo de sólo cuatro personas, nuevos empleados con estudios de doctorado (muy inhabitual en Microsoft.)  Les envié una copia de mis especificaciones y me reuní con ellos por si tenían algo interesante que contar.

“Bla bla!” dijo uno.  “Bla bla bla, bla bla bla” dijo el otro.  No creí que tenían nada interesante que decir.  Estaban enamorados de la idea de la subclasificación y pensaban que los que creábamos macros en Excel, queríamos subclasificar muchas cosas.  De todos modos uno de los miembros dijo: “Bueno, todo esto es muy interesante.  ¿Qué viene después? ¿Quién tiene que  aprobar tu especificación?

Me reí. Aun cuando sólo llevaba unos meses en Microsoft, sabía que no existía alguien que debía dar el visto bueno a mi especificación.  Qué diablos, nadie tenía tiempo de leer mi especificación y menos aprobarla.  Los programadores me estaban molestando cada día, para que les diera más páginas para que ellos pudieran escribir más código.  Mi jefe (y el de él) me dejó muy claro que nadie entendía los macros o tenían tiempo de desentrañarlos, así que hiciese lo que hiciese más me valía que estuviese bien hecho.  Y ahí estaba este doctor trabajando en este grupo raro de investigación en Microsoft, suponiendo que las cosas eran más formales de lo que eran.

Me di cuenta enseguida de que este grupo de “Arquitectura de la Aplicación”  sabía incluso menos que yo de macros.  Al menos, yo había hablado con unos cuantos desarrolladores y con antiguos programadores, para entender lo que la gente había hecho con los macros de Excel: cosas como el recálculo diario de una hoja de cálculo, o el reordenamiento de datos conforme a un cierto modelo.  Pero el grupo de Arquitectos de la Applicación simplemente habían pensado sobre macros como si de un ejercicio académico se tratase.  Ni si quiera podían plantearse algún ejemplo de clases de macros que la gente querrían escribir.  Presionado, uno de ellos expuso la idea de que desde que Excel ya tenía subrayado y doble subrayado,  quizás alguien querría escribir un macro con triple subrayado.  Sip.  Súper lógico.  A partir de entonces empecé a ignorarlos lo más diplomáticamente que pude.

Esto solía fastidiar a un tipo llamado Greg Whitten, el cual dirigía el grupo de los Arquitectos de la Applicación  En ese momento, Greg era algo como el empleado número 6 de Microsoft.  Parecía que llevaba toda la vida en la compañía aunque nadie podía contar qué es lo que él había hecho.  Por lo visto solía comer muy a menudo con Bill Gates y GW-BASIC fue bautizado gracias a él.  Greg convocó una GRAN REUNIÓN y procedió a quejarse de cómo el grupo de Excel (refiriéndose a mí) estaba fastidiando la estratégia del macro.  Le presionamos para que nos plantease razones específicas, pero su disputa no era convincente.  Pensé para mí mismo que era una situación ideal, ahí estaba yo, un nuevo empleado mocoso recién salido del instituto, discutiendo con el empleado número 6, y por lo que parecía ganando la discusión. (¿Os podéis imaginar esto pasando en la compañía “Traje de Franela Gris”?) Mi grupo de programación, encabezado por Ben Waldman (ahora un vicepresidente de Microsoft), me respaldó completamente.  Eso fue lo único que realmente importaba, ya que el grupo de programadores escribió el código y por ese motivo tenían la última palabra de cómo se tenían que hacer las cosas.

Yo hubiera dejado el tema como estaba.  Si el grupo de los Arquitectos de la Applicación necesitaba mimos y querían discutir sobre cosas, por mi parte bien.  Yo hubiera discutido con ellos tanto como quisieran siempre que dejasen a los programadores en paz con su trabajo.  Pero entonces algo más interesante ocurrió que me dejó alucinado.  Un día estaba sentado a la hora de la comida con algunos compañeros, bajo el sol de Redmond, cuando Pete Higgins se me acercó.  En ese tiempo Pete era el director general de Office—sabía quién era, por supuesto, pero no pensaba que él me conociese tan bien.

“ ¿Cómo va Joel?” me preguntó. “ He oído que has tenido algunas discrepancias con el grupo de los Arquitectos de la Applicación”

 “¡Oh no!”  le dije. “Nada que no pueda manejar”

“No digas nada más”, contestó, “entiendo”.  Se marchó.  Al día siguiente un rumor llegó hasta mi: el grupo de los Arquitectos de la Applicación fue disuelto.  No sólo eso, pero cada miembro del grupo fue enviado a un departamento diferente de Microsoft, lo más lejos posible.  Nunca volví saber más de ellos.

Me dejó desconcertado, evidentemente.  En Microsoft, si eres un Gerente de Proyecto trabajando en la estrategia del macro de Excel, incluso si llevas en la compañía menos de seis meses, no importa- eres el DIOS de la estrategia del macro de Excel, y nadie, ni si quiera el empleado número 6, puede ponerse en medio. Punto.

Esto deja un mensaje importante.  Por un lado, hace que la gente sea más conciente de sus trabajos. Uno no se puede esconder bajo la idea de que “los gerentes han aprobado las especificaciones”, ya que los gerentes no las miraron muy detenidamente. Todo lo que management hizo fue contratar un grupo de listos y darles algo que hacer.  Por el otro, esto hace que el ambiente de trabajo sea agradable. ¿Quién no quiere ser el rey de su propio territorio?  El software, por su propia naturaleza, es muy fácil de dividir en trozos más pequeños y más pequeños, por eso es muy cómodo dividir el trabajo entre los trabajadores, siendo ellos responsables de su propia área. Esta es probablemente LA razón por la que a los programadores les gusta mucho trabajar para Microsoft.


Los años pasaron y empecé a trabajar para Juno, un proveedor de servicios online y de e-mail gratis.  Esta vez, la experiencia fue exactamente la opuesta a mi trabajo en Microsoft.  Tenía dos programadores bajo mi control pero mi jefe constantemente determinaba mi (limitada) autoridad. Él solía mirar mis informes y darles a los programadores tareas, a veces, sin siquiera avisarme. Incluso para nimiedades como las de aceptar peticiones de días libres, él solía tomar la responsabilidad de aceptarlas o denegarlas.

Al cabo de unos años seguía en Juno. Estaba trabajando con el nuevo dispositivo de registro para una nueva versión del Juno 3.x.  Se me había asignado ser el responsable de toda la puesta a punto del proceso.  En esa época yo casi era un miembro superior en el equipo técnico.  Recibí muy buenas críticas por mi rendimiento, y mis jefes parecían apreciar el trabajo que hacía.  Sin embargo era imposible que confiaran en mi. Mando y control.

Una parte del proceso de registro solicitaba a los usarios introducir su fecha de nacimiento. Esto era una pequeña parte de un largo proceso de registro que se alargaba con unas 30 ventanas, en donde Juno acribillaba al usuario con preguntas sobre el sueldo, deportes favoritos, la cantidad de hijos y su edad y otros cientos de cosas más.  Para mejorar el proceso de registro, yo quería cambiar el campo de la fecha de nacimiento al formato libre, pudiendose escribir tanto “8/12/74" como “agosto 12, 1974” o “12 agosto 74” o lo que fuese. (¿Habéis usado Outlook? Llegaría a ser como Outlook en donde se pueden escribir fechas de cualquier manera y Outlook las acepta).

Sin contar muchos detalles, a mi jefe no le gustó la idea. Se convirtió en un problema de ego para él. Al principio le gritaba al diseñador que trabajaba en esa página (sin tan si quiera avisarme.) Luego me gritó a mí. Luego me hizo recordar cada día que tenía que volver a cambiarlo a la manera en que él quería. Incluso hizo que el director de la empresa lo revisara haciendo un gran espectáculo cuando convenció al director de criticar también mi nuevo diseño.  Incluso al Director de la Compañía de Juno no le molesta interferir con el trabajo hecho en los niveles más bajos de la compañía, de hecho, es un procedimiento normal.

Ni qué decir que me puse furioso. Era una poquedad, una cuestión de gusto realmente.  A algunos les gustaría mi opinión y otros tendrían otro punto de vista.  De cualquier modo el mensaje estaba claro: tu HARÁS  lo que te digamos aquí, ¡diablos!.  Era una mentalidad de mando y conquista.  Era más una batalla de cojones que una discusión sobre un diseño de interface para el usuario.

No voy a decir que esta fue precisamente la razón por la que dejé Juno, pero ilustra muy bien la razón del por qué lo hice: era esa idea de que no importaba que duro se trabajaba, no importaba que inteligente se era, no importaba si estabas “al mando” de algo o no, uno no tenía autoridad ni si quiera para la cosa más insignificante. Ninguna.  Cóge tus malditas ideas, formación, cabeza e inteligencia, todas las cosas por las que estamos pagando y escóndelas.  Y en Juno había bastantes jefes, algo así como ¼ de todos los empleados, así que tenían suficiente tiempo para meter sus narices en cada decisión y asegurarse de que ellos estaban en control.  El contraste con Microsoft,  donde el Vicepresidente descendía del Edificio 9 para dejar muy claro que tú tenías la autoridad de hacer lo que tú creyeras que tenías que hacer, era absoluto.

Hanging Tree in Jaffa, Israel

De alguna manera, el inepto proceso gerencial es un factor que viene de ser una compañía de la ciudad de Nueva Cork y no una compañía de la costa este [de Estados Unidos], así que los estilos modernos de administración no han calado.  También es un problema causado por la gran inexperiencia de los jefes en Juno, teniendo su origen en lo más alto – el director de la compañía es un tipo de 29 años el cual nunca ha trabajado en otros sitios. D. E. Shaw interfiere en cada cosa en las que pone las manos, incluyendo el orden de las palabras que salen en los mensajes de errores. El CTO [Chief Technology Officer, Director de Tecnología] cotidianamente les grita a los empleados si se atreven a cuestionar su sabiduría; se desquitan con los programadores quienes llegan a casa a patear a sus perros. Compara esto con Microsoft, donde las cosas se hacen desde el nivel más bajo.  El trabajo más importante de la mayoría de los jefes es el de moverse por la habitación quitando los muebles del medio, para que la gente se pueda concentrar con su trabajo.



Esté articulo apareció originalmente en Inglés con el nombre Two Stories  

Joel Spolsky es el fundador de Fog Creek Software, una pequeña empresa de software en Nueva York. Es titulado por la Universidad de Yale y ha trabajado como programador y gerente en Microsoft, Viacom, y Juno.


El contenido de estas páginas representan la opinión de una persona.
Todo el contenido es Copyright ©1999-2005  por Joel Spolsky. Todos los derechos son reservados.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky