Top Post actually makes sense this time.
PRD == Product Requirements Document
MRD == Marketing Requirements Document.
On 28 October 2013 07:19, Robyn Bergeron <rbergero(a)redhat.com> wrote:
Hi folks,
I took an initial cut at the framework/outline for a PRD, and started
filling in... some bits of it, mostly in an "example" type format so people
can get an idea of context, other parts in a more "this is a description of
what should be here," etc.
https://fedoraproject.org/wiki/Cloud_PRD
This is about as "traditional" of a PRD as I have gotten it to at this
point - given that typically, in a proprietary-type company setting, one
group might do a MRD (marketing), then product managers would do a PRD, and
then engineers might dive in and do a more detailed requirements document,
and then Dilbert-type things start happening (Engineers inform the product
managers that they are living in a dream world, the product managers tell
them that is nice but it needs to be finished by next week, etc..
http://garbuz.com/blog/wp-content/uploads/2013/02/dilbert-agile-user-stor... ) And
we're trying to cover most of those bases in one document, and
also be realistic (i hope) in the process.
There is still plenty of basic explanatory stuff that can be filled in
here, so I hope that people can bear with the fact that more is coming
along that might give them better context, but I wanted to get this out for
a few reasons:
* Validate that this is even remotely on the right track - I wanted basic
framework but... at some point release early/often kicks in.
...hmm, okay, maybe there aren't any more reasons. There are clearly some
sections where I'm questioning which way might be the better way to do
things (user stories vs. primary use cases, for example), feedback welcome
on that or anything else, obv.
Other things I'd just like to put on the table as food for thought:
* There are likely a lot of cases for overlap with the other working
groups. I would still prefer to list them out explicitly, just so we can
track / ensure that any dependencies are being coordinated / worked through
(with our help, or not, or whatever) with the other teams, and also so
people don't come along and say "OMG YOU FORGOT XYZ" and we don't have
to
explain that we already thought through this and decided it would be best
passed on to another team.
* In line with that, it would probably be useful to explicitly describe
somewhere towards the beginning of the document what we expect is *within*
our scope, vs. outside of it, particularly when it comes to server WG /
cloud WG things; and also ensure that we have mutual agreement with the
other WGs on that, so that we don't get into some situation of questioning
whose call it is, or worse, just assuming that another working group has
those bases covered. (Johann's mail that he sent just a bit ago to the
list,
https://lists.fedoraproject.org/pipermail/cloud/2013-October/002837.htmlmore or less
illustrates the need for this, IMO.)
Also: I realize that there is often times a desire to just think about all
the cool things we could add in in terms of packages but I do think it is
useful for us to actually think through the use cases or user profiles, to
ensure we have something that is useful in a variety of environments, for
multiple purposes, user types, etc. If you're a sysadmin or developer, or
know people who are, by all means, share what would make a cloud "product"
useful for you in your day to day work, or ask people what would make it
useful. If you know people who are explicitly avoiding Fedora like the
plague for cloud usage, ask them why. This is the kind of stuff that helps
us ensure that we are not just talking to ourselves, more or less ;)
Anyway: I know some folks are going to want to dive in and start filling
things out - and perhaps I should have maybe put this in a separate file as
a "template" and then have the actual filled-out thing on in the Cloud_PRD
spot, but ... maybe we can take a snapshot of it at some point soon and
save that as the template. In any case: I'd like to make sure that we make
sure that this is an effective way to format a PRD that will allow us to
produce useful results before we go filling it all in, so that we don't
wind up making a bunch of folks all sadfaced that they spent a bunch of
time writing stuff before we decided that this sucks and we should do it
some other way. :)
Finally (I'm wordy today, sorry) - I have no idea what the other WGs are
planning offhand for their PRDs. I don't know if it would be useful for
everyone to standardize on one template, or have each WG decide what works
best for them, and I'm not going to try and sort that out here :) but it
might be useful to keep an eye on what the other teams are putting together
so that we can make sure anything that does need cross-coordination can be
captured appropriately.
-robyn
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct:
http://fedoraproject.org/code-of-conduct