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

The multidisciplinary of the development teams - mainly composed of software
engineers and designers - it is necessary for the development of a software
product that naturally fit the user requirements and consequently achieve a
high quality. In the context of the SPB project, there was a stakeholders team
of technicians and managers of the MP, as well as the administrative team of
the UnB. The interaction with different professionals contributed as a great
learning opportunity for the students, which had their first professional
experience during their graduation course. On the other hand, the different
perceptions of the stakeholders generated a high complex communication and
management environment. All of this complication generated a lot of overhead
for the professors because they were responsible for the project management.

At the initial phases of the project, MP imposed the integration of Colab to
the platform by the claim that it had gamification features, which would
encourage MP managers to be active on the platform. Since the first moment that
MP demands it to us, we were totally against the idea because we already knew
that Colab was a very experimental project and its adoption could dramatically
increase the project complexity. Even though we provided technical reasons to
not utilize Colab, MP enforces it to us and we had to manage this problem. As
explained in section \ref{sec:architecture} we did a massive change in it, and
at the end of the project we completely rewrite Colab and made it stable. It is
important to notice that the MP compelled us to accept a technical issue based
only on political interests, without considering all the money they would spend
with their decision. At the end of the project, we verified that Colab consumed
a vast amount of the budget and indeed increased the project complexity. In the
end of the project and after our analyses on the decisions made by the MP, we
understand that MP's managers are capable of ignoring technical reasons in
favor to a political decision.

In the process of deploying the SPB platform in the MP structure, we had to
interact with the MP's technicians. We did several workshops, training and a
meticulous documentation describing all the required procedures to update the
platform, however, we realized that the MP's technicians constantly avoid the
responsibility. After notice the aforementioned situation, we organized a
specific team to start a DevOps activities and interacts with all the UnB
teams. After a year of work, we completely automated all the deployment
procedure. We simplified all the platform implantation to a few steps: (1)
initial configurations (just ssh configuration) and (2) the execution of simple
commands to completely update the platform. In the end of the project, we
observed that the MP technical invariably depends on our support to update the
platform even with all the automation provided by us.

From the point of view of management and development processes, we had to
develop strategies that would support different organizational cultures. As
reported in Section \ref{sec:process}, the MP is organized in a functional
hierarchical organizational structure, typically, a  traditional development
paradigm. The UnB team works based on agile manifest values and FOSS community
practices. Therefore, we had to create a translation process to communicate
with MP managers who manage their project based on the PMBoK ideas. On the one
hand, in the intermediary and final project's phases, we had matured this
process, mainly due to the perception of the results by the MP, on the other
hand, in the initial phase we had a lot of intervention in our work style,
which ended up focusing  strategic discussions for operational discussions. The
aforementioned situation created an overload to the professors because they
were responsible for maintaining the strategic alignment of the MP synchronized
with the development team.

Another important factor for the students was the composition of the teams with
the participation of senior professionals from the FOSS communities. These
professionals and professors promoted a work environment where the students
could develop their skills in a didactic way without transferring any pressure
to the students. Addition, these experienced professionals were responsible for
the most relevant technical decisions related to the SPB software product.
 
% * 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.

The experience of the SPB project led UnB to develop a work style which proved
to be appropriated to the characteristics of an educational environment and
brings the academy closer to the industry. The highest priority from the
university's point of view is the students, considering this, the activities of
the project were never prioritized to the detriment of the classes and other
pedagogical activities. In summary, we had students working at different times,
part time, remotely or locally, always respecting their individual conditions,
but doing the work in a collective, collaborative and open way. At the end of
the project, we realized that the skills developed by the students empowered
them with the state in the practice of software engineering. The members of the
teams got opportunities to work in public, private, national and international
organizations, in addition to those students they preferred entrepreneurship,
opening their own companies.