Personas - shared vision for our projects

Jiří Stránský jstransk at redhat.com
Fri Oct 26 12:53:35 UTC 2012


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



More information about the aeolus-devel mailing list