Top Post actually makes sense this time.

PRD == Product Requirements Document
MRD == Marketing Requirements Document.

On 28 October 2013 07:19, Robyn Bergeron <rbergero@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-stories.gif :D ) 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.html more 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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct



--
Stephen J Smoogen.