Archives
October 2006
10/31/06
10/31/06
10/30/06
10/29/06
10/26/06
10/26/06
10/25/06
10/25/06
10/24/06
10/23/06
10/20/06
10/20/06
10/19/06
10/19/06
10/18/06
10/17/06
10/17/06
10/16/06
10/13/06
10/12/06
10/10/06
10/10/06
10/9/06
What's Involved in Product Development?
10/9/06
10/9/06
10/5/06
10/5/06
10/4/06
10/4/06
10/3/06
10/3/06
10/2/06
Monday, October 9, 2006
3:08:00 PM EDT
For those of you who are interested...read on. Apologies for the long read, but I assume you all have figured out by now that I ramble.
So! To build a product, we come up with the initial idea. This can be through brainstorming as a team (my favorite way to do this, and what we did last week in Mountain View), through some executive mandate ("go build this now"), or a single person's idea they're pitching around (I've certainly done enough of that).
Someone - generally a Product Manager (that's me!) - then writes a PRD (Product Requirements Document) around the concept. A PRD is a disgustingly detailed document. For example, if you were writing a PRD to build a door, you'd need to talk about how many screws would be used to hold the doorknob in place. "A door will be built inside a doorframe to lead to the outside" would be the initial requirement (then, of course, you need to explain what a doorframe is, what "outside" is, etc). Every single piece of the product is spelled out. It takes a while to get a PRD down to that level of detail, an initial version is often very high-level. "We're building a door. It opens. It has a doorknob, and is red." PRD's also include priority calls on what features are most important and absolutely must get built. In this example, a doorknob would be P1, whereas making the door red could be P2...nice to have, but not quite as important.
Once a PRD has been written, it is shopped around to the teams involved in building it, and other stakeholders. A "stakeholder" is anyone who has the ability to ask for revisions to the PRD for various reasons. Stakeholders include groups like Sales, Marketing, and Legal. It can take a month or two to nail down all the details of a PRD. Each individual group will nitpick as best they can to make sure they understand every single detail - down to what kind of screws will be used in the doorknob.
When a PRD's finally been approved by everyone involved, it is considered "baselined." This means that the product has been defined, no more features will be added at this point (otherwise you get what's called "feature creep" and you're never done), and the next phase of work can begin.
The PRD is handed off to the engineers, and the UI (user interface) groups. UI will generally be developed next, which is the way the product will actually work. Clicking here does this, there will be a button here with a dropdown, or in the case of my door..."the doorknob will be placed on the door three inches from the left side," or something. The entire team will review the UI, and the PRD may be revised again to match the UI. These are the only revisions that will be made to a PRD after baselining.
The engineers, meanwhile, are writing a TRD ("Technical Requirements Document"), and architecting the product (an architect works on the TRD, although they don't always write it personally, to determine how all of the bits and bytes work together and where they live). A TRD would include "the door will use this kind of wood." Often, the UI needs to be complete before a TRD can be finalized. UI (along with Visual Design...see below) will sometimes also write a DRD ("Design Requirements Document"), depending on how complex everything is.
After UI, Visual Design steps in - they're the folks who make everything look pretty. They would yell at me if I actually said in a PRD to make the door red...that's really their call, not mine. Everyone reviews visual design, and I can push for a red door all I want, but they're the ones who understand the AOL and AIM styleguides (everything here follows a consistent look and feel), and can (and do) overrule me. Commonly, the TRD is complete and engineers have started building the product before visual design is complete - the pretty graphics and colors aren't necessary to build something, but UI often is.
And then the team begins to code. And code. And code. A timeline for milestones ("this piece will be done by this date") is normally set once a TRD is complete, but depending on the product, there may be external dependencies that require pieces to be delivered on certain dates. So while all teams like to make their own timelines, that's not always feasible. A Project Manager normally handles the timelines, and all of the moving bits and pieces involved in making those dates.
One of the major milestones will be when the code goes off to Q/A (Quality Assurance) for testing. The Journals team has folks doing Q/A both in Mountain View, California and in Bangalore, India, which presents some interesting challenges for communication. Each international journals version will also do some Q/A testing on their own. Q/A will file bugs (problems) as they find them, the engineers will fix, and Q/A will test some more. Depending on the product, this phase can last anywhere from a few days to a month or two.
After the team is done with Q/A, the product launches, unless it interacts heavily with something else. For example - things for AIM Pages (like the comments module) require some secondary Q/A, what is called "integration testing." A team in Virginia will put the code up on servers that mock our live environment as best as possible, and test how the code interacts with the other products they're testing.
Once all of that testing is done, the code is pushed live. Code pushes happen around 4am EST, Tuesday through Thursday (we try very hard not to do a push on a Friday - in case something breaks over the weekend, or Monday - nobody wants to get up at 4am on a Monday). Hopefully all goes well, we have a very extensive Q/A process to ensure that as best we can. But, as you've seen with R8, sometimes things happen that could not be predicted in a Q/A environment. Q/A is very similar to production ("production" is what's live), but not identical, it just can't be exactly the same (for one thing, it's not open to the public).
Another Q/A run is done once the code goes live (at 4am) to make sure all's good. If there are any problems, in a perfect world they will be caught then and the code is rolled back (the code is returned to its previous state). Sometimes there are problems that couldn't be predicted, though...like what happened with the add/edit buttons in R8.
Things like R* releases don't necessarily go through quite an extensive process as all of this, no PRD/TRD/DRD, but they still go through the Q/A cycles before going live. And, of course, the smaller the company, the less paperwork...we certainly didn't write PRD's at Pseudo. We didn't need to - anyone who needed to know what I was doing was within shouting distance. Here, we have teams all over the world who need to understand what's going on.
So there you have it - product development 101. :) Hopefully this has been useful, and it'll make a bit more sense in the future when I talk about where we are with whatever we're working on.
Technorati tags: BamBam, process
Written by stephaniebambam Blog about this entry |
Add to del.icio.us | 
digg this
3:08:00 PM EDT
What's Involved in Product Development?
For those of you who are interested...read on. Apologies for the long read, but I assume you all have figured out by now that I ramble.So! To build a product, we come up with the initial idea. This can be through brainstorming as a team (my favorite way to do this, and what we did last week in Mountain View), through some executive mandate ("go build this now"), or a single person's idea they're pitching around (I've certainly done enough of that).
Someone - generally a Product Manager (that's me!) - then writes a PRD (Product Requirements Document) around the concept. A PRD is a disgustingly detailed document. For example, if you were writing a PRD to build a door, you'd need to talk about how many screws would be used to hold the doorknob in place. "A door will be built inside a doorframe to lead to the outside" would be the initial requirement (then, of course, you need to explain what a doorframe is, what "outside" is, etc). Every single piece of the product is spelled out. It takes a while to get a PRD down to that level of detail, an initial version is often very high-level. "We're building a door. It opens. It has a doorknob, and is red." PRD's also include priority calls on what features are most important and absolutely must get built. In this example, a doorknob would be P1, whereas making the door red could be P2...nice to have, but not quite as important.
Once a PRD has been written, it is shopped around to the teams involved in building it, and other stakeholders. A "stakeholder" is anyone who has the ability to ask for revisions to the PRD for various reasons. Stakeholders include groups like Sales, Marketing, and Legal. It can take a month or two to nail down all the details of a PRD. Each individual group will nitpick as best they can to make sure they understand every single detail - down to what kind of screws will be used in the doorknob.
When a PRD's finally been approved by everyone involved, it is considered "baselined." This means that the product has been defined, no more features will be added at this point (otherwise you get what's called "feature creep" and you're never done), and the next phase of work can begin.
The PRD is handed off to the engineers, and the UI (user interface) groups. UI will generally be developed next, which is the way the product will actually work. Clicking here does this, there will be a button here with a dropdown, or in the case of my door..."the doorknob will be placed on the door three inches from the left side," or something. The entire team will review the UI, and the PRD may be revised again to match the UI. These are the only revisions that will be made to a PRD after baselining.
The engineers, meanwhile, are writing a TRD ("Technical Requirements Document"), and architecting the product (an architect works on the TRD, although they don't always write it personally, to determine how all of the bits and bytes work together and where they live). A TRD would include "the door will use this kind of wood." Often, the UI needs to be complete before a TRD can be finalized. UI (along with Visual Design...see below) will sometimes also write a DRD ("Design Requirements Document"), depending on how complex everything is.
After UI, Visual Design steps in - they're the folks who make everything look pretty. They would yell at me if I actually said in a PRD to make the door red...that's really their call, not mine. Everyone reviews visual design, and I can push for a red door all I want, but they're the ones who understand the AOL and AIM styleguides (everything here follows a consistent look and feel), and can (and do) overrule me. Commonly, the TRD is complete and engineers have started building the product before visual design is complete - the pretty graphics and colors aren't necessary to build something, but UI often is.
And then the team begins to code. And code. And code. A timeline for milestones ("this piece will be done by this date") is normally set once a TRD is complete, but depending on the product, there may be external dependencies that require pieces to be delivered on certain dates. So while all teams like to make their own timelines, that's not always feasible. A Project Manager normally handles the timelines, and all of the moving bits and pieces involved in making those dates.
One of the major milestones will be when the code goes off to Q/A (Quality Assurance) for testing. The Journals team has folks doing Q/A both in Mountain View, California and in Bangalore, India, which presents some interesting challenges for communication. Each international journals version will also do some Q/A testing on their own. Q/A will file bugs (problems) as they find them, the engineers will fix, and Q/A will test some more. Depending on the product, this phase can last anywhere from a few days to a month or two.
After the team is done with Q/A, the product launches, unless it interacts heavily with something else. For example - things for AIM Pages (like the comments module) require some secondary Q/A, what is called "integration testing." A team in Virginia will put the code up on servers that mock our live environment as best as possible, and test how the code interacts with the other products they're testing.
Once all of that testing is done, the code is pushed live. Code pushes happen around 4am EST, Tuesday through Thursday (we try very hard not to do a push on a Friday - in case something breaks over the weekend, or Monday - nobody wants to get up at 4am on a Monday). Hopefully all goes well, we have a very extensive Q/A process to ensure that as best we can. But, as you've seen with R8, sometimes things happen that could not be predicted in a Q/A environment. Q/A is very similar to production ("production" is what's live), but not identical, it just can't be exactly the same (for one thing, it's not open to the public).
Another Q/A run is done once the code goes live (at 4am) to make sure all's good. If there are any problems, in a perfect world they will be caught then and the code is rolled back (the code is returned to its previous state). Sometimes there are problems that couldn't be predicted, though...like what happened with the add/edit buttons in R8.
Things like R* releases don't necessarily go through quite an extensive process as all of this, no PRD/TRD/DRD, but they still go through the Q/A cycles before going live. And, of course, the smaller the company, the less paperwork...we certainly didn't write PRD's at Pseudo. We didn't need to - anyone who needed to know what I was doing was within shouting distance. Here, we have teams all over the world who need to understand what's going on.
So there you have it - product development 101. :) Hopefully this has been useful, and it'll make a bit more sense in the future when I talk about where we are with whatever we're working on.
Technorati tags: BamBam, process
Written by stephaniebambam Blog about this entry |
Add to del.icio.us | digg this
This entry has 3 comments: (Add your own)
-
I thought Journals was doing Agile and not SDLC?
-
Oy! It pays to be concise, right? Right?
-Dan
http://journals.aol.com/dpoem/TheWisdomofaDistractedMind/
10/11/06 3:47 AM
~Raven Smith
http://journals.aol.com/rebuk