Giving the Customer What They Wanted? 75
"Sometimes these different views can result in almost funny situations:
Back in the stone age of programming, we had a customer who wanted to have the result of a database query sorted by a specific field ('usable' databases at that time were either incredibly expensive or simply unavailable, so we had created our own proprietary database). He asked for this because the old software they were using could do this. However, we couldn't, and everyone was horrified by the thought of programming this 'ASAP' but we were ready to do it.
Eventually we talked to him and asked him what exactly he wanted this for. It turned out that he didn't even want a sorted list. He wanted look for a specific value in that field (something the old software couldn't do), and he got it by looking at the sorted query results. Our software, however, was capable of searching for field values already and return matching results only.
At this point both parts were happy: he got what he wanted and we didn't have to write a single line of code.
Of course, there will always be the geek with the 'use-it-my-way-or-f*ck-off'-attitude. For me however, talking to customers and trying to understand what they want (as opposed to what they tell you) was always a big part of what made developing software fun and satisfying.
So, how often did you find yourself in a similar situation?"
Customers never know what they really want (Score:4, Informative)
Re:Customers never know what they really want (Score:2, Funny)
with that said, ahem:
I DEAL WITH THE GODDAMN CUSTOMERS SO THE ENGINEERS DON'T HAVE TO!
I have good PEOPLE SKILLS, I AM GOOD at dealing with PEOPLE!
CAN'T you understand that! WHAT'S WRONG WITH YOU PEOPLE!
Yes, Customers Do Know (Score:4, Insightful)
Requirements should be written by techies who have actually worked alongside the customers long enough to understand what it is their are really trying to do. The author of the requirements should be required to explain them, in lay terms, to the customers, to ensure that both sides think they mean the same thing. And, foremost, both the customer and the tech staff must designate one individual each -- someone who has at least a passing acquiantance with the other's working environment -- to act as a translator, a bridge, between the communities.
You're lucky. (Score:3, Interesting)
Re:You're lucky. (Score:2)
The system engineer's job is primarily to translate between techies and customers. Note: this is a properly-trained person, with experience working both with customers and developers. I've seen good system engineers come from both sides - primarily developer, or primarily working with customers.
So, it is the system engineer who produces the requirements for the product, based on talking to the customer. The development team talks to the system engineer, and develops the requirements analysis together.
There are times that the development team should talk to the customer (it's incredibly valuable), but there should always be someone there who understands both groups.
I thought (Score:4, Informative)
Mod parent up (Score:1, Insightful)
Because of this the best way to develop software is prototyping. I strongly believe this.
Extreme Programming, Rational Unified Process, MS Solutions Framework... with little variation they believe in small iterations and phases.
Cost of change (Score:1)
These solutions all work because they recognise that the specification is a shifting target and so they seek to minimise the cost of change. If you know that the customer is going to change his mind in three weeks time then make the quickest change that you can to satisfy him, knowing that it will be gutted and rewritten several times. Quite different to the NASA school of programming where the spec (please don't blow up, oh god please don't blow up!) doesn't ever change so they invest time in doing it right first time rather than chasing a changing target.
I'm a people person! (Score:2)
Trying to resist the urge to throw in the obligatory Office Space reference...
Re:I'm a people person! (Score:1)
I often find myself in this situation. (Score:4, Insightful)
I'm an independent web developer, and as such I have a one on one relationship with the (non-technical) people who dictate the 'features' of the software I produce. Most of the time I'm doing not-so-glorified copy editing, but when I do have to create a maintenance tool or a more dynamic feature on the sites I work with, I find that I start to come up against what I perceive as a certain technical ignorance on their part--which is really a lack of communication between the two parties. Many times we'll get to a certain stage with a project, and our mutual assumptions will all of a sudden rear their ugly heads. Me: "Oh, didn't you realize that javascript/perl/unix/the current state of computer science and physics/etc. won't let me blah-dy blah blah?" Them: "Oh, didn't you realize that if you were going to build that thing it was necessarily going to have that feature because that's just a given?"
Having the relationship with my clients that I do, I find most of these problems pretty easy to solve; talk it through, try to understand what they really want, express the issues involved with implementation in as non-patronizing and non-technical a manner as possible. The most difficult point for me though is the debate between feeding the customers the line "that's not technically feasible" or trying to figure out some way to get what they want. I've found that 9 times out of 10 it's the case that I can do what they want if I push and prod myself a bit harder. What's even harder is those times when it's a balance between what the customer needs, what they are willing to pay for, and how long it might take me to do something, and I'm really not clear how it might all play out. An interesting problem.
I would also imagine that my personal solution to this problem wouldn't scale very well if you shifted it to a team of programmers working with a marketing department, customer service department, etc. My "organization's" small size is what enables me to solve these problems quickly and easily.
Sorry I've not supplied any real specifics, I really shouldn't; just wanted to comment on this issue because I definitely find it personally relevant.
Re:I often find myself in this situation. (Score:3, Insightful)
I just finished a giant (to me, at least) ecommerce site with over 700 products, all integrated into a shopping cart with affiliate programs, coupons, rebates, and discounts. Angler's Collection [anglerscollection.com]
There isn't anything particularly impressive about the site, other than it was done by one person, in a month from start to finish. It was also built from scratch, not using the shopping carts layout because my words "the layout won't be exactly like you have outlined there once we get into the shopping cart portion" came out to him as "of course I can lay that out to the nth degree EXACTLY as you have it spec'd there..." Overall though, I firmly believe that if the customer had gone to a "web-house" or some large company to get the job done, he would still be entrenched in meetings and the site would only be half done. As such, he came to me with a plan, and we worked the plan, if something came up, (which it did, mind you) then we worked it out in an hour on the phone. I laughed out loud at the "current state of physics" comment... it's very true. Customers have no clue what something takes to implement, they just saw it on some other site, and want it... Very fun to work through at times.
Most of the time, with the big companies I've worked with, it's not so much about solving the problems of the customer, it's about egos, and hidden agendas, and such... Too much crap to get anything done in the time it should take. There is a certain security in working for a big company, but I know one thing, after playing the corporate mind game for too many years, I'll never go back. I don't know how anyone does it. I'd take ramen for a month and no heat before I had to deal with that again.
Re:I often find myself in this situation. (Score:1)
But seriously, Thank you.
Shawn
Re:I often find myself in this situation. (Score:2)
Definitely, exactly! A variation on that theme is actually the reason my one client has hired me; if they let their in-house people try to take care of this stuff, it would still be tied up in committee. Instead they just farm it out to me and get it done in 1/5 (or whatever) of the time.
Yes, this is precisely what I was trying to get at.
Re:I often find myself in this situation. (Score:2)
I created the album so that it has thumbnail (128x128) images, which you can click for medium size photos (512x512), or click again for the unscaled version. My wife complains it is too difficult, apparently she was getting complaints that it was too difficult. She wanted me to make it have 512x512 images all on the same page without multiple pages or thumbnails..
However, she doesn't realize that dialup users (many of which are at 14.4 or 28.8k, due to quality of phone lines), who pay per-minute for their connection, would have to download over a hundred 512x512 images rather than a more elegant solution of being be presented with thumbnails giving them a choice as to what to spend their precious time (and money) on.
Of course, it is my fault that it is 'too hard'.. not her grandmother's fault for not knowing how to navigate a very simple webpage.
php perl freelancing has the same problems (Score:2, Insightful)
1) isn't web designing included in your quote I thought it was default ?
2) oh for making changes in those user options I thought there is going to be an admin panel by default ?
so what is the best way to solve all these issues
Differing priorities (Score:2, Informative)
I think it is always unreasonable for either person to do the other's job: that is why there are two people there. Nothing gets an enduser more upset than not being able to do what he wants - being forced to do something one way because the programmer likes it doesn't cut it.
At the same time, the enduser shouldn't try to write the software! Instead, describing what the user would want to do with the software, discussing it with the programmer, and letting the programmer decide the best way to implement it should be how it is done....I've yet to see it happen well, though. Both sides have egos to protect, it seems. The endusers are dumb and don't know what they want; the programmers don't understand what the enduser wants to do or why he needs it.
The biggest complaint seems to be feature-creep or missed specifications because the enduser wasn't aware of what he wanted. This is where programmers typically need help, it seems. The figuring out what the customer wants and finding out how to implement seems to be a very low priority for most programmers...
Re:Differing priorities (Score:5, Insightful)
So, ask why.
I have found that when you ask why a customer needs a particular feature, you get a much better understanding not only of what s/he wants, but how to best implement that feature.
Often, the customer attempts to speak in a more technical arena. It is at this point that they frequently make technical requests that aren't feasible (such as the example given above, with the sorted query results). When you ask them the what and why of that feature, you get a better understanding of what you actually need to implement.
I think oftentimes the problem with specifications is that the way that the customer phrases their needs. I recall trying to find directions to an Ethiopian restaurant. I was asking people where a given section of town was and wasn't getting helpful answers. Finally, when I rephrased the question to state the kind of restaurant I was looking for and the street it was on, they were able to give me better directions. I hadn't wanted to state my actual goal--"I'm trying to find an Ethiopian restaurant"--because I didn't want to broadcast what I really wanted (I thought it would make me look like a tourist which, admittedly, I was). When I actually stated my goals, I got a better response.
You have to squeeze better responses out of the customer. While it isn't my job to tell a customer how to do their business, nor is it their job to tell me how to program, I find that each can inform the other. Through my development work, I have helped many of the end users get a better conceptual understanding of their businesse processes, and their requirements have forced me to make creative programming decisions which have, in turn, made me a better programmer.
Basically, the fewer walls between developer and customer, the better.
customer - sales rep - manager - programmer (Score:4, Insightful)
One person whispers a short phrase into someone's ear who then passes it along in the same manner to another person, until the phrase gets transcribed by all people in the room, and the oft-hilarious result then disclosed.
I've often thought software development is like that.
Unless you're contracting directly with the customer, and note the requirements in his/her words, translating them to a technical equivalent (and, of course, translating back, and making sure you got the jist of what he/she wanted), you run the risk of these translation problems.
Often, such insulating layers are placed between well-meaning programmers and the customer to make sure they don't try to deliver more "work" than what the customer is willing to buy. This gets difficult because the programmer where the buck ends is expected to make the customer happy, but to spend the least amount of time possible on it, so that he/she can be assigned to the next project.
I've always thought that was a bad idea. Novice programmers' enthusiasm can be restrained by senior project leaders who might actually be the contact point with a customer -- they're called "systems analysts" for a reason -- the supposed ability to translate human-speak into technical requirements and estimate the work to be done.
In an ideal world, this estimate would be returned back to the customer via sales and a human-speak description of the work to marketting so they can get a feel what piece of it might be reusable on other projects and to feel the pulse of market desire.
More likely, much of this initial analysis is done by people not qualified to do it (sales and marketting types, though technically savvy people do exist in such roles), and critical customer requirements are either lost or not questioned.
I've been in situations where a customer's technical team rejected outright our technical proposals purely because of miscommunication across our respective management hierarchies. I've also been in situations where such miscommunication finally gave way to both technical groups getting together to convey an understanding of what's really wanted, usually after wasting much time and money. Often, in such meetings, one can almost feel the light bulbs finally turning on above the heads of those responsible for the confusion: "Oh! So when you said you wanted it ON a hard disk, you meant INSTALLED on the hard disk in the system, say, from a CDROM, and not DELIVERED that way!!" In all fairness I can see both ways being legitimate software delivery systems (the latter particularly if you're serving as hardware integrater too), but it is important to recognize the ambiguity and resolve it early.
What I've found works is a close technical liason to define the work to do, but, of course, no programmer delivers anything except through official channels, which are gated by the money stream.
Re:customer - sales rep - manager - programmer (Score:2)
Techies and customers almost always speak a completely different language and likely the specs were written by a tech person who doesn't quite comprehend the customer's workflow, or sometimes even worse, by the customer himself, trying to 'speak tech' without having the technical background.
The key section is bolded. I thought B.S.!
My experience was a NON-technical salesperson driving the requirements because they flat out LIE to the customer to get the sale.
huh... what???? (Score:2)
No, seriously, depends on teh company. SOme companies do and some don't. Usually I b&m till I get a conference call if I am to confused.
It's software engineering! (Score:1, Redundant)
They describe exactly what you are talking about, from writing specs to implementation. From forming teams, to prototyping a product before you start doing the hard parts.
Where do I start with this one..... (Score:5, Insightful)
As one other poster pointed out the customer may not really know what they want. They may have a vague idea, but haven't really thought about it thorougly enough. I see this sometimes when I'm talking to customers when you say "well what about X?" And this little light goes on inside their heads about some aspect of the system they'd never considered before, and reams of new requirements come spewing forth. If it is a time+materials project I try and work with them to fit the new requirements in to their budget, if it's fixed price they can sometimes get nasty and say they just "assumed it would be covered because Blah works that way" or some other nonsense when both of you are quite aware that up until 5 minutes ago they'd never even thought about it.
Another classic problem I've seen is when a "typical user" is chosen. Often this person is NOT a typical user of the system, they are the manager of a typical user, or a business analyst that "knows this area inside out". Politely listen to what this person has to say, and then go and find out what the _REAL_ users of the system think.
Another common defect is the "one line paradox specification". It goes a little something like this...."The new system should work exactly like the existing system, only better, and over the web".
Another common problem is the "user as frustrated interface desinger".. where a user will come up with very wild/unconventional/impossible ideas as to how items in the user interface should function. This is somewhat related to the "typical user" problem. This users crazy interface requirements might be possible, but you will end up building a system only they could like or even use.
Another problem is "users expectations completely out of synch with budget"..you have a budget for X hours, but the users have no idea of this and will run wild with features that will make their lives easier(if the project doesn't get canned beforehand), or playing amatuer graphic designer, screen layout games. Make not of all their suggestions but make sure you run by all the features they suggest with someone who is paying for what you are doing before you go and implement them.
Overall I would say that ineraction with users is great, but beware that the "user"
Re:Where do I start with this one..... (Score:2)
It's real simple, if I'm coding somethign for free, it's something I'm interested in, and I code for me, I'm the one with that authority. If it's for someone else, I'm only interested in what the person paying the bill wants. Now I'll talk with them and find out as much as I can about what is involved in their workflow and what they are doing. (And quite frankly selling them a custom software solution is an absolute last resort and only an option if the tools already out there meet less than 10% of their requirements. They won't thank me for a custom app tomorrow, regardless of how perfectly it works today.) I discuss this with the person who has the authority to say do it and get the bill paid for it. I find out what THEY want, describe it in plain english, tell them how the software will work, what it will do, what it won't. Then I write the app, if something comes up I call them and tell them what and why, tell them their options how to work around it, advised them on what is most economical vs what it will do. (customers trust me because I just tell them the truth). In the end, since the person who is responsible for saying "do it" knows exactly what they are getting with a play by play, then I get paid. Because I'm straight with customers, they tend to be straight back. If I told a customer firmly 10hrs for this, that's what I bill them, or at worst whatever breaks even. Customers appreciate that, and learn the difference between "it SHOULD take x amount of time" and "it WILL take x amount of time".
But the main point stays correct, the customer almost never knows what they need/want, they just want to be wow'd... no salesman can sell better than the tech... a salesman wow's with theoreticals. A tech wow's with realities, and when those realities get produced, each time, every time, customers keep coming back and will usually forgive you if something falls down. It also really wow's them when you refuse to let them pay for this or that. Not so much when you offer discounts, but when they actually try to pay for something and you tell them no.
That's not it but I'll know it when I see it. (Score:3, Interesting)
The second worst is: "The CEO who has never even cared about the website until now finally looked at and he hates the color blue." This is after 3 months of building an e-commerece site.
Re:That's not it but I'll know it when I see it. (Score:1)
Re:That's not it but I'll know it when I see it. (Score:1)
Re:That's not it but I'll know it when I see it. (Score:2)
How about "That is just what I asked for, but it's not what I want" ?
Re:That's not it but I'll know it when I see it. (Score:1)
The customer is an idiot (Score:1)
First thing to do is to ask the client what the problem is. If the answer starts off with "I need", grimace and ask again. Tell them pleasantly but sternly two things. One, that you will give them anything they ask for. Two, it is best to give you the problem, not the answer.
Now, on the programmers part two things are sorely overlooked. They are the requirement and the specifications. They are two very different things. There can be only one requirements document per project, as it details the requirements. There are many possible specification documents, because the specification is one solution.
After the programmer has a basic idea of what the problem is, the programmer should write a requirements documents. This should go through *at least* three rounds. If the original requirements document is said to be good, than the client is probably not willing to put in the effort neeeded to think about it. Explain to them the importance. You'd have to be incredibly lucky to get it right the first time around. Youy know you're done when the client says "wow". Finally, the client *must* agree that these are the requirements for the project. At this point, the fee and basic estimation is done.
Now, the client is not really needed. The problem is understood, and is clearly spelled out into an agreed upon requirements document. Now comes the solution. Think up one and write a specification document. Depending on how much the client needs to know should decide whether to share this with the client. There generally is no need, and they don't care how it's done, just that it works.
When work is up to specification, match it to the requirements, and go through it point by point with the client. Voila, done.
Re:The customer is an idiot (Score:1)
Re:The customer is an idiot (Score:2)
I once had a customer spec out an application so well that I was almost afraid to write it.
Almost.
The PHB just drew the whole thing on the whiteboard, explained the problem, then handed me the specs document. I had the extreme fear of it since he had just done it all himself. I read it. It was perfect. I quoted it. I wrote it. It works great for them.
How delightfully refreshing it was!
Re:The customer is an idiot (Score:1)
True, it does hapen. But rarely.
The question was how to make the customer happy. If they know enough to write their own spec, then they already are.
Dr. Blowhard (Score:3, Funny)
Systems Analysts (Score:4, Insightful)
System analysts then make up the design documents (called a 'functional requirements') for the programming team and customers to serve as the 'treaty' (or battle plan, if you like).
It's a profession that may have fallen out of favor in rapid startups, I guess-- isn't edgy enough. It's essential for any good project, but too many people are in a hurry and do the usual "I'll write up the requirements while you start coding, go!"
Re:Systems Analysts (Score:2)
They still exist... I know because I am one! My background is a few years programming and a couple of years as a management consultant, plus a Master's degree in Systems Analysis.
It's a profession that may have fallen out of favor in rapid startups
More likely these startups have never even heard of software engineering, and had no idea what they were doing! That's why so many of them aren't around anymore.
Re:Systems Analysts (Score:2)
LOL, that's hilarious. And it's exactly how our Systems Analysts work. In my company (Fortune 50 company) the Analysts are just business people who wanted a taste of the IT budget. A week or so of training, and voila, they're presented with the mantle and all the rights conferred thereunto. And this is not unique to my current employer, I've seen this at many large companies.
I rest much of the blame on the Human Resources department.
Re:Systems Analysts (Score:1)
god my company sucks...:(
Re:Systems Analysts (Score:2)
Step 1: Analyst talks to customer, develops a list of needs. These needs are NOT in terms of implementation, but in the terms of the customer. In other words, not "I need a 1600x1200 display", but "I need to be able to see my whole picture".
This document is written up, and the analyst and the customer sign off on it. This is called a Customer Requirements Document.
Step 2: The analyst and the systems architect go over the CRD, and determine what implementation features will be needed to meet the needs. This is in tech lingo - "OK, the customer needs to see his whole picture at once. Since the picture is at 300 dpi, and is 4 by 3 inches, that means at least a 1200 by 900 screen. Let's go to 1600x1200 for some headroom."
When this document is done, the analyst and the architect sign off on it. This is the Design requirements document.
Step 3: The architect creates the design for the system. This may be done via extreme programming, waterfall model, whatever.
Step 4: During the design and implementation, each feature of the DRD is checked off against the design.
Now, this does NOT guarantee that the customer will be happy. But it gives you a traceable path, so each group can know whether they did their job.
If a feature of the DRD is missing, the design team is at fault.
If a feature of the CRD is missing, the analyst and architect are at fault.
If the customer doesn't like the result, the either the customer or the analyst are at fault.
Re:Systems Analysts (Score:2)
And goodness knows it is more important to be able to assign blame than it is to get the job done right.
It's extremely difficult to get the job done right if a slacker knows he/she can do a half-assed job without consequence.
God forbid we should judge our co-workers based on performance.
Use Cases (Score:2, Informative)
example:
Use Case For the "View of Contact Addresses"
Actor: user
Preconditions: there are at least one contact in the database
Motivation: Actor wants to locate a pacticular address
Outcome: Actor locates particular address
Step 1) (left blank until you agree on the above)
Step 2) (blank)
Step 3) (blank)
If you *start* with this, than you and the client have a lot of wriggle room as to how you finish the use case. with a sortable tree? or a text input that looks up contacts by name? it doesn't really matter as long you both agree to the above.
too often, the two parties talk to each other and both come away with two entirely different ideas of what the use case is. if you come up with a really basic use case (like above), *write it down* and pass it to the client for review, you've saved yourself a ton of work.
Re:Use Cases (Score:3, Informative)
I must agree! User cases is the way to discuss software with users. You can draw user cases as in UML to make things really clear.
In mu profession I often write software to replace or complement older software. My applications are often used to reduce paperwork and to avoid doing things manually. To be able to do this in a good way, you need to know what your user does how and when and, idealy, why. This is why I often spend many hours letting the users explain their current work to me. When they are done, I put together a number of user cases trying to redescribe what they've explained to me and then schedule another meating. On the second meeting I try to explain what the user is supposed to do, and I explicitly as the user if this fits into the way they work. This process can take a few iterations 3-5 meetings (including the first 2), but always yeild good software and great user feedback.
I aggree.... (Score:2, Interesting)
There's then a bit a back and forth, itterating over the processes until both the user and I understand what's going on.
If the user asks for something then I will always re-write it in my own words and get the user to confirm that this is the case.
an example may be
Process:
MTA's with an MTA between the current risk and the time of the MTA
e.g. A customer asks for his wife to be put on the policy in a weeks time and then a change of vehicle in two weeks time, the aditional driver MTA is in-between the current risk and the COV.
Resolution:
an MTA must use the risk at it's effective date, if the in-between MTA is deleted, it must delete all MTA's after it.
user comment 1:
Is this not the same as CLX003 ? If not further detail required[CLX003 being another process listed on the sheet]
response: (use case, a bit more detailed than the first)
A customer phones up and asks for his wife to be put on the policy in a weeks time. A couple of days later he says he's moving house in 2 weeks time:The first MTA is actioned 'between' the current risk and the second.
the use cases are also good for testing.
Re:Use Cases (Score:1)
Talking to the customer (Score:3, Insightful)
Large company: You will never talk to the customer. Any communication between you and the customer will pass through at least five people who will all either add in their comments, edit text at whim "to make things clearer", or just make stuff up out of the blue.
Small company: You will always talk to the customer. In fact, you will never avoid being able to talk to the customer, even if you have four other projects that need to be done by end of day.
No, I'm not cynical. Why do you ask?
IT: Delivering what the customer needs (Score:3, Funny)
Step 1: Perform an on-site visit to the customer
Step 2: Drop a briefcase full of papers
Step 3: Kick 'em as they stoop to pick them up
Success! You have delivered exactly what the customer needs.
Of course, if they don't need a damn good kicking at the moment, save these instructions - you'll want to add it to the feature list at some point.
Re:IT: Delivering what the customer needs (Score:2)
The job of "programmer" is less'n half technical.. (Score:2, Insightful)
Unless you're part of a team working in a large organization, the job of programmer is less than half technical IMHO. As a freelancer, I feel my value to the customer lies more in my years of experience working with non-technical end users than it does in my understanding of a particular language or platform. Of course, that's tough to get across to someone you're trying to get work from...
The problem I'm having with my current main project - a customized time-tracking application - has more to do with requirements-creep. The customer (a state government agency) keeps coming up with strange and irrelevant types of information they want gathered along with the stuff that is actually necessary for the research. Fortunately, I'm just a subcontractor in this case; there's a layer between me and the client, and it's those people who are really suffering from their behavior since they'll have to figure out how to cope with this non-orthogonal information while compiling the report. All I have to do is keep adding more buttons and forms, periodically reminding them how much more complicated and intimidating the interface is becoming and how far past our original budget we are... it's actually nicer than a lot of other jobs I've had.
Another sideline I have is doing websites for friends in the entertainment industry. One site I've been trying to get started on for over a year now is for a comedian who, by his own report, is so bad at self-promotion that he freezes up when the emcee asks how he wants to be introduced! So this has been a long, hard slog to get anything out of him to put online...
Anyhow, enough rambling. The point is - helping the customer to figure out what they actually need is the unspoken part of the business that they don't teach you about at school. It's more than just leaving the jargon out of your conversation, and it's a skill too few of us have developed.
This pretty much says it all:
http://www.netfunny.com/rhf/jokes/91q4/prog
"Crater the Box" (Score:3, Funny)
He said that they wanted a load test in the middle of the night so as to minimize the effect of having customers not be able to access the box. I don't remember all of the instuctions but I remember the phrase "crater it" and "crater the box" were used (by the sales guy).
So, at midnight the cron job dutifully kicked off the Siege [joedog.org]. I wasn't being paid overtime for this, so I damn sure wasn't going to babysit it from midnight to three AM. I did get up (briefly) at three to make sure that the Siege had stopped as scheduled.
The next day the customer was livid. As it turns out this was an NT box. I hadn't been told this, and I didn't really think it was relevent to my thrughput numbers. The customer was PISSED because "we kept crashing his box" all night.
I don't know what the moral is. Maybe it is "get in the same room with the sales guy and the customer before doing anything . . . drastic." I don't know.
If any of the old Outernet/Aperian crew are reading this, mail me!
-Peter
Re:"Crater the Box" (Score:2)
Fire some shots. When it's dead, cease firing. In keeping with the sales propaganda, the customer wants to feel like it has passed some sort of endurance test.
The words may be the same, but they don't mean the same thing.
Re:"Crater the Box" (Score:2)
I really didn't get the whole thing. First of all, about half of the requests were for the exact same dynamic page over and over, which isn't much of a test, but it is what the customer wanted. The other half were static pages. I don't know what the underlying hardware was, but this was in 2001, so I would expect the system to be able to saturate a 100Mb connection pretty handily under these conditions.
Wrong. According to the customer it locked hard.
The graph was kind of cool though. Nice trend with sudden drops to zero.
-Peter
Re:"Crater the Box" (Score:1)
Your only hope would be to smell something fishy (and I don't mean penguin food) with an excited boss talking about cratering the box and the "not much of a test".
I found your tale quite interesting as an indirect but quite solid indication that Microsoft software is not enterprise-ready and is highly unlikely to get that way. If you played the same scene out on Linux (moreso on *BSD, Solaris, AIX, etc., methinks), I think you would get a very different response. (Fair chance you'd get a complaint of not running any tests;)
Ask the right questions (Score:4, Insightful)
Don't let the customer just hand you requirements. By virtue of the fact that they are coming to your firm for help, it is fairly safe to assume that they aren't experts on the kind of product you are producing for them. Because of this, they probably don't know enough jargon or have enough knowledge to translate all their ultimate goals into a good list of requirements.
When the customer says, "this product also has to do foo," make absolutely sure you ask them why they want it to do foo and what place activity foo has in the process of getting whatever productive work they want out of the software to be done.
Another classic example: professor goes to a computer lab attendant with a few sheets of paper, and asks them to be scanned. The student scans them and hands them to the professor as Photoshop images. The professor takes them back to her computer & tries to load them up, but doesn't have photoshop, so she can't load them. She calls the help desk, & the helpdesk helps her install photoshop.
Then she complains that she can't edit the text in the images, and ends up going through a crash course on editing images on Photoshop. Only after all of this happens does someone get around to realizing that since the papers were all text documents, she probably wanted them run through OCR and handed to her as Word documents, not image files.
Product Development vs. Software Development (Score:2)
Two things that are in common:
customers many times ask for a feature rather than explaining why or what they want
developers tend to design things that are useful or interesting to them and not the customer
The only solution that seems to help is to find a middle ground language and/or person to bridge the gap. Prototypes of any sort seem to be the most effective, especially when trying to introduce a customer to a new concept.
The main point I'm trying to make is that there may be some useful information from Product Development books and courses that are not aimed at software development.
Write Use Cases (Score:2, Informative)
Written Use Cases, until I saw and used them, thought they were a silly waste of time. Now I've used them and think they are indispensible for facilitating communication between the business and technical disciplines.
This is NOT UML!
Business Subject Matter Experts write the Cases, at the least the high-level ones, forcing them to really think out what they want and how it should work.
I recommend "Writing Effective Use Cases [amazon.com]" by Alistair Cockburn. After looking at several resources, this is the only book I've found focusing exclusively on this area, and one I have found useful.
Prototype! (Score:2)
Work with your customers!
Prototypes aren't just good for testing the feasability of your technical ideas. I like to bring my software to the users often throughout it's development. Just like Free Software...release early, and release often. I get valuable feedback before I spend too much time on features they don't like.
That said... this needs to be done PROPERLY, or you will become enslaven to users who just don't understand software development. You need to make users understand up front that they are going to have to take your word on it when you say NO (and you NEED to learn to say NO), else you will spend forever explaining to them why it would not be possible/cost effective to do it their way.
Customers are often unable to formulate needs (Score:2)
The customer is not an evilly whimsical person. He usually has needs that he tries to formulate by stating a possible solution. This is a natural reaction, since people solve problems with solutions. Only, it's not the customer's job (and often not in his ability) to specify a good solution: this is the job of either a "system analyst" or the programmer, depending on size of assignment etc. This is the reason that customers seem to change their minds on a whim, the "That's not it, but I'll know it when I see it" attitude. He's doing his best to help you, but in the process is misrepresenting the problem he has and actually making it harder for you to come up with the right solution.
Bottom line: good software people help the customer formulate their problem. It's an essential part of the job!
I've tried "helping" them out.... (Score:2)
I do still question things from time to time where our data integrity or security could be compromised (and then hear "oh yeah, I didn't think about that"), but that's about it.
Not always possible. (Score:1)
I have been on a couple projects where the salespeople promise customer that our product can do everything under the sun. So when we consultants show up to the customer site, we have re-align the customer's goals to what is feasible. That puts us in a horrible starting position because the customer is all upset that they aren't getting what they were promised.
And then there is scope creeping. If your project is fixed priced, you better have a capable PM that can say "NO!!!!!!!" to the customer when they request new things. Otherwise, the company/project is going to lose money and is doomed to fail.
The Question is what do you want to do. (Score:2)
Programer's nemesis (Score:1)
This affects the way clients describe what are their needs to programmers. And after they see the prototype or alpha version, their imagination begins to plot changes to the original plan. "Please add a new report here, change this database field; Port it HP-UX, OS X, and Solaris. All you have to do is to change a little bit the code... Right? Can this be ready by tomorrow so I can show it at the meeting?"
Netudo
requirements gathering is a skill (Score:1)
I'll never forget the time we spent weeks trying to figure out this one business rule for a system that tracked Employee's Sick Leave Credits. We'd go to meetings with the users and think we have it. Then we'd realize later why it didn't quite make sense and bring it up at the next meeting. Finally turned out to be that, to them, when an employee was 'away' they were absent without credits, while we thought that that when an employee was 'away' they were just absent.
Don't Start Coding until.... (Score:1)
I work on large scale implementations and upgrades - 12 months, '000s of man-months, multi-million $ budget etc. FWIW, my bible is The Mythical man-Month. It is less relevant, but still usefull, for smaller (say 3 months, 1/2 million labour budget) projects.
Plan, Plan, and when you're sick of planning, plan some more. Both you and the customer review the plan, till you both know it off by heart.
By this time, you and the customer have written the system. Now you just have to translate it into the platform / language of their choice.
to summarise (stolen (sorry -researched- )from The Mythical man Month):
1/3 planning
1/6 coding
1/4 component testing
1/4 system test
there's nothing new about this - my projects fail when I ignore the lessons I've learnt - they work (on budget, on time, on spec) when I follow the lessons I've learnt.
How to give the customer what they want. (Score:1)
We specialize in building automation systems that give the building accopants what they want (perfect office temperature control, humidity, etc) with the least amount of energy. We often have to justify our work by a measurable reduction in the customers energy bills.
Of course, I'm a complete geek, I had no experience in how these systems worked, or how tight you need to control an enviroment.
My solution was to not really listen to my mentor (a HVAC tech) when it came to the actual coding. But to make sure I worked right along side of him on every part of the installation and maintainence of the machinery.
This has had several results. First, I am picking metal slivers out of my fingers this morning after a really nasty fan rebuild yesterday. :) Second, I've become a halfway decent HVAC tech, with the corrisponding increase in systems knowledge. Third, I can now pick up a book on energy management and actually understand it. But most importantly, the systems that I have been writing code for keep tighter control and cost less to run.
In short, don't be afraid to get your hands dirty when you're finding out what the customer wants. Take the time to talk to a sampling of the people that are going to interact with your product. It'll save you LOTS of time on the back end.