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