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)

 

Especificaciones Funcionales sin esfuerzo - Parte 3: Pero... ¿Cómo?


Por Joel Spolsky
Traducido por Miguel Cardo
Editado por Domingo Piña Maza
4 de octubre, 2000

Ahora que has leído todo sobre por qué necesitas una especificación y qué contiene una especificación, hablemos de quién debería escribirlas.

¿Quién escribe especificaciones?

Permíteme contarte aquí un poco de la historia de Microsoft. Cuando Microsoft empezó a crecer seriamente durante los 80, allí todos habían leído El Mítico Hombre-Mes, uno de los clásicos de gestión de proyectos software. (Si no lo has leído, te lo recomiendo encarecidamente). El principal argumento del libro es que, si uno añade programadores a un proyecto que lleva retraso, este retraso se hace aún mayor. La causa es que, si uno tiene n programadores en un equipo, el número de canales de comunicación es n(n-1)/2, lo cual crece como O(n2).

Por tanto, los programadores de Microsoft estaban preocupados sobre la forma de escribir programas cada vez más grandes, cuando la sabiduría dominante del momento era que añadir programadores únicamente empeora las cosas.

Charles Simonyi, durante mucho tiempo el "arquitecto jefe" de Microsoft, sugirió el concepto de programadores maestros. La idea consistía fundamentalmente en que un programador maestro sería responsable de escribir todo el código, pero él o ella se apoyarían en un equipo de programadores junior como "esclavos del código".  En lugar de preocuparse por depurar cada función, el programador maestro simplemente prototiparía cada función, creando la estructura vacía, y entonces se la lanzaría a uno de los programadores junior para que la implementase. (Por supuesto que Simonyi sería el Maestro de Programadores Maestros.) El término "Programador Maestro" era un poco demasiado medieval, así que Microsoft tomó el de "Program Manager".

Teóricamente, se suponía que esto resolvería el problema del Mítico Hombre-Mes, porque nadie tiene que hablar con nadie más -- cada uno de los programadores junior sólo habla con su único program manager, y así la comunicación crece como O(n) en lugar de O(n2).

Bien, puede que Simonyi conozca la Notación Húngara, pero no conoce Peopleware. Nadie quiere ser un esclavo del código. El sistema no funcionó en absoluto. Llegó un momento en que Microsoft descubrió que, pese al presunto Mítico Hombre-Mes, uno puede seguir añadiendo gente inteligente a un equipo y obtener un aumento en la producción, aunque sea con valores marginales decrecientes. El equipo de Excel tenía 50 programadores cuando yo estaba allí, y era algo más productivo que lo que hubiera sido un equipo de 25 -- pero no dos veces productivo.

La idea de la programación maestro/esclavo fue desacreditada, pero Microsoft todavía tenía por ahí a esa gente, llamados program managers. Un hombre inteligente, llamado Jabe Blumenthal, reinventó prácticamente el puesto de program manager. A partir de aquí, el program manager sería el dueño del diseño y la especificación de los productos.

Desde entonces, en Microsoft los program managers recopilan requisitos, deducen lo que se supone que hace el código, y escriben las especificaciones. Hay normalmente unos 5 programadores por cada program manager; estos programadores son responsables de implementar en código lo que el program manager ha implementado en forma de especificación. Un program manager también necesita coordinar el marketing, la documentación, las pruebas, la adaptación internacional, y todo el resto de molestos detalles en que los programadores no deberían perder el tiempo. Por último, se supone que en Microsoft los program managers tienen en mente la "visión global" de la compañía, mientras que los programadores son libres para concentrarse en conseguir que sus trocitos de código sean perfectos.

Los program managers son inapreciables. Si alguna vez te has quejado de que los programadores se ocupan de la elegancia técnica más que del atractivo comercial del producto, necesitas un program manager. Si alguna vez te has quejado de que quienes son capaces de escribir buen código nunca son capaces de escribir buen castellano, entonces necesitas un program manager. Si te has quejado alguna vez de que parece que tu producto se mueve a la deriva, sin una dirección clara, necesitas un program manager.

¿Cómo contratar a un Program Manager?

La mayoría de las empresas ni siquiera tienen el concepto de program manager. Muy mal, creo yo. En mis tiempos, los grupos de Microsoft con program managers fuertes tenían productos de gran éxito: Excel, Windows 95, y Access me vienen a la memoria. Pero otros grupos (como MSN 1.0 y Windows NT 1.0) los llevaban desarrolladores que normalmente ignoraban a los program managers (quienes de todas formas no eran muy buenos, y probablemente merecían ser ignorados), y sus productos no tuvieron tanto éxito.

He aquí tres cosas a evitar:

1. No asciendas un programador a program manager. Las habilidades para ser un buen program manager (escribir claro, diplomacia, tener en cuenta al mercado, empatía con el usuario, y buen diseño del interfaz de usuario) son muy raras veces las habilidades para ser un buen programador. Seguro que hay gente capaz de ambas cosas, pero escasean. Recompensar a buenos programadores ascendiéndoles a un puesto diferente, uno que implica escribir en español, no en C++, es un caso clásico del Principio de Peter: se tiende a ascender a la gente a su nivel de incompetencia.

2. No dejes que la gente de marketing sean program managers. Sin ánimo de ofender, creo que mis lectores estarán de acuerdo en que los buenos empleados de marketing pocas veces tienen una idea de los aspectos tecnológicos lo bastante buena como para diseñar productos.

Fundamentalmente, la gestión de programas es una carrera profesional independiente. Todos los program managers tienen que ser muy técnicos, pero no tienen por qué ser buenos programadores. Los program managers estudian la interacción con el usuario, se reúnen con los clientes, y escriben especificaciones. Necesitan llevarse bien con una amplia variedad de gente -- desde clientes "retrasados", pasando por irritantes programadores ermitaños que vienen al trabajo vestidos de Star Trek, hasta pomposos tipos de ventas en trajes de 2000 dólares. En cierto sentido, los program managers son el pegamento que une los equipos de software. El carisma es crucial.

3. No obligues a que los programadores estén por debajo del program manager. Se trata de un error sutil. Como program manager en Microsoft, diseñé la estrategia de Visual Basic (VBA) para Excel y especifiqué totalmente, hasta el detalle más nimio, cómo debería implementarse VBA en Excel. Mi especificación se alargó hasta unas 500 páginas. En el punto álgido del desarrollo de Excel 5.0, estimé que cada mañana 250 personas venían a trabajar, y fundamentalmente lo hacían partiendo de esa enorme especificación que yo había escrito. No tenía ni idea de quiénes eran todos esos, pero había sobre una docena de personas en el equipo de Visual Basic solamente escribiendo documentación para ese chisme (por no mencionar el equipo escribiendo documentación por la parte de Excel, o la persona a tiempo completo responsable de los hiperenlaces en el fichero de ayuda). Lo extraño es que yo estaba "en la base" del árbol jerárquico. Eso es. Yo no era el jefe de nadie. Si yo quería que la gente hiciera algo, tenía que convencerles de que era lo apropiado. Cuando Ben Waldman, el desarrollador jefe, no quería hacer algo que yo había especificado, simplemente no lo hacía. Cuando los de pruebas se quejaban de que algo que yo había especificado era imposible de probar por completo, yo tenía que simplificarlo. Si alguna de estas personas hubiera estado por debajo de mí, el producto no habría sido tan bueno. Algunos de ellos habrían pensado que no está bien contradecir a un superior. Otras veces, simplemente me habría impuesto y les habría ordenado hacerlo a mi manera, por presunción o cortedad de miras. Tal como estaba organizado, no me quedaba más remedio que formar un consenso. Esta manera de tomar decisiones fue la mejor forma de conseguir que se hiciera lo correcto.

El artículo final de mi serie sobre especificaciones trata de cómo escribir buenas especificaciones que a la gente les apetezca leer.



Esté articulo apareció originalmente en Inglés con el nombre Painless Functional Specifications Part 3  

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