|
And that word was "correct", while the exact definition of correctness varies across user and across time.
Sounds like here! 
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation."
-- Caius Petronius, Roman Consul, 66 A.D.
|
|
|
|
|
Now, lets think about this for a second ... If there was no users where would be alot of programmers just bugging around, but without whose people, we will never be able to program solid applications.
Like someone once told me ... A programmer can put his heart and soul into a piece of code and an user will stuff it all up in about 30 seconds ....
:->
The only programmers that are better than C programmers are those who code in 1's and 0's..... 
Programm3r
|
|
|
|
|
A lot of my dev time has been spent writing programs only I will use. Users just confuse things
cheers,
Chris Maunder
CodeProject.com : C++ MVP
|
|
|
|
|
Chris Maunder wrote: A lot of my dev time has been spent writing programs only I will use
What do those programs do?
█▒▒▒▒▒██▒█▒██
█▒█████▒▒▒▒▒█
█▒██████▒█▒██
█▒█████▒▒▒▒▒█
█▒▒▒▒▒██▒█▒██
|
|
|
|
|
We always consult our users first. Actually my team sits down with our user community in person and goes over a list of concerns. then we head back to base and figure out how to improve our application based on that feedback.
|
|
|
|
|
For most of the projects I worked on, users don't have any specific requirement until they see a "working" version, it is waste of time to ask them for requirements, all they have are some vague ideas on what the application should do. So here is what I do:
- Get the vague ideas from users in written form, pretending it is the requirement document.
- Build an initial version based on the vague ideas, making up the missing requirements along the way, and ask users for input if necessary.
- Force the users to either provide more specific requirements or approve the current version.
Most of the times, users are happy with the initial version I built and add some minor things for me to improve it.
Of course, this approach won't work for everyone, it doesn't even work for the guys sitting next to me. I build internal business applications, all projects are already approved by the management and we do not bill the users separately for nailing down the requirements and designing the application, etc.
The ironic thing is, we do have a team of analysts to prepare formal requirement and design documents, but the main source of their information is not the users, it is me. 
-- modified at 8:33 Monday 9th October, 2006
|
|
|
|
|
Xiangyang Liu wrote: For most of the projects I worked on, users don't have any specific requirement until they see a "working" version,
which is why costly change orders are such a beautiful ting. If you dont know what you want (or dont want) till you see it, and only approved vague ideas, then everything you add or remove is a $$$ change to the system.
gotta love it.
|
|
|
|
|
i (and our company) think such specification written and validated before starting to develop is better not to be annoyed by a customer who doesn't really know what he wants, or worst, a customer who takes benefits of non written specifications to change his needs everytime.
For us, is the customer changes his needs, it then falls in the evolution case, which is paid with another scale.
|
|
|
|
|
In the last place I worked, you would be lucky to get the users parcipitation. Our users were busy people and had their own work to do
|
|
|
|
|
Yes, but IMHO you still need to OFFER this to the users if for nothing more than CYA.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
