Artigo

Engenharia De Software

29 de setembro de 2026

Da Planilha à Solução Centrada no Usuário: O Redesenho de um Processo Operacional na Atalaia

Da Planilha à Solução Centrada no Usuário: o Redesenho de um Processo Operacional na Atalaia

Aldair Garros Carvalho; Everton Gomede

DOI: 10.22167/2675-6528-202602610

Artigo derivado de Trabalho de Conclusão de Curso (TCC), com conteúdo baseado no trabalho original do aluno e adaptado ao formato editorial da Revista E&S com apoio da ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege para síntese e organização textual.

Resumo

O redesenho do processo de comunicação operacional em uma Atalaia, que utilizava planilhas com macros e e-mails para informar previsões de manobras, foi analisado. Identificou-se que o processo era manual, lento, propenso a erros e gerava sobrecarga aos operadores e insatisfação aos usuários. Objetivou-se propor uma solução mais eficiente e aderente às necessidades dos envolvidos. Para isso, adotou-se a pesquisa-ação, guiada pela metodologia Design Thinking, estruturada nas fases de empatia, definição, ideação, prototipação e teste. A investigação incluiu vivência profissional, entrevistas com operadores e práticos, observação contextual, análise de registros operacionais, construção de personas e testes de usabilidade. Os resultados revelaram a centralidade da previsão de manobras na rotina da Atalaia e as limitações das ferramentas legadas. Desenvolveu-se um protótipo web centrado no usuário, com importação automática de dados, múltiplas formas de visualização e acesso independente da conexão com a Internet. Nos testes, a nova solução reduziu em 82% o tempo médio de preparação do relatório, passando de 11,4 para 1,6 minuto. Concluiu-se que a aplicação do Design Thinking pode modernizar o processo, prevenir erros, aumentar a eficiência e ampliar a qualidade da comunicação operacional.

Palavras-chave: Automação de processos; Comunicação operacional; Design Thinking; Pesquisa-ação; Usabilidade.

1. Introdução

O setor portuário exerce influência significativa tanto em âmbito local quanto nacional, gerando impactos econômicos, sociais e ambientais substanciais, conforme destacado por Santos (2022). Nesse contexto, a estrutura organizacional e administrativa conhecida como Atalaia é responsável por promover, coordenar, controlar e prestar suporte ao serviço dos práticos às embarcações dentro de uma zona de praticagem, de forma eficiente e ininterrupta (NORMAM-311/DPC, 2026). Anualmente, observa-se um aumento significativo na quantidade de movimentações portuárias, conforme dados divulgados pela Agência Nacional de Transportes Aquaviários (ANTAQ, 2025), o que evidencia a crescente complexidade dos desafios enfrentados pelo setor e a necessidade de centros de controle preparados para cumprir suas responsabilidades de forma eficiente e eficaz.

A Sala de Controle da Atalaia, foco deste estudo, utiliza um sistema operacional baseado em planilhas personalizadas com macros, preenchidas manualmente pelos operadores. Esse processo culmina no envio de um e-mail contendo uma imagem estática de uma tabela, que apresenta as manobras realizadas no intervalo de maré atual, a previsão de manobras para os próximos intervalos de maré e a escala dos práticos em operação. Essa imagem constitui o principal recurso para informar os profissionais sobre as movimentações portuárias.

A experiência profissional do pesquisador no local, ao longo de mais de uma década, e seu interesse em contribuir para a adoção de novas tecnologias e aprimoramentos, revelaram que o processo de comunicação operacional era excessivamente manual, lento, suscetível a erros e dependente de retrabalho. Tal cenário gerava sobrecarga aos operadores e insatisfação entre os usuários finais. Observa-se que cerca de noventa e quatro por cento das planilhas em uso contêm erros (Poon et al., 2024), os quais nem sempre são facilmente identificáveis, e há uma excessiva confiança dos usuários, que desconhecem as falhas existentes (Panko, 2015). Embora o desenvolvimento de planilhas possua semelhanças com a programação, a engenharia de software se distingue pela aplicação de técnicas e metodologias fundamentadas e sistemáticas para a gestão de problemas complexos (Hermans e Murphy-Hill, 2015).

O estudo foi proposto após a constatação de que as ferramentas legadas em uso não atendem satisfatoriamente às demandas de qualidade exigidas de uma Atalaia. Justifica-se, portanto, a intenção de desenvolver um sistema com arquitetura de software alinhada às necessidades dos usuários (Keeling, 2017). Para abordar essa problemática, definiu-se a aplicação da metodologia Design Thinking, caracterizada por resolver problemas de forma criativa, com foco nas necessidades reais das pessoas e na identificação de soluções mais efetivas (Brown, 2020). Estudos empíricos recentes demonstram a eficácia dessa metodologia na promoção de criatividade e autoconfiança, contribuindo para o desenvolvimento de inovações (Rösch et al., 2023).

Este estudo teve como objetivo analisar e demonstrar de que maneira a aplicação dos princípios de Design Thinking pode contribuir para o desenvolvimento de um sistema capaz de suprir as exigências de qualidade de uma Atalaia e atender às necessidades de modernização dos processos operacionais de sua Sala de Controle, especificamente no que se refere à comunicação de informações requeridas pelos práticos para a adequada execução de suas atividades.

2. Material e Métodos

O presente estudo adotou a pesquisa-ação como estratégia metodológica, conforme preconizado por Thiollent (2025), que enfatiza a interação contínua entre o pesquisador e o contexto investigado. A concepção e a organização da pesquisa foram guiadas pela metodologia Design Thinking (DT), formalmente apresentada por Herbert Simon em 1969 e popularizada por Brown (2020). A abordagem seguiu as cinco fases propostas pelo Instituto de Design Hasso Plattner, que incluem empatia, definição, ideação, prototipação e teste (Gwangwava, 2021).

A investigação foi realizada na Sala de Controle de uma Atalaia, organização responsável pelo suporte ao serviço de praticagem. Os participantes foram divididos em dois grupos: o primeiro, composto por quatro operadores, representando um terço da equipe total da Atalaia; e o segundo, com três práticos, correspondendo a 10% do quadro de práticos da Zona de Praticagem (ZP) em questão. O critério de seleção dos participantes baseou-se na disponibilidade para colaborar com o estudo.

Na fase de empatia, procedeu-se ao levantamento da situação e das expectativas dos interessados, conforme sugerido por Häger et al. (2014). Os dados foram coletados por meio da vivência profissional do pesquisador, que atuou como operador na Sala de Controle por mais de uma década (entre 2009 e 2024). Adicionalmente, realizaram-se entrevistas etnográficas com operadores e práticos, e observações contextuais, incluindo a análise dos registros de todos os envios de relatórios de previsão de manobras no ano de 2025.

Para a fase de definição, analisou-se o material coletado com o objetivo de identificar oportunidades e problemas, empregando ferramentas e técnicas que estimulam a criatividade (Moreira, 2018). Este processo incluiu a definição de grupos de usuários, a elaboração de personas, o Mapa de Empatia, a Jornada da Persona, o Mapa de Afinidade, a ferramenta de Observações para Insights e as Perguntas Como Nós Poderíamos [CNP], conforme descrito por Vianna et al. (2012).

A fase de ideação concentrou-se na conceitualização de soluções a partir do entendimento dos problemas e das necessidades dos usuários. Para auxiliar na geração de ideias, aplicou-se a técnica de Brainstorming (Cavalcanti, 2026). Posteriormente, as ideias foram avaliadas e selecionadas utilizando-se a Matriz de Posicionamento por esforço e impacto, priorizando as soluções com maior potencial de impacto e menor demanda de recursos, conforme orientação de Vianna et al. (2012).

Na fase de prototipação, elaboraram-se esboços à mão de protótipos de baixa fidelidade, que serviram de base para a criação de modelos de alta fidelidade. Esses protótipos foram apresentados com visualização em dispositivos móveis, principal meio de acesso dos práticos. Desenvolveram-se interfaces para a alimentação do relatório, com um algoritmo para importação automática de dados do sistema interno, e um gerenciador de escala de serviço com funcionalidades de importação, arrastar e soltar, copiar, aplicar pontos e atualizar posições, visando otimizar o processo de atualização das previsões. A arquitetura Single Page Application (SPA) foi adotada para o desenvolvimento (Scott Junior, 2015; Torres, 2023).

A fase de teste envolveu a experimentação dos protótipos com usuários reais na Sala de Controle da Atalaia. Realizaram-se testes de usabilidade por meio da observação direta da interação dos usuários com os protótipos, e sessões de feedback para coletar opiniões e sugestões dos participantes. Os resultados foram sistematicamente registrados utilizando-se a Matriz de Feedback (Melo e Abelheira, 2015). Para análise quantitativa, cronometraram-se vinte testes de usabilidade com os quatro operadores participantes, comparando o tempo de preparação do relatório com o sistema em teste e com a planilha legada.

A funcionalidade offline do sistema foi viabilizada por meio da tecnologia Progressive Web App (PWA), permitindo o acesso às últimas informações armazenadas localmente, mesmo sem conexão à internet. Os operadores participaram de sessões individuais para avaliar a usabilidade da interface sem orientação prévia, o que permitiu identificar pontos de melhoria na disposição dos menus, localização de funções, nomenclatura de botões e clareza das mensagens de erro, resultando em revisões e simplificações iterativas.

3. Resultados e Discussão

A análise inicial do processo de comunicação operacional na Atalaia, fundamentada na vivência profissional do pesquisador e em entrevistas com operadores e práticos, revelou um cenário de ineficiência e insatisfação. Observou-se que a Sala de Controle utilizava uma planilha Excel com macros, desenvolvida por um operador em 2010, para gerenciar e comunicar as previsões de manobras. Essa ferramenta, embora tenha sido uma inovação na época, apresentava limitações significativas, como a dependência de um único programador para manutenção e a suscetibilidade a erros causados por alterações não intencionais dos usuários. A experiência prática do pesquisador, que atuou na Sala de Controle por quinze anos, entre 2009 e 2024, permitiu uma compreensão aprofundada das interações e dos desafios enfrentados diariamente.

A planilha de previsão de manobras, considerada a síntese das informações mais relevantes para os práticos, continha detalhes sobre quatro marés, amplitude, horários, nomes de navios, créditos, práticos escalados e suas pontuações, além de escalas de serviço e campos para avisos. As automações implementadas, como autoformatação, exportação para imagem e criação de e-mails, visavam otimizar o processo. Contudo, o preenchimento manual dos dados, copiados de um sistema web complexo, era demorado e propenso a falhas, gerando reclamações e conflitos. A atualização da planilha ocorria a cada três horas ou sempre que havia mudanças, sendo o envio feito por imagem JPEG via e-mail e plataforma web, o que, embora proporcionasse registro histórico, não resolvia a questão da dinamicidade das informações.

Os dados coletados por meio de entrevistas foram agrupados por afinidade, revelando as “dores” e “desafios” dos operadores e práticos. Os operadores expressaram preocupação com o tempo consumido no preenchimento manual e repetitivo, a fragilidade da ferramenta atual e a constante possibilidade de erros humanos. A previsão de manobras, embora central, era um processo manual intensivo, que exigia a cópia de dados do sistema web para a planilha, com digitação de informações como maré, horário, altura, amplitude e detalhes de cada manobra. Essa complexidade, somada a procedimentos diferenciados para alguns práticos, aumentava a propensão a erros e a burocracia.

Em relação aos critérios de tomada de decisão, a priorização de tarefas era guiada por fatores como risco, tempo e impacto operacional, destacando a natureza crítica do setor. A urgência estava ligada a prazos curtos e à necessidade de agilidade na comunicação com práticos, navios, lanchas e rebocadores. A segurança era um fator primordial, envolvendo o acompanhamento de movimentações e a comunicação via rádio VHF. As expectativas dos operadores para uma nova ferramenta incluíam modernização, fluxos de trabalho mais curtos e uma interface dinâmica e intuitiva, com automação da previsão de manobras para liberar tempo e foco para atividades de maior valor.

No grupo dos práticos, os desafios concentravam-se na acessibilidade, confiabilidade e completude das informações. A conectividade inconstante à internet no mar os forçava a solicitar a previsão como arquivo de imagem por e-mail ou aplicativo de mensagens. A natureza dinâmica da previsão, com frequentes mudanças de manobras, horários e pontuações, gerava dependência contínua da Atalaia e impactava o planejamento. Problemas de confiabilidade, como pontuações incorretas ou horários desatualizados, eram frequentemente mencionados. Os práticos valorizavam profissionalismo, agilidade, precisão, clareza e consistência, características essenciais para a segurança e eficiência das operações.

As necessidades dos práticos iam além das informações contidas na planilha atual, abrangendo dados como porte bruto (DWT), calado, ponto de embarque, carga segura dos cabeços e quantidade de rebocadores recomendada. A altura das marés e o histórico de falhas dos navios também foram citados como informações relevantes, que atualmente só eram obtidas por requisição direta à Atalaia. Desejos como notificações de atualização, chat dedicado e repositório de documentos indicavam a busca por um sistema mais abrangente e interativo. Contudo, a pesquisa também revelou resistência à mudança por parte de práticos mais experientes, que preferiam a manutenção do formato atual, apesar de reconhecerem suas deficiências.

A análise quantitativa dos logs de registro de previsões, referentes ao ano de 2025, demonstrou a intensidade do fluxo de trabalho na Atalaia. Foram registrados 7.937 envios, com uma média de 21,7 envios por dia e um intervalo médio de 1 hora e 6 minutos entre eles. Desconsiderando as 933 ocorrências de envios com intervalo inferior a 10 minutos, que configuravam correções e representavam 11,8% do total, o número anual de previsões ajustado foi de 7.004, com uma média diária de 19,2 envios e um intervalo médio de 1 hora e 15 minutos. A presença de 290 ocorrências com intervalo superior a 3 horas, representando 4,1% do total, evidenciou gargalos operacionais, especialmente considerando a orientação de um envio a cada três horas.

Fase 2: Definição

Na fase de Definição, o objetivo foi interpretar e dar sentido às informações coletadas, identificando padrões e necessidades latentes. A construção de personas, como Bárbara (operadora) e Kennedy (prático), permitiu compreender as características pessoais, sociais, profissionais e intelectuais dos usuários. Bárbara, de 35 anos, extrovertida e comunicativa, desejava um trabalho mais simples, sem erros, e sentia-se sobrecarregada e desmotivada pela complexidade dos sistemas e pela percepção de ser culpabilizada por falhas. Kennedy, de 60 anos, sério e profissional, buscava informações atualizadas e corretas para realizar manobras com precisão, mas se frustrava com a demora nas atualizações e os erros frequentes nos relatórios.

O Mapa de Empatia aprofundou a compreensão das percepções e comportamentos. Os operadores expressaram que seu trabalho exige muita atenção para evitar erros, buscam constantemente informações e preenchem planilhas manualmente. Eles pensam que se esforçam, mas a precisão é quase impossível, sentindo-se injustamente culpabilizados e desmotivados. Os práticos, por sua vez, desejam mais informações e diligência da Atalaia, buscando atualizações frequentes e acessando sistemas internos, mas sentem insegurança com a previsão de manobras e frustração com o comprometimento da Atalaia. Essa ferramenta revelou que, apesar dos esforços dos operadores, a complexidade dos processos dificultava o cumprimento de suas tarefas, enquanto os práticos buscavam informações seguras e atualizadas.

A jornada da persona do operador, detalhada na Tabela 4, evidenciou a complexidade do trabalho, que envolve múltiplas tarefas interdependentes e exige atenção constante. A impossibilidade de exportar dados do sistema principal forçava o preenchimento manual de planilhas, aumentando o risco de erros e retrabalho. A comunicação com práticos e agentes era crucial para garantir o respeito às preferências e a aplicação correta das normas. A necessidade de repetição e atualização constante das previsões, devido às frequentes mudanças operacionais, gerava sobrecarga e pressão. A jornada do operador apontou oportunidades claras de melhoria na automação, integração de sistemas e comunicação, visando reduzir erros e otimizar o tempo.

A jornada da persona do prático, apresentada na Tabela 5, revelou um fluxo de trabalho dinâmico que exige organização, flexibilidade e comunicação eficaz com a Atalaia. Os práticos enfrentavam desafios relacionados à imprevisibilidade de horários e à necessidade de planejamento prévio, sendo fundamental monitorar as informações mais recentes. A decisão sobre onde permanecer após o serviço dependia do agendamento do próximo trabalho, indicando que a jornada se estendia além da execução. Essa análise destacou oportunidades de automação na comunicação e atualização de informações, o que poderia reduzir o retrabalho e otimizar o tempo do prático, aprimorando sua experiência e a eficiência do sistema.

O Mapa de Afinidade, sintetizado nas Tabelas 6 e 7, agrupou os relatos por características comuns. Para os operadores, as “sobrecargas” incluíam o desejo por um trabalho mais simples, o retrabalho constante devido a mudanças nas previsões e a dificuldade de atualizar escalas manualmente. Os “desafios” envolviam a necessidade de enxugar procedimentos, o tempo gasto no preenchimento manual, a antecipação de cenários e a complexidade do sistema. As “cobranças” focavam na atualização dos práticos e na aplicação de normas, enquanto os “temores” abrangiam a negligência de informações, o desconforto em propor melhorias e a crença de que a culpa é sempre do operador.

Para os práticos, as “necessidades” incluíam o suporte da Atalaia durante as manobras e o acesso offline à previsão. As “insatisfações” eram a falta de aviso prévio para o trabalho noturno e os erros de pontuação e escala. As “carências” apontavam para a necessidade de uma interface mais eficiente, mais informações sobre operações de terminais, balizamento e histórico de falhas. Os “costumes” revelavam a frequência com que consultavam o relatório e a preferência por não haver mudanças, apesar de buscarem erros. Essa etapa de Definição, portanto, consolidou a compreensão de que as ferramentas existentes eram insuficientes, gerando insatisfação e desconfiança, e que a automação era crucial para mitigar erros e otimizar o tempo.

Fase 3: Ideação

A fase de Ideação teve como objetivo conceitualizar soluções a partir do entendimento aprofundado dos problemas e das necessidades dos usuários. A ferramenta Brainstorming foi aplicada para gerar uma ampla gama de ideias, conforme apresentado na Tabela 10. As propostas abrangeram desde o aprimoramento da planilha existente, com verificação automática de erros, até o desenvolvimento de um sistema sob medida que facilitasse o preenchimento e a validação de dados. Outras ideias incluíram a solicitação de ferramentas de exportação de dados ou acesso ao banco de dados do sistema interno, a criação de algoritmos para extração de informações e o desenvolvimento de um sistema capaz de gerenciar múltiplos cenários de maré.

Para mitigar erros relacionados às normas técnicas, foram sugeridas funções na planilha ou um sistema dedicado para avaliar os dados do relatório de previsão de manobras. A questão do acesso offline foi abordada com a ideia de enviar a previsão automaticamente por aplicativos de mensagens ou desenvolver um sistema com capacidade de funcionamento sem acesso à internet, como um Progressive Web App (PWA). Para melhorar a qualidade e confiabilidade das informações, propôs-se um sistema que validasse os dados e permitisse aos práticos consultar atualizações em tempo real. A disponibilização de mais informações sem sobrecarregar a interface foi pensada por meio de recursos interativos ou relatórios adicionais, e a visualização das previsões poderia ser oferecida em múltiplas formas, incluindo uma que mimetizasse a planilha atual.

A Matriz de Posicionamento por Esforço e Impacto, exibida na Tabela 11, foi utilizada para selecionar as ideias mais promissoras, priorizando aquelas com maior impacto e menor esforço, dada a condução individual do projeto. Ideias como o desenvolvimento de um sistema sob medida, a criação de um algoritmo para extração de dados e a implementação de um sistema com capacidade offline foram classificadas como de alto impacto. Embora a possibilidade de aprimorar a planilha Excel ou consultar a empresa do software principal tenha sido considerada, a preferência dos operadores por uma solução customizada e a recusa da empresa em desenvolver novas funcionalidades direcionaram o foco para a criação de um novo sistema.

Fase 4: Prototipação

Na fase de Prototipação, foram desenvolvidos protótipos de baixa e alta fidelidade para visualizar as soluções propostas. Inicialmente, esboços à mão orientaram a criação de modelos mais detalhados. Em seguida, protótipos de alta fidelidade, como os apresentados na Figura 3, foram exibidos em prévias para dispositivos móveis, reconhecendo que esta é a principal forma de acesso dos práticos. A nova abordagem de visualização apresentava as previsões de manobras de forma dinâmica, permitindo interatividade, como o arrasto de quadros de evento de maré para revelar as escalas de serviço correspondentes, exibindo o estado anterior e posterior às manobras. Essa configuração otimizou a leitura e permitiu a inclusão de informações adicionais sem sobrecarregar a interface.

As apresentações dos protótipos geraram sugestões de gestores, práticos e operadores sobre indicadores visuais, cores e tamanhos de fonte. Foi proposta uma alternativa de visualização com menos detalhes, além da versão que simulava a planilha Excel, para atender a preferências individuais e proporcionar uma visão geral mais limpa. Em reuniões subsequentes, foram incorporadas funcionalidades como o compartilhamento de observações importantes e a fixação de avisos críticos na interface. Também foram apresentados esboços para telas grandes, demonstrando a adaptação dinâmica e responsiva da interface para os monitores da Sala de Controle, que exibiriam as previsões de manobras juntamente com o quadro de avisos e observações.

A terceira reunião de apresentação focou na experiência do operador, exibindo interfaces para a alimentação do relatório. Destacou-se o recurso de importação automática de informações por meio de um algoritmo que extraía dados da página de visualização de manobras do sistema interno. Foi apresentado um gerenciador de escala de serviço com funcionalidades como importar, arrastar e soltar, copiar, aplicar pontos e atualizar posições conforme as normas. Essas soluções foram implementadas para otimizar o processo contínuo de atualização das previsões, tornando-as instantaneamente disponíveis aos práticos e liberando os operadores para outras demandas operacionais, evidenciando o potencial da prototipação para refinar e validar as ideias.

Fase 5: Teste

A fase de Teste foi crucial para validar as soluções propostas, envolvendo a experimentação com usuários reais na Sala de Controle da Atalaia. Os testes de usabilidade resultaram na criação de experiências intuitivas e eficientes, um aspecto fundamental para o sucesso de iniciativas digitais (Melo e Abelheira, 2015). Os usuários foram convidados a compartilhar suas impressões, incluindo elogios, críticas e dúvidas, que foram sistematicamente anotadas na Matriz de Feedback, conforme o modelo exibido na Figura 4. Essa abordagem iterativa permitiu aprimorar continuamente o desenvolvimento da interface, tornando-a simples, objetiva e intuitiva.

Sob a ótica da engenharia de software, a adoção da arquitetura Single Page Application (SPA) foi fundamental para o desempenho, escalabilidade e experiência do usuário. Conforme Scott Junior (2015) e Torres (2023) apontam, a SPA promove eficiências no design, manutenção de código e tempo de desenvolvimento, permitindo que atualizações e navegação sejam processadas localmente, reduzindo recarregamentos de página e latência percebida. Essa arquitetura viabilizou interfaces modernas e funcionalidades dinâmicas, como atualização automática de dados e gerenciamento em tempo real, alinhando-se aos requisitos identificados nas fases anteriores do projeto.

As sessões individuais de usabilidade com os operadores revelaram dificuldades iniciais na localização de funções e nomenclatura de botões, o que levou à criação de atalhos, reorganização de menus, revisão de textos e simplificação de instruções. Após os ajustes, os operadores expressaram satisfação, especialmente com as funções de importação automática de dados, que proporcionaram maior disponibilidade para outras atividades. A simplificação na atribuição de práticos e a geração automática de escalas, com cálculo correto de pontuações e ajuste de posições, foram destacadas. A navegação facilitada e a visualização intuitiva das previsões contribuíram para uma experiência mais eficiente, com potencial para agilizar o processo, reduzir erros e otimizar recursos cognitivos.

Para uma análise quantitativa, foram cronometrados vinte testes de usabilidade com os quatro operadores, comparando o tempo médio gasto na preparação do relatório de previsão de manobras entre o método da planilha Excel e o novo sistema. Os resultados, ilustrados na Figura 5 do TCC original, evidenciaram uma redução de 82% no tempo médio, que passou de 11,4 minutos no Excel para apenas 1,6 minuto no sistema SPA. Essa economia de tempo, aliada à melhoria da precisão dos dados e à diminuição da sobrecarga nas caixas de entrada dos destinatários, reforça a importância da nova ferramenta para otimizar o fluxo de trabalho da Atalaia, que registrou 7.937 envios de previsões em 2025, com um intervalo médio de 1 hora e 6 minutos.

O acesso dos práticos ao sistema foi simplificado e limitado à consulta das informações da previsão de manobras e das observações. Diversos ciclos de testes com os práticos resultaram em quatro modelos distintos de visualização do relatório de previsão, sendo dois deles com opções adicionais de exibição. O modo de visualização que simulava a estrutura da planilha foi finalizado com precisão e correspondeu às expectativas dos usuários familiarizados com esse formato, proporcionando acesso imediato à versão mais atualizada do relatório e eliminando a necessidade de aguardar envios por e-mail ou aplicativos de mensagens. A funcionalidade offline, viabilizada pela tecnologia Progressive Web App (PWA), permitiu acesso ágil e eficiente ao sistema mesmo sem conexão à internet, carregando as últimas informações armazenadas localmente e oferecendo notificações, além da possibilidade de instalar um atalho na tela inicial dos dispositivos móveis.

Em síntese, a aplicação da metodologia Design Thinking permitiu uma compreensão aprofundada das ineficiências e necessidades do processo de comunicação operacional na Atalaia. O desenvolvimento de um protótipo web centrado no usuário, com importação automática de dados, múltiplas formas de visualização e acesso offline, demonstrou uma redução de 82% no tempo médio de preparação do relatório, passando de 11,4 para 1,6 minuto. Essa solução representa um avanço significativo na modernização do processo, prevenção de erros, aumento da eficiência e melhoria da qualidade da comunicação operacional, atendendo aos objetivos de modernização e qualidade da Atalaia.

4. Conclusão

Este estudo analisou a aplicação dos princípios de Design Thinking para o desenvolvimento de um sistema capaz de suprir as exigências de qualidade e modernizar os processos de comunicação operacional da Sala de Controle de uma Atalaia, focando nas informações requeridas pelos práticos. Verificou-se que o processo anterior, baseado em planilhas com macros e e-mails, era manual, lento, propenso a erros e gerava sobrecarga aos operadores e insatisfação aos usuários. A metodologia Design Thinking, com suas fases de empatia, definição, ideação, prototipação e teste, permitiu uma compreensão aprofundada das necessidades e desafios dos envolvidos. Como resultado, desenvolveu-se um protótipo web centrado no usuário, que incorporou importação automática de dados, múltiplas formas de visualização e acesso offline. Nos testes de usabilidade, observou-se uma redução de 82% no tempo médio de preparação do relatório, que passou de 11,4 para 1,6 minuto, demonstrando um avanço significativo na eficiência operacional e na qualidade da comunicação.

Apesar do potencial transformador da solução, o produto não foi integralmente concluído até o encerramento deste trabalho, e identificou-se certa resistência à mudança por parte de práticos mais experientes. Contudo, a aplicação do Design Thinking contribuiu para modernizar o processo, prevenir erros e aumentar a eficiência, além de ampliar a qualidade da comunicação operacional. Recomenda-se a conclusão do desenvolvimento e a implantação da solução em ambiente operacional real para avaliações longitudinais de desempenho, usabilidade e aceitação. Sugere-se, ainda, investigar a integração com o sistema interno da Atalaia para reduzir redundâncias e explorar funcionalidades complementares, como notificações em tempo real e mecanismos de validação de regras operacionais, bem como pesquisas futuras para mensurar o impacto em indicadores como tempo de atualização e satisfação dos usuários.

Referências Bibliográficas

ANTAQ, 2025 [Referência completa não encontrada no documento original]

Brown, T. 2020. DT: uma metodologia poderosa para decretar o fim das velhas ideias. Alta Books, Rio de Janeiro, RJ, Brasil.

Cavalcanti, C.; Filatro, A. 2026. Design thinking: inovação com propósito. 2ed. Atlas, Barueri, SP, Brasil. Disponível em: <https://amz.onl/01Z6zAXg>. Acesso em: 6 mar. 2026.

Gwangwava, N. 2021. Learning Design Thinking Through a Hands-On Learning Model. International Journal of Innovative Teaching and Learning in Higher Education. 2(1): 1-19. Disponível em: <https://doi.org/10.4018/IJITLHE.20210101.oa4>. Acesso em: 14 dez. 2025.

Hermans, F.; Murphy-Hill, E. 2015. Enron’s Spreadsheets and Related Emails: a dataset and analysis. In: IEEE/ACM 37th IEEE International Conference on Software Engineering, 2015, Florence, Italy. Anais… p. 7-16

Häger, F.; Kowark, T.; Krüger, J.; Vetterli, C.; Übernickel, F.; Uflacker, M. 2014. DT@Scrum: integrating design thinking with software development processes. p. 263-289. In: Plattner, H.; Meinel, C.; Leifer, L. Design Thinking Research: understanding innovation. Springer, Cham, Zug, Switzerland. Disponível em: <https://doi.org/10.1007/978-3-319-06823-7_14>. Acesso em: 11 jan. 2026.

Keeling, M. 2017. Design It!: from programmer to software architect. The Pragmatic Programmers, Raleigh, NC, EUA. Disponível em: <https://amz.onl/0ecF8PP4>. Acesso em: 7 abr. 2026.

Marinha do Brasil. 2026. Portaria DPC/DGN/MB n° 199, de 27 de janeiro de 2026. Aprova as Normas da Autoridade Marítima para o Serviço de Praticagem – NORMAM-311/DPC. Diário Oficial da União, Brasília, 29 de janeiro de 2026, Seção 1, p. 31.

Melo e Abelheira, 2015 [Referência completa não encontrada no documento original]

Moreira, B.R. 2018. Guia Prático do DT: aprenda 50 ferramentas para criar produtos e serviços inovadores. Kindle Edition. Disponível em: <https://amz.onl/0aExXth7>. Acesso em: 2 mar. 2026.

Panko, R. 2015. What We Don’t Know About Spreadsheet Errors Today: the facts, why we don’t believe them, and what we need to do. In: 16th European Spreadsheet Risks Interest Group Annual Conference: spreadsheet risk management, 2015, Moorgate, London, England. Anais… p. 73-87.

Poon, P.; Lau, M.; Yu, Y.; Tang, S. 2024. Spreadsheet quality assurance: a literature review. Frontiers of Computer Science 18, (182203). Disponível em: <https://doi.org/10.1007/s11704-023-2384-6>. Acesso em: 6 abr. 2026.

Rösch N.; Tiberius V.; Kraus S. 2023. Design thinking for innovation: context factors, process, and outcomes. European Journal of Innovation Management, 26(7): 160-176. Disponível em: <https://doi.org/10.1108/EJIM-03-2022-0164>. Acesso em: 14 dez. 2025.

Santos, T. 2022. Relação Porto-Cidade: Sustentabilidade – Porto de Santos. Dialética, São Paulo, SP, Brasil.

Scott Junior, E. 2015. SPA Design and Architecture: Understanding single-page web applications. Manning, Shelter Island, NY, EUA.

Thiollent, M. 2025. Metodologia da pesquisa-ação. 19ed. Cortez Editora, São Paulo, SP, Brasil. Disponível em: <https://amz.onl/0erEjoJ8>. Acessado em: 2 jan. 2026.

Torres, Fernando. 2023. Single Page Application. Senac, São Paulo, SP, Brasil. Disponível em: <https://amz.onl/0aEx6QI0>. Acesso em: 04 fev. 2025.

Vianna, M.; Vianna, Y.; Adler, I.; Lucena, B.; Russo, B. 2012. DT: Inovação em negócios. 2ed. MJV Press, Rio de Janeiro, RJ, Brasil.

Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy

Você também pode gostar

Engenharia De Software

09 de outubro de 2026

O papel da densidade de texto instrutivo na eficiência de uma aplicação web.

O desenvolvimento de aplicações web se conecta à experiência do usuário, e este trabalho investigou como o uso excessivo de textos instrutivos pode retardar a conclusão de tarefas e impactar a eficiência da aplicação. O objetivo foi identificar o impacto da densidade textual do conteúdo instrutivo na eficiência de uma aplicação web, utilizando como principal referência a terceira lei de usabilidade de Krug. A pesquisa, de caráter exploratório e delineamento experimental quantitativo, empregou um teste A/B em uma aplicação web responsiva, onde a única variável controlada foi a densidade textual (alta vs. baixa, definida pela contagem de palavras). Participaram 25 usuários, e os dados foram coletados via Datadog RUM, mensurando tempo de conclusão, erros de submissão e taxa de conversão. Os resultados revelaram que a variante com densidade textual reduzida (variante B) apresentou uma taxa de conversão superior (58,3% contra 33,3% da variante A) e um tempo médio de conclusão significativamente menor (1:38 minutos contra 4:58 minutos da variante A), representando um aumento de 67,12% na eficiência. O teste t de Welch (p=0,042) confirmou que a redução da densidade textual impactou a eficiência. Concluiu-se que a redução da densidade textual afeta a eficiência e a taxa de conversão, reforçando a importância de conteúdo objetivo e conciso. Contudo, a baixa densidade textual, por si só, não garantiu o pleno entendimento, sendo essencial a comunicação clara e objetiva das instruções, validando a relevância do UX Writing.

Palavras-chave: Eficiência; Experiência de usuário; Teste A/B; Texto Instrutivo; Usabilidade.

Engenharia De Software

09 de outubro de 2026

Implementação de sistemas de analytics em ambientes de automação na indústria de processos

A digitalização de plantas de processo depende de coleta e armazenamento estruturados de dados, sem os quais não há visibilidade da operação. Chama-se analytics industrial a cadeia que percorre esses dados desde a aquisição do sinal no instrumento de campo, passando pelo armazenamento ordenado no tempo, até a disponibilização para análise e para outros sistemas. Softwares industriais proprietários cobrem hoje essa cadeia, e os custos de licenciamento e manutenção restringem sua adoção. O estudo teve por objetivo arquitetar, implementar e validar um sistema dessa natureza, empregando técnicas correntes de desenvolvimento de software e componentes sem custo de licenciamento. O sistema, denominado Sistema de Aquisição e Tratamento de Informações de Processo (SATIP), foi estruturado em três camadas independentes, tendo como fonte de dados um simulador de reator farmacêutico que executou uma receita de oito etapas e gerou séries temporais com variação estocástica. O simulador foi escrito em Go, linguagem adotada por gerar binários autocontidos, adequados à execução em equipamentos de borda. O armazenamento utilizou o TimescaleDB e a disponibilização foi realizada por meio de uma interface REST com um painel web. O sistema processou cerca de 414 mil registros por execução, com tendência multivariável, registro de alarmes e correlação temporal entre instrumentos. A arquitetura mostrou-se reproduzível e sem custo de licenciamento, e a identificação da degradação exigiu apenas as leituras já armazenadas pelo sistema.

Palavras-chave: Arquitetura de software; Digitalização; Integração IT/OT; Manutenção preditiva; Séries temporais.

Engenharia De Software

09 de outubro de 2026

Utilização da voz em conjunto a grandes modelos de linguagem como ferramenta à acessibilidade digital

A fala é uma base essencial para a interação humana, e para pessoas com deficiência, pode representar a principal forma de comunicação com o ambiente externo. Diante da crescente influência tecnológica, a identificação de comandos de voz emergiu como uma estratégia promissora para a interação homem-máquina. O trabalho explorou como a voz, em conjunto com Grandes Modelos de Linguagem (LLMs), pode ser utilizada de forma eficiente, natural e precisa. Para tal, empregaram-se diversos padrões de projetos e a linguagem Python, visando maior extensibilidade. Utilizou-se o Gemini como provedor de LLM, enviando o áudio diretamente e aproveitando sua capacidade de chamada de função para interagir com o dispositivo. Desenvolveu-se um sistema capaz de compreender a intenção do usuário e convertê-la em ações, cujo diferencial foi a capacidade de visão computacional baseada em capturas de tela e um sistema de malha para orientação da LLM. Os testes revelaram uma taxa de compreensão da intenção do usuário de 91,81% e uma taxa de sucesso na execução de 75,45% com o modelo “Flash-3” (top p 0,5 e top k 5). O sistema proposto validou a premissa de que a integração de LLMs a interfaces de voz aumenta a autonomia de usuários com deficiência motora, cumprindo o propósito de ser uma Tecnologia Assistiva moderna e eficaz. Contudo, foram levantadas questões sobre os custos da IA e a segurança dos dados do usuário, indicando a necessidade de aprimoramento.

Palavras-chave: Chamada de função; Interação homem-máquina; Reconhecimento de voz; Visão computacional.

Engenharia De Software

09 de outubro de 2026

ReasonGuard: Uma Plataforma de Auditoria de Raciocínio para Modelos de Linguagem Baseada em Decomposição Estruturada de Pensamento

Apresentou-se o ReasonGuard, uma plataforma de auditoria de raciocínio de Inteligência Artificial, desenvolvida como middleware de observabilidade entre aplicações cliente e modelos de linguagem de grande escala (LLMs). O trabalho teve como objetivo oferecer transparência e rastreabilidade para processos de tomada de decisão baseados em IA, abordando a lacuna na operacionalização de técnicas de raciocínio estruturado para fins de auditoria. O sistema interceptou, analisou e documentou interações com LLMs por meio de cinco módulos fundamentados nos paradigmas Chain-of-Thought (CoT), Tree-of-Thought (ToT) e Graph-of-Thought (GoT). Esses módulos capturaram trilhas de raciocínio, detectaram falhas lógicas estruturais, avaliaram a consistência de respostas e geraram relatórios de auditoria direcionados a diferentes perfis de stakeholders. A plataforma implementou-se com FastAPI (Python) no backend, React com TypeScript no frontend e PostgreSQL como banco de dados relacional, seguindo arquitetura modularizada com isolamento multitenancy por usuário. Os resultados demonstraram a viabilidade técnica da abordagem proposta, com todos os cinco módulos operacionais e integrados. Concluiu-se que o ReasonGuard contribui para a governança de IA ao instrumentalizar paradigmas de raciocínio estruturado como ferramentas de observabilidade e auditoria, preenchendo uma lacuna na literatura.

Palavras-chave: Auditoria de IA; Chain-of-Thought; Governança de IA; Modelos de Linguagem de Grande Escala; Transparência Algorítmica.

Engenharia De Software

09 de outubro de 2026

EngTT: software para motor de frete rodoviário baseado em custos operacionais e parâmetros ANTT

O transporte rodoviário representa a principal modalidade logística do Brasil, com a composição dos custos de frete regulada pela Agência Nacional de Transportes Terrestres (ANTT). Diante da ausência de uma metodologia estruturada para o cálculo de frete e da dependência de planilhas isoladas no setor, desenvolveu-se o software EngTT. O objetivo foi criar uma ferramenta de apoio à decisão que integrasse variáveis operacionais, calculasse o custo total por rota e comparasse os resultados com o piso mínimo da ANTT, identificando cenários de não conformidade e compressão de margem antes da precificação. A metodologia adotada foi aplicada, quantitativa e experimental, com construção incremental orientada ao conceito de Produto Mínimo Viável (MVP). O sistema foi estruturado em três modos de uso – Montar Rota Visual, Batch por planilha e Scrape de rotas – compartilhando um motor de cálculo desacoplado e parâmetros centralizados. Os resultados obtidos demonstraram que o software atendeu ao objetivo proposto, evidenciando variações de margem e conformidade regulatória entre as rotas analisadas. Observou-se que rotas de maior extensão, como Ribeirão Preto × Guarujá, apresentaram incremento de custo devido à necessidade de diárias adicionais do motorista, enquanto rotas mais curtas, como Cajamar × Guarujá, mostraram maior aderência ao piso regulatório da ANTT. Concluiu-se que a solução desenvolvida é aplicável ao setor de transporte rodoviário de cargas como ferramenta eficaz de precificação e gestão operacional.

Palavras-chave: ANTT; Carga conteinerizada; Engenharia de software; Frete rodoviário; Python.

Engenharia De Software

08 de outubro de 2026

Pipeline de dados para o monitoramento de ações considerando a metodologia fundamentalista

O cenário financeiro brasileiro enfrenta desafios como o endividamento familiar, a baixa literacia financeira e a descentralização de informações para análise de investimentos. Diante disso, o objetivo da pesquisa consistiu em desenvolver um pipeline de dados financeiros, fundamentado em boas práticas de Engenharia de Dados, para estruturar, processar e disponibilizar informações relevantes que apoiassem a tomada de decisão de investidores individuais na análise de ações. Implementou-se uma arquitetura medalhão, utilizando MinIO S3 para armazenamento em camadas bronze, silver e gold, com Delta Lake para governança de dados. Empregou-se Apache Spark para processamento distribuído, Prometheus para monitoramento e Power BI para visualização analítica. Os dados foram majoritariamente demonstrações financeiras da Comissão de Valores Mobiliários (CVM). Construiu-se uma carteira teórica de investimentos com base nos princípios de Benjamin Graham (2017), aplicando filtros de seleção e validação de dados. Os resultados indicaram um retorno positivo de 32,88% para a carteira teórica, superando o índice Ibovespa (4,25%) no período de 2021 a 2024, embora inferior à taxa Selic (46,96%). Qualitativamente, o pipeline processou conjuntos de dados volumosos, com reduções significativas de redundâncias, como 99,27% na tabela BPA e 94,29% na DRE, após a aplicação de filtros. Evidenciaram-se ganhos em organização, rastreabilidade e qualidade dos dados, possibilitando análises financeiras estruturadas e mais robustas.

Palavras-chave: Arquitetura Medalhão; Engenharia de Dados; Investimentos; Pipeline de Dados.

Engenharia De Software

08 de outubro de 2026

Desempenho e Custo Total de Propriedade de Bancos de Dados em Nuvem e Infraestrutura Local

O presente estudo analisou o desempenho de operações de banco de dados em infraestruturas de nuvem e local, correlacionando o comportamento técnico com a projeção do Custo Total de Propriedade. A pesquisa caracterizou-se como um estudo quantitativo e experimental, no qual um sistema de testes submeteu instâncias isoladas de bancos de dados a cargas progressivas de execução, mensurando o impacto da latência de rede e do consumo computacional. Para a análise financeira, elaborou-se uma modelagem de investimentos e despesas operacionais diluídos em um ciclo de trinta e seis meses. Os resultados técnicos revelaram que o acúmulo da latência da internet causou severa degradação de tempo nas execuções em nuvem, apesar de a infraestrutura remota operar com alta ociosidade de processamento, registrando quase 98% de inatividade da CPU. Em contrapartida, o ambiente local obteve desempenho superior amparado pela comunicação de rede quase instantânea. No aspecto financeiro, a consolidação dos custos demonstrou um empate empírico entre o modelo de aquisição física e o de assinatura de serviço em um horizonte de três anos, mas o ambiente local mostrou-se mais vantajoso em um ciclo de sessenta meses. Concluiu-se que a degradação na nuvem não decorreu da capacidade computacional, mas da interação entre a latência de rota e o padrão de comunicação unitário da aplicação. A adoção da nuvem exige otimização profunda da arquitetura do sistema para minimizar a dependência de comunicação constante com o servidor remoto. Sem essa modernização, a infraestrutura local consolidou-se como a estratégia mais viável, garantindo alto desempenho, previsibilidade orçamentária e soberania dos dados.

Palavras-chave: Despesas operacionais (OPEX); Escalabilidade transacional; Latência de rede; Sistemas legados.

Engenharia De Software

08 de outubro de 2026

Integração assíncrona Slack-Jira via “middleware” de filas: comparação de soluções de “cloud computing”

A latência e a interoperabilidade entre sistemas corporativos distribuídos constituíram o problema investigado, motivado pelos custos e fragilidades das integrações manuais entre plataformas de colaboração e gestão de projetos. Desenvolveu-se e validou-se um “middleware” de integração assíncrona entre Slack e Jira, com o objetivo de reduzir o tempo de resposta percebido pelo usuário e garantir a estabilidade do sistema sob carga. A metodologia consistiu na construção de uma arquitetura de software orientada a eventos em Python, utilizando os padrões “producer-consumer” e “adapter” para isolar a interface do usuário do processamento de “backend”. A solução evoluiu para uma arquitetura agnóstica de nuvem, baseada em funções “serverless”, e foi submetida a testes de estresse em ambientes local, de rede real e de produção em duas nuvens. A arquitetura reduziu o tempo de espera do usuário de uma estimativa síncrona de 2.000 milissegundos para uma média local de 8,96 milissegundos. Sob carga de 50 requisições simultâneas, ambos os provedores de nuvem mostraram-se viáveis: a Amazon Web Services registrou menor latência média na camada de recepção (951,35 ms) e o dobro da vazão, enquanto a Microsoft Azure executou o processamento em segundo plano com mediana de 113 ms. A aplicação de “optimistic UI” assegurou fluidez de uso, e o nivelamento de carga por filas dispensou o sobredimensionamento de infraestrutura. O “middleware” consolidou-se como um modelo de referência corporativa escalável, resiliente e protegido contra o aprisionamento tecnológico.

Palavras-chave: Arquitetura orientada a eventos; Desacoplamento temporal; Eficiência operacional; Gestão de serviços de tecnologia da informação; Interoperabilidade de sistemas.

Inscreva-se em nossa newsletter!

Receba conteúdos e fique sempre atualizado sobre as novidades em gestão, liderança e carreira com a Revista E&S.

Ao preencher o formulário você está ciente de que podemos enviar comunicações e conteúdos da Revista E&S. Confira nossa Política de Privacidade