(para leer la tira sin lupa, pulsa en la imagen)
Hace un tiempo, a un amigo, en el colegio, le denegaron un premio en un concurso de dibujo porque el trabajo que presentó lo había hecho "con ordenador" y, como todo el mundo sabe, "el ordenador hace casi todo el trabajo".
Hoy en día, ese chico es director de animación de una empresa española que tiene en su haber un largometraje con un premio Goya y que ha producido un cortometraje nominado a los Goya y a los Oscar. Pero claro, supongo que será porque "el ordenador hace casi todo el trabajo".
Casi na.Esta anécdota viene a resumir lo que mucha gente piensa:
la tecnología es mágica
Atención: rollo ingeniero a partir de aquí:
Esta es una máxima en la que creen con los ojos cerrados muchas personas que quieren soluciones a sus problemas mágicamente; cuando hay una limitación de tiempo, de recursos y/o de conocimientos, la tecnología, mágicamente, puede suplir todo esto y más; haz "flexible" este proyecto; queremos que este software se pueda "adaptar" a multiples plataformas sin esfuerzo; queremos que este software sea fácilmente "ampliable" a nuestras necesidades futuras...
todo eso es precioso, pero...¿para qué necesitas esa flexibilidad? ¿has pensado en qué plataformas tienes como objetivo? ¿qué necesidades inmediatas tienes? ¿qué te planteas en el futuro? ¿puedes hacer una lista de tus necesidades, de lo que quieres que haga el sistema?
Pero pensar es costoso.
Y hay gente a la que le debe doler mucho hacerlo.La mayor parte de las veces, la gente te argumenta que
"no hay tiempo para hacer toda esa engorrosa documentación". Argumentan que no pueden detallarte de manera perfecta todo a la primera. Ya puedes decirles que no es eso lo que se pretende, que lo que se busca es un documento inicial, que se revisa y refina, como el software, en sucesivas iteraciones.
Es lo mismo. Ellos tienen en su cabeza lo que necesitan, a veces incluso ni siquiera eso; saben que otros tienen esas ideas y se limitan a exigirte que leas mentes. Es curioso como entienden que puede haber varias versiones de un programa pero no de un simple documento.
Otra excusa que se suele dar es que todo eso son "cosas técnicas"; de nada sirve que les digas que son documentos en lenguaje coloquial, en los que hay que decir qué se pretende del software / hardware; documentos en los que se describe como interactua el usuario con el sistema. En cuanto hay un
chupachups con brazos al que llamas 'actor' y un recuadrito que se llama 'sistema', ya es algo técnico.
Otra cosa que suele ser el pan de cada día es recibir requisitos 'mínimos' o 'limitados'. El objetivo, loable él, es que des una estimación de tiempo mínima para las funcionalidades básicas de un software y luego soltarte la otra mitad de la funcionalidad. Esto, la primera vez suele producir tirones de pelos, gritos y probablemente, rehacer una arquitectura o desecharla por completo porque a alguien pensó que era mejor no decirte que el sistema debía ser multiusuario, por si te liabas. No entienden que, en realidad, cuanto más grande es un proyecto, más importantes son los cimientos. Y que sin saber lo que se te va a exigir, sin conocer si te van a pedir añadirle 30 plantas al edificio o simplemente que le pongas unas macetas, no puedes decidirlo todo. Y que la palabra 'flexibilidad' no es mágica.
Ya, cuando tienes experiencia, supones que te van a pedir mil cosas y haces una arquitectura tremebunda, con una flexibilidad de mil pares. Y sobrediseñas. Y acabas perdiendo tiempo.
Las señales que os pueden indicar que estáis ante un proyecto indefinido suelen ser:
- La documentación existente está en formato Powerpoint o en documentos sin organización ni estructura; el efecto "carta a los reyes magos".
- Ausencia de glosario de términos. duplicación de conceptos; dos cosas que se llaman igual y son distintas.
- Reuniones maratonianas de varias horas en las que se hacen 'brainstormings' y se definen los requisitos de manera informal, sin plasmarlos en un documento ni asignarlos a nadie específicamente. Se confía en que los que tengan que hacer las cosas sepan que tienen que hacerlas. Usualmente, estas reuniones se repiten en el tiempo, machacando los mismos temas, dado que nadie parece percibir avances; ni los ingenieros perciben necesidades, ni los comerciales / gestores perciben trabajo enfocado a sus necesidades.
Conclusión; lo que no se ha hecho para ahorrar tiempo, se hace durante sucesivas reuniones, sin plasmarlo en documentación, gastando recursos y energía que no sería necesaria de hacer las cosas bien desde un principio; paradójicamente, a pesar de esto, hay gente que cree que hacerlo así es 'más eficiente', dado que 'parece' más trabajo. Es esa misma gente que cree que hacer varias cosas a la vez es más productivo que enfocarse en ellas una a una.
Y al final, lo único que puedes hacer es confeccionar la documentación tú mismo, desde arrancar la especificación de requisitos al 'cliente' hasta desarrollar los casos de uso, definir la arquitectura, hacer el análisis, el diseño, el desarrollo, el despliegue y el mantenimiento. Ser arquitecto, desarrollador, chico de sistemas y atención técnica. Porque no queda otra.
¿quieres leer más tiras? Entra en el listado de tiras y escoge!
Puedes usar esta tira libremente,
cumpliendo tan solo esta licencia CC:
