Especificaciones Funcionales

Leonardo Herrera
Creado: 24/12/2001
Última Actualización: 21/9/2004

En todas mis experiencias como programador, mi gran problema ha sido no con el código, sino con las personas a cargo de un determinado producto. Mi primer trabajo fué de junior programmer en una empresa de Automatización de Procesos. Todo iba bien; yo era una suerte de code slave, que es algo así como el ayudante de los Senior Programmers de la empresa (cabe destacar que éramos sólo tres programadores). Cuando alguien necesitaba una rutina tediosa de hacer, o simple pero que tomaba tiempo, me llamaban a mí (trabajaba por hora, una suerte de freelance), y para los toques finales a las UI también me llamaban, pues tengo inclinaciones artísticas y el diseño de íconos, botones, bitmaps de fondo, etc., también eran mi trabajo.

Cuando a mi jefe se le acabó el presupuesto, tuvo que deshacerse de los dos senior programmers. Ahí fue cuando Nuevito Leus entró en escena, luego de un brutal (para mis expectativas de la época) aumento de sueldo. Me tuve que hacer cargo del producto estrella de la empresa, un sistema de monitoreo de procesos, que consistía básicamente en un programa conectado por un puerto a un PLC, que es un autómata programable, espectacular aparatejo para controlar cosas eléctricas, y que mostraba de manera visual qué estaba pasando. Si conectábamos este programa a una línea de, por ejemplo, conteo de cajas de bebida para una embotelladora, lo configurábamos de tal manera que en la pantalla se veían cajas que pasaban en una correa transportadora.

Las especificaciones comerciales del programa eran bastante atrayentes para las empresas. Visualización en tiempo real, control limitado de algunos procesos (no críticos) y además la habilidad de correr en máquinas ya existentes; estaba enfocado a 386, cuando el 486 ya estaba posicionado en el mercado. Esto, unido a un buen precio, lo convertía en un producto más que recomendable para cualquier fábrica pequeña o mediana.

Había un sólo problema. No existía un documento funcional de especificaciones. Nada. Ni documento descriptivo, ni resumen de las funciones que se suponía que debía hacer. Había un manual de uso, pero era rudimentario y escrito por una persona cuyo lenguaje nativo no era español.

Obviamente, mi trabajo, aunque interesante desde el punto de vista tecnológico, pronto se volvió una pesadilla.

Cada uno o dos días mi jefe venía hasta mi cubículo -era una oficina pequeñísima, sin embargo yo tenía un cubículo- y me largaba un requerimiento, nunca escrito, acerca de alguna funcionalidad que era imperativa de implementar. "Pero, Jefe," reclamaba yo, "jamás se me habló de esta característica." "Lo sé," respondía él, "pero está en las especificaciones del producto."

Eso bastaba para que yo quedara mudo, y me hundiera en mi asiento. Luego, sin más datos, comenzaba a codificar. Click click click. Tap tap tap. Salía humo de mi teclado, según me comentaba alegremente el junior de la empresa. El reloj corría, horas y horas, para, al final, la característica que se suponía era parte de las "especificaciones" del programa estuviera ahí.

Pronto mis niveles de stress subieron a órbita, pero nunca me atreví a reclamar, y además no tenía tan claro que se necesitase tal cosa como un documento. En ese tiempo, mis conocimientos acerca de programación eran tan sólidos como ahora. Programación orientada a objetos, punteros, algoritmos de ordenamiento, estructuras de datos, todo estaba a mi alcance. Excepto el manejo de situaciones como ésta. Era sólo un joven de diecinueve años, aprendiendo al máximo de su capacidad, enfrentándose a un ingeniero alemán, y experto en robótica, como si fuera poco, de la universidad de Subenempujenstrügenbajen.

¿Cuál sería vuestra reacción? Les contaré cual sería mi actual reacción a tal problema. En un escenario ideal, sin miedo a perder el empleo, me opondría terminantemente a cualquier nueva implementación hasta no ver y tener en mis manos un Documento Funcional de Especificaciones, o, como dice mi amigo Mito, Specs. Usualmente, quienes deben escribir estos documentos son los mismos quienes diseñan el producto y quienes deben comercializarlo. Pero como usualmente estas personas son gerentes cuyo tiempo no puede ser malgastado escribiendo documentuchos y restar el tiempo usado en reuniones, comidas, correo y otras cosas ilegales o que engordan, me pondría manos a la obra y lo escribiría yo mismo.

¿El resultado? Un documento que reflejaría el diseño del programa. No es más, pero fíjense, es nada menos que el diseño del programa. Este documento, sumado a una presión constante por opiniones, cambios, revisiones, llevaría a tener una salvaguarda para casos de "featuritis", que tan a menudo suceden cuando las ideas no están ordenadas en un documento así. Además, al término de la escritura de este documento, se logra cerrar un ciclo. ¿Al amigo del jefe se le ocurrió que el programa ahora debería ser capaz de mandar SMS al encargado de mantenerlo? Interesante, pero quedará para la siguiente versión.

Existe otro caso, y es cuando el pobre programador no puede darse el lujo de perder un empleo. Todos sabemos que este es un escenario recurrente hoy en día. Una buena estrategia en este caso es escribir el documento de especificaciones mientras se sigue implementando lo que es necesario. Indudablemente, es trabajo extra. Probablemente no sea una buena idea comunicarlo inmediatamente al superior, pues éste puede ver la escritura de este documento como una "pérdida de tiempo." A medida de que el documento se vaya completando, se puede ir mostrando en dosis pequeñas. Llegará un momento en que el jefe ya no pedirá la nueva característica, sino que pedirá un documento de especificaciones para agregar una nueva característica.

En ese instante, la batalla estará ganada.

Nota: Parece que hay algún tipo de enlace invisible con Joel. Un par de días después publicó este artículo.

Este sitio es mantenido con ePublish