requisitos

Este es un tema tan manido en nuestra profesión, tan pesado, pero al mismo tiempo tan importante, que seguimos años y años hablando de lo mismo y sufriendo las mismas consecuencias una y otra vez.

¿Están bien especificados los proyectos? ¿Se parte de un grupo de requisitos suficientemente amplio? Es cierto que en software ágil ya se da por sentando que los requisitos pueden cambiar, porque de hecho cambian, es lo natural, pero lo hacen a partir de entregas, y esto es bueno y es precisamente lo que resuelven de manera magnífica todas las prácticas y principios de lo ágil.

Sin embargo, el peor vicio de nuestra profesión consiste en no saber o no querer esforzarse lo suficiente en establecer correctamente un documento con el catálogo de requisitos o especificaciones que indiquen qué es lo que hay que hacer. Es de sentido común dejar claro lo que el cliente quiere, ¿no?, sin embargo...

Muchas veces, el que tiene que tomar los requisitos, no sabe cómo hacer ese trabajo, me temo, pero en otras ocasiones, es la pura pereza de hablar con el cliente lo suficiente lo que impide que el equipo del proyecto sepa con más exactitud lo que hay que desarrollar.

Existe una ley universal que deberíamos tener siempre presente:

Cuanto más esfuerzo se dedica a especificar, menos tiempo se emplea en el desarrollo del proyecto.

Esto es una obviedad, una sandez decirlo, pero en el día a día, metidos en la vorágine del trabajo, reuniones, visitas, etc. se nos suele olvidar este principio.

Así de sencillo, así de simple. 

No me me deja de sorprender que compañías 100% de desarrollo e implantación de soluciones software, este trabajo previo e indispensable para crear una cotización aproximada y correcta, sencillamente no se tenga en cuenta con la seriedad que debería. Sí, me temo que puedo contar casos que harían palidecer a más de uno.

Hace un tiempo lanzé una encuesta con el siguiente lema: "El tiempo que se establece para los proyectos, ¿es correcto?"

El 81% de las respuestas seleccionaron la opción "No, se suelen hacer estimaciones cortas y muy ajustadas". Genial, como para recomendar a tus hijos esa profesión...

¿Cómo podemos estimar tiempos si no llegamos a especificar correctamente un porcentaje alto de lo que el cliente necesita?

Es cierto que nos podemos guiar un poco por la intuición después de llevar muchos años trabajando en el desarrollo de productos y proyectos, pero ningún negocio puede sobrevivir basado únicamente en este olfato, ni sería serio para ningún cliente determinar el precio de una manera no profesional: "pues a este, le vamos a cobrar X, más o menos", no, de ningún modo es serio, y sin embargo en muchas ocasiones se hace así, o ojo y con prisas, me temo.

La consecuencia natural de esta forma de hacer las cosas la he comentado mucho en este blog y en El Libro Negro del Programador: desarrolladores sin tiempo de hacer bien su trabajo y presionados, clientes enojados porque no se cumplen las fechas o porque se les entrega algo que no es exactamente lo que han pedido, compañías que pierden dinero, etc. También digo que con frecuencia es el mismo cliente el que te impide hacer el trabajo correctamente y te pone impedimentos.

La solución es bien sencilla, pero como todo lo fácil, requiere de disciplina y no dejarte llevar por la comocidad: no se pasa a la fase de ejecución de un proyecto hasta que no esté en su mayor parte especificado en un documento; pero, lo más importante, ese documento debe estar consensuado con el cliente. No es necesario que ese documento sea el que contenga los requisitos software, sino que la especificación puede estar en el mismo lenguaje con el que el cliente habla y entiende su negocio; de ahí, se extraerán después los requisitos software pero es suficiente para hacer una valoración de tiempos más acertada.

Pensándolo bien, en una compañía es vital gestionar los riesgos, ¿no es un riesgo ejecutar un proyecto por debajo del precio que se va a cobrar por él?

Esta falta de seriedad en la especificación la puedo comprobar continuamente y si de otras muchas cosas dudo, de hecho, suelo dudar de casi todo, en esto no hay nadie que me pueda rebatir. La buena ejecución de un proyecto depende enormemente de lo bien especificado que esté. Parece una perogrullada decir esto, pero como sabemos del día a día, a veces es difícil ponerlo en práctica. Otra cosa es que aplicando correctamente buenos principios de desarrollo, el proyecto sea mantenible y evolucionable cuando se planteen nuevos requisitos.

Otras veces es el mismo responsable comercial de la compañía el que quiere cerrar el tema (lanzándole la pelota o el marrón a otros), y a otro asunto.

Así son las cosas. Sin embargo, un buen responsable de equipo o de proyecto, no debe aceptar la puesta en marcha de un nuevo proyecto si no tiene claro en su mayor parte lo que hay que hacer. Es como si le pidiéramos a un constructor que nos levante una casa: ¿y cómo la hago?, pues mira, más o menos...

Esta es una de las cosas más difíciles de resolver cuando afrontamos la creación de un nuevo proyecto: distinguir claramente entre qué debe hacer de cómo se debe hacer.

El "qué" está relacionado con requisitos, especificaciones, historias de usuario, todo aquello que nos haga entender lo que el cliente quiere, su problema a resolver.

El "cómo" tiene que ver con las tecnologías que van a resolver ese problema que el cliente nos plantea, en otras palabras, el cómo abarca desde las tecnologías a usar, metodología, evidencias a entregar hasta dónde se desplegaría el proyecto final.

Hay una confusión tremenda entre esa separación de conceptos, hasta el punto de tener que forzar o usar mal tecnologías mal elegidas para el propósito indicado en una sencilla especificación (cuando no se le dice a un cliente que "eso no se puede hacer").

Si ya es difícil extraer al comienzo todos los requisitos y conseguir que estos estén descritos con buena calidad y que sean entendibles, más complicado aún el elegir ese cómo a partir de todo lo anterior.

De cómo se gestione esto y las decisiones que se tomen en ese momento dependerá en gran medida la calidad del proyecto que se entregue, su coste final y su facilidad de mantenimiento y evolución. Errores en esta fase hacen que el proyecto termine en un completo fracaso o haya que tirarlo al cabo de algunos años.

Lo peor de todo es que en muchas ocasiones confundimos requisitos objetivos, indicados o no por un cliente o intermediario, con aquellas tecnologías que nos gustaría usar porque sí o bien porque son las únicas que conocemos bien y no queremos salir de nuestra zona natural de confort. 

Traducido al desarrollo de proyectos software, esto viene a ser algo así como empezar la casa por el tejado: si antes de afrontar un nuevo proyecto, sea del tipo de que sea, ya estamos diciendo que lo vamos a hacer con una base de datos en SQL Server, ya estamos levantando paredes en el laberinto que se formará durante su desarrollo, o dicho en otras palabras, en lugar de solucionar, estamos poniéndonos a nosotros mismos obstáculos.

Este no es que sea un error más, el confundir qué se tiene que hacer con cómo se debe hacer, sino que es un error paradigmático de una profesión tanto si a ella llegan gente titulada con uno u otro título académico o intrusos sin formación formal relacionada (sin ánimo de menospreciar a nadie, al fin de al cabo sólo valen el talento de cada cual y el trabajo bien hecho).

Este error clásico, de libro, consiste en forzar el uso de un conjunto de tecnologías para una solución sin hacer el ejercicio intelectual previo de validar si esas tecnologías son las adecuadas o no para ese tipo de proyecto.

Las razones que hacen que caigamos en este error recurrente, en mi opinión, siempre son algunas de las siguientes:

• Por pura pereza: puesto que conozco mejor las tecnologías x, y o z, no me voy a molestar en aprender o indagar otro tipo de cosas que quizá serían más convenientes para este proyecto.
• Porque la política de la empresa es trabajar con tecnologías de x, sí o sí y no hay que darle más vueltas.
• Porque en la estimación del esfuerzo, no hay cabida para incluir una curva de aprendizaje en nuevas tecnologías más apropiadas para ese nuevo trabajo.
• O lo que es peor todavía: porque me gusta la tecnología x y quiero jugar con ella, ahora tengo la oportunidad, valga o no valga para el proyecto en el que me han metido, así por fin puedo jugar con ella a costa de mi trabajo en la empresa, aunque el resultado sea penoso.

En cualquier caso, las consecuencias de no hacer ese ejercicio previo antes de lanzar a un equipo de desarrollo a construir una nueva solución, son malas y a veces catastróficas.

Sin ir más lejos, en el último año he visto cómo se ha tirado a la basura la solución inicial, pero ya en explotación en una gran compañía eléctrica, para rehacerla completamente con tecnologías más apropiadas para el escenario que se planteaba. De este modo vemos que el no considerar ese aspecto del software al comenzar un nuevo proyecto tiene un coste económico que alguien tendrá que pagar, tu propia empresa o tus propios clientes (encareciendo tus servicios y perdiendo así oportunidades competitivas).

Esto ocurre en pequeñas empresas, pero también en esas que llamamos grandes, con recursos suficientes para hacer todas las auditorías del riesgo del mundo...

Hay que preguntarse siempre y justificar al máximo posible si es conveniente o no usar ASP.NET MVC o cualquier otro framework para interfaces de usuario web en el contexto de un proyecto particular, si es mejor AngularJS o Backbone, si es necesario o no una base de datos relacional (MySql, SQL Server, etc.) o repositorios de información no estructurada (MongoDB, Cassandra, Amazon Simple DB, SQL Tables de Azure, etc.). 

No toda tecnología es adecuada para cualquier tipo de proyecto. Esto parece una obviedad, pero el modo en que veo que en ocasiones se elige qué emplear en cada proyecto me da muchísimo que pensar, cuando no esa motivación nace de la última moda...

En mi opinión, esta debe ser una decisión del líder técnico del proyecto, si es que lo hay, ya que sólo se puede aproximar a una solución adecuada si cuentas con suficiente experiencia y si conoces en alguna medida todas las posibilidades tecnológicas existentes que podrían dar solución a un proyecto en particular.

No sé si es acertado o no, pero por esta razón me gusta promover dentro de la delegación de trabajo que dirijo sesiones internas y completamente desinteresadas en las que cada miembro del equipo expone algo que le interesa, tenga que ver o no con los proyectos que gestionamos en el día a día. Esas sesiones internas nos las preparamos en su mayor parte fuera del horario laboral, pero el resultado es que ampliamos así el acervo tecnológico existente y cuando nos llega algo que afrontar totalmente nuevo, tenemos, cómo decirlo, un horizonte más claro por haber tenido más contacto con un conjunto de tecnologias más amplio. Evidentemente esto requiere de un esfuerzo difícil de valorar, pero que aporta un valor intangible extraordinario en lo que hacemos, o eso creo.

En cualquier caso, el cliente nunca te va a pagar la curva de aprendizaje que necesitaría al comenzar con una nueva tecnología que desconoces, aspecto que distingue radicalmente nuestra profesión de otras: si intentamos repercutir en el cliente ese coste, seremos más caros y por tanto, más débiles de cara a la competencia.

Todo esto que en cierto modo no deja de ser sutil (porque sus consecuencias son difícilmente medibles); es algo con lo que tenemos que enfrentarnos queramos o no. A lo mejor si trabajas en una gran empresa donde alguien te dice con pelos y señales lo que tienes que hacer y cómo, los tiempos, etc., esta discusión sea irrelevante, pero la mayoría de desarrolladores se tienen que enfrentar a estas decisiones continuamente.

Sin clientes, ¿a quién le venderíamos nuestros productos o proyectos software?

Esto es evidentemente una obviedad, es una desfachatez siquiera comentarlo; sin embargo, no siempre tenemos a esos mismos clientes en cuenta para escucharles y que en cierta medida nos ayuden a mejorar todo aquello que hacemos y cómo lo hacemos.

Por lo general, no programamos o trabajamos en un proyecto cuyo cliente o usuario vamos a ser nosotros mismos, sino que siempre, de algún modo, vamos a realizar algo para que lo utilicen otros. No entiendo, por tanto, por qué no se trabaja intensamente con una actitud de escucha y recopilación activa de sugerencias y críticas para mejorar aquello que hacemos.

Es cierto esa frase ya clásica en software que dice que "el cliente no sabe lo que quiere" hasta que se le comienza a enseñar algo de esa nube abstracta de funcionalidad y requerimientos que pide. Pocos, muy pocos proyectos, comienzan con una definición clara y exhaustiva de requisitos. Por tanto, lo más normal (y natural) es que el cliente o nuestros usuarios comiencen a matizar y a solicitar nueva funcionalidad cuando ya por fin tiene algo entre manos que tocar y usar.

Esto no es malo, no hemos hecho nada erróneamente: sencillamente es lo habitual. Hay que vivir con ello y sabiéndolo, anticiparemos posibles problemas por desviaciones en tiempos y esfuerzos.

En realidad, esa falta de definición inicial es una gran ventaja si la sabemos usar correctamente.

Independientemente de quien esté más en contacto con tu usuario final, es imporantísimo para mejorar todo aquello que haces escuchar activamente las sugerencias, opiniones y críticas (positivas o no) de quienes en definitiva están usando el resultado de tu trabajo.

¿Y para qué? Sólo de esa manera vas a obtener una información muy valiosa:

• Entenderás mejor las necesidades específicas del cliente.
• Comprenderás mejor cómo este usa el producto.
• Manteniendo una actitud abierta, podrás recibir sugerencias de mejora que nunca se te habrían ocurrido.

En definitiva, dejas que los usuarios de tu producto (que además pagan por él directa o indirectamente) lo moldeen en cierto sentido para ajustarse mejor a las necesidades que tienen.

Como desarrolladores, en ocasiones se nos olvida que no programamos un producto o proyecto para nosotros mismos, sino que lo hacemos exclusivamente para que otros lo usen para resolver algún problema en particular. El cliente o usuario, en definitiva, es quien tiene la última palabra para validar si lo que se le entrega está bien, mal o es una solución más bien mediocre. Sin usuarios contentos, no hay producto (obviedad), y tampoco nadie que pague por nuestro trabajo (otra obviedad).

No siempre es fácil reconocer que algo en lo que se ha estado trabajando mucho tiempo, al final no sirve para nada (porque ningún usuario lo utiliza). Tampoco solemos tener una actitud suficientemente abierta como para encajar críticas que nos suenan negativas.

En el último año he tenido experiencias al respecto bastante buenas. Desde hace tiempo, uno los productos que comercializamos en la compañía para la que trabajo (y cuyo desarrollo lo he liderado yo desde el primer momento) ha evolucionado y crecido, básicamente, con el feedback activo de nuestros clientes consolidados que lo utilizan.

¿Resultado?

Me gustaría pensar que hemos ganado con esta actitud activa de escucha lo siguiente:

• Reconocemos todas aquellas mejoras que el cliente necesita en su día a día.
• Este feedback en realidad es una información valiosísima que nos permite generar un producto más cercano aún a las necesidades de ese mercado en particular.
• El cliente se siente valorado al tenerse en cuenta sus sugerencias.
• El producto evoluciona, por tanto, los clientes sienten que están usando (y pagando) un producto que mejora con el tiempo.

Del mismo modo, es difícil a veces saber identificar aquello que ese cliente solicita y que es muy particular y específico de aquello que realmente se puede incorporar como nueva funcionalidad útil al producto.

Esto es realmente lo que se persigue con una aproximación lean al sacar nuestros productos, tal y como lo describe Eric Ries en su libro El Método Lean Startup.

Son muchas las experiencias que se cuentan sobre la aproximación MVP (minimum viable product) para la generación de nuevos productos y la validación de ideas. Es decir, antes de dedicar mucho esfuerzo al desarrollo de algo que crees que va a funcionar, primero sacas un simple (y barato) prototipo para que lo valide tu entorno más cercano (que perfectamente pueden ser amigos y familiares). Con la información que recabes de ellos vas a validar tu hipótesis sobre la idea inicial o no; en caso negativo, también tendrás suficiente información como para abandonar esa idea (porque a nadie le interesa) o pivotar, es decir, evolucionarla para ajustarla mejor a una base mayor de posibles usuarios o clientes.

Podemos ser magníficos desarrolladores de software y crear soluciones limpias, evolucionables y maduras, pero si nadie las usa, entonces todo quedará en un bonito e inútil ejercicio o pasatiempo de fin de semana (con muchas horas de esfuerzo derrochadas e inútiles). De ahí que me interesen tanto todos esos aspectos que rodean el éxito de un producto software, sea éste del tipo que sea, una aplicación pesada de escritorio, un portal web o una aplicación móvil.

Recientemente me he acordado mucho de esto al leer Vender es Humano (de Daniel H. Pink); este es un libro muy interesante que recomiendo y que considera la venta como algo consustancial a cualquier actividad que realizamos. Todos, en el fondo, somos vendedores de algo, es decir, necesitamos usuarios o clientes que paguen por lo que hacemos. Venderemos más y mejor si además mantenemos una actitud abierta de escucha y si alentamos y recibimos con agrado cualquier tipo de feedback.