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 2: ¿Qué es una especificación?


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

(¿Has leído ya la primera parte? Si no, está aquí.)

Esta serie de artículos trata sobre especificaciones funcionales, no técnicas. Hay gente que las confunde. No sé si hay una terminología estándar, pero esto es lo que yo quiero decir cuando uso estos términos:

  1. Una especificación funcional describe cómo funcionará un producto completamente desde la perspectiva del usuario. No le importa cómo se implemente la cosa. Habla de funciones. Especifica pantallas, menús, diálogos, etcétera.
  2. Una especificación técnica describe la implementación interna del programa. Habla de estructuras de datos, modelos de bases de datos relacionales, elección de lenguajes y herramientas de programación, algoritmos, etc.

Cuando uno diseña un producto, por dentro y por fuera, lo más importante es fijar la percepción que tenga el usuario. Cuáles son las pantallas, cómo funcionan, qué hacen. Más tarde, te preocupas de cómo llegar de un sitio al otro. No sirve de nada discutir sobre qué lenguaje de programación usar antes de haber decidido qué es lo que va a hacer tu producto. En esta serie de artículos, sólo hablo de especificaciones funcionales.

He escrito una pequeña especificación de ejemplo que debería darte una idea de la aspecto que tiene una buena especificación funcional. Antes de seguir, por favor lee la especificación de ejemplo.

¿La has leído?

No, no la has leído. Ve a leerla ahora y vuelve cuando lo hayas hecho, para que podamos hablar más de lo que una buena especificación debe y no debe tener. Estaré aquí esperándote. Gracias.

(esperando pacientemente...)

[Image]

Ah, bien. Ya estás de vuelta.

He aquí algunas de las cosas que pongo en toda especificación.

Una nota de aviso. Pura autodefensa. Si pones un párrafo que diga algo como "Esta especificación no está terminada", la gente no invadirá tu oficina para arrancarte la cabeza de un mordisco. Según pase el tiempo, cuando la especificación vaya estando terminada, puedes cambiarla a "esta especificación está terminada, según mi mejor ciencia y conciencia, pero, si he olvidado algo, indícamelo, por favor". Lo cual me recuerda que toda especificación necesita:

Un autor. Algunas empresas opinan que la especificación debería ser escrita por un equipo. Si has probado alguna vez a escribir en grupo, sabrás que no hay peor tortura. Deja la escritura en grupo a las firmas de consultoría de dirección, con sus ejércitos de diplomados por Harvard recién salidos del horno, quienes necesitan hacer montañas de trabajo para poder justificar sus enormes tarifas. Tus especificaciones deberían ser propiedad de, y escritas por, una persona. Si tienes un producto demasiado grande, divídelo en áreas y entrega cada área a una persona diferente, para que lo especifiquen por separado. Otras compañías opinan que es egoísta o mal "trabajo en equipo" el que una persona se "apropie del mérito" de una especificación por poner su nombre en ella. Tonterías. La gente debería tener la responsabilidad y la  propiedad de las cosas que especifica. Si algo está mal en la especificación, debería haberse nombrado un dueño de la especificación, responsable de arreglarlo.

Escenarios. Cuando estás diseñando un producto, necesitas tener en mente algunos escenarios reales que representen cómo lo va a usar la gente. De otra manera acabarás diseñando un producto que no se corresponde con ningún uso real (como el  Cue?Cat). Escoge los grupos de audiencia de tu producto e imagina un usuario ficticio, totalmente imaginario pero a la vez totalmente estereotipo de cada grupo, quien utiliza el producto de una forma totalmente típica. El Capítulo 9 de mi libro de diseño de Interfaces de Usuario (disponible gratis online) habla sobre la creación de usuarios ficticios y escenarios. Que son el lugar donde los colocas. Cuanto más vívido y realista sea el escenario, mejor trabajo harás diseñando un producto para tus usuarios reales e imaginarios, por lo que tiendo a poner muchos detalles inventados.

No objetivos. Mientras se está desarrollando un producto con un equipo, todo el mundo tiende a tener su función favorita (real o imaginaria), sin la cual no pueden vivir. Si las haces todas, te llevará un tiempo infinito y costará demasiado dinero. Tienes que eliminar funciones innecesarias enseguida, y la mejor forma de hacerlo es con una sección de la especificación que se puede llamar "no objetivos". Cosas que no vamos a hacer. Un no-objetivo puede ser una función que no piensas incluir ("¡nada de interfaz telepático de usuario!") o algo más general ("En esta versión no vamos a preocuparnos del rendimiento. El producto puede ser lento, siempre que funcione. Si para la versión 2 tenemos tiempo, optimizaremos los trozos más lentos.") Es probable que estos no-objetivos causen alguna discusión, pero es importante afrontarla abiertamente lo antes posible. "¡No lo voy a hacer!", como decía George Bush padre.

Una visión general. Es como el índice de tu especificación. Puede ser un simple diagrama de flujo, o bien una extensa discusión de la arquitectura del producto. Todo el mundo la debe leer para hacerse una idea de conjunto, a partir de ella los detalles tendrán más sentido.

Detalles, detalles, detalles.
Finalmente, te metes en los detalles. La mayoría lo leerá por encima hasta que necesiten saber un detalle concreto. Cuando uno está diseñando un servicio de tipo web, una buena forma de hacerlo es dando a todas las posibles pantallas un nombre canónico, y escribiendo un capítulo que describa cada una de ellas con un nivel de detalle tan minucioso que nuble el entendimiento.

Los detalles
son lo más importante en una especificación funcional.  Te habrás dado cuenta de cómo, en la especificación de ejemplo, entro en un nivel de detalle exagerado para todos los casos de error de la página de login. ¿Qué pasa si la dirección de e-mail no es válida? ¿Qué pasa si la constraseña está mal? Todos estos casos se corresponden con código real que va a ser escrito, pero, lo que es más importante, estos casos corresponden a decisiones que alguien va a tener que tomar. Alguien tiene que decidir cuál ha de ser la política a seguir en el caso de una contraseña olvidada. Si no lo decides, no puedes escribir el código. La especificación necesita documentar la decisión.

Asuntos pendientes. No pasa nada por dejar asuntos pendientes en la primera versión de una especificación. Cuando yo escribo un primer borrador, siempre me quedan muchos asuntos pendientes, pero los señalo (usando un estilo especial para poder buscarlos luego) y, si viene a cuento, presento las alternativas. Cuando llega el momento en que los programadores empiezan su trabajo, todos ellos deben ser liquidados. (Alguien podría pensar que basta con dejar que los programadores empiecen con lo fácil, y resolver los asuntos pendientes más tarde. Mala idea. Ya tendrás bastantes problemas resolviendo los nuevos asuntos que surjan cuando los programadores intenten implementar el código, sin que estén todavía por ahí los viejos asuntos pendientes que ya conocías por adelantando y que pudiste haber resuelto entonces. Además, la forma en que resuelvas cualquier cosa no trivial puede tener un impacto considerable en cómo se debe escribir el código.)

Notas al margen. Mientras estés escribiendo una especificación, recuerda tus distintas audiencias: programadores, pruebas, marketing, redactores técnicos, etc. Según escribes la especificación, se te pueden ocurrir ideas útiles que pueden ser de utilidad a uno solo de estos grupos. Por ejemplo, yo indico ciertos mensajes para el programador, que suelen describir algún detalle de implementación, como "Notas técnicas". Los de marketing las ignoran, pero los programadores las devoran. Mis especificaciones suelen estar repletas hasta el agotamiento de "Notas de prueba", "Notas de marketing", y "Notas de documentación".

Las especificaciones necesitan estar vivas. Ciertos equipos de programación adoptan una mentalidad "en cascada": diseñamos todo el programa de una vez, escribimos una especificación, la imprimimos,  la tiramos por encima de la pared a los programadores y nos vamos a casa. Todo lo que tengo que decir es: "¡Ja ja ja ja ja ja ja ja!"

Semejante forma de actuar es la causa de que las especificaciones tengan esa reputación tan mala. Mucha gente me ha dicho, "las especificaciones son inútiles porque nadie las sigue, siempre están obsoletas, y nunca se corresponden con el producto".

Discúlpame, pero a lo mejor tus especificaciones están obsoletas y no se corresponden con el producto. Mis especificaciones se actualizan con frecuencia. Las puestas al día se van haciendo según el producto va siendo desarrollado y se toman nuevas decisiones. La especificación siempre refleja nuestro mejor conocimiento colectivo de cómo funcionará el producto. Solamente se congela la especificación cuando el producto está en estado de "código completo" (o sea, cuando toda la funcionalidad está completa, pero todavía queda probarlo y depurarlo).

Para facilitar la vida de la gente, no reedito la especificación a diario. Suelo mantener una versión puesta al día en un servidor, en algún lugar donde el equipo puede usarlo como referencia. En hitos ocasionales del proyecto, imprimo una copia de la especificación con marcas de revisión, para que la gente no tenga que releerla toda entera -- basta con que echen un vistazo a las marcas de revisión para ver qué cambios se han hecho.

¿Quién debería escribir las especificaciones? Léelo todo en la Parte 3.



Esté articulo apareció originalmente en Inglés con el nombre Painless Software Specifications Part 2  

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