Develop for the customer, or for a manager?

Question

So you're striving for a job, then you have two to choose from:

Job A: You have direct contact with the customer. You get the user requirements. You design and develop being able to contact the customer for whichever issue you have. You receive the bug reports directly from the client, for whichever issue they have.

Job B: You don't have contact with the customer. You get the user requirements from a manager. You design and develop in contact with the manager. You receive the bug reports from him.

Which one would you choose, given that both jobs meet your expectations, and client and manager are average, real programming job market ones?

Answer 1

Customer, every time.

It's thrilling to see real people get value from your work - and incredibly valuable to hear directly what problems they're having, or what they want to see next. That's why I quite like doing work in the support forums for my project. Talking to actual users is great :)

Answer 2

Direct contact with the customer. Most managers won't give you enough details, get some of the details wrong or become annoyed when you continue to ask for necessary clarifications. Then when things go sour they blame you.

Okay so that's a worst case scenario. Still, if the option is there I'll pick directly dealing with the customer every time. Translating a non-technical specification into a well formed technical specification is a tricky business and the less people involved in this process the better. If you can take the middle man out you'll be a lot happier.

Answer 3

B - but mostly because there's less chance of having to file timesheets at the end of every week.

Is "C: working for yourself" not an option?

Answer 4

Can I choose Job C? I'd vastly prefer having direct contact with the customer, but have a manager who filters out meetings, etc.

This way you get to see the results of your work without being bombarded by the overhead of a project. Plus, the project makes a whole lot more sense because your customers are able to explain what they expect out of you. Also, many customers need to be presented things in a certain way, and having a filter there can skew that and ruin the customer's experience. However, if you have a good PM and access to your customers, life is very good.

Answer 5

In the end, the most important thing is having your customer be satisfied. The most efficient way to get there, with the least headache, is my preference.

IMO, I would prefer to deal with a good manager, since they will filter out and get good clarification of requirements, and leave me to be able to be more productive directly. This leaves me more time to do what I do best - namely develop the product. That being said, I'd much rather deal with a customer directly than deal with an average to poor manager, since getting poor or lacking information just leads to frustration on all sides, and less total productivity and satisfaction all around.

Answer 6

For this one I'd like to reference User Stories Applied (Chapter 5) by Mike Cohn:

It is vital that a project include one or more real users on the customer team. While others may be able to guess at how a user wants the software to behave, only a real user knows.

I think the term "customer" gets easily confused too. My guess is that you meant end user when you referred to customer... However, they are not always the same person... just something else to be careful about; the person that makes the buying decision (customer) is not necessarily someone who uses the software (end user).

Answer 7

Direct contact to the user is a thing that many software development practices like XP require. Maybe there is not contact from every programmer at every time and if the team is big there should be a filter mechanism but nothing gives the programer a better view for his tasks then to see how people use what you have programmed. Sometimes the programmer sees error the customer and the manager are not aware of. A simple thing would be a bad work flow in the GUI design.

So I would prefer to have contact to my User not necessarily my customer.

Answer 8

Assumming you have a well defined User Requirements document, it doesn't matter. Somebody (either you, your manager, or a customer advocate inside your organization) should put together a well defined user requirements document. The person in charge of this document should be in direct contact with your customer and should be a liaison between development and the customer. He/she should not care of implementation details, he/she should simply put what the customer needs (and that does not necessarily means what the customer wants)

In my opinion is not whether you or your manager has contact with the customer, is how good the job of gathering requirements is done. You or your manager could be very good at it, or very bad.