La percepción del valor de lo intangible contra lo tangible

En el sector de la , y en el particularmente, sufrimos a diario la infravaloración de los costes que se generan con nuestra actividad. La gran mayoría del trabajo realizado se oculta bajo una interfaz de usuario. Por ello la percepción sobre la cantidad y calidad de los esfuerzos necesarios para crear lo que se ve, es mínima. Únicamente se asume el esfuerzo necesario para lo visible, dando por hecho que no hay nada más complejo de lo que se observa a través de la pantalla.

Los clientes de hoy en día mayoritariamente asocian el volumen de trabajo al esfuerzo habitual de las cadenas de montaje, al trabajo físico, a los materiales y los elementos que ocupan espacio. Estos requieren fuerza bruta o mecánica para transformarlos, y por ello, dicha asociación hace que, trasladándola al mundo digital, se limite a lo que pueden ver o tocar.

el cliente de un desarrollo software normalmente no suele titubear cuando pide una modificación, en cualquier momento o en cualquier lugar de la aplicación, porque asume que el de eso es ínfimo

Para ellos, un botón en una pantalla es elemento donde se puede hacer click, con su color y el texto que hay encima. Un texto es meramente un conjunto de letras que se han pintado o colocado en cierta zona donde navega. Como si fuesen piezas de un LEGO para niños, se asume que el coste de crear esos elementos debería reducirse al requerido para colocarlos en el sitio requerido. Se desconoce que existe una lógica con la que se crean dichos textos y que permite que esos elementos aparezcan cuando son necesarios.

Este pensamiento suele conducir a una grotesca simplificación del esfuerzo que puede requerir o un conjunto de datos de un sitio a otro. O el de eliminar un formulario en el . La percepción del coste de dichas acciones vuelve a medirse con el de los trabajos físicos, la interacción con lo tangible.

Eliminar un formulario al iniciarse una aplicación se asume tan sencillo como el retirar esa pieza del LEGO, que al quitarla no afecta a las demás piezas que la rodean. Este razonamiento implica, por lo tanto, que el coste en tiempo y dinero necesario para ello es mínimo.

Suele ser un axioma en software que cuanto más sencillo es algo para el usuario, más complejo es lo que hay por debajo para que lo parezca.

Pero el cliente de un desarrollo software normalmente no suele titubear cuando pide una modificación, en cualquier momento o en cualquier lugar de la aplicación, porque asume que el de eso es ínfimo. Lo puede llegar a asemejar al ejercicio de borrar y pintar en otro lado. Así que, ¿por qué iba a ser necesario incrementar el por algo tan trivial?

Para hacernos una idea, veamos un clásico ejemplo de percepción simplificada errónea:

Nuestro cliente quiere una para su empresa. Esta app, será un catálogo de sus productos para vender a nivel mundial. De hecho, a día de hoy seguramente lo ha pedido porque ve que el resto de la competencia lo está haciendo.

Después de varias reuniones, donde nos explica qué y cómo quiere su app de catálogos, se desarrolla y entrega el análisis preliminar. Un donde se detalla el comportamiento de la app, así como la de la misma. Igualmente, se realiza el diseño de cada una de las con el aspecto final. Todas estas vistas se incluyen en nuestro clásico , donde se muestra al mínimo detalle el flujo entre las distintas vistas, así como una de cada uno de los elementos que va a tener la app.

“Perfecto, ¿cuándo tengo la app?”, parece decir minimizando la dificultad de todo el desarrollo.

Se lleva a cabo el proyecto y cada dos semanas se le presentan los resultados de los distintos . Pero cada vez que va a verlos, parece sentirse decepcionado al ver ‘solo’ a varios tipos ‘cómodamente’ sentados en una silla detrás de un ordenador donde sólo mueven los dedos mientras miran absortos la pantalla. No hay maquinaria, ni ruidos, ni gente moviéndose de un lado a otro, ni tan siquiera murmullos, tan solo el constante machaqueo de las teclas y los clicks de los ratones.

Finalmente, llega el día de la entrega del último de los sprints, y antes de comenzar nos comenta lo siguiente:

“Es que pensándolo, ahora que veo la app completada, …”.

¡Un segundo!, esto no es totalmente cierto. La app debería haberla visto, exactamente tal cual la está viendo ahora cuando aceptó el Diagrama de la Felicidad. Bueno, se la entregamos pero seguramente no llegó a darle importancia, no asumió que dicho documento contenía lo que iba a recibir.

“… necesito que los usuarios se registren al comienzo porque necesito sus datos en nuestro ”. Así que nuestro cliente lo simplifica todo con la siguiente frase. “Es solo pasar ese formulario de cuando compra al final, al principio”. Es decir, “solo en vez de pintarlo aquí, hacerlo aquí, solo eso”.

en vez de pintarlo aquí, hacerlo aquí, solo eso.

A nuestro cliente no le ha temblado la voz, nos ha mirado a los ojos tranquilamente, y casi de forma condescendiente, lo ha simplificado a una simple acción de “pintarlo”. Claro que por el camino no ha vuelto a nombrar la palabra “CRM”, que hasta ahora ni se había mencionado una sola vez.

Veamos lo que puede significar el que nos plantea nuestro cliente ahora:

  1. De entrada, y aunque no lo haya hecho más que de refilón, la palabra “CRM” nos ha puesto a todos en estado de alerta “DEFCON1”. Las sirenas no dejan de sonar por todos lados. La , requiere la definición de una en alguno de los dos lados. Normalmente el CRM ya la tiene definida, pero ahora nos queda saber cómo y qué datos hay que sincronizar con ese CRM que ni conocemos. Dicho CRM deberemos analizarlo, aclarar las dudas referentes al mismo y añadir su casuística a nuestro sistema.
  2. Probablemente este CRM, para crear ciertas entidades propias, requiera de atributos que nosotros no habremos tenido en cuenta cuando se definieron en la app. Eso requiere por lo tanto, de nuestra app para incorporar esas entidades y sus atributos.
  3. Debido a la aparición de estas nuevas entidades, las relaciones en la base de datos cambien por lo que habrá que tenerlas en cuenta también. Por ello nuestros analistas deberán realizar un rediseño de la misma.
  4. Seguramente, las consultas que teníamos hasta ahora desarrolladas, igualmente haya que modificarlas para tener en cuenta estas nuevas entidades y sus atributos. Tareas que deberán hacer nuestros programadores.
  5. Por todo ello, los que ‘comunican’ los datos entre la App y la base de datos del servidor también tendrán que recodificarlas nuestros programadores para que contemplen ahora estos nuevos datos.
  6. Al aparecer nuevos datos en el formulario de registro para una correcta sincronización con el CRM, las vistas que deben gestionar y mostrar esos datos en la App deben rediseñarse. Esto requiere un nuevo análisis de la por parte de nuestro analista de (User Experience & User Interface) de las vistas para ver cómo presentarlos o cómo redistribuirlos. Estas vistas que ya estaban organizadas de una manera concreta según el anterior diseño de Interface de y de , podrían cambiar. Incluso puede hacer que aparezcan nuevas vistas o la forma de presentarlas ya que el número de datos ha crecido.
  7. Al mover el formulario de registro al comienzo de la App, empezaríamos a incumplir de las tiendas online de apps, que son las que finalmente aprueban o rechazan la . Pero nuestro cliente nos insiste en que lo necesita así, desestimando nuestro consejo.
  8. Por otro lado, ahora que los datos de los productos del catálogo van bajo registro, todas las llamadas internas de la app a los datos, deberán ir “securizadas” de forma que solo puedan acceder a ellas usuarios registrados. Dicha de cada una de dichas llamadas en la app deberán ser realizadas por los programadores.
  9. La interacción entre los datos de la app y el CRM requiere ahora una serie de llamadas para los datos entre ambos sistemas, que deben añadirse al código.
  10. Al cambiar el flujo de la app, el ‘’ de la misma debe remaquetarsepara que refleje el nuevo flujo solicitado.
  11. Al cambiar el flujo de la app, las deben enviarse en momentos diferentes a cómo estaban contempladas hasta ahora. Deberán reconsiderarse los de las mismas, porque puede que alguno ya no tenga sentido, así como añadir otras.
  12. Una vez acabadas las modificaciones, hay que por parte del equipo de (quality assurance) la app para comprobar que las nuevas funcionalidades y la nueva usabilidad no ha afectado al resto de funcionalidades del sistema.
  13. Toda la documentación del proyecto, así como los diagramas del mismo deberán modificarse para que reflejen el nuevo , así como la nueva distribución de los datos en las diferentes vistas.

¿Tú crees que todas las horas necesarias para llevar a cabo esto, donde intervienen tantos perfiles, el cliente espera que se lo vayamos a “regalar” y que lo hagamos gratis?. Todo esto, una vez que se le había entregado la app siguiendo las especificaciones pactadas, porque “solo en vez de pintarlo aquí hacerlo aquí con sus datos en el CRM”?.

Evidentemente, la respuesta es SÍ.

De hecho, lo más normal es que nos diga “es de sentido común”. Al fin y al cabo, solo quiere que la vista del registro en vez de verse al final, se vea al principio, nada más. Ahh, y que los datos estén en su CRM, pero tampoco debería producir un impacto importante. Igual que se ven ahí, que los envíen al CRM y listo.

Nuestro cliente no es capaz de ver dónde puede estar el problema, ni en tiempo ni en esfuerzos de que se traslade una cosa de un sitio a otro. Para él, es “simplemente que se arrastre de allí a aquí”.

qué ocurre cuando no tienes en cuenta todo lo que rodea un problema.

Puede que toda esta terminología técnica utilizada en el ejemplo anterior, no ayude a entender el problema. Para ayudar a hacerlo, vamos a trasladar el caso desde el mundo de lo intangible a la realidad tangible que nos rodea. Esto ayuda ayudará a visualizar qué ocurre cuando no tienes en cuenta todo lo que rodea un problema.

“Una reforma en el baño de la casa de nuestro cliente”.

Nuestro cliente virtual ahora ha puesto en marcha un proyecto en casa. Este consiste en reformar su baño.

Para ello, ha planteado cómo querría que quedara finalmente, y contrata a una empresa para que la lleve a cabo. Dicha empresa desarrolla unos planos, unos esquemas y unos diseños asociados a unos materiales y modelos que nuestro cliente desea.

Él es feliz con lo que ve, y aunque el presupuesto le parece un poco elevado, lo acepta porque ‘entiende’ que son mucha las ‘cosas’ que hay comprar y poner. Como todo eso lo va a poder ver y tocar con sus manos, le es más sencillo asumir y aceptar su pago. Al fin y al cabo, pensará, ha existido un trabajo previo de alguien construyendo todas esas piezas del baño, y eso tiene su coste.

Nuestro cliente visita la obra diariamente para ver cómo va. Observa cómo van llegando los nuevos azulejos, el cemento, la bañera, el lavamanos, el inodoro y materiales por todos lados. Claro, esto es lo que esperaba encontrar a cambio de lo que va a pagar. Ve obreros que van de aquí para allá trabajando, ensuciándose y sudando para terminarle su encargo.

Una vez se finaliza la obra y se le entrega, imaginemos que de repente cambia de opinión, y desea un “”. Ya sabemos que nuestro cliente no le da mucha importancia a las cosas. Así que básicamente es ‘solo’ cambiar la bañera de sitio, que en el plano “parecía” que quedaba mejor en la pared de la derecha, y “ahora que lo veo en real”, parece que me gusta más en la de la izquierda. “Solo es coger la bañera de allí y ponerla aquí. ¿A qué viene esa cara?”, pregunta ahora también.

Este cambio que le parece tan sencillo a priori, igualmente requerirá como mínimo lo siguiente:

  1. Analizar si es una buena idea, y es usable para el día a día en el baño. Puede que al salir de la bañera ahora se tropiece con el lavabo, o que al estar más cerca de los espejos, estos se estropeen con más facilidad por el agua que ahora les cae encima ya que no estaba pensado que pudiese caer agua en ese lado. Pero el cliente se empecina en que quiere cambiarla, que para eso “paga él”, así que seguimos con las cosas a tener en cuenta.
  2. Ver si efectivamente la nueva posición es factible para la bañera, y no queda muy pegada al lavabo o al inodoro. Si quedara, habría que mover algo las otras piezas del baño para que fuese usable. Vamos a suponer, que hay espacio, y que no hay que mover nada del resto del mobiliario del baño.
  3. Romper el piso y la pared donde quieres poner ahora la bañera.
  4. Ver si en el lado donde quieres la bañera ahora, pasan las tubería del agua.
  5. Si pasa el agua, comprobar que tenemos agua caliente además del agua fría.
  6. Si no hay agua o no pasa el agua caliente, hay que romper en el sitio más cercano por donde pasa, hasta el nuevo emplazamiento.
  7. Mirar que no pase instalación eléctrica cerca y si lo hace, modificarla para que sea seguro el nuevo emplazamiento de la bañera, pero que al mismo tiempo no te quedes sin el enchufe que tanto te gustaba cerca del lavamanos.
  8. Llamar al fontanero para que haga la nueva red de agua fría y caliente hasta el sitio deseado. Esto incluye tuberías y grifería.
  9. Buscar si tenemos bajantes cerca para el desagüe de la bañera.
  10. Si no lo hay, poner tubos hasta la conexión más cercana, así como un bote sifónico.
  11. Cerrar las tuberías antiguas y asegurar la instalación anterior.
  12. Una vez terminada la instalación del agua y desagüe, hay que llamar al Albañil, para que traslade la bañera, repare paredes y piso, ponga suelos nuevos y azulejos.
  13. Asimismo, debe arreglar donde estaba antes la bañera, colocando pisos y azulejos que sean iguales a los que había antes, si logras encontrarlos. Y si no, buscar la forma que se parezcan todo lo posible.
  14. Finalmente, hay que limpiar el baño retirando todos los escombros que se crearon con el cambio.

Si volvemos a plantear la pregunta anterior, ¿Tú crees que todo este trabajo añadido, el cliente espera que la empresa de reformas se lo vaya a regalar y que se lo vaya a hacer gratis una vez entregada la obra según las especificaciones requeridas, porque “solo era cambiarla de allí a aquí”?.

Evidentemente, la respuesta es NO.

De hecho, lo más normal es que aún pensando que se equivocó al poner la bañera donde está ahora, ni tan siquiera se atreva a comentarlo si no está dispuesto a pagar una buena diferencia de dinero.

En el ejemplo anterior, donde la mano de obra era mucho más cualificada, y se requerían mayores dotes de creatividad, la percepción del coste asociado era mínimo. Sin embargo en el ejemplo tangible, aún desconociendo de entrada todas las acciones que debían llevarse a cabo, nuestro cliente seguramente ni tan siquiera se hubiese atrevido a solicitarlo.

¿Y cómo arreglamos esto? No queda otra que hablar mucho, informar y explicar otro tanto, por medio de diagramas y documentos para poder al menos crearle la preocupación a nuestro cliente de que tal vez, las cosas no son tan sencillas como él había pensado.

Singular Factory Blog

The Internet Business Factory

Singular Factory

Written by

www.singularfactory.com

Singular Factory Blog

The Internet Business Factory