Personas - shared vision for our projects

Mike Orazi morazi at redhat.com
Fri Oct 26 16:15:50 UTC 2012


On 10/26/2012 08:53 AM, Jiří Stránský wrote:
> 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

+1

We've been missing this for quite a while.  I think you picked quite a 
good example of something that has been causing a little bit of tension 
lately and how having defined a set of defined personas may indeed 
bridge the gap that exists today.

m




More information about the aeolus-devel mailing list