Requerimiento: acabar con los requerimientos
Esta semana, Xavi y yo hemos estado hablando sobre los requerimientos. Y me alegra que en un tema tan trascendente estemos de acuerdo sin necesidad de darle excesivas vueltas.
Llevo varios años en proyectos de investigación, y he pasado por dos proyectos europeos. Si algo he aprendido es que los requerimientos no sirven absolutamente para nada. Bueno, sí. Sirven para darse cuenta al final del tiempo de implementación de que los requerimientos más estúpidos han sido cumplidos con brillantez mientras que los esenciales aún están criando malvas en lo más profundo del documento de análisis. Por supuesto que ésto no tiene que ser una regla general. Pero sí que es aplicable a nuestro proceso de desarrollo.
Tenemos la inmensa suerte de estar recopilando un grupo de gente competente que, además, sabe cuál es el objetivo y dónde tenemos que mirar en cada momento. Como equipo. ¿Hace falta que malgastemos nuestro preciado tiempo en redactar un documento lleno de frases sin sentido, que no hacen más que cimentar una futura carrera de obstáculos?
La respuesta es NO.
En una de las transparencias de la presentación base que Tom Peters lleva a cuestas por todo el mundo, hay una cita extraída de "Bloomberg por Bloomberg" que describe lo que quiero expresar con suma precisión:
“We made mistakes, of course. Most of them were omissions we didn’t think of when we initially wrote the software. We fixed them by doing it over and over, again and again. We do the same today. While our competitors are still sucking their thumbs trying to make the design perfect, we’re already on prototype version No. 5. By the time our rivals are ready with wires and screws, we are on version No. 10. It gets back to planning versus acting: We act from day one; others plan how to plan—for months.”
Yo tambien escribo 
En ThinkInGrid hemos definido los pilares básicos que debe cumplir nuestra aplicación (Soft requirements). Todos hablamos el mismo idioma y tenemos claro los objetivos.
A más, ningún cliente nos va a comprar un primer proyecto por el simple hecho que nuestro código cumple el standard SUN o supera el CheckStyle.
Primero ganar el time to market con un producto 9 y Cuando tengamos una oficina con ventanas… ya buscaremos el 10.
xfernandez - noviembre 1, 2006 a las 3:31 pm |
La verdad es que hay veces que me preocupáis (agarraos, que vienen críticas)… 😉
No hacéis planes de negocio, no queréis procesos, no haceis documentos de requerimientos…Entiendo que cuando sois poquitos y tenéis las ideas muy claras os sobren muchos papeleos. Pero todo tiene una medida. Por ejemplo, cuando trabajéis para un cliente ya me contarás si «pasais» de los requerimiento y no los ponéis por escrito (Diox os libre)…Y si nunca antes habéis plasmado requerimientos en un papel, os resultará confuso y fallaréis en todos los primeros intentos. El trabajo en interno tambiñen sirve de entrenamiento para trabajar hacia fuera. Y os aporta credibilidad y solidez (por mucho que ‘moleis distribuidamente’ ;-), vais a necesitar algo más para salir ahi fuera, y sin salir ahi fuera lo unico que deberíais hacer es contar los minutos que os quedan hasta que se agote el combustible…
Si no tienes un plan, formarás parte del plan de otro. Si no tienes unos objetivos, nunca sabrás si has llegado. Si no cerráis requisitos, aunque sean de alto nivel, corréis el riesgo de divagar.Antes de que te des cuenta tienes a los técnicos trabajando siete días para implementar una funcionalidad «cool» pero que, pasado un análisis del valor, no aporta nada…Y eso es pasta que estás tirando por el desague.
Angel M. - noviembre 2, 2006 a las 1:16 pm |
No es exactamente así 🙂
Plan de negocio tenemos, y tenemos versiones para aburrir. Lo que pasa es que llega un momento en que no sale a cuenta darle más vueltas o pulir mil detalles.
Y requerimientos sí que tenemos, al menos a alto nivel. Lo que intento decir es que no necesitamos un documento de tropecientas páginas porque no nos va a servir de nada. Tenemos la dirección bien clara. Cada semana nuestra pizarra se llena y se borra muchas veces, y todos sabemos en cada momento qué está haciendo el otro.
(Edit:) Entiendo que el día que crezcamos habrá que adaptarse, pero de momento tenemos claro que centrarse en los requerimientos no nos va a hacer más eficientes.
Sergio - noviembre 2, 2006 a las 1:28 pm |
Siendo así, dormiré más tranquilo sabiendo que hay entregas de «Think in» para rato… 😉
Angel M. - noviembre 2, 2006 a las 1:40 pm |
PD: Sí esoy de acuerdo en que los documentos de tropecientas páginas, sean requerimientos o planes técnicos, no sirven para nada por definición…Nadie se lee nada que exceda las tres páginas (seis con el indice, la portada y esas cosas… 😉
Angel M. - noviembre 2, 2006 a las 1:41 pm |
Por cierto, me ha encantado que hayas usado la expresión ‘molar distribuidamente’ 😉
Sergio Álvarez - noviembre 2, 2006 a las 1:43 pm |
Si, el entregable como base de que las cosas se hacen bien hechas y muchas veces, para cubrirte las espaldas.
Con mi experiencia me he dado cuenta, que los documentos de requerimientos detallados, diseños a bajo nivel, etc. Són aquellos que todo el mundo sabe que en un 95% no sirven de nada, pero queda bien decir que los tienes, o los haces…
Por cierto, Ricardo Semler, en su libro «El fin de semana de siete dias» (Gracias Diego) apuesta por la dirección sin planes de negocio, ni planes de estrategia, plena libertad al trabajador etc etc. Quiza la clave está realmente a quien dejas que forme parte de tu empresa.
Angel, gracias por tu aportación.
xfernandez - noviembre 2, 2006 a las 2:11 pm |
Leete «Radical» de Ricardo Semler…»El fin de semana de siete días» no son más que divagaciones sobre el auténtico «how to», que es Radical…Ya me contarás. Por cierto, compruebo que compartimos bibliografía…Vamos a tener que cambiarnos «cromos»… ;-). De todas maneras, el mismo Semler reconoce en varios párrafos que, llegados a cierto nivel de libertad, hay que incluir unos mínimos controles. Aun así, estoy de acuerdo en que si tratas a los empleados como niños, se comportarán como tales.
Respecto a los documentos tochos que no sirven para nada, me refería en interno. Con los clientes, todo el papel es poco (lamentablemente). Me he salvado de más de un marroncete por tener actas de las reuniones y documentos de requisitos al dedillo («pues no, mire usted, un botoncito que haga que la aplicación toque la marcha de los campanilleros de semana santa no está incluido en el presupuesto, ¿ve usted?»).
Angel M. - noviembre 2, 2006 a las 4:58 pm |
[Desaparece uno un día y se encuentra con esto :D]
En el fondo ha quedado claro el planteamiento de Ángel. Y creo que la culpa es nuestra por no saber expresarlo bien.
Tenía pensado redactar en la reunión del próximo lunes un manifiesto que sirva para definirnos. Viendo la imágen que proyectamos será necesario.
Diego Mariño - noviembre 2, 2006 a las 6:39 pm |
La cita de bloomberg me encanta (y la comparto al 100% ya que trabajé 3 años en el principal competidor de Bloomberg y eso es exactamente lo que pasaba).
Respecto al tema de los requisitos, al menos en el desarrollo de un producto, en términos generales estoy de acuerdo con el planteamiento. Los requisitos «core» de alto nivel hay que tenerlos cuanto más claros y cuanto antes en el ciclo de desarrollo mejor.
Lucas - noviembre 7, 2006 a las 7:49 pm |