Hola a todos, mi nombre es Douglas Dourado y este es mi primer artículo sobre Tech Writers. Hablaré de mis aprendizajes en mi carrera como Analista de Negocios. Para poder dilucidar esta cuestión, primero necesito retroceder un poco en el tiempo. Me uní a la empresa Softplan en mayo de 2013 para participar en el Proyecto Puma de nuestro cliente Tribunal de Justicia del Estado de São Paulo (TJSP), más específicamente para procesos digitales de Segunda Instancia. Este proyecto fue sumamente importante para nuestro cliente porque, con él, se optimizaron día a día procesos que consumían mucho tiempo, tanto para los empleados como para todas las demás personas involucradas durante ese período. Comencé mi carrera como Analista de Sistemas y, durante ese tiempo, con la ayuda de varias personas involucradas en mi ciclo profesional, logré absorber muchas cosas hasta llegar a donde estoy hoy, trabajando como Analista de Negocios. Este artículo proporcionará algunos consejos de quienes ya han recorrido el camino y será interesante para cualquiera que busque seguir una carrera en el área de productos. En todos estos años destaco 3 habilidades importantes que aprendí y que considero pilares importantes para cualquiera que quiera seguir esta carrera. Ellos son: Resiliencia, Comunicación entre Equipos y Sinergia con el cliente. Habilidades esenciales para un Analista de Negocios Resiliencia Según el diccionario virtual, el término Resiliencia se puede definir brevemente como: la capacidad de enfrentar y superar la adversidad. A lo largo de tu carrera pueden aparecer algunas adversidades, pero la resiliencia nos ayuda a navegar los acontecimientos, aprender de ellos y tener más tranquilidad y confianza para dar los siguientes pasos. Por tanto, aprende a recalcular la ruta, reorganizarte y seguir adelante. Comunicación entre equipos La comunicación entre equipos también es muy importante. Esto se debe a que, para estar en un nivel seguro, dependemos de otros equipos y personas. Como diría el fallecido Chacrinha: “Quien no se comunica, se confunde”. En ocasiones, en este puesto deberá presentar demandas, negociar y realizar reuniones con los clientes y el personal. Aprende técnicas de comunicación asertiva, storytelling, intenta ser claro y objetivo, adaptando tu comunicación a cada oyente, si tu cliente es formal adáptate. Si el entorno requiere términos más técnicos, utilízalos o incluso todo lo contrario: aprende a explicar escenarios complejos con palabras sencillas y ejemplos. Pero recuerda que el primer paso para una buena comunicación es saber escuchar y comprender las necesidades de la otra persona. Sinergia con el cliente Existen diferentes formatos y flujos de trabajo dentro del rol de Business Analyst, incluso aquí en Softplan. En el proyecto al que me uní, el Business Analyst tiene en ocasiones contacto directo con el cliente, por ejemplo, para mapear requerimientos y necesidades. Si este es tu caso, intenta seguir estos consejos: Siempre me aseguré de absorber la mayor cantidad de información posible de lo que los usuarios tenían que decir para poder analizar el escenario. Centrarse en tu cliente, comprender sus necesidades, hacer las preguntas adecuadas y tener una visión dinámica es fundamental. No salgas de una reunión con dudas, ten claro lo que necesitas entregar a ese cliente, esto es fundamental para una entrega de calidad. ¿Quieres seguir una carrera como analista de negocios? Por lo tanto, para aquellos de ustedes que quieran seguir una carrera en el área de Business Analyst, busquen desarrollar habilidades de resiliencia, comunicación y enfoque al cliente. Estas habilidades son pilares esenciales que he aprendido a lo largo de mi carrera y que uso a diario.

En lo que respecta a la disciplina de la arquitectura en el desarrollo de software, nos encontramos ante varios tipos de arquitectura. Cada uno, con sus características y especificidades. En este artículo abordaremos tres tipos de arquitectura, son: Arquitectura de Software, Arquitectura de Soluciones y Arquitectura Corporativa. A pesar de ser arquitecturas diferentes y tener funciones específicas en algún momento del desarrollo, terminan interactuando entre sí. Arquitectura de software Esta arquitectura es la más cercana al código y al desarrollador. Se centra en la organización interna de un sistema y aborda la división del sistema en componentes, tales como: clases, módulos o servicios. También define cuál será la interacción entre ellos, siendo responsable de aspectos como modularidad, escalabilidad, seguridad y reutilización de código. Algunas de las definiciones de esta arquitectura: • Qué lenguaje de programación se adoptará; Por ejemplo: Java o .NET C#. • Qué frameworks y bibliotecas utilizar en la solución: por ejemplo, si elige el lenguaje de programación Java, utilice Spring Boot Framework para facilitar y acelerar el desarrollo de aplicaciones web y microservicios. • Cómo acceder a la capa de datos y cómo se producirá la persistencia, ya sea a través de un marco de mapeo relacional de objetos o manualmente. Si elige un ORM, defina qué herramienta se utilizará; Por ejemplo: Hibernar o EclipseLink. • Qué modelo arquitectónico se utilizará en la implementación y los patrones arquitectónicos apropiados que cumplan con los requisitos del sistema. Por ejemplo: MVC, Arquitectura en Capas, Cliente-Servidor, Hexagonal u Orientada a Servicios. • ¿Cuál es la forma de comunicación entre los componentes del sistema? Por ejemplo: HTTP, REST o mensajería asincrónica. • Cómo se producirá la escalabilidad y cómo se escalará el sistema para manejar los aumentos de carga y demanda; Por ejemplo: equilibrio de carga, escalamiento horizontal/vertical o división de datos. ¿Cuál seguir? Estos temas enumeran algunos ejemplos de decisiones arquitectónicas que se pueden tomar durante el proceso de definición de una arquitectura de software. No hay una respuesta correcta o incorrecta para estas definiciones. Justo el que mejor se adapta a cubrir una necesidad dentro de un contexto empresarial. Estas decisiones son muy importantes y deben tomarse con muchos antecedentes y cautela, ya que cambiarlas posteriormente afectará toda la estructura del sistema, provocando costos no deseados y retrasos en el proyecto. Por lo que se recomienda realizar Pruebas de Conceptos (POC's) para que las decisiones tomadas sean lo más asertivas posibles y garanticen un sistema robusto, escalable y de alta calidad. Es importante que el arquitecto de software tenga un buen conocimiento técnico y en base a sus experiencias tome la mejor decisión para que el desarrollo sea fluido y cadenciado. Además, el arquitecto debe estar preparado para actuar en tiempos de crisis. A menudo, se le puede pedir que identifique problemas específicos y altamente complejos, como depurar una biblioteca o un marco para tomar una decisión importante y corregir un problema en producción, haciendo que la operación vuelva a funcionar con normalidad. Arquitectura de la solución La arquitectura de la solución se encuentra en una capa superior a la arquitectura del software y es responsable de transformar los requisitos comerciales en componentes de ingeniería que trabajarán juntos para resolver el problema y satisfacer las necesidades comerciales. Abarca la definición de los sistemas involucrados, la integración entre ellos, las interfaces de comunicación y las estrategias para asegurar que la solución en su conjunto funcione de manera efectiva y alcance sus objetivos. Este tipo de arquitectura es ideal para identificar áreas dentro de una organización donde se pueden reducir los costos, mejorar el rendimiento y automatizar los procesos para volverlos más eficientes, optimizados y estandarizados. La principal diferencia entre Arquitectura de Software y Arquitectura de Soluciones es que la primera se ocupa únicamente de cuestiones relacionadas con la ingeniería, mientras que la segunda es responsable de garantizar que un producto de software resuelva un problema comercial específico dentro de la estrategia de una empresa. Atividades que estão associadas a esta disciplina: • Compreender e analisar os requisitos do negócio e do sistema para identificar as necessidades e os objetivos da solução; Por exemplo: Entrevistas/workshops, estudos de viabilidade e criação de diagramas de contexto.  • Criar e liderar os processos de integração entre sistemas para atender os requisitos de negócio; Por exemplo: Definição de interfaces, serviços web (API's REST) e Middleware de integração (Kafka).  • Identificar e definir as medidas de segurança necessárias para proteger a solução contra ameaças; Por exemplo: Autenticação, Autorização, Criptografia e proteção de dados sensíveis.   • Colaborar com stakeholders (desenvolvedores, analistas de negócios e gerentes de projeto), para garantir a compreensão e a adoção da arquitetura de soluções; Por exemplo: Comunicação clara das decisões arquiteturais, realização de revisões técnicas e a obtenção de feedback dos envolvidos.  • Identificar os riscos associados à solução e desenvolver estratégia para mitigá-los; Por exemplo: Análise de riscos técnicos, operacionais e segurança.  • Considerar os requisitos de desempenho, como tempo de resposta e capacidade de processamento, e também a capacidade de escalar a aplicação para lidar com picos de aumento de carga; Por exemplo: Uso de caches, escalonamento horizontal, arquitetura de microsserviços ou serviços de mensageria.  Vínculo forte Podemos concluir que a arquitetura de soluções está na divisão entre o técnico e o negócio, e que há um vínculo forte entre essas duas vertentes, considerando a importância de que a solução técnica está sendo definida para resolver um problema de negócio. As habilidades de comunicação na arquitetura de soluções são imprescindíveis, pois há frequentemente um contato direto com a área de negócio, que normalmente tem o conhecimento técnico muito pequeno ou inexistente, com isso, cabe ao papel do arquiteto de soluções ser capaz de explicar e traduzir de forma simples toda a solução técnica que será construída, de uma forma abstrata o suficiente para que todos entendam. Algo importante a se considerar é o conhecimento necessário para representar a arquitetura através de diagramas, como por exemplo o C4, e que ele possa representar de forma clara os componentes do software, a interface com outros sistemas, o fluxo de dados e demais informações que forem pertinentes tanto para a engenharia quanto para o negócio.  Arquitetura Corporativa Define-se arquitetura corporativa como uma série de conhecimentos técnicos e habilidades de gestão que integram a tecnologia aos objetivos do negócio, é uma visão mais ampla que abrange a arquitetura de todo o ambiente de tecnologia da informação da organização. Determina os princípios, políticas e os padrões de governança que orientam a estruturação dos sistemas de software e infraestrutura de uma empresa, se concentrando em como os diferentes sistemas e soluções se encaixam dentro do contexto organizacional, garantindo a consistência, a integração e a eficiência dos recursos de TI.A arquitetura corporativa também considera fatores estratégicos e de negócios, alinhando a tecnologia da informação com os objetivos e necessidades da organização. Puede incluir la definición de modelos de procesos de negocio, la gestión de la cartera de sistemas, el gobierno de TI y la definición de políticas de seguridad de la información. Decisiones tomadas dentro de este tipo de arquitectura: • Estandarización del lenguaje de programación y frameworks utilizados en las soluciones dentro de la empresa, delimitando qué tecnologías se habilitarán para su uso; Por ejemplo: usar la pila de Java con Spring Boot Framework en soluciones API. • Estandarización de bases de datos; Por ejemplo: SQLServer y Oracle. • Procesos de control de cambios para auditar publicaciones en un ambiente productivo; Por ejemplo: Controlar accesos y permisos, revisar y aprobar cambios. • Definir y documentar un modelo de arquitectura con el que trabajará la organización; Por ejemplo: cree un diagrama que ilustre las capas principales de la arquitectura, que abarque las capas de presentación, negocio y datos. • Evaluar la implementación de nuevas tecnologías; Por ejemplo: realización de pruebas de concepto (POC) e investigaciones de mercado. • Implementar soluciones corporativas DevOps; Por ejemplo: Automatización de compilación y empaquetado utilizando Jenkins como transportador CI/CD. Importancia de la arquitectura corporativa Contar con una arquitectura corporativa es muy importante, ya que define estándares que toda la empresa debe adoptar y seguir, y ayuda a alinear los objetivos estratégicos de la organización con sus actividades operativas, ayudando a identificar redundancias, ineficiencias y oportunidades de optimización, permitiendo la simplificación, consolidación y racionalización de recursos resultando en una mayor eficiencia operativa y reducción de costes. La arquitectura corporativa ayuda en la gestión del ciclo de vida de los sistemas de TI, desde la planificación estratégica, el establecimiento de estándares de calidad, gobernanza y cumplimiento hasta el desarrollo, implementación, operación y mantenimiento de sistemas, asegurando una gestión eficaz y sostenible de los activos de TI. Conclusión En este artículo, analizamos los tres tipos principales de arquitectura que existen en el desarrollo de software, los detalles de cada tipo y cómo se relacionan entre sí. Esta división es importante para que cada arquitectura se centre en un área específica para que las tres juntas puedan cubrir todo el ciclo de desarrollo de software. Como hemos visto, la arquitectura de software está más cerca del código y del desarrollador, la arquitectura de soluciones está más enfocada al negocio que la solución pretende resolver y la arquitectura corporativa para definir los estándares tecnológicos que la organización debe adoptar para el software implementado. soluciones. La aplicación de estos tipos de arquitectura varía según el tamaño de la organización, cuanto más grande, más separados y específicos son los tipos de arquitectura, y cuanto más pequeña, menor separación entre los tipos de arquitectura, y muchas veces fusionándose en un solo tipo. . Es importante señalar que, para cada tipo de arquitectura, el arquitecto puede desempeñar un rol diferente, y cada uno con sus habilidades específicas para cada área, pero las habilidades de comunicación, pensamiento crítico, proactividad y resiliencia son comunes a todos los tipos de arquitectura. .

Aquí en el equipo de soporte de Projuris, cuando recibimos un ticket (también conocido por muchos como ticket), analizamos cuidadosamente cuál es la demanda del cliente y cuál es su impacto en la operación. Como dice el refrán: “la vida imita al arte”. Por tanto, puedo decir que nuestra vida tiene mucho que ver con un ticket de soporte. Incluso podemos dividirlo en los mismos pasos de análisis para resolver un problema. Servicio, categoría y urgencia. En cuanto al análisis del servicio, podemos compararlo con la vida separando todos los puntos de la vida en áreas, ya sean personales, profesionales o espirituales. Es decir, busca, de manera amplia, no sólo tu identificación, sino también tu mejor manera de actuar. Inmediatamente después del servicio llegamos a la categoría, con la que podemos relacionarnos como si fuera una pregunta, problema o tarea. Esta pregunta es importante para que analicemos actitudes para superar este problema. Los problemas, que forman parte de la vida humana, pueden confundirse con la duda. Pero hay una diferencia: mientras las dudas se refieren a desconocimiento o falta de interpretación sobre algo, los problemas no siguen el mismo flujo. Los problemas son notas que deberían seguir así, pero no lo son. Por ejemplo: Todas las demandas para las que no tenemos respuesta, al menos al principio, se consideran problemas, y pueden haber soluciones en el momento o en el futuro. Si los problemas se refieren a cómo hacerlo, no es un problema, sino una duda. El último punto, en mi opinión, es el más sencillo. Estas son tareas, que son operaciones en un punto determinado. Y cuando hablamos de urgencia la clasificamos en: bloqueante, urgente, alta, media y baja. El bloqueo es una categoría en la que se paraliza toda la operación y todos los usuarios de la organización. Desde la perspectiva de la vida, la categoría de bloqueo es algo que debe resolverse de inmediato. Urgente es similar a bloquear, sin embargo, no paraliza toda la operación. Se puede resolver con más tranquilidad. Las categorías alta, media y baja son problemas en los que debemos analizar cuáles serán los impactos en la vida diaria. Las urgencias ayudan a comprender las demandas prioritarias. Porque cuanto más grave es, mayor es su impacto. ¿Soporte o ticket de por vida? Ahora te pregunto: ¿quién es el experto detrás de este billete de vida? Así es, somos yo, tú, nosotros. Por eso, ser experto en las propias “exigencias” (lo que también podemos llamar autoconocimiento) es un elemento esencial para comprender las cuestiones que te aquejan. Y cuanto más te organices, clasifiques tus problemas y los priorices, mejor los solucionarás, haciendo tu vida más tranquila. 

Si trabaja con proyectos de software y alguna vez ha tenido la necesidad de tratar objetos individuales y colecciones de objetos de manera uniforme, el patrón de diseño compuesto lo ayudará. Descubra a continuación cómo el patrón Composite le ayuda a crear interfaces de usuario más intuitivas y procesar árboles de objetos de manera eficiente. En este artículo te invitamos a explorar los beneficios de este patrón, que simplifica las estructuras jerárquicas y ofrece mayor flexibilidad en la manipulación de elementos. Consulta a continuación qué es Composite, cuáles son sus ventajas y desventajas y mira un ejemplo práctico de su implementación. ¿Qué es el compuesto? Compuesto es un patrón de diseño estructural que le permite tratar objetos individuales y composiciones de objetos de manera uniforme, formando una estructura jerárquica. Es el cuarto estándar en esta categoría presentado por la "Banda de los Cuatro" (GoF). Como lo expresan los propios autores, la intención oficial de este patrón es "componer objetos en estructuras de árbol para representar jerarquías de partes y todo". Con Composite, un objeto individual y un grupo de objetos se tratan de la misma manera, ya que ambos implementan una interfaz común. ¿Cómo funciona el patrón de diseño compuesto? Dentro del patrón Composite encontramos una clase abstracta conocida como "Componente", que establece una interfaz compartida para objetos individuales y grupos de objetos. Los objetos individuales están representados por una clase concreta que implementa el Componente, mientras que los grupos de objetos están representados por una clase compuesta que también implementa el Componente. La estructura jerárquica se crea mediante la composición, en la que un grupo de objetos puede incluir otros objetos individuales o grupos de objetos. Esta estructura permite realizar interacciones recursivas y, por tanto, permite aplicar operaciones a todos los objetos de la jerarquía. El patrón Composite es ideal cuando es necesario tratar objetos individuales y colecciones de objetos de forma homogénea, simplificando el código y proporcionando mayor flexibilidad. Su uso es común en interfaces de usuario, árboles de procesamiento y otras estructuras jerárquicas. ¿Cómo se implementa el compuesto? Para comprender mejor la implementación del Composite, analicemos el siguiente ejemplo: En un supermercado tienes dos formas de comprar un refresco: Puedes comprar la unidad O comprar un paquete con 12 unidades Aquí tenemos un Composite: la noción de que la bala (estructura) se comporta como un producto, y que puede decir su precio delegando su valor, sumando así los costos de las unidades hijas y usándolo como propio. Por supuesto, el escenario anterior sólo tiene sentido si la paca no tiene un valor fijo, sino que su valor se suma al número total de unidades que contiene. Veamos un código del escenario descrito (en este caso, usando Java para ejemplificar): En el ejemplo anterior, definimos una interfaz de Producto, que será implementada tanto por la unidad de “soda” como por el fardo. El método común que implementarán, en nuestro caso, es getValor(). El refresco, a su vez, tiene valor y nombre. La implementación de getValor(), al ser una sola unidad, solo devuelve su propio valor. Arriba tenemos el paquete de refresco, actuando como un Composite, su “valor” se delega a las unidades que contiene. Es decir, si hay 5 unidades de refrigerante, cada una con un valor de “5”, el valor del fardo será 25. Lo interesante de este patrón de diseño es que la complejidad de este tipo de estructuras no termina ahí. Como la clase BundleOfSoda tiene una lista de tipos de productos dentro de sí misma, puede incluso admitir otros paquetes dentro de sí misma. Ejemplo de Estructura Compuesta Aunque el “fardo de refresco” no es el mejor ejemplo en este caso, podemos imaginar una caja dentro de otra caja, y cada una con productos de diferentes valores en su interior, las cajas internas sumaban el valor de la productos internos, y la caja externa sumaría el valor de las cajas internas, pareciéndose mucho a la estructura a continuación: Ejemplo de cómo puede verse la estructura de un compuesto. Fuente: “Patrones de proyecto: soluciones de software orientadas a objetos reutilizables” Normalmente, el patrón de diseño compuesto se utiliza, por ejemplo, para ejecutar una batería de validaciones sobre un objeto. Mientras que el Decorador sirve para ampliar funcionalidades dentro de una clase existente, sin cambiar la clase original y preservando los principios SOLID. La forma de implementarlo puede variar mucho dependiendo de cómo lo uses, pero lo importante es conocer el patrón y saber cuándo encajarlo en tu sistema. No sigas estrictamente los diagramas propuestos por GoF, ni los ejemplos mencionados, ajústalos según tus necesidades y situaciones. ¿Cuándo utilizar el patrón de diseño compuesto? El patrón de diseño compuesto se aplica en situaciones donde existe una estructura jerárquica de objetos y cuando se desea tratar objetos individuales y grupos de objetos de manera uniforme, simplificando el código y brindando mayor flexibilidad. A continuación se muestran algunos ejemplos de situaciones de uso del patrón compuesto: Estructuras jerárquicas: el patrón compuesto es ideal para trabajar con estructuras jerárquicas, como árboles o gráficos, donde los nodos pueden ser objetos individuales o grupos de objetos. Modelado de Interfaz de Usuario: Es común utilizar el patrón Compuesto en la construcción de interfaces de usuario, especialmente cuando hay elementos que pueden contener otros elementos, como menús, botones y paneles. Procesamiento de documentos: Composite puede resultar útil para tratar elementos como documentos con secciones, párrafos, listas, etc., de forma uniforme. Manipulación de gráficos: si necesita trabajar con elementos gráficos como formas, líneas y grupos de formas, Composite le permite tratarlos de manera uniforme y facilita la aplicación de operaciones a todos los elementos. Implementación de Estructuras de Datos: También es posible aplicar Composite para implementar estructuras de datos como arreglos, listas y matrices, en las que los elementos individuales y grupos de elementos se tratan de manera similar. ¿Cuáles son los pros y los contras de utilizar Composite? Consulte los principales pros y contras de Composite: ProsConsSimplifica la estructura jerárquicaPuede tener un impacto en la eficiencia en estructuras muy grandesOfrece flexibilidad en la manipulación de objetos y operaciones recursivasPuede requerir un mayor diseño y esfuerzo de implementación inicialPromueve la reutilización de códigoRequiere una interfaz común bien definida Sin embargo, es importante Recuerde que los pros y los contras de Composite pueden variar según el contexto y los requisitos específicos del proyecto. Por lo tanto, es esencial considerar cuidadosamente estos aspectos antes de decidir utilizar el patrón de diseño compuesto. ¿Y ya sabías cómo implementar Composite?

Con el aumento exponencial del uso de dispositivos y gadgets electrónicos en nuestra rutina, la importancia de la Interacción Humano-Computadora, también conocida como HCI, ha aumentado cada vez más en la transformación de la sociedad, impactando directamente en la vida diaria de todos. Especialmente para los desarrolladores de software y profesionales del diseño de interfaces, es esencial comprender los principios de HCI para crear productos exitosos que cumplan con las expectativas de los usuarios. Si quieres saber más sobre el tema, descubre qué es la IHC a continuación. También abordaremos los principales pilares de estudio en esta área para comprender mejor este concepto. ¿Qué es la IHQ? La transformación digital se produce de forma más fluida con el buen uso de buenas interfaces, que deben diseñarse cuidadosamente para permitir una comunicación efectiva entre personas y máquinas. El foco es brindar una experiencia placentera y satisfactoria para el usuario, en la que pueda realizar su tarea y resolver su “dolor” de manera eficiente y sin frustración. Ahí es donde entra en juego la IHC. La Interacción Humano-Computadora (HCI) es un área multidisciplinaria de tecnología dedicada a estudiar y mejorar la interacción entre humanos y sistemas informáticos. Su objetivo es crear interfaces de usuario que sean intuitivas, eficientes y agradables de usar. HCI cubre varios aspectos del diseño de interfaces, como usabilidad, accesibilidad, experiencia de usuario y ergonomía. Por ello, el área utiliza métodos y técnicas de diferentes orígenes, como la psicología, la ingeniería de software, la informática y el diseño. ¿Cuáles son los 3 enfoques del estudio de HCI? Los tres principales focos de estudio de HCI (Interacción Humano-Computadora) son: 1. El usuario (y su tarea): HCI se centra principalmente en comprender las necesidades, habilidades y limitaciones de los usuarios, con el objetivo de diseñar sistemas e interfaces que sean intuitivos y optimizados para las acciones previstas. Para lograrlo, el área utiliza técnicas de investigación, como entrevistas cuantitativas y cualitativas, observación de modelos mentales, mapeo del viaje del usuario y pruebas de usabilidad. 2. El sistema: Otro foco del área es el sistema en sí, es decir, comprender cómo funcionan los sistemas informáticos y cómo diseñarlos de forma optimizada y segura teniendo en cuenta diversos factores, como las limitaciones de hardware y software, por ejemplo. Para incrementar este conocimiento es necesario profundizar en las áreas de arquitectura de software, tecnologías de interacción, usabilidad y diseño de interfaces. 3. El contexto de uso: Finalmente, otro foco de estudio en el área es el contexto de uso de los sistemas. Por ejemplo, las condiciones ambientales, las limitaciones de tiempo, las capacidades o posibles limitaciones físicas del usuario, así como sus deseos, necesidades y cultura (digital o no). Todos estos elementos dan forma a la respuesta a las necesidades de quienes utilizan el sistema. De este modo, es posible garantizar que el sistema esté diseñado teniendo en cuenta las expectativas de acción y reacción del usuario en una amplia gama de situaciones. La retroalimentación es vida. Por ejemplo, la retroalimentación que el usuario necesita recibir del sistema informático debe planificarse y programarse explícitamente. Esto es esencial para garantizar que el usuario comprenda claramente lo que sucede internamente en la computadora y pueda interactuar con ella de una manera más asertiva. Imagine la siguiente situación: activa un ascensor para llegar y no recibe respuesta del sistema, ningún botón encendido, ningún mostrador de piso, ninguna flecha hacia arriba o hacia abajo, y a partir de ese momento su interacción con el sistema se basa en la fe: que el ascensor llegará en algún momento… Jakob Nielsen, el Yoda de la usabilidad, no se conforma con diseños bonitos; nos invita a pensar primero en el usuario. La eficiencia de uso y la satisfacción del usuario son como su mantra de diseño. Es más que crear algo hermoso; es crear algo que funcione magistralmente y haga “sonreir” al usuario mientras lo usa. Y aquí es donde entra en juego la heurística de Nielsen, el maestro de los magos del pragmatismo funcional. Estos principios no son sólo directrices adoptadas por los diseñadores; Son como los 10 mandamientos del diseño de interfaces. "¡Haz visible el estado del sistema!" él proclama. "¡Mantén una correspondencia con las cosas del mundo real y controla al usuario!" Estas reglas son como brújulas que guían a los diseñadores a través de los mares de la experiencia del usuario. Así que deja de usarlos y navega sin rumbo hacia tus propios dispositivos. Podemos enumerar 10 heurísticas principales y una de ellas, mencionada anteriormente, es precisamente la primera de todas: Visibilidad del estado del sistema. Para completar el combo tenemos 9 heurísticas más — que iremos abordando paulatinamente en próximos posts: Correspondencia entre el sistema y el mundo real Control y libertad del usuario Consistencia y estándares Prevención de errores Reconocimiento en lugar de memorización Flexibilidad y eficiencia de uso Estética y diseño minimalista Reconocimiento de errores, diagnóstico y recuperación Ayuda y documentación Origen de HCI y línea de tiempo Anteriormente, en los albores de los tiempos de las interfaces podemos señalar con seguridad a Lisa como el "horno horneado" de las interfaces. Lanzada en 1983 por Apple, la primera computadora comercial que tenía una interfaz gráfica de usuario (UI). Esta tecnología permitió que las computadoras fueran utilizadas por personas sin ninguna capacitación especial, haciéndolas accesibles a todos. Sin embargo, Apple ya estaba trabajando en una versión más accesible y de menor coste. Un año después, la empresa lanzó Macintosh, la primera computadora con una interfaz gráfica verdaderamente accesible. Venía con monitor, teclado y ratón con botón, y tenía una mayor organización que los ordenadores anteriores. Las opciones estaban ordenadas en menús y había íconos en los que se podía hacer clic para operar un programa. El foco aquí es entender que el mayor legado de este movimiento disruptivo fue la metáfora de las carpetas del Escritorio, utilizada comercialmente por primera vez por Apple en Lisa OS, que también aprovechó el uso de Interfaces Gráficas de Usuario (Graphical User Interface, o GUI) por parte de Apple. otras compañías. Esta metáfora del escritorio representaba una mesa de oficina con varios papeles encima, simbolizando archivos de computadora, así como otras representaciones del mundo real, como la papelera, el calendario, el reloj, los archivos, las hojas de cálculo, el bloc de notas, la calculadora, etc. En aquella época, los primeros usuarios y aficionados a la informática fueron personas que trabajaban en oficinas, con máquinas de escribir, calcular, carpetas de archivos, etc. Por lo tanto, se dio cuenta de que al simular el entorno físico de la oficina en una interfaz de computadora, los usuarios comprenderían más fácilmente el almacenamiento de información en el escritorio. Ese era el modelo mental. Después de este recorrido por el pasado, miremos ahora al presente. No podemos ignorar los rumores en torno a la inteligencia artificial (IA). Ahora, las cosas se están volviendo reales, con comandos de voz a punto de entrar en escena. No estamos simplemente haciendo clic y arrastrando; Estamos hablando con nuestras máquinas. Es como tener un asistente personal que no sólo entiende lo que dices, sino que también puede ayudarte o realizar la tarea que realmente necesitas hacer, al mejor estilo JARVIS de Tony Stark. Sin embargo, un gran poder conlleva una gran responsabilidad. A medida que la IA se vuelve omnipresente, comenzamos a cuestionar la privacidad, la seguridad e incluso la confiabilidad de estas interacciones. Es como si estuviéramos coqueteando con una nueva era de conversaciones digitales, pero realmente no conocemos todas las reglas del juego. También vale la pena señalar que incluso con un poco de ayuda de su asistente personal parlante, el niño Tony todavía hace un uso extensivo de las interfaces gráficas. Conclusión En definitiva, llamamos Interacción Humano-Computadora al estudio, diseño e implementación de software para uso directo con los usuarios. Dichos sistemas cuentan con interfaces de usuario (UI). Es a través de ellos que una persona interactuará con una computadora. De esta manera, fue a través de interfaces que la computadora se convirtió en lo que conocemos. ¿Te gustó saber más sobre la Interacción Humano-Computadora?

En los últimos años, hemos notado un aumento en la complejidad de los sistemas de software, la aparición de SaaS y aplicaciones híbridas. En consecuencia, esto aumenta el riesgo de errores, además de una mayor exposición de los sistemas a invasiones y fugas de datos. En este nuevo contexto, la observabilidad puede ayudar a identificar problemas más rápidamente, optimizando el trabajo del equipo de desarrollo y mejorando la calidad de los sistemas. Si aún no estás familiarizado con este concepto, consulta a continuación más información sobre una de las principales tendencias en ingeniería de software y descubre qué es la observabilidad, sus pilares, ventajas y ¡cómo implementarla! ¿Qué es la observabilidad en TI? La observabilidad en TI es la aplicación de un sistema de monitoreo, seguimiento, análisis y diagnóstico constante de un sistema, haciendo uso de algunas herramientas de software. La observabilidad permite investigar y comprender con mayor profundidad cómo se comporta un sistema, especialmente en arquitecturas de nube. A partir de las herramientas de observabilidad es posible recopilar y analizar un amplio espectro de datos, detectar problemas, comprender las causas de los problemas identificados y elaborar un plan de acción para mejorar el funcionamiento de los sistemas. De esta forma, la observabilidad ayuda a resolver problemas antes de que afecten los KPI de la empresa. Además, transforman un problema incomprensible en algo más detectable, visible e investigable. Este concepto es ampliamente aplicado por los equipos de DevOps, infraestructura y desarrollo, pues ya está extendido en Ingeniería de Software que beneficia al software y facilita la resolución de problemas. Lo ideal es adoptar la implementación de la observabilidad del software, especialmente cuando el enfoque de su negocio es la experiencia del cliente o optimizar el trabajo de los desarrolladores de su equipo. Aprovecha para consultar también nuestro artículo que habla un poco más sobre la observabilidad orientada a dominios, una metodología para implementar la observabilidad. ¿Cuáles son las ventajas de implementar la Observabilidad en TI? Algunas ventajas de implementar la observabilidad son: Disponibilidad, ya que facilita la identificación y corrección de errores, minimizando el tiempo de inactividad y el impacto en los usuarios finales; Fiabilidad, porque, cuando se utiliza de forma preventiva, la observabilidad es capaz de mitigar de antemano los problemas de escalabilidad o rendimiento de una aplicación; Trazabilidad del uso de funcionalidades, con el fin de obtener insumos para las decisiones estratégicas que se puedan tomar dentro del negocio; Productividad, como observabilidad te permite monitorear los cambios en tiempo real, aumentando la capacidad productiva de tu equipo a la hora de atender las demandas diarias, ayudando a DevOps, infraestructura u otros equipos; Menor costo, ya que la observabilidad previene problemas de seguridad, la empresa gasta menos en mantenimiento inesperado; Previsibilidad, porque cuando la cultura del equipo se centra en el seguimiento y monitoreo de los sistemas en tiempo real, la empresa puede predecir más fácilmente algunos problemas futuros. Entre estas ventajas, la trazabilidad es la que más impacta en el negocio, pues es la que define el éxito de su aplicación. Las llamadas “métricas de alto nivel”, al estar intrínsecamente ligadas al negocio, son las que aportan mayor valor. Mediante el seguimiento del uso de las funcionalidades de un sistema, podemos comprender si se está desempeñando de acuerdo con los objetivos de un producto. ¿Cuáles son los 3 pilares de la observabilidad en TI? La efectividad en la implementación de la observabilidad del software sólo es posible a partir del uso de datos de telemetría, que son los pilares que recopilan toda la información sobre el sistema investigado. En el concepto de observabilidad tenemos 3 pilares: registros de eventos, métricas y seguimiento. Vea a continuación una explicación de los 3 pilares de la observabilidad en TI: Registros de eventos: Es un registro inmutable que presenta la hora y fecha de los eventos. Es posible capturarlo a través de texto, binario o estructurado. Métricas: Las métricas son valores definidos según el objetivo. Se utilizan para investigar el comportamiento de un evento durante un intervalo de tiempo específico y proporcionar datos como fecha, nombre, hora y KPI. Seguimiento: Es el pilar que detalla todas las operaciones, desde su inicio hasta su fin. Esto sucede monitoreando todo el viaje para comprender si el sistema es normal o está en riesgo. ¿Cuál es la diferencia entre monitoreo y observabilidad? La estrategia de observabilidad no es exactamente diferente del seguimiento, ya que el seguimiento aborda los problemas de una manera más reactiva y no es capaz de abordar problemas muy complejos. Esto se debe a que desde la incorporación de la arquitectura de microservicios para aplicaciones web, ha habido una mayor escalabilidad en la creación de componentes del sistema que se implementan de forma individual en las plataformas. En este escenario en el que pueden surgir nuevos problemas desconocidos, la monitorización por sí sola ya no es tan eficaz. Por otro lado, la observabilidad es una gran suite de monitoreo centrada en la arquitectura de microservicios en la capa de aplicaciones y contenedores en el área de infraestructura. Además, correlaciona los datos de telemetría recopilados con el objetivo de crear soluciones más efectivas. Así, la observación constante puede proporcionar datos que ayuden al seguimiento, facilitando la identificación de los problemas y sus causas. En otras palabras, el monitoreo asegura que una aplicación se vuelva observable; por lo tanto, la observabilidad es una evolución del concepto de monitoreo. A través de la observabilidad es posible tener un mejor seguimiento del sistema, siendo casi sinónimo en este sentido. ¿Cómo implementar la observabilidad? Para implementar correctamente la observabilidad, primero debe definir sus objetivos. En otras palabras, identificar los principales indicadores de desempeño (KPI), sus objetivos y enumerar los puntos críticos que se pueden monitorear. Luego instrumente su código con métricas y registros. Algunas herramientas pueden ayudarte con esta tarea, como Prometheus para métricas y Fluentd para registros. También puede utilizar herramientas de seguimiento para analizar los datos generados en la aplicación. Por ejemplo, Grafana para visualizar métricas y Kibana para analizar registros. Además de estos puntos, es importante contar con alertas que notifiquen al equipo cada vez que ocurre un evento crítico. Para comprender cómo se comportan las solicitudes dentro del sistema, puede utilizar el seguimiento de transacciones para rastrear el flujo de solicitudes a través de los diferentes componentes. Siguiendo estos pasos y manteniendo un proceso continuo, actualice sus objetivos y ajuste su implementación a medida que cambien las necesidades. ¿Aún tienes alguna pregunta sobre la observabilidad?