First cut - Cloud PRD outline

[Stephen John Smoogen]

Top Post actually makes sense this time.

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

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



-- 
Stephen J Smoogen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/cloud/attachments/20131028/5ab40834/attachment.html>