Hi everybody,

while I was reading the Winged Monkey thread, I realized we might be missing a key thing 
in our projects - some shared vision of what are we building and who are we building it 
for. I started reading the WM thread being sceptic and gradually moved to a point 
"yeah, it starts to make sense to build this thing". But I had to do a lot of 
thinking and read a lot of explanations before I was able to come up in my mind with 
ideas of concrete people who would actually want to use Winged Monkey. I think this lack 
of clear vision and target users causes some confusion in communication and lengthy 
mailing list threads where we come to a shared point of view quite slowly. I'm thinking 
of whole Aeolus, not just Winged Monkey.

I don't think our scrum user stories are enough to provide us with a shared point of 
view. They state what is the purpose of each feature, but they don't give us any idea 
*who* will need such thing in the first place. "As a user, I want..." is not 
enough, because I still don't know who is the user. And this leaves room for endless 
debates about whether features are needed or not.

A good tool for getting a shared point of view about a project is personas (= imaginary people who will use 
our product). I've seen Francesco and Justin discussing personas on IRC, but I'm not sure what was the 
result, so I'd like to bring them up again here. For getting familiar with personas and why they are useful I 
recommend reading first half of this article [1], sections "Defining Personas", "Personas as a 
Comminication Tool" and "Empathetic Focus". It's quite short :)


I believe that personas, when done right, would enable us to make project 
decisions with less friction. I believe that many of the differences in 
opinions are caused by the fact that each one of us has a slightly different 
idea of users and their use cases for Aeolus.

We could also find personas helpful when defining long-term project roadmaps.

====
An example with decision making:

Should we build APIs over network (e.g. REST) between our components, or will 
we just use components as Ruby gems?

1) - I don't want to put network in between our components. It makes things 
more complicated and there's no real benefit.
   - No, it's important for connecting the components to other systems.
   - Well but we still don't know if anyone will want to do that.
   (... 2 hour conversation about whether external API is needed ...)

2) - Hmm, I think John, the IT infrastructure administrator in the small 
business company, would want to use just /this component/ and have it 
communicating with his /that app/.
   - Hmm, so we will need some external API.
   (... still far from conclusion ;) but moving forward faster ...)

The important thing is that the personas should be defined well, so that they 
help us with such ^^ decisions.
====

I should also admit here that personas are a lot of work and it is probably going to have 
to be done by someone else than me, as I have no experience with the business side of 
cloud computing so I have little knowledge of what users/customers might need. But 
"As an engineer, I'd like to have personas in order to make community decisions more 
effectively and efficiently" :)

Take care,
J.

[1] http://www.jnd.org/dn.mss/personas_empath.html

Reply via email to