PM Mex Corner

En las organizaciones que se han dado a la tarea a profesionalizar y mejorar sus áreas de TI, se han implantado o se está implantando mejores prácticas de gestión de la TI, tal como ITIL, dentro de este marco, es común observar que se empieza por la implantación de los procesos de Service desk y gestión de las operaciones, lo cual es lo recomendado por diversos consultores, sin embargo es común encontrar que el rey de la colina es el proceso de gestión de incidentes, es decir, es el proceso del que más se escucha y en el que todos tienen algo que ver, llegando con frecuencia a hacerse un abuso y mal uso del dicho proceso, donde todo lo que pasa en el área de sistemas es tratado como si fuera un incidente.

Bob Fearman en su artículo “ITIL: Dangers of Treating Everything as an Incident”  ( http://www.pmhut.com/itil-dangers-of-treating-everything-as-an-incident ) menciona que una causa de este fenómeno es el quererse ahorrar las licencias de los módulos de gestión de solicitudes y gestión de problemas de las herramientas de software que se emplean para auxiliar los procesos ITIL; sin embargo, esa no es precisamente siempre la explicación del fenómeno.

La gestión de incidentes es como un incendio y el profesional de la TI que lo resuelve es como el  bombero,  se siente muy bonito ser reconocido como “él bombero héroe” que apagó el incendio. Más sobre todo en tiempos de turbulencia en la empresa, de recortes y de adversidad económica, es muy confortable sentir que la organización tiene alguna deuda de agradecimiento para con uno, por haber apagado este y/o varios incendios. Es la forma en que uno puede hacerse de algún confort de estabilidad laboral. El problema echa raíces cuando en efecto la Organización reconoce al profesional que apagó los incendios, recompensándolo de alguna manera, y no me refiero a que no debe ser reconocido en lo absoluto, pero al fin y al cabo ese era precisamente su función, no hacerla, no intervenir para apagar el incendio, hubiera sido una falta. Pero cuando la organización privilegia o protege de manera especial al profesional que esta apagando los incendios, entonces todos los demás comprenden muy rápido el mensaje: “Debemos apagar incendios para recibir el mismo premio o la misma protección”.

De repente todo es un incidente:  …hay que crear una cuenta de correo?… es un incidente, ya que la cuenta es para un alto funcionario de la organización y no debemos dilatarnos…. Hay que hacer un reporte del consumo en llamadas telefónicas?…. es un incidente, ya que debe llegar rápidamente a manos del funcionario que lo solicita pues tomará decisiones importantísimas… Todos los profesionales de TI se vuelven héroes, todos atendiendo incidentes, como si de un partido de futbol se tratara y todos, incluido el portero corren simultáneamente tras el balón en búsqueda de ser el que mete el gol.

Y qué pasa si por algún tiempo, …angustiante, no hay incidentes?… ese es el momento de quiebre de una organización, ya que si, por alguna condenada tentación un profesional que se sienta en peligro de recorte o mal reconocido, es débil y decide consciente o inconscientemente no ejecutar un proceso, se hace de la vista gorda y … no atiende una alarma de un equipo que sólo él sabe usar… se tendrá un incidente,  Bendito incidente!, ya que con toda oportunidad el profesional apaga el fuego y voila!… hay un nuevo héroe… o se han actualizado sus credenciales de héroe. Para que se le considere en su evaluación de desempeño… al menos que sirva para que la organización comprenda que le iría muy mal sin la presencia del héroe en su nomina…  El secuestro de la Organización!

En muchos casos, la actitud de asegurarse una estabilidad en la empresa por medio del “Secuestro de la organización”, va a extremos tales como la inclusión intencional de código en los sistemas de la empresa, que ocasionará fallas continuas intencionales, y que requiera la intervención del profesional que insertó el código, para que se libre la falla y el sistema pueda seguir funcionando… hay muchas variantes de esta artimañita, teniendo común denominador , la necesidad de contar con el profesional que ocasiona y/o permite la falla para que los sistemas puedan seguir funcionando.

Es fenómeno de la “organización secuestrada” se da fácilmente cuando en esta, las áreas usuarias piensan que la TI es muy complicada y deciden que no quieren ni deben enterarse de lo que pasa en TI, y solo esperan que alguien lo resuelva. En ocasiones, cuando el área de sistemas es tan grande o tiene sistemas tan sofisticados, esta actitud de no querer ni tener que enterarse, también se observa incluso entre los altos funcionarios de  las mismas áreas de TI.

No quiere decir que los procesos alineados a ITIL tengan una debilidad especial que permita estas malas prácticas, ya que estas se dan con o sin procesos ITIL, sin embargo es muy revelador ver lo que se está catalogando como incidente, una vez que una organización intenta establecer procesos ITIL. De hecho, poder detectar malas prácticas es uno de los beneficios den instrumentar ITIL y con esto, mayor transparencia en la gestión de la TI.

Los supervisores de la TI, ya sea gerentes de la TI, directores del área de sistemas, los auditores internos e incluso los auditores externos, debe prestar mucha atención para detectar la continua aparición del caso del bombero pirómano en las organizaciones de TI. Una forma de hacerlo, es tener una buena formación y criterio con respecto a que conviene que sea catalogado como incidente y porque, y que cosa debiera ser tratado mejor bajo el flujo de procesos de gestión de requerimientos, gestión de problemas y/o de mantenimiento preventivo.

Otra forma de detectar la existencia y el vicio de Todo-es-un-incidente en el área de TI, es vigilar continuamente los reportes históricos de incidentes, para detectar casos repetitivos donde surgen continuos incidentes derivados de la misma causa, si esto se detecta, se podría estar ante la presencia de uno de esos hechos en los cuales los profesionales de la TI hacen de la vista gorda, y no reparan los problemas de raíz, para tener incidentes garantizados que atender en el futuro.

Claro está, que un mejor método para evitar o disminuir el fenómeno del bombero pirómano, es eliminar o reducir las circunstancias que lo generan, por ejemplo, teniendo un fuerte programa de comunicación de cultura empresarial; una planeación estratégica de TI que le dé a todos un sentido de pertenecía y le permita a los profesionales identificar su importancia en los objetivos por cumplir; un proceso sólido de evaluación objetiva del desempeño con acciones concretas para sumar al área de sistemas los mejores elementos disponibles y dejar ir a los que ya no se sientan satisfechos con la organización; un proceso formal y sólido de capacitación a todos los niveles, incluidos y sobre todos a los supervisores, gerentes y directivos; un sólido proceso de supervisión; En resumen, buscar que la gestión de la TI sea una comprometida con la excelencia y con los resultados, en los hechos y no solo en las palabras.

Recientemente leí un libro muy interesante para la práctica de gestión de proyectos; se trata de “Las 5 disfunciones de un equipo” de Patrick Lencioni. Los proyectos son ejecutados por medio de equipos de personas. A mejores equipos, mejores proyectos y mejores organizaciones.
El autor nos expone de manera secuencial, los 5 problemas que a su juicio, afectan la capacidad de trabajar en equipo, y por tanto sus resultados. Dichas problemas o disfunciones se exponen a continuación:

– PRIMERA: Ausencia de confianza entre los miembros del equipo – Lo que provoca que los temas importantes no se discutan; que se actúe presuponiendo el punto de vista de los demás, pero sin preguntárselo. A la defensiva y sin cooperación.

Se expone que la confianza no es algo que se genere por medio de un decreto, ni por medio de políticas de empresa, ni mucho menos en los estatutos del proyecto; La confianza se gana, y es un trabajo de dos vías, pero sobre todo, la confianza se promueve desde la posición de liderazgo de un equipo. Si el líder no cultiva la confianza entre los miembros del equipo, es poco probable que esta confianza se instale por sí misma.

– SEGUNDA: Miedo y renuencia a enfrentarse en conflicto – El no haber confianza, los temas no se discuten abiertamente, por lo que no se suman las riquezas de conocimientos y opiniones que los demás tienen de los asuntos en conflicto. En un grupo asertivo, los conflictos se enfrentan y discuten, sin acudir a golpes bajos, sin agredir personalmente al contrincante, pero si luchando con las ideas y postulados, como si de un juicio legal se tratara.

La apariencia artificial y nociva de armonía se encuentra muy ligada a la ausencia de confianza, y ambas tiene raíz en la ausencia de certidumbre del trabajo de la persona en la organización; es decir, cuando la dirección y/o el líder son inmaduros, tratan las diferencias de opinión como problemas de “ajustes al equipo” y por tanto se cuestiona la permanencia de quien tiene las ideas diferentes o enfrentadas, como si un problema de alineación se tratara. Esta mala gestión de las diferencias de opinión, son destructivas de la creatividad y de la construcción de equipos. El líder tiene una responsabilidad importantísima y principal en saber reconocer que cosa es un conflicto constructivo y que cosa obedece más a una insubordinación (lo que sería un problema de alineación), el fallo de juicio del líder puede traer consecuencias desastrosas para el proyecto y la organización.

– TERCERA: Ausencia de compromiso – Al rehuirse el conflicto, los miembros no tienen los elementos suficientes para tomar decisiones, y solo siguen la instrucción del superior, pero sin compromiso, con la actitud de “Es lo que pidió el jefe; está mal, pero no seré yo quien lo enfrente, así que cuando la cosa falle, no será mi culpa, sino la del jefe”.
La ausencia de compromiso también se observa en un pobre compromiso con las decisiones que uno mismo toma en el equipo, pues existe una inseguridad (por falta de discusión) que provoca arrepentimientos continuos de lo decidido, en un vaivén de decisiones, que no construyen sino que solo generan más inestabilidad y ambigüedad en los proyectos; de hecho, la existencia de un Plan de gestión del proyecto, los estatutos del mismo y el plan de gestión de cambios en el proyecto, son mecanismos importantísimos y principales para luchar contra problemas de bajo compromiso con las decisiones en un proyecto.

– CUARTA: Evasión de responsabilidades – Al existir poco compromiso con las decisiones, y mucha ambigüedad con lo decidió, la gente tiende a rehuir todo contacto y obligación para con dichas decisiones. La ambigüedad y el miedo al conflicto nos impiden el cuidar y exigir que todos los involucrados en las decisiones ejecuten su parte.

Cuando el equipo se comparta de manera sana, todos y cada uno de los miembros del equipo, preguntan a los demás sobre sus avances, problemas y asuntos donde requieran ayuda sin esperar a que esta supervisión la ejecute de manera exclusiva el líder. Es como en los equipos deportivos, todos exigimos a nuestros compañeros, que ejecuten su posición de juego inteligente y oportunamente, so pena de que el equipo entera pierda. El objetivo superior y común, que es el triunfo del equipo, nos da la autoridad y la responsabilidad de monitorear el buen desempeño no solo de nosotros mismos, sino el de los demás en el equipo.

– QUINTA: Fallas en la búsqueda de resultados grupales – Como existe evasión de responsabilidades, la gente tiende a luchar exclusivamente por sus posiciones personales, reuniendo evidencias que la ejecución individual es correcta aunque todos los demás estén haciendo todo equivocado, decimos: “es su problema de ellos”, “son decisiones que no compartimos, no tenemos compromiso con ellas”.
En un equipo sano, prevalece el interés del grupo sobre el individual, se busca el gol del gane, sea quien sea que lo meta, y para ellos todos luchan principalmente primero por ganar el partido, y después por tener buenas estadísticas individuales en el juego.

En realidad, muy buen libro, ya que trata que podemos observar con mucha facilidad en cualquier entorno laboral (y extra laboral), y expone temas mucho más profundo que el simplista: “Échale ganas”, o el “Acepta el cambio aunque te partan tu queso”. Nos expone en cambio, un tema muy humano que es una herramienta principal que no debiéramos asegurar que fueran parte del bagaje básico de todo líder de empresa, y de todo gestor de proyectos.

– Una SEXTA disfunción consecuencia inevitable cuando existen las primero cinco, es la Des motivación generalizada del staff. Los profesionales no encuentran sentido a las labores y luchas diarias, pues al final de cuentas, cada uno lucha por sus intereses individuales, bien podrían hacerlo desde sus casas y sin conectarse con nadie… algo muy distante a lo que nuestra naturaleza humana gregaria exige. Es en la desmotivación que aparecen nuestros propios infiernos, generados por nosotros mismos, acusando y culpabilizando a todos a nuestro alrededor, de la naturaleza lamentable de las cosas; como si culpar al otro fuera suficiente para limpiarnos de toda culpa propia, por no haber comprendido nuestras fallas individuales de trabajo en equipo.

Nota: Encuentro a las tiras cómicas “Dilbert” de Scott Adams, como una parodia muy efectiva, de lo que sucede en el mundo corporativo.

Malas noticias,  hacer Scrum no es sinónimo de trabajar sin burocracia….   Al contrario de lo que se puede pensar cuando se conoce muy poco de Scrum. Scrum es un método de desarrollo de sistemas, que no reduce la carga burocrática del tradicional método de desarrollo en cascada.

En realidad, el Scrum es sólo un método para trabajar las necesidades del Cliente/Usuario de manera tal que su ansiedad disminuya… o en palabras de los Scrum Masters… “Que obtenga los mayores beneficios en el menor tiempo posible”,  sin soslayar los beneficios de poder obtener rápida retro alimentación y con esto encausar de mejor manera el resto del desarrollo.  Pero no por ello, se dejan de levantar requerimientos, ni tampoco tienen porque ser meno detallados. El usuario, de cualquier manera los debe firmar (hacerse responsable de lo que pide); de cualquier manera existe una gestión de backlog que es incluso más extensiva y burocrática que la Gestión de cambios de un proyecto tradicional en cascada.

Escuché a un alto ejecutivo argumentar: “A mí me gusta más ese método de desarrollo ágil, porque cuando usan ese método, puedo pedir lo que quiera, en el momento que quiera y no me van a salir con eso de que “Esta fuera de alcance”  “.

Creo que hay un error en esta concepción,  ya que todo lo que pida el usuario, fuera del tiempo calendarizado para recabar los requerimientos específicos de una  función, estará siempre fuera de alcance, independientemente del método que se emplee de desarrollo. Lo mejor que puede hacerse, es colocar el requerimiento en el siguiente sprint…   Todo lo que se pida costará, nada es gratis, y en la medida que se pida y descubran las cosas de la manera más ordenada posible, en esa medida el producto final gozará de mayor calidad y menor costo.

Es una cuestión de equilibrio entre que tanto permitir un descubrimiento evolutivo y que tanto congelar un requerimiento y una arquitectura para hacerlo más sustentable.  En la medida que se tenga la totalidad del requerimiento  desde el inicio, en esa medida se podrá asegurar una mejor arquitectura resistente al paso del tiempo y de los cambios…  pero al congelar todo el requerimiento en un solo paso (un sprint),  no gozaremos de la retro alimentación práctica del funcionamiento del sistema en la vida real (en producción).

En realidad no hay ningún proyecto que pueda definirse  en un solo paso, pues todo sistema o producto derivado de un proyecto, entrará en una etapa operativa, donde se recibirán cambios, mantenimientos y evolución.  Es decir, tendrá “raleases”.

Pero por otro lado, permitir una libertad total en la toma de requerimientos, es decir, permitir vacilaciones, requerimientos contradictorios, especificaciones insuficientes, puede llevar al producto a una inestabilidad tan seria, que lo vuelva insostenible, in-mantenible y muchas veces inoperable. Algo así como una favela que aunque funciona, su funcionamiento no es sostenible y la calidad de vida ínfima.  No todo tiene que ser un Champs elysee..  El punto es planear y acordar de antemano con el Cliente/usuario cual será la morfología (Favela o Champs elysee, o que tanto de uno y que tanto del otro) del producto deseado considerando su tiempo total de vida; Desde su concepción, incluyendo operación, su retiro y sustitución. Este acuerdo tiene implicaciones de tiempos, costos y entrega de beneficios; es parte del “Business case”.

Hay quienes prefieren un método ágil, como medida para mitigar el riesgo de que se construya algo muy alejado de lo especificado por el usuario, pero esta aproximación es sólo una manera de formalizar un método sucio de trabajo, de prueba y error. No hay cura contra una especificación deficiente, ya sea porque el usuario no ha sabido especificar o el analista.  En otras ocasiones, es el usuario el que no sabe lo que quiere y prefiere no tener que comprometerse con especificaciones de gran alcance y se conforma con ir pidiendo según la necesidad del día a día, es decir, desarrollo a base de bomberazos.. eso definitivamente no es Scrum.

Scrum tiene muchos beneficios,  pero librarse de la burocracia y de enfrentar todos los requerimientos expuesto por PMBOK no es uno de ellos.

De todas maneras se debe hacer una gestión de Tiempos, Costos, Alcance, Recurso, Calidad, Riesgos, Interesados, Comunicaciones y de todas maneras existe una línea base que debe administrarse. En Scrum se llama Backlog y “Árbol de características / funcionalidades”.

Aún no cambio de opinión, para poder hacer Scrum de manera responsable, primero se debe saber hacer proyectos según PMBOK.

Para más información, les recomiendo este excelente artículo de Joy Beatty and Candase Hokanson ->   RequirementsinAgileWhitepaper1

Autor: Humberto Ramos  ( [email protected] )
PMI Capítulo México, Comunicaciones Digitales

I have been always interested in Leadership topics. I have read many books about leadership and taken many courses about the same topic.

I truly believe that, when leadership is discussed, one of the most important aspects of a leader is related to maturity: the maturity of the leader.

How mature is the leader of a team? Maturity is not measure by the age of the leader, neither by his / her expertise or look.

Maturity is a combination of factors: attitude, skills, learning, education; but it is also a matter of values: honesty, respect, humbleness, loyalty.

Therefore, a leader might be very skilled but if he / she is not honest, then cannot be considered a mature leader.

And I want to emphasize the importance of having mature leaders in a company; usually, when a leader lacks of maturity, he / she creates and participates in fraudulent or illegal situations that affect the company’s interest. Therefore, “honesty” is one of the principal values of a mature leader.

Thru my work experience and what I have seen in the many different companies where I have worked either as a consultant or as an auditor, this is what I have noticed regarding mature leaders:

1. Mature leaders want to build teams. Immature leaders want to build flocks.

This is clear and does not need further comments. Flocks are easier to control and manage; and do not require great knowledge, skills or values. You just need a stick and a loud voice.

2. Mature leaders hire talent while immature leaders hire friends.

An immature leader builds a team based in friendship and favors. This is like a “mafia style”. So talent is not important. An immature leader is looking for “friends” who can return him/her favors when he/she is in troubles.

3. Mature leaders clearly define strategies and action plans to be followed by the team. Immature leaders feel comfortable with the team acting on an “ad hoc” basis.

Immature leaders feel comfortable with the chaos and confusion that the “ad hoc” basis style creates, because if nothing is formally defined, then they feel they have no accountabilities and they can get rid of difficult situations blaming others instead of facing those as a team.

4. Mature leaders take ideas when the subordinates have different opinions from theirs. Immature leaders take retaliation when a different opinion is brought by any subordinate.

This is very common from an immature leader: whenever something different from his / her opinion is said or suggested, retaliation will be taken. Again, this is because the leader feels threaten with a different idea or opinion.

5. Mature leaders have healthy and professional discussions with the subordinates to benefit the team. Immature leaders try to defeat the subordinates to get the false sense of winning.

An immature leader cannot stand healthy discussions with the subordinates and gets into discussions to beat and humiliate subordinates. Immature Leaders are passive violent aggressors when it comes to hold discussions. At the bottom, the immature leader has the intense need to feel superior and this is accomplished by causing fear.

6. Mature leaders feel proud of the team’s accomplishments. Immature leaders feel threaten by the team’s accomplishments.

An immature leader feels threaten by talented subordinates. As a result, immature leaders will try to hide any team’s accomplishments; even will impede the subordinates to improve their skills. Immature leaders will also “steal” the team’s accomplishments, showing them as theirs. To the eyes of the others, the leader will expose himself / herself as the talented piece of the team.

7. Mature leaders motivate communication to flow in different ways. Immature leaders block communication.

I have noticed in many cases that immature leaders prohibit their subordinates to communicate with other leaders or teams; sometimes they even create communication gaps to have a false sense of control. Immature leaders feel comfortable with these communication gaps and do not like to clear things up.

This is a great one for the season:

8. A Mature leader goes to the Christmas social events, spends a couple of hours with the team, and makes a toast. An immature leader goes to the Christmas social events, stays until the end and the subordinates have to take him/her home because is too drunk to drive.

And just to think about:

• What are the behaviors that you have noticed from mature and immature leaders?
• What behaviors do you have as a leader?
• Are you a mature or an immature leader?

Adriana Acosta, CISA, CISM, CRISC, COP, ISO27000, TOGAF practitioner
Mexican Experienced Consultant and Auditor
Works for a leader financial institution; in a Latin American regional responsibility position

Uno de los conceptos menos homogéneo en nuestra profesión es el de la “PMO”.  Para unos es el acrónimo de la “Project Management Office”, para otros es la “Program Management Office”,  para otros más es la “Portfolio Management Office”. Las funciones que desempeña son aún más variadas, desde entes administrativos que se dedican a recabar los reportes de avance de los diferentes Project Managers, hasta una entidad dedicada a hacer reportes por sí misma.

Algunas versiones de PMO agregan mucho valor a la cadena de valor de la empresa en que está inmersa, otros no tanto, algunas otras lamentamos observar, restan valor.

En parte este fenómeno acontece derivado de la misma juventud del concepto de PMO. Pero también en parte se debe a que, un ente que mete control, orden, procedimientos y metodología, no siempre es muy bien aceptada en organizaciones que prefieren métodos de gestión del pasado, métodos de “carisma y tradición”, basados en las ocurrencias y caprichos que vaya teniendo el jefe en cada momento.

Se les conoce como métodos de “Carisma y tradición” ya que los proyectos se logran por el carisma de las personas, por su capacidad de convencer a los demás y  siguiendo las formas “como siempre se han hecho aquí las cosas”.  Es decir, no hay procedimientos formales, y el éxito depende exclusivamente de las habilidades de los individuos involucrados y no de la organización.

Sin embargo, muchas de las aversiones que se observan al respecto de la existencia y funcionamiento de una PMO, los ocasionan las mismas PMO. Las personas detectan con gran velocidad, si una ente organizativa agrega valor, o solo agrega formularios que llenar y reporte que entregar.  Si una PMO es observada como un ente destructor de valor, y no una que agregue el valor, la resistencia de toda la organización la tendrá asegurada. Lo peor es que una PMO así,  adicionalmente estará contribuyendo a generar una mala imagen del concepto de PMO en la industria en general.

A mí me gusta más la versión de la PMO que se encuentra en el frente de batalla, respondiendo por los resultados, avances y problemas en los proyectos de manera directa con el cliente y usuarios de los proyectos.  No me gusta nada la PMO que se esconde en el Corporativo tras puerta cerrada, que no da la cara al cliente.

La PMO “accountable”, es aquella que asume directamente toda la responsabilidad por el estado de salud, de avance o atraso en la que se encuentren los proyectos bajo su gestión.  Esta versión de PMO, no concentra sus energías en perseguir el rellenado de formatos y validar el cumplimiento de metodologías.  Más bien, concentra su atención en entregar valor al cliente y usuario final.  En esta versión de PMO, la metodología se usa para asegurar consistencia y calidad de resultados ante el cliente final y no solo para demostrar cumplimiento ante alguien más. Este tipo de actitud es la que permite mostrar valor, es decir, a todos quedara claro el valor  que la PMO entrega a la organización.

Una PMO “accountable” se encontrará ampliamente motivada en cortar todo tipo de trabajo que no genere valor, ya que sería desperdiciar recursos en cosas que no aportan en la entrega de resultados al cliente.  La PMO al tener que dar la cara y responder por los resultados, no se puede esconder tras la “reportitis”, pues el cliente quiere resultados, quiere que le entreguen valor y no reportes.

Cuando una PMO se concentra en los reportes, es porque está fungiendo como paje o escudero de algún jefe, es decir;  concentra sus energías en quedar bien con un jefe y no con el cliente.  Este jefe a su vez, al permitir este estado de las cosas, tampoco está concentrando sus energías en quedar bien con el cliente, sino en quedar bien con su jefe. Intenta quedar bien, mostrando que  “aparentemente” tiene todo bajo control, demostrado con reportes bonitos, generosamente bien diseñados…. Y sin valor.   ¿Te imaginas que toda la línea de comando este dedicada a quedar bien con los jefes sucesivos y no con el cliente que es el que alimenta a la organización?

Para promover un avance en gestión de proyectos, y vencer las resistencias de los que prefieren el “Carisma y tradición”,  no deberíamos estar dando argumentos adicionales que apoyen la resistencia contra la formalización y la metodología. En su lugar, nos conviene desmotivar el crecimiento de aparatos que no generan valor, o al menos no darles el nombre de PMO, quizás RGO sería más apropiado  (“Reporting Generation Office), y orientar el desarrollo de nuestra profesión hacia la generación de valor,  al Accountability directo ante nuestros clientes y usuarios finales.