Una pregunta que surge muchas veces en las acaloradas discusiones sobre desarrollo de software se centran en el costo del software. Cuanto cuesta producirlo, cual es el valor monetario del mismo, y si bien existen diferentes formas, desde el punto de vista de la ingeniería de sistemas para lograr esto, nosotros, los desarrolladores y productores de dicho software carecemos de la capacidad de transmitir dicho valor hacia el usuario final.

Cuantos de nosotros, después de un exhaustivo análisis, hemos ido con el cliente y nos encontramos con las típicas frases: – No, es muy caro. – No, es mucho tiempo. – No, yo pensaba pagar [1% del costo propuesto].

Y esto se ve potenciado cuando el producto requerido es más grande. O sea, mientras más grande es el resultado esperado, menos es lo que el cliente percibe que debe pagar por el trabajo. – Quiero una copia de GMail. Vociferan sin pensarlo dos veces. – No quiero gastar más de [0,001% del costo resultante de la producción del mismísimo GMail].

Tenemos la suerte de que rara vez el cliente final necesita un sistema operativo, porque ahí sí que estaríamos en serios problemas.

En todo caso, este problema, desde mi punto de vista, esta relacionado con la falta de cultura adquirida por este usuario/cliente final hacia el esfuerzo y trabajo que producir software requiere. Posiblemente fuertemente ligado a la ausencia de elementos materiales de gran volumen entregables. Convengamos que un CD/DVD no ocupa mucho espacio, y esto puede producir, neuronalmente en el cliente, una concepción de que eso es pequeño, que no vale mucho más de lo que él piensa. Muy diferente, para arrojar algunos ejemplos varios, lo tiene planteado un arquitecto (que también tendrá sus problemas, claro está, pero hay cosas que no se discuten), ya que por un lado este le entregará una buena cantidad de papeles representando los planos de su casa, firmados, avalados. Y con suerte, terminará entregando una estructura donde el cliente habitará. Si vamos por otro ejemplo, ningún cliente discute (fuera de los límites tolerables), el costo de un automóvil. El valor de este es puesto por el vendedor, y es normalmente aceptado por el cliente sin ningún problema, hasta prácticamente feliz; esto por un lado debido a que la cultura del automóvil está más arraigada en el consumidor común, y por otro lado, porque vamos, es UN AUTOMÓVIL, hasta hace BRRRRMMM!!!.

Lo más interesante del automóvil es que en concepto, resulta mucho más simple producirlo que un software. Tienes una línea de montaje, todos son idénticos, y a lo sumo cambia el color. O sea, mientras se producen cientos de miles de automóviles de serie, el valor de este es inamovible y aceptado por el cliente, mientras que el desarrollo de un software a medida es objeto de regateos, siendo que se está construyendo uno a gusto del usuario. Ni vengamos con el típico problema de: – Y este botón ¿Podes moverlo acá?. Imposible de hacer entender que mover dicho botón (ejemplo llevado al extremo) no resultaría una cuestión trivial, ya que impactaría en tiempos de entrega y costos. Ahora, que pasa si el cliente dice: – Está lindo el automóvil, pero lo quiero en púrpura con pintas blancas. Supongo que los ojos del vendedor brillarán y sacará un gran talonario para facturar el costo del cambio.

Entonces, que pasa con esta falta de educación por parte del usuario para el entendimiento de lo que hacemos y lo costoso que resulta. Esto no es culpa del usuario, es culpa nuestra, y es algo que deberemos cambiar o si no seguiremos intentando vender esfuerzo extremo a costos ínfimos.

Teniendo en cuenta que estamos en el momento donde la información fluye, y donde más código se comparte libremente para su reutilización, es mucho más natural ver como los desarrolladores seden su código y queda libre dando vueltas. De la misma forma, si estamos en la posibilidad de hacerlo, sería excelente entregar de alguna forma, este código al usuario para que vea cuando esfuerzo llevó en confeccionar su “pequeña aplicación”.

Por mi lado, arranco con esta idea que, tal vez pueda no ser la mejor, pero es un inicio, y cuelgo el código realizado para el PacMan de los post anteriores, en formato PDF. Como podrán notar, un juego simple, aún no terminado, cuenta con 33 hojas de código, un tremendo documento si a esto le incluimos los trabajos circundantes como la creación de las imágenes, horas de pensamiento en la lógica del código entre otras características inherentes al desarrollo de software. Pensemos en un proyecto maduro, con miles de líneas de código donde seguramente podremos armar un documentos de varios cientos de páginas solo para que el usuario/cliente se dé cuenta del trabajo que representa hacer lo que hacemos.

Para descargar el PDF: http://cid-44a6f6b3589906f1.skydrive.live.com/self.aspx/Public/XNAPacManforPC.pdf