Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I have been using gvim at work for a year or so, just at the point where I'm loving it, getting the hang of it and trying to j,k all over Microsoft Outlook. Then my computer died. Now, originally I had installed gvim myself, which at the time was a "no-no" and is now is really a bad idea (what with all the people introducing viruses to the network and whatnot).
We have a software review board to which I was sent when I wanted gvim "legally" installed. I was told that the standard text editor is UltraEdit and they don't want to support more than one. If I want to use gvim I need to talk management into making it the standard.
I'm kind of at a loss. Obviously, I can tout the cost savings, but I was having a hard time explaining what my fuss was about. If it were another programmer, I'd just force them to use it and they'd figure it out for themselves. But management folk aren't much interested in not being able to figure out you need to "i" before you can type, er, insert.
I told my manager it was like having a rowboat instead of swimming everywhere. And sometimes you're motorboating in that thing, but I'm looking for concise, compelling arguments which aren't based on bad analogies. There are a number of similar-ish questions, but I fear they trend too technical. Any ideas?
And after all your awesome advice wins the day for me, how do I ease former UltraEdit users into becoming gvimmers?
Update:
Thanks for the answers! I accepted one but took from many (don't know if that matters as question is now closed). Even though it was apparently too open-ended it is helping me plead my case with the powers-that-be.
Seems simple enough. Tell them that you are far more proficient with Vim and that you know next to nothing about UltraEdit. Whether this is true is irrelevant - provisioning requests for software aren't delivered under oath :-)
This has two effects:
you won't need the IT staff to support you since you such a guru.
you won't need weeks of ramp-up time trying to figure out how UltraEdit works.
Managers understand cost/benefit analyses. The cost of letting you use Vim is zero. The cost of making you use UltraEdit is considerably more.
Likewise Vim's benefits are high since you're immediately productive.
The company where I work actually has two classes of software that they let us use. The first is the stuff they support. The second is stuff that you need to get yourself (off the company distribution site, not from outside, they're still paranoid about malware and rightly so) and, if you have trouble with it, don't call them.
But don't make the mistake of trying to evangelise Vim. You want to be given a choice, not try to convince everyone else to have their choice taken away.
gvim is a portable app. So don't install it but have it anyway.
The argument I would use is that individual developers are more productive in different environments and this one doesn't even cost them anything. And, on that note, while I'm a gvim lover myself, I think forcing others onto it is guaranteed to only make them hate it.
To be honest, I don't know what UltraEdit provides that Notepad++ doesn't - which suggests a waste of money.
But, their response seems like a canned "we don't want to do our job so go away". If I were in your position I would present the use cases that I used with vi and DEMAND that they show me how to do the same thing in UltraEdit because they "support" that product. And trust me, I would make sure I make multiple tickets in the ticketing system just to piss them off. And at any point if they say "I don't know", contact their supervisor and ask them why you can't have gvim installed when the techs don't even know about the "supported" software.
If they refuse to help you or take their time, contact their supervisor and tell them they are impairing your ability to do your job.
Eventually someone will listen to you and cave :).
gvim is indeed a thing of great power. Grown men have been known to weep at the mere thought of its beauty. The productivity increases provided by this tool are immense if you know them by heart, and switching back to a conventional editor can make you feel as if you are typing with only your thumbs.
Given this, I would suggest you take some sort of productivity measurement, if you can. For similar straightforward development tasks, measure the lines of code you output in n hours with gvim, and then with UltraEdit. Include tasks such as refactoring into these measurements. Then, take these numbers to management and say, "Would you have me perform at 1/x the speed that I could be performing? Remember, this is dollars and cents we are talking about!"
Also assure these naive creatures that gvim is not a virus and will not take down the network in flames. It is, in fact, a text editor.
Implore them to amend the standards to allow for the application of a little logic. A little logic can go a long, long way.
Good luck to you, roger. As a fellow gvim enthusiast, I salute you.
This question is a better fit for programmers.stackexchange.com. But anyway. I think this whole "everybody at work must use one editor only" is absurd. Whatever happened to "different strokes for different folks", especially for creative types like programmers?
If your work doesn't see programmers as creative types, then you have a bigger problem. Time to visit careers.stackoverflow.com. ;-)
As a personal aside, I type with Dvorak. I don't necessarily want to convert all my workmates to Dvorak, but, I would find a different job if work made me use qwerty. There is simply no way I would agree to retrain myself on qwerty given that I type at 100 to 120 wpm on Dvorak, and no amount of qwerty training will get me to that speed.
Under these circumstances, I would consider going rogue.
I'm afraid you've presented a no win situation that I've faced many times in my programming career - a draconian policy inflicted on productive employees by middle management. A vain effort to homogenize the environment and work force beyond any level that can be considered reasonable.
Ponder the consequences of going rogue, by installing vim on your box anyways, and see if they are worth the benefit to you. If you decide that it is worth it, just do it. It's not like you are doing something illegal, after all. If the consequences are dire, I'm afraid you will have to cave in and start using UltraEdit. It's not the end of the world (it could have been notepad), but as an avid vim user myself, I feel your pain.
Update: I see people are voting me down, but this is the real world and the real world isn't perfect(ly theoretical in nature). Sometimes sacrifices have to be made, but in the end it's still your decision and only you have enough information to weigh the consequences. All we can do is present you with options, some more extreme than others...
Programmers are a very expensive resource, and you are losing productivity by using UltraEdit. Just do a little math:
Suppose you spend 60 minutes a day for a month dealing with UltraEdit instead of programming. Then, maybe after month of adjustment, it only takes you an extra 30 minutes a day to use UltraEdit. Add those minutes together, and you get nearly 20 days per year! This means it costs your company nearly a month of your time every year to use UltraEdit.
Now find a few colleagues who have similar opinions. If four or five of you get together, the amount of lost time gets really big really fast.
Just flip the numbers around, and tell your manager that you know a great way to A) save the company a bunch of money or B) greatly improve programmer productivity.
Whether that argument will work depends on your company (and your position in the company).
The people who craft IT policies should understand that a programmer's computer needs are quite different from those of the average business user.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I work in a large outsourcing company based in India. I am in the US and have a team of 3 developers and we are using scrum practices and have had great success with our approach.
My problem is that our company requires us to estimate time on activities monthly whereas we work on weekly iterations. The system provides a list of 45 activities. To give an example of how granular it gets, we have activities like Coding, Coding Review, Coding Rework.
Now everyday we are supposed to enter actual time aginst these activies. And to make things worse the system for time tracking is very poorly designed and is very slow.
The rationale the management has behind this process is that they want to use this time logged to forcast future work. But the problem is that there are no processes in place to ensure that we enter correct time. So we end up putting any numbers and the end of the day.
This is affecting productivity and morale of the team and defeating the whole purpose.
What are you thoughts on Time tracking in an Agile projects?
What are you thoughts on Time tracking in an Agile projects?
100% waste: when asking you to do this, your managers are actually keeping you from working on code which is the only thing that really adds value to the product (not even to mention that the application you have to use is slow, poorly designed so this looks actually closer to 200% waste). This really sounds like outdated command and control to me. This should be handled by the ScrumMaster as an impediment.
Make sure and bring this up as and impendement to your scrum master, also bring it up in your retrospective.
Because you may have to live with it let me suggest two approaches:
Be as accurate as possible and give an estimate at the end of the day.
Write a front end to the clunky reporting system. Figure out and easy to use and time saving interface, write it, then have it feed the clunky old system.
Unless you work in a ROWE, chances are time should be recorded somewhere so that whoever is paying the salary knows where the money was spent. How useful this is and how much it can be used can be debated forever. Evidence-based Scheduling may be the idea that your management has, which has the potential to work and the potential to backfire terribly.
I'd be tempted to see if management would agree to some inbetween timeline here so that the iterations and planning align. The problem with trying to plan 3-4 weeks down the road is that what happens in the next 1-2 weeks can dramatically impact that. My suggestion would be to see if a 2-week timeline could be agreed so that almost a half-month is planned at a time. It is a bit of a compromise but assumes that whatever system the monthly data goes into would accept something biweekly. An alternative would be to do monthly iterations though that may cause some upheaval I'd imagine.
Time tracking can be useful if there is trust, honesty, and most everyone is respectful about the information. This can be asking a lot as I'd imagine many have been burned by such systems. Does management know of the slowness and poor design of the time tracking? For example, if it is taking an hour a day to log all the time and you can explain why that really is the case, there may be an opportunity to get a better system. A key point here is to know what specifically are the problems, why they are problems and what kinds of suggestions could be made as while I'd say that time should be tracked, one could use spread sheets for a relatively low-tech way that may not be great for management, but part of this is accepting trade-offs, IMO.
Sounds like the time tracking is probably a bit too granular, or too rigid in its entry. What if, instead of having you enter time for each category at the end of the day, they instead asked you to keep a log that you could fill out with what you were currently doing during the day - so you'd get something like this:
8:30am - 9:45am: Coding
9:45am - 10:00am: Coding Review
et cetera.
This is a tough one. The problem is that the time used will NOT forecast future work. That's very well documented and a dangerous trap many fall into. Velocity can help to forecast future work but it obscures the hours by design.
The problem with the approach is this: Not all hours are alike. Capturing hours turns work into "ideal" time. Future work is the estimated not by the team that is doing the work (and no 2 teams are alike), but by management that has used those hours to come up with some algorithm. Sound familiar? It's not Scrum or Agile. Management neither understands the process of Scrum nor has bought into it.
Having that confusion is not good. Clients believe you are providing something you are not, team members work under false assumptions, and management is not there to provide the support you truly need.
So, it really won't matter what you put down for hours... very likely the process will fall back into a non-agile approach which will be statistically as accurate as just making up hours and reporting them randomly. At the risk of sounding ridiculous, you might as well save your time and just make up hours.
Now, if time is used to see how much you spend doing interviews, that's easy to gauge without a tracking system.
If the time is used for billing, that's a different story. That's not Scrum-related, but a part of business process.
I was in a formal testing class, and the lecturer was trying really hard to convince one of the student to use timesheet to track time, because the entire software engineering/project management theory is based on that time sheet to do linear projection.
The problem is the reality is nonlinear (depends on the level volatility of the project)
Agile process like scrum focus on people not process, but how about people and business.
because we mentioned that tracking time was using for billing customer. the problem with tracking time is it may hurt people. for example, you estimate task and do it 10 day, next time you do the similar task and now with 10 days you cannot do it because of some unpredictable reasons, even your scrum master or PO can understand and share with your the feeling of missing the deadline(not entirely your fault)...BUT how about others behind that layer, top managers, other project managers, other developers...they may read it wrong that you had issue with your performance....so for me tracking time should be fine if we have a way to do it completely behind the developers and we then use that data to analyse the root cause and feedback for the team to learn from it. the tricky part is doing without creating bad feeling for the people which I still cannot find any workplace can do this well except rumor said that Google is the place with their fancy style.
I'm doing some job interviews for the first time for my replacement. I want to know how they would approach a brownfields project, but am not really sure how to phrase the question.
I'd like to know what their attitude is: e.g. throw out and rewrite, use a tool to refactor, step through the code and understand, what books they've read (e.g. "Working Effectively with Legacy Code").
How do you find out how someone takes on brownfields software development?
When interviewing, try to engage in scenario brainstorming or role playing, not definition swapping. In this case try to engage an applicant in telling their story about what they would expect "...when taking over responsibility for the main finance system, which this department and that group use daily for these things, and there are a couple things that are wrong with it today, and oh by the way, there is a upgrade release scheduled for three months from now that will allow direct integration with this new banking partner for 1099 processing". Make the scenario specific and real for your situation, and get them talking.
The important thing is to draw out from them not only what they would do, but almost as importantly, what they know to expect. If your candidate sits across from you and weaves a story about getting up to speed in a couple days and making major changes up through production by next Friday, without asking any of the important questions and impressing you with their effectiveness, doubt their experience (and if you are in a regulated industry or, unfortunately, Big Company, possibly their sanity). If instead they ask good questions about what the environment is like today, what's the review process, who makes the decisions about functionality, is there a testing environment, is the code testable or are there unit tests (gasp) in place, and what happens today if a change needs to get in place by Friday - hey, they've probably been here and done this before.
You of course want to hear how they would make sure existing functionality works and time bombs aren't being set but you also want to hear them making reference to things they would be doing so that this project becomes better, easier to work with, and more fun over time. The activities they specifically are engaging in to turn the inherited legacy project into a rocking world of fun should come through in their storytelling. I mean, they are planning on doing that, right?
Great interviews are conversations and experience sharing and story telling. Draw those stories out, bounce them against the b.s. shield, and go.
This sounds like a great interview question. Why not just ask them
what steps they'd take on inheriting/maintaining/extending a badly written legacy codebase, or how do you determine when a codebase needs to be refactored? Another option would be to give them a medium sized piece of spaghetti code and ask them how they'd extend it.
Lots of good suggestions for answers here.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Recently, we've come across an issue at work where if one person is working on some code by themselves, it seems to come out with the other team members looking at it and going "Huh? That's ugly, unmanageable, I need to rewrite that"
In fact, recently, I myself have had to re-factor something that was written the week before so that I'd be able to add in my (related) feature.
I know that Pair programming is the way to go for this, but we have an uneven team (3 members). As our team is being pushed pretty hard at the moment, we really don't have time for Peer Reviews (though we can do Pair Programming, as we're allowed to estimate that into our task estimates)
I'm just curious as to how people would suggest we overcome these issues with poor code being generated.
When you work alone, and produce code which your colleagues find ugly and unmanageable and needs to be rewritten, then do you:
(a) agree with them when you look at it a second time,
(b) disagree?
If (a), then the problem is that on your own, you aren't fully clarifying your code when you write it. Since pair programming is the only thing making you write decent code, I suppose I'd recommend that the "odd one out" should work on tasks which do not involve writing long tracts of bad code: bug-hunting; maybe writing test code, since that tends to be a bit less fiendish. Meanwhile, work on improving your skills at writing better code - perhaps do reviews of your own code from a few months ago, and make notes as to what was wrong with it.
If (b), then the problem you have is incompatible ways of expressing your ideas. The code may not be bad by your standards, but it's mutually incomprehensible, which in a corporate setting means it's bad code. Pair programming means what you write is a compromise that 2 out of 3 of you understand, but that's not really a solution. You need to come to some mutual agreements about what you find most difficult about each other's code, and stop doing that. And you all urgently need to start thinking of "code quality" in terms of "my 2 colleagues will like this code", not "I like this code".
Either way, you all need to work on writing code for the purpose of being read, rather than for the purpose of getting the immediate job done as quickly as you possibly can. Personally I have done this by trying to express things in the way that I think other people might express and understand them, rather than just what makes sense to me at the time. Eventually it becomes habitual. When I write code, I write it for a public audience just like I'm writing this post for a public audience. OK, so on my personal projects it's an audience of people who think just like me, whereas at work it's an audience that thinks like my colleagues. But the principle is to write code as if someone's reading it. You're explaining yourself to them, not the compiler.
Not that my code is the best in the world, but I do think I benefited in that my first job was in a company with 30-odd programmers, so I got to see a wide range of ways of thinking about things. Also a few examples of "what not to do", where one programmer had done something that nobody else could easily understand, and therefore could definitively be said to be bad. With only 3 people, it's not clear whether a 2 v. 1 difference of opinion means that the 1 is a freak or a reasonable minority. When I did something and 4 or 5 people could glance at it and immediately say "eeew, don't do that", then I started to really believe it was just a dumb idea in the first place.
I'd also recommend that if you aren't allowed to budget for code review, lie and cheat. If you're heavily re-writing someone else's code, you're effectively taking the time to review it anyway, you just aren't providing the feedback which is the worthwhile part of code review. So sneak the review in under the radar - write a function or three, then ask a colleague to look at it and give you instant feedback on whether it makes sense to them. It helps to have a conversation as soon as you've done it, with the code on the monitor, but do try not to interrupt people when they have "flow", or to get into lengthy arguments. It's not pair programming, and it's not formal code review, but it might help you figure out what it is you're doing on your own that's so bad.
I'm surprised that you don't have time to do peer reviews but you have time to do paired programming. Is the latter not a much bigger sink of time?
We also have three developers only at our company and, surprise, surprise, we're being pushed hard at the moment. I'm pretty sure my boss would laugh at me if I suggested paired programming because that would be viewed as doubling the number of man hours for a task even though in practice that's not the result it should produce. Our peer reviews are never more than an hour and that is an extreme case. On average I would say they are probably about 10 minutes and, per developer, only happen once or twice in a day.
IMO you should give peer reviews a try. You often find that the offending people (i.e. the people writing the lower quality code) eventually realise that they need to make more of an effort and the quality improves over time.
If you have three developers and each of you think the others code is not good, you urgently need peer reviews.
So:
you are being pushed pretty hard
your code is of poor quality
Do you think the two could possibly be related? The answer is to fix the schedule.
Pair up all three at once.
Set up some coding standards.
Use a dunce cap for build breaking developers.
Perform daily stand up meetings to communicate progress.
Also try peer reviews twice a week, like Tuesday and Friday.
Pair Programming doesn't have to be all day every day to be effective. I have seen good results from even an hour or two working together each week. One way to go would be to pair A & B for a while, then A & C, then A & B... with a lot of individual time in between.
It also depends a lot on the personalities and chemistry of the team members. Two of the three might work exceptionally well together and you'd want to benefit from that.
You should still pair. Set up sessions say 1 day per week and rotate the pairs. This should keep your manager happy and increase the quality of the code, improve communication. If you keep metrics on how many faults happen in paired vs solitary coding you should start to see the benfit and display this to your manager,
eg This took x man hours but saved on average y in defect fixing. Additionally the clode is cleaner and will take less time to alter then next time we touch it.
From there you will have hard statistics and you can start to code more.
Basically your story seems to be the same as mine.
No time to do things.
Mistakes happen.
Rush to fix it (taking more time)
Go to 1
You need to stop the rot.
Code reviews
Enable Stylecop that will force you to write readable, standardised and manageable code
We use code reviews. Additionally there are some single task: changing a diagram, installing some stuff...
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've read somewhere (I forget the source, sorry - I think the MS Office developer's blog?), that when you do a survey of users asking them about what features they would like to see in your software/website, they will more often than not say that they want every little thing, whereas collected metrics show that in the end, most people don't use 99% of these features. The general message from the blog post was that you shouldn't ask people what they use, you should track it for yourself.
This leads to an unfortunate chicken-and-egg situation when trying to figure out what new feature to add next. Without the feature already in place, I can't measure how much it's actually being used. With finite (and severely stretched) resources, I also can't afford to add all the features and then remove the unused ones.
How do you find out what will be useful to your users? If a survey is the only option, do you have to structure your questions in certain ways (eg: don't show a list of possible features, since that would be leading them on)?
Contrary to popular belief, you don't ask them. Well, you don't listen to them when they tell you what they want. You watch them while they use what they have right now. If they don't have anything, you listen to them enough to give them a prototype, then you watch them use that. How a person actually uses software tells you a lot more than what they actually say they want. Watch what they do to find out what they really need.
Give them options and the have them arrange them in order of importance. As you said, the users are going to want everything, but this will allow you to tell what they want the most.
You tell them. Then both of you know.
(No, your users won't tell you what they want. That's work. If users wanted more work to do, they wouldn't be looking for software to do their work for them.)
An anecdote from a previous life:
We were planning for a new release and wanted to add some new features to the application. We got the users together and brainstormed what things they wanted to see in the system, placing each "feature" on a yellow sticky on a white board. We then grouped similar requests together and eliminated duplicates or near dups.
We then laid each sticky on a table with a cup in front of it. Each user got 10 pennies to "vote" on the features they wanted. They could put as many pennies in each cup as they wanted, up to all their pennies in one cup if they so desired. We then counted the number of pennies in each cup and chose to implement the top 5 vote getters, in order of votes.
It was surprising to see people that were passionate about a feature while brainstorming and categorizing turn around and not vote for that feature (or vote lightly for it).
Of course, a technique like this will only work if you have ready access to your user base (this was for an enterprise system we developed internally).
You ask them.
(No, you do not know what your users want better than they do. Yes, you will get a lot of stupid answers. Avoid multiple-choice surveys and instead opt for reviewing free-form answers. The information you collect will be invaluable.)
Of course — you could always allow your users to vote on which features they like most...
Users know what they don't want better than they know what they want.
We had brought in a team do do an Oracle eBusiness Suite implementation. They took an interesting approach that had worked very well for them in the past. But it was phenomenal in our environment.
We had cultural issues which meant none of the users were going to stick the necks out to say what they wanted. I had history with the users from the past. Trying to get get requirements out of them was like trying to get blood from a stone. But once you went live the bitching would start.
Anyway the implementation team installed Oracle eBusiness Suite straight out of the box. Give the users the basic training. Then about every 4 weeks for the next 6 months they customized the base installation to accommodate the complaints.
I would recommend against showing them options; as you point out, if it's available, then people will want it just for the sake of having it. Often the users are not aware of the extra costs of developing a particular feature, and just want it because you mentioned the possibility of having it.
The other option is to show a list of all the features you could possibly add, and then attach a price to each one, and then ask users, would it be worth $X to have feature Y, or, how much extra would you be willing to pay for feature Y?
Eat your own dog food
Try to use the application that you write yourself as much as possible. Then you will know how you can improve your application.
According to 37 Signals - Getting Real book, you don't do anything, you don't even record what they want, you just delete mails after one read without any action.
When it comes to implement / fix stuff you'll remember the most important things that your users want from top of your head. Obviously this requires a bit user base.
You need to tie features to cost. Everyone wants features, but not every feature is worth paying for. Ask which features are most important, which would your users be willing to pay for? Develop features based on the priorities supplied by users and stop when they aren't willing to pay for any more. Get the product into their hands as quickly as possible so that you can get real feedback on what doesn't work and what needs to be added. When the users have access to real software, you get much better information. This works best when you are developing specifically for a particular customer. If you don't have access to real customers, consider seeding your product with people (can you say, public beta?) free in order to get better feedback.
Users don't know what features they want. You don't know what features they might be offered. "Features" don't mean anything except as they help them accomplish tasks and achieve goals. And that's where you should start, because they will have a very imperfect understanding how they relate.
There is one thing they know, maybe, much better than you do. And that's how to get their jobs done.
As soon as computer/software concepts and terminology start to leak into the discussion between users and designers, you're off the rails.
So many times users will focus their requirements in terms of what's wrong with, or could be improved about, the software they currently use. Over time, even they lose the distinction between their jobs, and the software they use to do their jobs.
It's a very hard, critically important problem for you to solve this.
The only way to know what the users "really" need is to "be" the user.
Its programming kung fu black belt level.
"Be like water making its way through cracks. Do not be assertive, but adjust to the object, and you shall find a way round or through it. If nothing within you stays rigid, outward things will disclose themselves.
Empty your mind, be formless. Shapeless, like water. If you put water into a cup, it becomes the cup. You put water into a bottle and it becomes the bottle. You put it in a teapot it becomes the teapot. Now, water can flow or it can crash. Be water my friend."
When you be the water/customer, you'll now.
I think Bruce Lee would be a good programmer.
Im very serious. This is the way I work. I cant do things I dont understand, so I have to understand before I do things. When I understand, and my costomers know I understand then I can do a good job. Without understanding there will be missunderstandings. You are the only person who know when you have the correct level of understanding, you are also the person who is responsible to get that knowledge.
The Oracle at Delphi
Pros: accuracy is superb
Cons: if you can interpret the messages, which many people fail to do (often seeing what they want to see). Also requires supplication, which can get messy (contrary to popular opinion, your hecatomb need not be 100 of the same type of livestock).
Psychics
Pros: accurate to a point.
Cons: rare. Prone to mental instability, highly vulnerable to eldritch beings, and might attract unwanted attention from them. Also, it takes experience to sort through the mystery that is the human mind to get to desired information. And sometimes you still need to probe subjects while they're actually doing the thing they need help with, since users lie.
Plant a mole
Pros: New gadgets. New Poisons! Plans within plans within plans. Baby's a freak show. You might learn all sorts of fascinating things in addition to the information you need to help the user.
Cons: Expensive. Chances remain that the agent will turn on you, or fail to learn anything you couldn't learn more simply. If discovered, organization will likely turn or liquidate the asset, which represents a huge investment of resources. Organization might reciprocate.
Guess
Pros: Take a group of people with average to great imaginations and problem solving skills, give them some booze and inspire them with some quotes from Ghostbusters, Big Trouble in Little China, or The Big Lewbowski. Who knows where it will go, but it'll be fun and they might produce something interesting/useful.
Cons: Chances of meeting user's needs are higher than you think, but not that good.
Ask the user
Pros: users feel empowered as part of the process.
cons: until they have to decide on anything, at which point you are on your own. Unless the user is a very experienced user, in which case they probably have a good idea of what the want. There's only like 4 experienced users on the planet though, and nobody ever knows anyone who gets to do a job for them. They may be mythical beasts.
Pretend you care and ask the user (even though you don't really), and then observe them doing whatever key workflow/process/etc is involved and pay attention to what they do.
Pros: you trick the users into thinking their opinion matters, which empowers them but doesn't deliver any other baggage. Since users lie - no purposefully or maliciously mind - you actually get to see them in action and get a better grasp of what the problem is, thus giving you a better foundation for building a solution. Also, you avoid the psychic route, and thus avoid a long and winding road that begins with promise but ends with you and the psychic being eaten by some monstrous, unspeakable thing that is not of this world. Observing the process is like totally Zen, which is good for your Developer Mystique.
Cons: No road trip to the Oracle (which would be EPIC). Spies are much sexier; chicks dig spies. Ghostbusters|Big Trouble in Little China|The Big Lewboski probably aren't involved. Feels more like work than the rest of the options.
Asking users about features will prompt them to talk to you about features.
If you want to find out what users really want then you are talking about understanding their goals and motivations. I've found the easiest way to start doing this is user interviews, not about features but about how users use your product and products like it, why they are using it and how it fits in with their life.
Once you build an understanding of what your users are trying to do with your product and why they want to do it you are in a position to make an informed judgment as to whether the features people requested are what they really need.
Ideally I think your problem is about understanding users rather then just listening to their requests.
This is an old question with a lot of good answers already, but I thought I'd just add a little bit of personal experience for the sake of people who end up here in the future through a search like I did.
If your project does not need to gain an audience as quickly as possible in order to succeed (like a webapp) if it's more of an internal project or product to be sold for a fixed client, or type of client, then I believe your best bet is to go the 37signals way: give your users the absolute minimum they need in order to accomplish the most basic tasks of the most basic cycle of work at first, then listen to what they say it's objectively missing in order for them to do their work properly. Not what they want or would like it to have, but what they really need. And the only way you know for sure what you really need is when you don't have it.
I worked as the designer in the development team of an intranet-based "heart-of-the-company" app that followed that strategy, and the results were wonderful. First week: everyone was pissed. When it was over, 90%+ of approval, and the app was still simple and beautiful. And most of the people who were not entirely satisfied seemed to understand why it couldn't be like they wanted, and the main request of nearly everyone was to, whatever we did, keep the app simple.
Again, if you're working on a product or website that needs to attract people first, that might not be feasible or delay things a lot. But if you have some control or leeway over the userbase, I'd definitely recommend this approach.
You don't ask for features. You ask for problems. Pain points. Find out what they hate about their current solution. Find out what eats in to their time.
When you know what they don't like, then you build the solution to those problems.
When you solve real problems, then you're creating real products that people will gladly give you money for.
But what's also important is respecting them during your research phase. Surveys are still great for doing research, but if you ask them a dozen questions, they will hate you. You need to respect their time and use a survey tool that engages them and leaves a great impression.
It's a proven fact users don't know what they want. What you need to ask them is what is wrong with what there is now - what problems are they having with your software? why aren't they using x feature and y control? why interaction x worked for them while interaction y made them try to gauge their eyes out?
Of course to be able to ask those questions, you need to do some field study and see what features are used, what patterns your users exhibit and analyze that data. That analysis will give you the base for much more specific questions which users are able to answer decisively and accurately.
If you're serious, you videotape them at their work, and then you break down what they are trying to accomplish and how your product can help them. This is part of a whole discipline called usability engineering. A good introduction to technique is Jakob Nielsen's book Usability Engineering. Back before he became a shameless huckster, Jakob was a very good scientist and he learned a lot about cheap ways of figuring out what users need. Especially good if you're on a budget. What impressed me most was using paper prototypes; this is a great way to mock up software you haven't built yet and helps answer your question about what to build next. Until I saw this technique in action I couldn't believe how effective it could be.
P.S. One example of what happens if you just ask people: 90% of the feature requests for Microsoft Office 2007 were for features that were already in Microsoft Office 2003. In that case what users needed were better ways of finding what was already there. I wish I could find where I read about this... sorry not to have a reference.
I'm assuming based on your wording that you are building a product to sell, and not building something to order for a specific client.
In that context, I'd say that you should start by becoming a user yourself and building the features you need in the way that you want it. As you evolve the product, you'll need feedback from other users, but this at least this gets you started and breaks the chicken-egg cycle.
As for measuring actual usage of features, you can set up a discussion forum to get feedback on the features you added... you don't need anything too complicated if you are time-strapped.
I personally like the hands off approach from customers. They give you high level requirements and you provide the implementation. Your software team/company/division are supposed to be the experts. Sure you will make some mistakes, if its horrible the customer will pipe up and you will fix it, but generally having the implementation up to you and your developers is a fun dilemma to solve.
Research, research, research. Learn from others designs, then make your own kickass design. Not easy but then again they don't pay developers the big bucks for nothing.
That's a good question.
If you're building an FPS game, you really need to know for yourself what should be included, because 99% of your users will never contact you to say "I wish your game just had X". An experienced beta-testing team can help here.
If you're writing an accounting application, you need to understand the industry and what users are trying to accomplish when they use your product, and try and focus your feature set around those goals.
If you're writing a custom app for 100 users in one business, you could have a chat to the dozen or so most avid users of the software. They're the ones who know all the forms back-to-front, have discovered all the undocumented shortcut keys, and have also figured out how to circumvent many of your data validation rules.
Imagine you are them
Use Cases.
What will they do with that feature?
It works like this.
People take actions. We build software to help them take actions
In order to take an action a person must make a decision. We build software to help them make decisions.
In order to make a decision to take an action, a person needs information. We build software to collect and present information.
Every feature must be an Action, a Decision or Information. And the connection had better be direct. Information that does not lead to a decision or an action isn't even "nice to have" -- it's junk.
Users say a lot of things. What do they do? What decisions do they make? What information do they need?
Edit
Note that not everyone is good at describing use cases. Some people have no vision and will simply tell you what they do today without understanding how they are creating business (or personal) value. They may not really know what decisions they're supposed to be making, and are vague on the information they need.
Other users know what value they create, and why, and can discuss use cases well. They can envision alternative ways to create value; they can articulate options for their actions. Decisions don't have a lot of alternative implementations (people make decisions, not software) and the information required doesn't change much, either.
Watch them.
Identify bottlenecks in their work
Create something that solves that
bottleneck in an elegant way
Let them use it
Repeat until everyone is happy
Based on the principles:
Users know what they want, but they
don't know what they really need.
You ARE
NEVER going to get it right the
first time.
It seems like a chicken-and-egg problem. Much like computing PageRank. A page's page rank is dependent on the PageRank of other pages linking to that page.
One way of computing PageRank is by iteration.
Iteration is the key!
A. Voting
Gather a biiiig list of features all users want (make them enumerate each feature they want).
Then have them review the list and allow them to vote on features. Say, give em 100 points to distribute on features. They can give more than 1 point to a feature.
B. Analysis
Analyze the business model, List the features that you think is needed.
This is needed because:
users sometimes don't get the big
picture
you have this REALLY great
idea that users won't think of in a
bajillion years.
C. Implement
Analyze list from A and B, merge, remove a few, improve some. Implement.
D. Test
Test it on users. Hear their complaints. Look at
- features they use often
- stuff they get stuck on
- etc etc etc
E. Iterate
Usually, users do not always know what they want and whether they want anything. In our company sales people go to existing and potential customers, show them our product and explain them why they desperately want that.
In my time in university we were taught something called "userp-driven development". Here you really have to go to the customer, observer how people there work, what tools do they use, and try to find out what could facilitate their life. You then create a mock-up, go to the customer again, present it to the users, get their feedback and then proceed to improve your mock-up. When everyone more or less agrees to the course of action, you do implementation, regularly showing the customer what you have trying to get correction feedback as early as possible.
Important is not to talk to the managers who want the product, but to the users who will use the product. Otherwise the whole play will bring you nothing.
P.S. Asking them directly "What do you want?" could be a dangerous question...
Babylon 5 - What do you want?
It's called Market Research.
No, this wasn't a dig at the guy, that's really what it is about. Sure, there's a bunch of techniques that UCD people use in the field to get user requirements, but they are exactly the same tools used by market researchers. Card Sorting, Priority lists and so on are all market research terms.