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 y 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 y el problema que hay que 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 que se van a usar y la metodología hasta las evidencias que se entregarán y dónde se desplegará 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 estén descritos con buena calidad y que sean entendibles, más complicado aún es elegir ese cómo a partir de todo lo anterior.
De cómo se gestione esto y de 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 de software, esto viene a ser algo así como empezar la casa por el tejado: si antes de afrontar un nuevo proyecto, sea del tipo 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. Dicho de otro modo, en lugar de solucionar, estamos poniéndonos a nosotros mismos obstáculos.
Esto no es un error más —confundir qué se tiene que hacer con cómo se debe hacer—, sino un error paradigmático de una profesión, tanto si a ella llega gente titulada con uno u otro título académico como intrusos sin formación formal relacionada (sin ánimo de menospreciar a nadie; al fin y 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 adecuadas o no para ese tipo de proyecto.
Las razones que hacen que caigamos en este error recurrente, en mi opinión, suelen ser 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 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 de 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 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, 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 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 necesaria o no una base de datos relacional (MySQL, SQL Server, etc.) o repositorios de información no estructurada (MongoDB, Cassandra, Amazon SimpleDB, Azure Table Storage, 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, sobre todo cuando 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 se cuenta con suficiente experiencia y se conocen 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 las preparamos en su mayor parte fuera del horario laboral, pero el resultado es que ampliamos el acervo tecnológico existente y, cuando nos llega algo totalmente nuevo que afrontar, tenemos —cómo decirlo— un horizonte más claro por haber tenido más contacto con un conjunto más amplio de tecnologías. Evidentemente, esto requiere de un esfuerzo difícil de valorar, pero que aporta un valor intangible extraordinario a lo que hacemos, o eso creo.
En cualquier caso, el cliente nunca te va a pagar la curva de aprendizaje que necesitarías al comenzar con una nueva tecnología que desconoces. Este aspecto distingue radicalmente nuestra profesión de otras: si intentamos repercutir ese coste en el cliente, seremos más caros y, por tanto, más débiles frente a la competencia.
Todo esto, que en cierto modo no deja de ser sutil (porque sus consecuencias son difícilmente medibles), es algo a 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 los desarrolladores se tienen que enfrentar continuamente a estas decisiones.