Software Público Brasileiro

\section{Lições Aprendidas}
\label{sec:lessons}

A partir da superação dos desafios deste projeto, destacamos sete lições aprendidas para melhor compartilhar a nossa experiência no desenvolvimento do novo Portal SPB.

\textbf{Envolver alunos de graduação em projetos do mundo real, interagindo com clientes reais.}
%
Nossa equipe foi composta principalmente de estudantes de graduação em
engenharia de software, que tiveram a oportunidade de interagir com
desenvolvedores e designers sêniores dentro da equipe, bem como com a equipe de técnicos e gerentes do governo brasileiro.
%
Eles interagiram com profissionais que possuíam diversos conhecimentos e foram
capazes de participar em todos os níveis do processo de desenvolvimento de
software. Isto contribuiu para uma grande oportunidade de aprendizado, e para
a maioria deles esta foi a sua primeira experiência profissional.

\textbf{A participação de profissionais experientes é crucial para o sucesso do projeto.}
%
Um fator importante para os alunos foi a composição das equipes com a
participação de profissionais experientes. No lado técnico, os desenvolvedores
sênior e designers lidavam com as decisões técnicas mais difíceis, criando
um ambiente de trabalho onde os alunos poderiam desenvolver suas habilidades de
forma didática e sem pressão. No lado gerencial, a participação ativa dos
professores - que são, no final, os responsáveis pelo projeto - é
crucial para garantir que a participação dos alunos seja conduzida de forma
saudável e seja um exemplo de liderar pelo exemplo.

\textbf{Uma relação equilibrada entre academia e indústria.}
%
A experiência do projeto SPB levou o LAPPIS/UnB a desenvolver um estilo de trabalho que
demonstrou ser apropriado para um ambiente educacional que reúne academia e
indústria. A maior prioridade do ponto de vista da universidade são os alunos.
Diante disso, as atividades do projeto nunca foram priorizadas em detrimento
das aulas e outras atividades pedagógicas. Em resumo, tínhamos alunos
trabalhando em horários diferentes, a tempo parcial, localmente,
sempre respeitando suas condições individuais, mas fazendo o trabalho de
maneira coletiva, colaborativa e aberta. E mesmo sob um ambiente potencialmente
adverso, o projeto entregou a solução desejada com sucesso.
%
Ao final do projeto, notamos que as habilidades desenvolvidas pelos alunos
os capacitaram próximo ao estado da prática de engenharia de software. Após a conclus\~ao do
projeto, tivemos membros da equipe que abraçaram com sucesso
oportunidades em organizações públicas, privadas, nacionais e internacionais,
além dos estudantes que empreenderam e abriram suas próprias
empresas. Conforme relatado na seção\ref{sec:process}, o MP possui uma estrutura organizacional funcional, hierárquica, tipicamente presente no paradigma de desenvolvimento tradicional. Diante disso, tivemos que desenvolver estratégias e processos de trabalho que apoiassem a comunicação de diferentes culturas organizacionais.




\textbf{Gerenciar separadamente os objetivos de nível estratégico e de nível operacional.}
%
Durante a fase inicial do projeto, a equipe de MP costumava trazer discussões
estratégicas para reuniões técnicas/operacionais, onde deveríamos discutir
decisões práticas e técnicas.
%
Isso resultou em um ambiente de comunicação e gerenciamento altamente complexo,
sobrecarregando os professores, uma vez eles eram responsáveis por
manter o alinhamento estratégico do MP sincronizado com os planejamentos de
implementação da equipe de desenvolvimento, especialmente à luz do
desmembramento cultural acima mencionado. A mistura de ambas as preocupações
nas mesmas discussões causava confusão em ambos os lados. Na metade final do
projeto, conseguimos manter essas preocupações separadas, o que facilitou o
trabalho de todos os envolvidos.

\textbf{Não aceitar más decisões técnicas por questões políticas.}
%
Nas fases iniciais do projeto, por motivação política, os principais
atores do MP, envolvidos à época, impuseram a restrição do uso do software Colab. Nossa equipe foi contra a essa ideia, porque sabíamos que o Colab era um projeto
muito experimental e sua adoção poderia aumentar a complexidade
do projeto. Mesmo com as justificativas técnicas para não adoção do Colab, o MP manteve a restrição e tivemos de gerir este problema. Para adequar o Colab às necessidades do SPB, ao
final do projeto, tivemos que reescrevê-lo e com isso, o tornamos estável (o
transformando em um Sistema de Sistema em camada de aplicação). Ao final do projeto, verificamos que o Colab, de fato, consumiu a
maior quantidade do orçamento e contribuiu sobremaneira para o aumento da complexidade do projeto.

\textbf{Considerar a sustentabilidade desde o início.}
%
No processo de implantação da plataforma SPB na estrutura do MP, tivemos que
interagir com os técnicos do MP. Realizamos workshops, treinamentos e uma
documentação meticulosa descrevendo todos os procedimentos necessários para
atualizar a plataforma. Organizamos uma equipe específica de DevOps que automatizou completamente
todo o procedimento de implantação. Simplificamos a implantação da
plataforma em algumas etapas: (1) configurações iniciais (apenas configuração
SSH) e (2) a execução de comandos para atualizar completamente o ambiente. Ao final do projeto, observamos que os técnicos do MP sempre dependiam
do nosso apoio para atualizar a plataforma, mesmo com toda a automação
fornecida por nós. Em retrospectiva, percebemos
que o MP dedicou analistas de sistemas e gerentes para o projeto, mas não
técnicos de operações e desenvolvedores, que deveriam ter sido envolvidos com o
processo para que pudessem, pelo menos, de forma confortável, fazer a manutenção
da infra-estrutura plataforma.