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

\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 sênior e designers 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
estavam no estado da arte da prática de engenharia de software. Depois que o
projeto terminou, tivemos membros da equipe que abraçaram com sucesso
oportunidades em organizações públicas, privadas, nacionais e internacionais,
além dos estudantes que entraram no empreendedorismo e abriram suas próprias
empresas. No início do projeto, as partes interessadas do governo brasileiro
tinham certas expectativas sobre o desenvolvimento de projetos que, digamos,
não correspondiam exatamente ao nosso trabalho baseado em práticas ágeis e de
software livre. Tivemos que desenvolver estratégias que apoiassem diferentes
culturas organizacionais. Conforme relatado na seção\ref{sec:process}, o Ministério do Planejamento é
organizado em uma estrutura organizacional hierárquica, tipicamente,
um paradigma de desenvolvimento tradicional. Portanto, tivemos que criar um
processo de ``tradução'' entre nossa equipe e os analistas do MP que gerenciaram o
projeto do lado deles.

\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. Para o meio e fim 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 e pessoal, os principais
atores do governo brasileiro, envolvidos na época, impuseram o uso da Colab
para orientar o desenvolvimento da nova plataforma SPB. Nossa equipe estava
totalmente contra a essa ideia, porque já sabíamos que o Colab era um projeto
muito experimental e sua adoção poderia aumentar dramaticamente a complexidade
do projeto. Mesmo nós fornecendo as razões técnicas para não utilizar Colab, MP
foi inflexível e tivemos de gerir este problema. Fizemos mudanças maciças e, ao
final do projeto, reescrevemos completamente o Colab e o tornamos estável (o
transformando em um Sistema de Sistema em camada de aplicação). É importante
notar que o MP nos obrigou a aceitar uma questão técnica baseada apenas em
interesses políticos, sem considerar todos os recursos que seriam gastos devido
a essa decisão. Ao final do projeto, verificamos que a Colab de fato consumiu a
maior quantidade do orçamento e aumentou a 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. Fizemos vários workshops, treinamento e uma
documentação meticulosa descrevendo todos os procedimentos necessários para
atualizar a plataforma, no entanto, percebemos que os técnicos do MP
constantemente evitavam essa responsabilidade. Depois de notar essa situação,
nós organizamos uma equipe de DevOps específica que automatizou completamente
todo o procedimento de implantação. Nós simplificamos toda a implantação da
plataforma para algumas etapas: (1) configurações iniciais (apenas configuração
SSH) e (2) a execução de comandos simples para atualizar completamente a
plataforma. 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.  Ficamos tristemente com um sentimento de incerteza sobre o
futuro da plataforma após o término do projeto. 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 deveria ter sido envolvido com o
processo para que pudessem, pelo menos, de forma confortável, fazer a manutenção
da infra-estrutura plataforma.

Por fim, o novo portal do Software Público Brasileiro está disponível em
\url{https://softwarepublico.gov.br}. Toda a documentação, incluindo a
arquitetura detalhada e os manuais de operação, também estão disponíveis em
\url{https://softwarepublico.gov.br/doc}. Todas as ferramentas integradas são
software livre e nossas contribuições foram publicadas em repositórios abertos,
disponíveis no próprio portal SPB. Também contribuímos com funcionalidades e
melhorias para as respectivas comunidades dos projetos integrados: que
beneficiam essas comunidades, assim como nós, pois podemos compartilhar o
desenvolvimento futuro e o esforço de manutenção com outras organizações que
participam de seus projetos.