El rincón de JMACOE

Quizá sea difícil entender decir no al usuario, cuando sentimos que nuestro trabajo es brindar soluciones y soporte a usuarios o completar proyectos de TI, se torna difícil decir “no” a cualquier requerimiento de un usuario.  Cuando hablo de usuarios, me refiero a todas las personas que usan los recursos de TI (gerentes, usuarios finales, jefes, personal técnico, etc.) El servicio al usuario tiene la misión más difícil, la de ayudar a la gente a resolver sus problemas, y eso implica una aceptación de todos y cada uno de los requerimientos. Pero, los servicios de TI son únicos y particulares dentro del mundo del servicio al cliente.

Obviamente, el objetivo de la organización interna de TI es el de entregar soluciones informáticas y brindar soporte a los usuarios finales, y eso incluye resolver problemas y satisfacer las necesidades requeridas. Pero las organizaciones de TI tienen que servir más que a la necesidad individual de un usuario final, también tienen que servir a los intereses empresariales, a la ética profesional y a las mejores prácticas de la tecnología. Por ejemplo, los accesos a los sistemas serían mucho más simples para los usuarios sin los molestos nombres de usuarios y contraseñas, pero no se cumpliría óptimamente con los intereses de la empresa suprimiendo los sistemas de seguridad. En este tipo de situaciones, los intereses de la empresa priman por sobre los intereses de los usuarios, y Ud. necesitará decir “no”, incluso cuando esté capacitado técnicamente para satisfacer el requerimiento.

Pero los estándares y las prácticas son solamente un elemento a considerar cuando se debe decidir en aceptar o denegar un requerimiento por parte de un usuario. Quizás pueda ayudar algunas preguntas que debería responderse antes de aceptar un requerimiento o siquiera intentar negociar con el usuario.

• ¿Tiene tiempo para completar el requerimiento?
• ¿Cuenta con los recursos para completar el requerimiento?
• ¿Tiene las herramientas para completar el requerimiento?
• ¿Cuenta con las habilidades para completar el requerimiento?
• ¿Tiene la autoridad para acordar con el usuario?
• ¿Cuáles son sus compromisos anteriores?, ¿Este requerimiento presenta algún conflicto, que desplazará?
• ¿Este requerimiento se haya dentro del alcance de sus responsabilidades?
• ¿Este requerimiento agrega valor a la institución, está alineado a los objetivos de negocio?
• ¿La implementación de esté requerimiento tiene un alto esfuerzo, tiempo, costo, complejidad, riesgo que dificulte su implementación?

A pesar de la inclinación natural a ser útil, Ud. podrá necesitar decir “no”. Cuando deba negarse ante un requerimiento de un usuario, deseará hacerlo sin una rotunda objeción por parte del usuario, sin que este manifieste su descontento, eso no va a suceder y probablemente su usuario terminará alienado, generando que la próxima vez lo esquiven a Ud. o simplemente prescindan de Ud.

Entonces, aquí la cuestión es decir que “no” sin necesariamente emplear el término. Esto se puede lograr en cinco pasos:

1. 1.    Considere la fuente. Aunque pueda resultar desagradable, e incluso injusto, las políticas internas son una realidad en cualquier empresa, grande o pequeña. Antes de responder negativamente cualquier requerimiento, Ud. necesitará saber “¿Quién lo está pidiendo?”. A veces, no podrá negarse, incluso cuando la negación sea la mejor respuesta. Por otra parte, un “si” en estas circunstancias puede ser también peligroso, particularmente si realmente no se puede satisfacer el requerimiento. En estas situaciones, aún si Ud. no puede decir “no”, el consiguiente análisis seguirá valiendo la pena. Si Ud. está informado y preparado, se puede trabajar comprometidamente y buscar una orientación desde su propio jefe. Además, las limitaciones de recursos, cada “sí” a estos requerimientos pueden generar un “no” a otros, entonces deberá estar preparado para justificar y reprogramar sus otros compromisos.
2. 2.    Escuche el requerimiento. Si desea responder adecuadamente, es importante que haya comprendido enteramente la naturaleza y especificaciones del requerimiento, ¿Se relaciona a un problema de servicio o a algún otro tema? Si rechaza un requerimiento sin comprender completamente sus partes y orígenes, correrá el riesgo de pasar vergüenza en una próxima comunicación.
3. 3.    Evalúe el requerimiento. Empleando las preguntas listadas arriba, necesitará evaluar el requerimiento a fin de determinar si es posible su aceptación y solución o determinar su negación. Su análisis deberá contemplar las políticas de la empresa, las prioridades actuales, el tiempo disponible, los recursos, habilidades y otros temas relacionados.
4. 4.    Desarrolle su respuesta. Basándose en la naturaleza del requerimiento y su análisis desarrollar una respuesta. Sus respuestas pueden encajar en una de relacionado, necesitará las siguientes cuatro categorías:
   • Un «si» (Se compromete al requerimiento).
   • Un «no» con una explicación (No puedo completar este requerimiento y es porque…).
   • Un compromiso (alguna alternativa al requerimiento inicial).
   • Una derivación (el nombre de un recurso alternativo de asistencia)

   Si Ud. debe rechazar un requerimiento, deberá estar preparado para justificar esa decisión. De esta manera, las razones para el rechazo toman prioridad por encima de la negación en sí misma. Si está por decir “no” sin una explicación, será difícil justificarse o defender su posición posteriormente. Además, su trabajo es servir a la empresa y a sus usuarios, si Ud. rechaza requerimientos sin razones factibles, difícilmente se mantendrá en su puesto por mucho más tiempo.

5. 5.    Ofrezca su explicación. Una vez que haya desarrollado su respuesta, comienza la parte más difícil, debe hacérselo saber a su usuario. Cómo elija comunicar su respuesta dependerá de varios factores: la naturaleza del requerimiento (formal o informal), la persona que realiza el requerimiento, su relación con esa persona, la sensibilidad de su respuesta, y la cultura de su empresa. Podrá elegir en efectuar su respuesta en persona, por teléfono, vía correo electrónico, por escrito, o alguna combinación entre ellas.

   Cualquiera que sea el mecanismo que emplee, deberá seguir siempre unas pocas técnicas básicas:

   • No esté a la defensiva o pida demasiadas disculpas. Simplemente exponga que lamenta no poder satisfacer el requerimiento en esta oportunidad, y ofrezca sus razones(por ejemplo, problemas de programación, conflictos con las políticas internas, conflictos con otros planes o proyectos, etc.). Ponga énfasis en la razón y no en la negación.
   • Intente ser lo más positivo posible, enfocándose en los compromisos o alternativas que pueda ofrecer.

   Siempre deje abierta la posibilidad para una salida elegante. Su usuario puede ofrecer una alternativa propia, señalar un error en su análisis, o puede reaccionar negativamente ante su respuesta. De ser necesario, permítase una vía para “re-pensar” el asunto y así podrá buscar asistencia de su jefe antes de que las cosas se pongan feas. Se puede conseguir esto con un simple “si tiene alguna pregunta, o siente que no comprendí correctamente su requerimiento, por favor hágamelo saber”. Transmítale al usuario la sensación de que no le ha cerrado la puerta en la cara.

Ayúdese Ud. mismo

No cabe duda de que el acto de rechazar un requerimiento de un usuario pueda resultar difícil y estresante, y de que requiere la exacta combinación de comunicación y habilidades interpersonales para llevarlo a cabo. Pero también puede tomar pasos pro-activos para facilitar este proceso:

1. Busque consejo y orientación de su Jefe/Supervisor cada vez que sea necesario. Por lo menos, es sabio darle alertas de aviso a su Jefe, si un problema (por ejemplo, un usuario insatisfecho) está perturbando el trabajo. Además, no tiene sentido cargar con el peso de una decisión difícil sobre sus hombros si no es necesario que lo haga.
2. Establezca procedimientos y formatos estructurados para los envíos de requerimientos de parte de los usuarios. Podrá sorprenderse en cuanto a cómo cambiará la calidad y cantidad de las requerimientos, cuando los mismos deben estar por escrito y organizados. Además, si establece y refuerza un proceso estructurado para los requerimientos de los usuarios, podrá disminuir el tipo de requerimiento inconsistente, que es tan fácil de olvidar y que puede llegar a meterlo en líos (Por ejemplo, cuando los usuarios ven a un integrante del área de soporte caminando y le piden que se acerque para solicitar asistencia, sin llamar como corresponde al Servicio de Atención al Usuario). Si bien sus usuarios pueden resistirse, con un poco de esfuerzo es fácil justificar un proceso estructurado de requerimientos, como un medio de mejora de los servicios de TI.
3. Manténgase, tanto Ud. como el grupo de TI, tan organizado como le sea posible para aprovechar al máximo la disponibilidad de tiempo y poder programar y priorizar su carga laboral de manera efectiva.

En resumen, la naturaleza del servicio al usuario es la de servir, y no es fácil decir que no. Pero el reto en TI reside en equilibrar la necesidad de asistir a múltiples usuarios con la necesidad de cumplir con las prioridades globales de la empresa y satisfacer sus intereses. A menudo se requiere de un “no” para llegar a esa meta.

Autor: El informan

Blogs similares