On Friday we worked with all the information we had collected during the week. What we did is, after defining problems, consequent and hypothetical reasons, along with their verifications obtained with our possible users; we generated doubts and approaches (according to our development method are 'insights' that are reasons that we normally don’t think, and ‘guidelines’ that are questions oriented to solve one insight). Which will help us to choose an idea to solve the problem. The team participated fervently and even with our low experience in this way of working, we did a remarkable performance.
On Monday
each team in the class made a quick presentation of the problem chosen. The
exhibition was short and went to the point. The purpose of that was basically explain
the problem and the work done by each team, such as the validations of jtbd,
pains and gains of the extreme users. After finishing we made a round of feedback.
The
recommendations made to our team were variated, the two more important were: The
problem wasn’t correctly defined, because is a bit ambiguous; and the second
one was that our extreme users are not well defined.
After the
analysis made by the others teams, we realized that one of the important points
(extreme users) in fact was not defined. So, after making a review in our
documents, we began to rework in order to correct the problem to avoid a marked
deviation in the future.
At first,
we have a breakdown 馃様 because we felt that all our work was in vain. But we took
a big breakfast that recover our determination to solve the problem working hard 馃槑.
So, we went back to the point of analyzing and defining (correctly in this time)
our extreme users. Making the validations of our JBTD gains and pains again,
then we accommodate them and perform again the brainwriting that throwed the
two new guidelines. In this point we realized that the problem in fact made differences
in our solutions. But the impact wasn’t big, on the other hand, we weren’t having
important deviation of the correct way that we have to follow since the beginning.
We learned
that detecting errors like these at an early age of the project is crucial in
order to have a viable solution or an option. In this way we will avoid problems
in the future.
As a team
we saw that we have a good performance and synchronization because in just two days
we found a possible solution to the problem that we’ve been developing in a
week.
Once the error
was solved, the team had a better perspective of the problem, our possible users,
the two more feasible solutions. But we have to say that, we spend two days.
And this will delay us.
One thing
that is to interesting Is the way of find the solutions. First, we done a brainwriting
(method of write solutions to some problem, and then compare them with your
team) then we group the look alike solutions to finally chose the solution that
best represent their group. After that others member’s teams go to our team and
made groups of these main solutions. All these in order of find innovative
ideas from different combinations of solutions.
It was a hard week. But for us it doesn’t
represents nothing. 馃挭馃挭馃挭馃挭馃挭馃挭
Author: Inventors.
