|
We've been talking to our users/customers constantly since we started in 2004.
At the start that was a bit of a revelation for me, as most companies I'd worked for kept customers away from developers - partly for reasons of organisational culture, and partly because they thought it was the best way to ring things.
They were wrong.
The depth of feedback and engagement we get from our customers is quite stunning, and we've had a lot of guidance over what customers want (and therefore what we should be building) as a result. Indeed, some of the most innovative and useful capabilities we've added have been as a direct result of that process. When we screw up (which all teams inevitably do occasionally) the rapport we have with out customers and beta testers means that we find out about it quickly before it has a chance to cause lasting damage.
Without that engagement, there is no way we'd have the products we have now. Enough said, really.
Anna ![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
|
Thanks! It certainly works for us. 
Anna
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
If u are regular coder, not some kind of boss, PM, Sales manager, u should not concern this things. This will disturb you from main coding problems, all you should do is write good code, not test, sale things (single responsibility principle). Then your work will be better. However if you writing your own software then u must do all job for all roles, u should test, sale, support and of cource listen yor customers and users, but unfortunetly in this way u will spend much more time, or code will be not good as usual.
|
|
|
|
|
Err - no. 
If you don't talk to your customers (or their stakeholders) how on earth can you have any confidence that you are building the right thing?
Anna
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
Hey.
Im sure that everything is going fine, becouse sales manager keeping finger on pulse, this is guy who knows what we need to change, he is one who dealing with customers, customers usualy have a LOT of requests, his job is also to filter what we need to do and what we dont need to do, so lets imagine i trust sales and do whatever he ask me to do.
In situation if u have 5 users u have to listing each of them carefully beacouse if will heart loosing one of them, and if have 5000 of users that is absolutely other thing u should understand that, and as VERY expirienced person u should also understand that answer for main question is depend from MANY things, like project, team or personal soft, complexity and so on ...
|
|
|
|
|
Whilst I understand what you're driving at, a sales person is absolutely the wrong person to use as a sole customer contact in this situation - they are anything but a customer advocate, and not generally technically engaged with the development team (which is crucial if they are to stand between you and the customer). I only appreciated that after working in a team that had such a stakeholder - it was absolutely invaluable, and gave us a real responsiveness and perceived quality our competitors did not.
FWIW, despite the number of customers we have we don't find the contact onerous or overbearing at all - quite the opposite in fact. Furthermore, when you receive an obscure or weird feature request, being able to ask them directly exactly why they want such a feature can reveal insights your salesperson certainly would not be able to give, and prevent you investing a ton of wasted effort on something that won't really benefit your customers in the way you thought it would based on the filtered and sanitised information with which your team had been presented.
Remember, the vast majority of customers will only contact you when they have a problem that needs solving; our job is to ensure those problems are opportunities (i.e. changes that will make our customers lives easier and our tools more effective) and not liabilities (i.e. bugs which stop them working).
Anna
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
modified on Monday, November 29, 2010 5:29 AM
|
|
|
|
|
Thanks for response Anna, i understand your point and ur absolutelly rite. What about me i cant imagine if i were specking with customers, we have 5000 +, how this could effect to my code, we have CEO, he also sales person, and i trust this person, and all discussion about new features, and new behaviour not bugs i prefer to discuss with him not with horde of users. But again all things u wrote are correct and i take some personal profit from ur words =)
|
|
|
|
|
No worries. FWIW, the size of our customer base is broadly of the same order of magnitude as yours and we get maybe 1-2 emails a day, which I would hope indicates that we're doing something right.
Anna
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
That is like saying "As a car driver, I am concerned with what gear I am in, what speed I am doing. That is all. What goes on outside the windscreen is none of my business and I will not pay any attention to it."
Result: CRASH!
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
Hello, good example but what about that, As a car driver i should not ask anyone what they think about my car, my job is win race. Also i mention that if u writing your own soft this is complete different situation. I always working in teams i didnt have much expirience in writeing own soft in comerce purpouse, so i thing your example is better for this situation and not for team project.
|
|
|
|
|
Jason Ti wrote: As a car driver ... my job is win race.
No! That isn't even 10% of your job as a race car driver! Think about it: the F1 starting grid is 20 odd cars, of which only 6 or so have a realistic chance of winning. The drivers job is to look good for the team and in that way to secure or maintain sponsorship - which is what keeps the team going as a whole.
Companies are just the same: If you pay attention only to your narrow task, you will miss the bigger picture (even as part of a team) which lets you and the company expand and grow.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
If you do not do any testing then I feel very sorry for your users.
Henry Minute
Do not read medical books! You could die of a misprint. - Mark Twain
Girl: (staring) "Why do you need an icy cucumber?"
“I want to report a fraud. The government is lying to us all.”
|
|
|
|
|
Hey, testing is for QA and i feel very sorry for you if u doing tests and coding, im not talking about unit tests of cource, Its like write code and clean floor or cooking at same time.
|
|
|
|
|
So, you just type in the code, compile it, then ship the product off to QA.
You are very lucky. I used to have to compile it and run it. Do you know on the odd occasion I even had to click on a button or two, just to make sure the event handling code worked correctly. It was a different world back then, we even used to call that testing.
It must be a very nice feeling, being able to write perfect code, first time, every time. Have you offered your services to the major software vendors? I'm sure they would snap you up in an instant.
Henry Minute
Do not read medical books! You could die of a misprint. - Mark Twain
Girl: (staring) "Why do you need an icy cucumber?"
“I want to report a fraud. The government is lying to us all.”
|
|
|
|
|
Im not sure what u talking about, i did not tell u that i just type code and ship to QA so this is your pure imagination i guess, i see u tryed to be a little bit funny but think about that - imagine we have old system, it is working since 2000 year, it is using .net 1.1, there was no ajax libs, unit testing nothing, all this years system was grow up to 5000+ customers. Your post is good for writing NEW code, new product, with new technologies, u used to comfort so u never will understand my situation. When i change something, add new feature, or fix, i cant spent time to test becouse i will spend 2x time for testing, my change can broke something in so unexpected place. So we have QA for this, they working twice more then me, even with my basic tests. See that happens that it could be a lot of specific situations that u just did not meet in your life.
|
|
|
|
|
I'm one of the lucky ones because not only do I write the applications, I also train our users (Air Traffic Controllers & Technications) at their facilities (Airport Control Towers)
Steve
_________________
I C(++) therefore I am
|
|
|
|
|
Ah, that would explain the high suicide rate there 
|
|
|
|
|
only at sites that do NOT have our equipment 
Steve
_________________
I C(++) therefore I am
|
|
|
|
|
What company you work for? I used to work in Thales on this subject and I've never seen an user...
I might be tempted to apply to your company if it is European based.
Cheers
Federico
|
|
|
|
|
sorry, we're in the Los Angeles area...the company is NBP (New Bedford Panoramex)
Steve
_________________
I C(++) therefore I am
|
|
|
|
|
For the first time in many years I'm truly happy again in my job and now I realise it is to do with being able to interact with the users and see how they use the software and what works best for them.
For the 6-7 years before this position, I was part of teams where I was blind as to where my piece of the puzzle fitted in within the whole picture. I repeatedly asked for the opportunity to visit clients on site and at least see them in action with the software, but NOOOOOOOOOOO!
Again before that I was happy for 4 years in a place where we used the developed software internally and I got immediate feedback.
Having an engineering and analytical background myself, I have always been able to serve the clients better when I could talk to them and see what they were doing. I would sometimes come up with solutions that they had not even thought of. Only then would things translate to software! And we would both be happy.
How can you confine a developer to a cubicle and expect your software to answer the real problems of the client? If that is not bad enough, what is worse is that in places where I worked and they did just that, the Functional Requirements Specification (FRS) document would come to me AFTER I had finished 80% of the work. Indeed the Business Analyst would ask me what should go into the FRS. It's a joke believing we give developers enough understanding for them to be able to sit and develop a mature, well thought out solution in a cubicle.
|
|
|
|
|
If you don't talk to your users, no-one else is going to tell you what works / doesn't work. What they are actually doing with your software. What they don't / can't / won't use.
If you listen to what they say, then all out jobs get easier.
Supporting them is a pain, but it is worth doing right - and at least the users know that the person on the other end actually has run the software, rather than reading from a script on a cheaper continent...
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
Best End-User Support ? End the user
Yeee 
|
|
|
|
|
End the user - End our jobs...
Happy user == more work for us.
Think about it: Do you go back to a restaurant if you felt you got sh*t service and food? Or try somewhere else instead?
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
