On Fri, Oct 26, 2012 at 04:19:34PM +0100, Angus Thomas wrote:
On 10/26/2012 01:53 PM, Jiří Stránský wrote:
>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
>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 , 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
>We could also find personas helpful when defining long-term
>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" :)
+1 on the whole thing.
This ties into several conversations I've had recently. I was
talking with Mainn today, for example, about the need to have
personae and stories to convey the capabilities and features for
I agree entirely that we have suffered because of a lack of focus on
users in our design. We had technical objectives, like putting a UI
on the underlying capabilities of deltacloud and imagefactory, but
not nearly enough was done in terms of designing for types of users
and their objectives.
All we can do is improve, so, let's have people's best shot at
encapsulating the personae we're building Aeolus for.
Believe it or not, we have some pretty good collateral already around
personas. I've attached the set that Jonelle Lay (some of you probably
remember her) put together a couple years ago. It occurs to me now that
I should have shared these with you all long ago... oh well...
I feel like she really nailed the most important roles here. Of course
there's plenty of room for debate around the details, but I think you
all will find them helpful.
Jeremy Perry updated these a bit a few weeks ago, but I can't find his
update right now, so these will do.
== Hugh Brock, hbrock(a)redhat.com ==
== Engineering Manager, Cloud BU ==
== Aeolus Project: Manage virtual infrastructure across clouds. ==
"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."