|
|
|
Sponsored Link •
|
Summary
Read most any software engineering text book and you'll be told that requirements gathering is key to successful projects. Yet, many projects in start-up companies never develop such a document or, perhaps worse, have useless, sketchy documents that serve only political needs. What's going on here?
|
Advertisement
|
"The best way to perpetuate a bad system is to work around it."
-- Anonymous.
Read most any software engineering text book and you'll be told that requirements gathering and an accurate software requirements specification (SRS) is key to successful projects. Yet, many projects in start-up companies never develop such a document or, perhaps worse, have useless, sketchy documents that serve only political needs. What's going on here?
In this weblog, I'll relate some of my experiences with requirements gathering in small companies and start-ups. I'll also explain why I believe this is one aspect of the software crisis that shouldn't be blamed on developers.
Who owns the vision for the product? In the early days of most start-ups the answer is clear: the engineers who started the company. Soon thereafter, however, it becomes less clear. The accepted thinking is that engineers, while adept at building things, aren't in touch with customer's needs to create solutions usable by normal people. Further, it isn't just Human-Computer Interface (HCI) concerns that worry management. Product road maps should account for sales cycles, competitive analysis, marketing initiatives, market trends, and other factors outside of engineering considerations. So, there are plenty of reasons why the nerds shouldn't unilaterally declare what product is built. That should fall to the product management function, a person or persons responsible for specifying the product's features and appearance, burdened with making the hard choices, and charged with having the vision for the product and instilling that vision into others.
In the small companies I've worked for, this is a fairy tale. When I hear the words "effective product management" I think "Unicorn". I've heard lots of things about both; I've seen neither. Let's forget for a moment most of the things I've listed above. Forget about the market analysis, the bold leadership, and the ability to make difficult choices. Let's concentrate on the vision thing and the ability to instill that vision into others. An SRS would be an ideal vehicle for this. Yet, I've never seen a product manager produce such a document. Nor have I seen anywhere close to the amount of detail such a document would need in any of the meager writings a product manager has produced.
I believe the problem here can be neatly summed up in with just a couple of points:
I've struggled within companies where a product management function was mandated by top management and the results were, without exception, either embarrassing, disastrous, or both. Here are a couple of stories to illustrate my point.
I worked for a company in the early 1990's that made systems that went into restaurants and resorts. When I first arrived, engineering was creating a new product to replace the aging, existing product. The head of software development tried to solicit requirements (or at least ideas for the product's features and its interface) from the part of the organization responsible for product management, but failed on each attempt. It was especially important, argued the software development manager, to get input and advice regarding the HCI aspects of the system. It wasn't at all obvious how a restaurant manager, for example, would wish to view the configurations of their terminals, or enter data about their staff.
As time passed, the development team created their own interface so testing could proceed. In the end, it was that interface, the one created by the engineers for their own testing, that shipped with the product. It was not loved.
Product management was quick to claim that engineering hadn't listened to them. Of course, there wasn't a single sheet of paper, not one document, not one memo, indicating product management's wishes or demands. Nevertheless, upper management sided with product management on the issue and chastised the cowboys in engineering for running off and creating something without due guidance. The nasty cold war didn't last long, though, as bankruptcy soon obliterated upper management, product management, and nearly all of engineering.
I was one of the three nerds left in engineering in the new, reconstituted company that emerged from the bankrupt original. It wasn't long before the development manager quit and I was promoted to lead engineering. In the next few months I rebuilt the team and we fixed as many bugs as we could, as quickly as we could.
The new management team, brought in to turn around the company, again demanded that a product management function be established. The new product manager, a nice enough fellow, seemed unwilling or unable to put any thoughts on paper. I had many ideas that I wanted to explore to move the product forward, but each time I'd broach the topic, the company President would insist that such things were the product manager's role and not mine.
I encouraged the product manager, I cajoled, and I pleaded, and offered to write if he would only read and approve. I would do all the work, if he liked, and he could take all the credit. Yet, we were still at a stalemate. I understood his reticence. The new senior management team was ruthless and unforgiving of mistakes. Writing something that wasn't received well by these cutthroats might well lead to his dismissal. He wanted to keep his job; I was at a point where I no longer cared.
Finally, the Board of Directors (representing the new investors) wished to see our product plan. I wrote a 25 page "vision" document that was passed up as our long term product plan. To my knowledge, no mention was ever made that it originated from the me, the VP of Engineering, and not the product manager. Yet, that vision stuck, which is all I cared about. I left not long afterwards.
Engineering was forced to run the entire project, from the moments after conception, up until the day I left, with guerrilla tactics. A product was made that eventually became good enough to fuel the resurrection of the company after bankruptcy, but the cost was high. It was impossible to get buy-in from a product management function or upper management before, or even during, development. There were no leaders, only art critics, happy to distance themselves from any controversy, and yet thankful that a product existed to enable sales and their own paychecks.
A friend related a story where the engineers wrote the requirements so "the product manager would know what we were doing". Help me understand what value the product manager had if he (a) didn't lead, (b) simply watched the engineers do his job, (c) and required the engineers to spoon feed him the plan (in the unlikely event that somebody might ask him about it, I suppose).
I think I saw a glimpse of this problem from the outside at the recent JavaONE conference in San Francisco. Scott McNealy, President and CEO of Sun Microsystems was the keynote speaker on Friday, June 13th and he brought up several guests including Verizon's chief information officer Shaygan Kheradpir. Kheradpir demonstrated Verizon's Digital Companion, a product that provides dynamic rerouting to and from various numbers, interception of urgent calls, and so on. You can read more about it here.
At the end of the crowd pleasing demo, McNealy asked Kheradpir why this project had originated in engineering instead of marketing (or product management). The first answer provided by Kheradpir was a joke, "well, we're smarter than they are", but he quickly followed with the stock, politically correct answer, "we listen to our customers, blah, blah, blah."
How did McNealy know that the project was done "skunk works style" and not through regular product management channels? More importantly, why was it that nobody appeared surprised by the revelation? Could it be that even big companies have this product management vacuum?
This is not a software problem. Read that bit again. This is not a software problem. The problem, simply stated, is this:
The requirements gathering phase, one of the most important phases of a project, according to the literature, is heavily dependent upon untrained people who are only marginally interested in doing the work. Further, upper management is likely to insist that those who might be trained stay out of the process. Since so few examples of good requirements documents exist, it is easy for these untrained, unmotivated, product managers to pass off sparse, terse, useless documents as an SRS. Upper management is unlikely to assess or understand the SRS's importance or quality, if, indeed, such a document is ever produced.
The best way to perpetuate a bad system is to work around it. This is a bad system and software departments are forced to work around it. When we do, we win: we ship product. Guerrilla tactics of working around, or behind, or in spite of, an inept product management function can still lead to a successful product. But at what cost?
Engineers are fond of their ability to drive to root cause for a given problem. When it is a technical problem, we're very good at quickly isolating the root cause. This problem, with the myth of product management, isn't a technical problem; it is a social problem. Oddly enough, engineers aren't very good at dealing with social problems. So, what do we do?
I don't think the role of "product manager" is going away. Our only chance is to try to encourage the right kinds of people, folks who have a keen sense of the appropriate technology, good communication skills, and an attention for detail, to fill those positions. We also need to get business schools and management degree programs to recognize that this is part of their world, too. If management is going to fill these positions with MBAs, then we need to make sure that these people get the education they need to do the job correctly.
This might be a book opportunity as well. Instead of writing every software requirements book as though an EE is going to read it, perhaps there should be a few assuming a well meaning, hard working MBA is going to read it.
I do believe that continuing down the road we're on now, continuing to work around the bad system we have, will only make things worse. Applications and environments are getting too complex to have these kinds of distractions. Guerrilla tactics or no, there will be a breaking point when even clever development managers can no longer circumvent the system.
This is a bit more lengthy than I expected but it is an important topic. I'm interested in your views. You can write me directly or post your comments here on Artima.com.
Have an opinion? Readers have already posted 12 comments about this weblog entry. Why not add yours?
If you'd like to be notified whenever B. Scott Andersen adds a new entry to his weblog, subscribe to his RSS feed.
 | B. Scott Andersen has 20+ years of experience in software development splitting his time between individual contributor and management. He is now a Principal Software Engineer with Verocel, Inc., a company specializing in helping safety-critical system developers attain certification for their products. The opinions expressed here are his own and he takes full responsibility for them... unless, of course, they are worth money, at which point they belong to his employer. |
|
Sponsored Links
|
Digg
del.icio.us
Reddit