Personas - shared vision for our projects

Hugh Brock hbrock at redhat.com
Fri Oct 26 16:17:00 UTC 2012


On Fri, Oct 26, 2012 at 04:19:34PM +0100, Angus Thomas wrote:
> On 10/26/2012 01:53 PM, 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 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
> Aeolus.
> 
> 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.
> 
> 
> Angus

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

-- 
== Hugh Brock, hbrock at redhat.com                                   ==
== Engineering Manager, Cloud BU                                   ==
== Aeolus Project: Manage virtual infrastructure across clouds.    ==
== http://aeolusproject.org                                        ==

"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."
--Robert McCloskey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AeolusCloudUserClasses.odp
Type: application/vnd.oasis.opendocument.presentation
Size: 118082 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/aeolus-devel/attachments/20121026/81ce71b6/attachment.odp>


More information about the aeolus-devel mailing list