\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.