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

\textbf{How to involve students in real-world projects, interacting with
real customers.}
%
Our team was mainly composed of software engineering undergraduate
students, who had the opportunity to interact with senior developers and
designers on the team, as well as with the team of technicians and
managers from the Brazilian Government, and the management team from
UnB.
%
The students interacted with professionals of diverse fields of expertise, and they were
able to participate in all levels of the software development process.
This contributed to a great learning opportunity. Moreover, for the majority of
the students, this was a first professional experience.

\textbf{The participation of experienced professionals is crucial to
the success of the project.}
One important factor for the students was the composition of the teams
with the participation of experienced professionals.
%
On the technical side, the senior developers and designers would handle
the more difficult technical decisions, creating a work environment
where the students could develop their skills in a didactic way without
pressure.
%
On the management side, the active participation of professors -- who
are, in the end, the ones responsible for the project -- is crucial to
make sure students participation is conducted in a healthy way, and it is an
instance of leading by example.

\textbf{A balanced relationship between academia and industry.}
The experience of the SPB project led UnB to develop a work style which
proved to be appropriate for an educational environment that brings
academia and industry together.
%
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 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.
%
And even under a potentially adverse environment, the project delivered
the desired solution with success.
%
At the end of the project, we noted that the skills developed by the
students were at the software engineering state of the art.
After the project ended, we had team members successfully embracing
opportunities in public, private, national, and international
organizations, in addition to those students that
opened their own companies.

\textbf{Managing different organizational cultures.}
In the beginning of the project, the Brazilian Government stakeholders
had certain expectations about the project development that, let's
say, didn't exactly match our work style based on agile and FLOSS practices.
%
We had to develop strategies that would support these different
organizational cultures. As reported in Section \ref{sec:process}, the
MP is organized in a functional hierarchical organizational structure,
typically adopting a traditional development paradigm. Therefore, we had to
create a translation process between our team and the MP managers who
managed the project on their side assuming a traditional waterfall
process.

\textbf{Managing higher-level and lower-level goals separately.}
During the initial phase of the project, the MP team has brought
strategic discussions to technical/operational meetings that
were supposed to be about practical technical decisions.
%
This produced a highly complex communication and management environment,
overloading the professors because they were supposed 
for maintaining the MP strategy synchronized with the
implementation plans of the development team. This was hard, especially because the
aforementioned cultural mismatch. Mixing both concerns in the same
discussions caused confusion on both sides.
%
From the middle of the project we were able to keep those
concerns separated, what eased the work of everyone involved.

\textbf{Living with ill-advised political decisions.}
At the initial phases of the project, by political and personal
motivation, the main stakeholders from the Brazilian government imposed
the use of Colab to guide the development of the new SPB platform. Our
team was 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, the MP was adamant and we had to manage this problem. As
explained in section \ref{sec:architecture}, we did massive changes to
Colab, and at the end of the project we have completely rewritten it to make
it stable. It is important to notice that the MP compelled us to accept
a technical decision based only on political interests, without considering
all the resources that would be spent due to that decision. At the end
of the project, we verified that Colab indeed consumed a vast amount of
the budget and increased the project complexity. At the end of the
project and after our analysis on the decision made by the MP, we
understand that MP managers are capable of ignoring technical reasons
in favor of political decisions.

\textbf{Consider sustainability from the beginning.}
In the process of deploying the SPB platform in the MP infrastructure we had
to interact with the MP 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 technicians
constantly avoid the responsibility. After noticing the aforementioned
situation, we organized a DevOps team that completely automated all
the deployment procedure. We simplified all the platform deployment to a
few steps: (1) initial configurations (just ssh configuration) and (2)
the execution of simple commands to completely update the platform. By
the end of the project, we observed that the MP technicians invariably
still depended on our support to update the platform even with all the
automation provided by us. We were sadly left with a feeling of
uncertainty about the future of the platform after the project ended. In
hindsight, we realize that the MP dedicated system analysts and
managers to the project, but not operations technicians. The later
should have been more involved with the process so they could at least be
comfortable in managing the platform infrastructure.