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

The multidisciplinary composition of the development teams, mainly software
engineers and designers, is necessary for the development of good software
products, which naturally aim to meet the users needs. In the context of the
SPB project, there were also stakeholders from different areas who composed the
team of technicians and managers of the MP, as well as the administrative teams
of UnB. This interaction with different professionals brought a great learning
opportunity for the students, who had their first professional experience, even
during their graduation course. On the other hand, the different perceptions of
stakeholders generated high complexity of communications and expectations
management, burdening too much the professors who were responsible for project
management.

The use of the Colab tool was a requirement required by the MP. They argueed
that this tool presented functionalities that would allow MP managers to
stimulate the participation of SPB service providers with gamefication
practices. As we said, in order for Colab to perform the expected behavior in
SPB its architecture had to be completely redefined and this caused in
practice, (i) the considerable increase in the architectural complexity of the
SPB and (ii) it was the subsystem that consumed the most effort and budget
during development.

Due to the computational complexity related to the SPB deployment, associated
with the Brazilian government needs for product support, we made an effort to
provide complete automation of the entire deployment procedure, a result of
DevOps activities.  In this way, we encapsulate all this complexity and enable
the deployment of new SPB releases through the execution of few commands, as
registered in the project documentation. Although we have provided a high
degree of automation, training workshops for the MP technical team, and a
meticulous description of the procedures in the documentation, we observed that
the MP technical staff invariably depended on our support to perform these
procedures.

From the point of view of management and development processes, we had to
develop management strategies that would accommodate different organizational
cultures. As reported, the MP has a functional hierarchical organizational
culture, strongly supported by process management, typical of the traditional
development paradigm. The UnB teams use a process based on agile manifest
values and FOSS and agile community practices. So we created a process of
"translation" of work done to communicate with MP managers who manage their
portfolio based on the PMBoK processes. On the one hand, in the intermediary
and final project's phases we have matured this process, mainly due to the
perception of the results by 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. Again there was an overload in
professors, who were responsible for maintaining the strategic alignment of the
MP with the day to day development of the UnB team.

Another importance factor for the students and maturing of the software
engineering practices used in the project was the composition of the teams with
the participation of experienced professionals from the FOSS communities. These
professionals together with the professors promoted a work environment where
the students could develop their skills in a didactic and practical way without
being transferred the pressures for them. In 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 model of team
composition and work style that proved to be appropriate to the cararteristics
of an education environment, bringing 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 didactic-pedagogical activities. In short we
had students working at different times, part time, remotely or presential,
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.