Top Post actually makes sense this time. PRD == Product Requirements Document MRD == Marketing Requirements Document.
On 28 October 2013 07:19, Robyn Bergeron <[email protected]> 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 > [email protected] > https://admin.fedoraproject.org/mailman/listinfo/cloud > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- Stephen J Smoogen.
_______________________________________________ cloud mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
