\section{Lessons Learned}
\label{sec:lessons}

* Dividir entre positivo e negativo (interação com profissionais de diferentes áreas)
A composição multidisciplinar dos times de desenvolvimento, principalmente engenheiros de software e designers, é necessária ao desenvolvimento de bons produtos de software, que tem naturalmente como objetivo atender as necessidades dos usuários. No contexto do projeto do SPB, haviam ainda stakeholders de diferentes áreas que compunham a equipe de técnicos e gestores do MP, além das equipes administrativas da UnB. Essa interação com diferentes profissionais trouxe uma grande oportunidade de aprendizado para a formação dos alunos, que tiveram sua primeira experiência profossional, ainda durante sua formação. Por outro lado, as diferentes percepções dos stakekholders geraram alta complexidade de gerenciamento das comunicações e expectativas, onerando demasiadamente os professores que eram responsáveis pela gestão do projeto.

 * arquitetura ficou mais complexa do que o necessário devido à exigência de utilização do colab (gamificação)
O uso da ferramenta Colab foi um requisito exigido pelo Ministério do Planejamento. A justificativa era que esta ferramenta apresentava funcionalidades que permitiriam aos gestores do MP estimular a participação dos fornecedores de serviço ao SPB com práticas de gameficação. Como dissemos, para que o Colab desempenhasse o comportamento esperado no SPB sua arquitetura precisou ser completamente redefinida e isso representou na prática, i) o considerável aumento da complexidade arquitetural do SPB e ii) foi o subsistema que mais consumiu esforço e orçamento durante o desenvolvimento.
 
* incapacidade do governo de continuar mantendo (mesmo com documentação e automação)
* automação/DevOps
Devido a complexidade computacional relacionada ao deployment do SPB, associada com a necessidade de sustentação do produto por parte do MP, fez com que envindássemos esforço para prover completa automação de todo o procedimento de deployment, resultado das atividades de DevOps. Com isso, encapsulamos toda essa complexidade e viabilizamos a implantação de novas versões do SPB por meio da execução de poucos comandos, conforme registrado na documentação do projeto. Embora tenhamos provido alto grau de automação, oficinas de treinamentos para a equipe técnica do MP, além de uma minusciosa descrição dos procedimentos na documentação, observamos que a equipe técnica do MP invariavelmente dependia do nosso suporte para executar esses procedimentos.

 * processo PMBok do Governo versus Ageis/SL do LAPPIS
 Do ponto de vista dos processos de gestão e devenvolvimento, tivemos que desenvolver mecanismos de comunicação que acomodassem as diferentes culturas organizacionais. Como relatado, o MP possui uma cultura organizacional hierárquica funcional, fortemente apoiada na gestão por processos, típico do paradigma tradicional de desenvolvimento. Dado que utilizamos um processo apoiado nos valores do manifesto ágil e em práticas de comunidades ágeis e FOSS, criamos um processo de "tradução" do trabalho realizado para nos comunicarmos com os gestores do MP que que fazem a gestão de seu portfólio de projetos baseada nos processos do PMBoK. Se por um lado nas fases intermediáras e finais do projeto tenhamos amadurecido esse processo, principalmente pela percepção dos resultados por parte do MP, por outro, na fase inicial tivemos muita intervenção em nossa forma de trabalho, o que acabava tirando o foco de discussões estratégicas em prol de discussões operacionais. Novamente aqui houve uma sobrecarga na participação dos professores, que eram os responsáveis por manter o alinhamento estratégico do MP com o dia a dia do desenvolvimento da equipe da UnB.
 
 
 * Atores da comunidade SL no projeto
 Outro fator de fundamental importância para a formação dos alunos e amadurecimento dos práticas de engenharia de software utilizadas no projeto foi a composição dos times com a participação de experientes profissionais oriundos de comunidades de FOSS. Esses profissionais juntamente com os professores promoveram uma ambiente de trabalho onde os alunos puderam desenvolver suas habilidades de uma forma didática e prática sem lhes serem transferidos as pressões do projeto. Outrossim, esses experientes profissionais foram responsáveis pelas decisões técnicas mais relevantes relacionadas ao produto de software SPB.
 
% * Gestão dos recursos: Fizemos mais por menos (2.6M de 3.2M) --- sem os dados (escopo, custo, tempo e qualidade) bem discutidos é difícil sustentar essa afirmação, embora eu e Paulo consigamos perceber isso.

 * Impacto nos alunos (pós projeto)
 * como trabalhar com alunos (tempo parcial etc)
A experiência do projeto SPB fez com que a UnB desenvolvesse um modelo de composição de equipe e forma de trabalho que se mostrou adequado a cararterística de um ambiente de educação, aproximando a academia da indústria. A maior prioridade do ponto de vista da universidade é a formação dos alunos. Considerando isso, as atividades do projeto nunca foram priorizadas frente às aulas e demais atividades didático-pedagógicas. Na prática tínhamos alunos trabalhando em diferentes horários, em tempo parcial, de forma remota ou presencial, sempre respeitando suas condições individuais, mas fazendo com que o trabalho fosse realizado de forma coletiva, colaborativa e aberta. Ao final do projeto percebemos que as habilidades desenvolvidas pelos alunos os capacitaram com o estado na prática da engenharia de software. Os integrantes dos times, conseguiram oportunidades de trabalho em organizações públicas, privadas, nacionais e internacionais, além àqueles alunos que preferiam empreender, criando suas próprias empresas.



