El amigo informático III: Situaciones donde quedar comprometido

Continuamos con la serie de artículos sobre el amigo informático. En números pasados hablamos de las causas de la indignación y evaluar la probabilidad de reciprocidad para el retorno del favor según el tipo de persona. En esta ocasión hablaremos de situaciones muy frecuentes para quedar en compromiso o, como se dice comúnmente, quedar pringado.

Nuevamente me gustaría mencionar que el hecho de quedar pringado con trabajo no deseado y muchas veces gratis, no es algo exclusivo de nuestro sector. En todo tipo de profesionales existe la necesidad de quedar bien, la imagen y que otras personas una visión positiva de nosotros.

Os imagináis después de un concierto de música el público aclame “¡Otra!, ¡Otra!, ¡Otra!” y el cantante diga por el micrófono “Iros a vuestra casa. ¡¡Gorrones!!”. :). En muchos sectores ocurriren situaciones parecidas: “Restaurantes que tienen que cerrar tarde porque un grupo se queda de cháchara”, “Transportistas en que se les hace desplazarse a sitios fuera de su ruta” y así un largo etcétera.

La probabilidad de quedar pringado viene aparejada con la incertidumbre de la conclusión de un trabajo. Cuando un trabajo es predecible, monótono y fácilmente cuantificable, es fácil deducir cuanto cuesta hacer algo y cuando se va a acabar.

Sin embargo, cuando una tarea es diversa, multidisciplinar y variada es muy complicado predecir o estimar cuanto cuesta algo. La incertidumbre de una profesión es el ingrediente esencial para quedar pringado incluso por acciones realizadas por uno mismo.

Esta incertidumbre nos la encontramos principalmente en cosas complejas. Un ordenador o un sistema puede llegar a ser todo lo complejo que tu quieras. La imaginación muchas veces no tiene límite para darle un poco más al ordenador. Si quieres evitar acabar pringado realizando una tarea durante todo un día cuando inicialmente pensabas que era 1 hora, haz las cosas fáciles.

Pero en otras ocasiones depende también del usuario final. Si se utiliza el ordenador de una manera irresponsable, instalando todo lo que encuentra o realizando tareas que no debe, más le vale que se tengan altos conocimientos de informática o tenga un amigo informático paciente.

A continuación vamos a ver formas comunes de quedar pringado con tareas y favores que se podrían haber evitado. En esta selección voy a poner tareas tanto de informática general como, ya que este portal habla de programación, sobre desarrollo de software.

Formatear e instalar un sistema operativo al amigo

La primera tarea que, para la cual solicitan tus conocimientos de informático, es la de instalar un sistema operativo. A veces habría que decir: “Si lo que quieres es borrar el disco duro e instalarlo, inténtalo tu mismo. Si te equivocas siempre puedes volver a intentarlo”.

Lamentablemente, cuando aceptas una tarea así normalmente te tienes que desplazar para estar 1 hora para pulsar unos 4 o 5 botones con la palabra “siguiente” y el resto será mirar una barra de progreso. Por favor, si traes a un informático para esto, llena la nevera de cervezas.

En bastantes ocasiones se pide algo más. “Quiero todo tipo de programas para hacer cosas”. Ya que estamos, vamos a dejarle el ordenador con programas para que haga cosas. Intenta instalarle siempre programas que ya conozca el usuario y haya utilizado antes.

Si instalas programas que el usuario no haya utilizado antes o no sepa utilizar corres el riesgo de que el trabajo de instalación se extienda a un trabajo de capacitación en el que tendrás que enseñar al usuario a utilizar los programas incluso en tiempo indefinido: “Hola. ¿Te acuerdas del programa que me instalaste el mes pasado?. Pues he traído una lista de una serie de botones que necesito que me expliques.”

Consultas sobre el uso del ordenador

Suele ocurrir que la tarea no se queda cuando acabas de instalar el sistema. Las consultas durante el uso del sistema o de programas son también frecuentes. En estos casos, suele ser habituales que el usuario se desplace o te llame por teléfono para que le vayas explicando que debe hacer o donde debe pulsar. Esto no es un problema … excepto cuando no entiende nada de lo que le estás contando. En ese último caso una consulta de 10 minutos se puede alargar 1 hora.

También, a modo de curiosidad, se puede dar el divertido juego de “las adivinanzas por secuencia”. Esto consiste en adivinar que le pasa conociendo únicamente el texto del botón que ha pulsado y donde estaba ubicado el mensaje sin conocer lo que dice el mensaje.

“Oye. Me ha salido un mensaje muy raro en la parte de abajo y he pulsado el botón Aceptar. Después me ha salido otro y he pulsado Si. Luego me ha salido el reloj y me ha vuelto a aparecer un mensaje …”. Entonces preguntas: “¿Que ponía en los mensajes?” y te contestan “No sé. Cosas muy raras”.

Requisitos indeterminados

Como comenté en el primer post, uno de los problemas consiste en no definir el trabajo que vas a realizar. Cuando algo se convierte en un buffet libre de solicitud de funcionalidades, la imaginación y las ideas pueden llegar a ser infinitas porque sencillamente son gratis. Definir que haces y que desarrollas es fundamental para un trabajo salubre. Aceptar unos halagos y tener que demostrar que eres el superman de la programación te llevará a tener que hacer muchas horas gratis. Ser profesional no es ser Dios.

Otra situación en la que se da por supuestos los requisitos son en las comparaciones. Escuchar frases del tipo “esto es posible hacerse porque lo hace la aplicación X” o “que tu aplicación tenga que tener esto es de sentido común” suelen ser habituales. El problema está en que es para el usuario el “sentido común”. Seguramente el usuario lleve utilizando una aplicación desde hace ya algunos años y al cambiar a otra aplicación de por hecho que las cosas se hacen de un modo determinado que no encaja en tu aplicación.

Tanto de un modo como del otro he visto desde usuarios que han tenido que echarle muchas horas teniendo que aprender cosas de su tiempo libre tan solo porque en otra aplicación utilizaban funcionalidades que tu no deseabas poner en la aplicación y no las conocías hasta aplicaciones de escritorio y Web que tenían que “emular” la forma de trabajar de aplicaciones hechas en MS-Dos con los problemas innecesarios que ello conlleva.

Responsabilidad entre múltiples empresas, equipos y personas

Pero en el desarrollo de grandes sistemas también nos encontramos con un caso también molesto que consiste en trabajar entre diferentes equipos que por supuesto tienen cierta presión para entregar en plazos, cumplir errores, etc. En ese caso, es habitual que entre diferentes empresas o equipos las responsabilidades de los problemas se los echen los unos a los otros como si fueran políticos.

Suele ser habitual que finalmente recaiga el trabajo para comprobar el problema al que es más colaborativo o al informático que tienen más a mano aunque el problema no tenga que ver con su trabajo. Esto ocurre más en sistemas distribuidos o recursos compartidos donde el error de uno perjudica a otro. También nos encontramos el caso de usuarios que realizan inserciones o apuntes erróneos y finalmente se le echa la culpa al programa. Lo curiosos de esto es que lo que realmente cuesta hacer el trabajo no es el corregirlo, sino el localizarlo.

Plazos de vértigo o que exista carácter de urgencia

Otros de los motivos que de estar hasta arriba de trabajo es aceptar plazos que reflejan más las necesidades del cliente que la realidad técnica de hacer ese trabajo. Es un grave error que personas que no conocen como se realiza un trabajo se comprometan a establecer horas a un trabajo o incluso establezcan un planning “a ciegas”. Cuando se estima algo es muy importante conocer el trabajo que se va a realizar, el riesgo o incertidumbre que tiene ese trabajo y los conocimientos y aptitudes que disponen las personas que realizan ese trabajo.

Curiosamente, con frecuencia ocurre es lo contrario. En grandes proyectos primero hay un compromiso de plazos y después se buscan las personas. Por ello, es habitual pillarse los dedos con este tipo de cosas. Podrás encontrar proyectos así si cuando entras a una entrevista de trabajo te dicen que te necesitan ya y no pueden esperar. En ese caso, me lo pensaría dos veces.

Igualmente puede darse el caso de que algo tenga carácter de urgencia. En la mayoría de los casos esa urgencia no lo es tal ya que si se llega a cierta situación de urgencia puede ser por no haber hecho algo en el pasado o por no desear que se realicen las cosas en los plazos necesarios. Las situaciones de urgencia son situaciones provocadas de accidentes que tienen consecuencias graves. Muchas tareas catalogadas como urgentes no lo son.

Cuidado con el movil

Una ultima situación para que en cualquier momento te recuerden tus capacitaciones y tus conocimientos de informático es la de estar localizable constantemente para estos amigos que necesitan ayuda. Es importante, separar quien realmente tiene debe tener un movil y quien te lo solicita por si tienen algún problema con el ordenador. En caso contrario tendrás de dejar de hacer cualquier cosa para atender consultas.

Conclusión

Con todo ello, aquí tenéis algunos casos en los que bien por una mala planificación tanto en plazos como en tareas, desear aparentar tener conocimientos que no se tienen o desconocimiento del usuario, existen situaciones en los que uno mismo puede quedar comprometido a realizar un trabajo que no se tenía previsto.

Finalmente, en el próximo número acabaremos esta serie de artículos comentando algunas formas de decir NO.

En Genbeta Dev | El amigo informático I: Causas de la indignación en el sector informático
En Genbeta Dev | El amigo informático II: Tipos de personas necesitadas

Portada de Genbeta