w.r.t professional experience in software development, what exactly is a product development experience and project development experience. I am working in a service based company rather than a product based company so what are the actual differences between the two ?
I like Lasse's generalization. Other characteristics of *Product* development versus projects that I've noticed:
- Products have multiple releases - Products tend to keep the same team together - Products are revenue generating, not cost saving
I'm also seeing many IT shops split up their development into "products" and "projects." Products are those areas where they choose to create a competitive advantage, something they feel will help them win more business (e.g. a new provisioning system for distribution to channel partners). Projects are run in areas they want to achieve technical parity (e.g. implement a new packaged CRM application).
Hope that helps. Richard
posted 15 years ago
Actually, in XP2004, Mary Poppendieck called out to the XP community to move into product development mind-set instead of the current project-oriented thinking. Martin Fowler echoed this in his closing keynote.
In project management they define "project" as a set of tasks with a defined beginning, goal and end. So a project might produce several products or an incremental upgrade to a product. I guess I think of product oriented teams as having more of a "shrink wrap" mentality, perhaps delivering major releases to non-captive audiences infrequently. I live somewhere else - we can ship small upgrades and bug fixes and whatever else as often as we need to a captive corporate audience.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Lasse Koskela: In general, I would say the difference is that product development requires much more attention to maintainability and architecture than projects, which may be one-off solutions.
This doesn't match my experience. I've never seen a user of a system who didn't want a good software system to be even more improved.
Similarly, every "prototype" I've seen did go into production for a while, regardless of what people told beforehand.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
posted 15 years ago
Originally posted by Ilja Preuss: This doesn't match my experience. I've never seen a user of a system who didn't want a good software system to be even more improved.
Well, I've seen some (and it wasn't about the system being perfect but about the system being good enough for nobody wanting to shell out extra dollars for improving it further).
Having said that, I really don't think we're disagreeing here -- or then I just don't understand what you're referring to?
Trying to clarify what I meant by In general, I would say the difference is that product development requires much more attention to maintainability and architecture than projects, which may be one-off solutions:
If you're a product company, selling a product named WhizBang 5.0, WhizBang 6.1, WhizBang X, WhizBang 2009, etc., you typically can't afford to start every new version from scratch. Your architecture has to be in a good shape. Otherwise you'll end up open-sourcing your product in a desperate move to avoid bankruptcy after your product releases have slipped severely for many years in a row...
Then again, if you're a stovepipe company engaging in a bespoke development project building a piece of software that automates some mandatory but non-essential part of your company's operations, you might not have too strong an interest to invest too much into a rock-solid, nuke-proof architecture. In other words, you're not expecting to need major changes into the software being built (and the contractor might have his own profit margins in mind...) so the Good Enough bar tends to be lower compared to a product company.