A colleague of mine, Brad Goldense, does a biannual survey about new product development practices. It’s time for another one. Here’s what he says: Is Product Development important to you and your company?
We’re getting ready for my parents’ 50th wedding anniversary, and my sister decided a scrapbook of family pictures would be a great present. She’s right, it will be wonderful. Mark and I were looking for pictures of us and our children, so we pulled out all of the pictures from the last 20 years. We
I’ve been at the STAR conference this week, and Cem Kaner’s keynote talk yesterday discussed the idea of extended random regression testing — take all your programmatic tests, and run them in random sequences for a long time. You’ll find defects you cannot find just running the tests by themselves. Here’s the logic behind this
Based on yesterday’s comments, it’s past time for me to define what I mean when I talk about product management, product lifecycle management, lifecycle choices, and project management. Here goes: Product management: The activities that plan the product’s evolution from birth to obsolescence. In a product company, product managers perform these roles. In an IT
A colleague emailed me a few days ago, and asked “for a code base with a [given size], what can we expect to see for numbers of defects per KLOC (given the actual industry average or given what the industry believes we should expect). We need some way of gauging whether or not our
Joel’s discussion of project managers (MS calls them program managers) and developers got me to thinking about the differences between project managers and developers. The difference between project managers and developers is where they deal with complexity and decision-making. PMs deal with complexity and decision-making between people. Developers deal with complexity and decision-making in
I’ve been thinking more about requirements. In the most recent two assessments I’ve done, both organizations have been stuck on thinking they could define their requirements before design and implementation. IWBNI (It Would Be Nice If) users could know their requirements early. For small projects (a couple of people, maybe a couple of months)
If you haven’t read Joel Spolsky’s entry on office architecture stop and read that first. Finally, an office in which people can successfully work alone andwith other people — and who don’t have to worry about keeping their voices down. I’m amazed at the space per person (425 sq. ft if I understood). Most
Earlier this week, I was at the Rational User Conference. I was part of a dynamic panel, “The People Factor: Experts Weigh In On The Soft Side of Software.” One question was about how technical managers or project managers have to be. Murray Cantor, one of the other panelists, summed it up this way:
One of the most difficult problems in software development is knowing how to elicit and discuss requirements. It’s difficult because the people who are supposed to know the requirements don’t always have a clear idea of what they want. And, even people with tremendous communication and other soft skills don’t always have good ways