Projeto de Extensão
em Análise e Desenvolvimento de Sistemas

O desfecho mais comum: o sistema que ninguém mantém

A tentação de quem estuda tecnologia é resolver o problema construindo. Uma ONG sem controle de doações ganha um sistema de doações; um pequeno negócio sem agenda ganha um agendador. A entrega impressiona no relatório e some da vida real em poucos meses.

O que acontece é sempre parecido: a hospedagem gratuita expira, o número de telefone que recebia as notificações muda, o único computador que rodava aquilo é formatado, ou simplesmente surge uma dúvida que ninguém ali sabe responder. Do outro lado, quem recebeu o sistema fica em situação pior do que antes, porque abandonou o método antigo confiando no novo.

Reconhecer isso cedo muda a pergunta que você leva ao local. Não é o que eu poderia construir para vocês, e sim o que vocês conseguem manter sozinhos depois que eu sair.

Por que a oficina costuma render mais que o software

Ação de formação não expira. Uma tarde ensinando um grupo a reconhecer golpe por mensagem, a configurar verificação em duas etapas ou a organizar arquivos em nuvem deixa capacidade instalada em pessoas, não em infraestrutura.

Há um bônus para o seu relatório: a atividade formativa produz evidência limpa e observável — material de apoio, presença, perguntas feitas, prints de configuração feitos pelos próprios participantes com autorização. Já um sistema entregue produz uma captura de tela e pouca coisa mais.

Isso não proíbe construir. Só coloca o software como uma opção entre outras, a ser escolhida quando de fato for a mais adequada — e não por ser a mais confortável para quem programa.

Se for construir, construa para ser entregue

Quando a solução técnica se justifica, o desenho muda. O objetivo deixa de ser a melhor arquitetura possível e passa a ser a menor dependência possível de você.

Isso significa preferir ferramenta que a pessoa já usa a uma aplicação nova; preferir planilha compartilhada a banco de dados quando o volume permite; evitar qualquer coisa que exija servidor pago, domínio renovado ou chave de API em nome do estudante. Se o acesso depende de uma conta sua, o projeto já nasceu com prazo de validade.

E documente a passagem: quem tem a senha, onde o arquivo mora, o que fazer se parar de funcionar, para onde recorrer. Uma folha com essas quatro respostas, entregue impressa, vale mais que um repositório bem organizado que ninguém daquele local vai abrir.

Quatro recortes de baixo risco

Os formatos abaixo exigem pouca infraestrutura e sobrevivem à sua saída. Escolha pelo que o local pede, não pelo que é mais interessante de fazer.

• Oficina de cidadania digital: uso consciente da internet, reconhecimento de desinformação, noções de privacidade. Funciona bem em escola e em grupos de idosos.
• Guia de segurança online: material curto e ilustrado sobre senhas, golpes por mensagem e verificação em duas etapas, entregue impresso e explicado presencialmente.
• Diagnóstico de presença digital: analisar como um pequeno negócio ou uma ONG aparece na internet e entregar uma lista priorizada de ajustes que a própria equipe consegue executar.
• Apoio a serviço público digital: ajudar um grupo a usar aplicativos de serviços que já usa mal — agendamento, documentos, benefícios — orientando o caminho sem operar a conta de ninguém.

Dados pessoais mudam o projeto inteiro

Assim que a sua ação toca informação de pessoas identificáveis — nome, telefone, endereço, documento, foto —, ela ganha uma responsabilidade que não desaparece quando a disciplina acaba. Vale tratar isso como restrição de projeto, e não como detalhe de implementação.

A saída mais segura costuma ser não coletar. Um material educativo, um diagnóstico ou uma oficina raramente precisam de cadastro. Quando a coleta for inevitável, ela deve ficar sob controle da instituição que recebe a ação, em ferramenta dela, com acesso dela — nunca em conta pessoal do estudante.

Se o local já mantém dados de pessoas atendidas, não os leve embora para analisar em casa e não os inclua no relatório. Trabalhe com estrutura e processo, não com o conteúdo dos registros.

Ensinar segurança sem produzir medo

Oficinas sobre golpes e privacidade têm um efeito colateral frequente: a pessoa sai mais assustada e menos capaz do que entrou. O excesso de exemplos alarmantes convence o público de que a internet é perigosa demais para ele, o que empurra na direção contrária da inclusão digital.

O ajuste é de proporção. Para cada risco apresentado, mostre a ação concreta que o reduz, e termine sempre pela ação. Melhor uma oficina que ensina três verificações simples e as pratica com o celular na mão do que outra que cataloga dez tipos de fraude.

Deixe também o caminho de socorro: para onde ligar, onde registrar ocorrência, quem procurar no bairro. Saber o que fazer depois do erro faz mais pela autonomia do que qualquer lista de ameaças.

ODS 4 ou ODS 8: depende de para onde a habilidade aponta

Os dois aparecem com naturalidade neste curso e a escolha costuma ser feita sem critério. Vale usar o destino da competência que você desenvolve no público.

O ODS 4, sobre educação de qualidade, se sustenta quando a ação amplia repertório e capacidade de aprender — alfabetização digital, uso crítico da informação, autonomia para resolver problemas com a tecnologia. O ODS 8, sobre trabalho decente e crescimento econômico, se sustenta quando a habilidade ensinada tem destino produtivo — melhorar a presença digital de um empreendimento, qualificar alguém para uma vaga, organizar o trabalho de um coletivo.

Uma oficina de segurança online para idosos é claramente ODS 4; a mesma oficina para vendedores de uma feira, com foco em proteger o meio de pagamento, encosta no ODS 8. O que muda não é o conteúdo, é o propósito — e é o propósito que você precisa justificar.

Como comprovar uma ação que é digital

Evidência é um ponto fraco típico deste curso, porque boa parte do trabalho acontece na tela. Captura de tela sozinha comprova pouco: mostra um artefato, não uma ação com pessoas.

Combine três camadas. A primeira é o artefato — o material, o guia, a tela do que foi construído. A segunda é o uso — foto do grupo com os celulares durante a atividade, sem enquadrar telas com dados pessoais nem rostos sem autorização. A terceira é o registro escrito — a lista fornecida pelo local, o roteiro seguido com suas anotações, a devolutiva de quem acompanhou.

Cuidado específico com prints: antes de incluir qualquer captura no relatório, verifique se não há nome, telefone, endereço, número de documento ou conversa privada visível. Esse é o vazamento mais frequente em trabalhos de tecnologia.

Um exemplo fictício, com as escolhas explicadas

O cenário abaixo é inventado, apenas para ilustrar o encadeamento das decisões. Não descreve atividade real.

Uma estudante é procurada por uma ONG do bairro que quer um sistema para controlar a entrega de cestas básicas. Ela pergunta como o controle é feito hoje e descobre um caderno preenchido por três voluntárias, nenhuma delas confortável com computador. Em vez do sistema, propõe outra coisa: uma planilha compartilhada na conta da própria ONG, com três colunas e validação simples, mais duas sessões de uma hora ensinando as voluntárias a usá-la. Deixa uma folha impressa com o passo a passo e o contato de suporte da própria ferramenta — não o dela. Na segunda sessão, uma das voluntárias já preenche sozinha e aponta um campo que falta; o campo é acrescentado ali, com ela.

O que esse relato entrega: um pedido reinterpretado a partir do contexto real, uma solução dimensionada para quem vai operar, uma passagem de bastão documentada e um sinal concreto de apropriação — a sugestão que veio de quem recebeu a ação.