Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm currently working in a small company that its taking care of implementing lots of systems, most of them for goverment institutions, in witch it generally means taking software developted 20 years ago and refurbish them so fit up-to-date needs. The clients generally are very used to them and tend to discourage change (they are in their 50s 60s give or take, so not technologie-friendly in general).

As you can imagine, dev-team in most cases starts taking care of relation with clients, generating the documentation needed in this cases (CU usually), assisting to weekly meets to see improvements with clients.

As for experience, this is a gold mine for me, because gives a nice perspective on all the aspects of software development, but also some problems rise because, if developers come from mars then clients are from venus. There is a fine gap on the vocabulary/experience/capability-to-interpret-needs that generates a noise in the communication, and some times affecting the final product.

Should a developer be in direct contact with the client, or there should be an "adapter" guy that translates client needs in pseudo formal requirements understandable to us?

share|improve this question
add comment

5 Answers

up vote 5 down vote accepted

Always be in direct contact with your client. Always. Always.

I will narrate an example which we faced earlier. The product which was already existing was of Version 2.0 where you can write your own CSS (a heavy task!). During the implementation of V2.0 (eons ago), they wrote the CSS, to reflect their internal brand, in green color. (Reason - the default scheme was in magenta!)

2 years ago, when we embarked on upgrading it to Version 6.0, the product itself chose Microsoft(!) blue as the default scheme.

As expected, the client was not willing to let go of their green color. Internally too, there was a conflict. The BA's agreed that the internal branding was not needed and we can go with the default Microsoft(!) blue. But no, the final stakeholder kept insisting on retaining the green color or we do NOT do the upgrade at all.

What did we developers do?

Held a meeting with final stakeholder. Started of the meeting along the following lines -

You know what, I am upset that we are to lose out the internal branding color. I cannot tell how much I am upset that we are about to lose the internal branding which you have built and stood for in so many years. But, unfortunately we are now at a stage where we need to make some hard decisions and I am hoping that you would help us (developers) with it.

We then listed down all of the great features of performing the upgrade.

  1. Anchor tabs (ooh, so lovely!)
  2. Drag and Reorder columns in a Web browser(ah, that is fantastic!)
  3. ...
  4. ...
  5. ...
  6. ...

And then we listed out what we would be missing?

  1. Internal branding color would be lost

Threw in a nice quote as

You can lose battles to win wars!

And then, we left the decision for them to make. Needless to say they accepted the Microsoft's color and all was fine.

None of this would have been possible if we had not been in direct contact. Because, it is you the developer who can sell the great features of the new technology not the BA.

PS: Now that Wanted is released, you can replace the quote as "We kill one, and maybe save a thousand"

share|improve this answer
1  
This is an excellent approach when the client / customer knows what the actual users want (or you can at least trust them to be responsible for knowing -- whether they actually do or not). Somewhat out of scope maybe, but when that falls apart, pressure and frustration ensue. –  opello Dec 28 '10 at 6:45
    
@opello: Completely agree. –  Kanini Dec 28 '10 at 8:45
    
That amazing, i really going for it! When dealing with those kind of people you should put on the table pro and cons so they choose and not you! Thanks! –  guiman Dec 28 '10 at 12:56
    
@guiman: Remember though that you have to put the pros and cons in such a way that they make the decision which you want. –  Kanini Dec 28 '10 at 14:56
1  
This is a sign of a poorly managed company. BA is not capable/willing to manage their clients. Not only did they want to waste developer resources on an unnecessary feature they wasted even more of your time doing their job. Hope they did not get a commission on this deal. You went above the call of duty-good job. –  JeffO Dec 28 '10 at 22:25
show 2 more comments

Developers should absolutely be in contact with the clients! Even if a business analyst writes a formal specification, its always beneficial to have access to the client to ask specific questions or get instant feedback on a feature you are working on. Business analysts are very helpful, but I would never want to work solely through them for requirements. Also, I would never want to wait more than a week or two to show off a feature to a client. Even if they make changes, its always easier to make a small change closer to the time of development rather than piling all the changes to the end of the project.

Newer software methodologies are also geared toward bringing the client and the software development teams closer together. One of the main principles of Agile/Scrum is that the client be on the team and always be available for questions. Agile teams also demo their software after every sprint or iteration. Agile was formed under the assumption that software changes and that teams should be "agile" and adapt to changing business requirements.

share|improve this answer
1  
I agree with most of this but having the client to close could be also a pain in the "!#%&@ , especially when it's your responsability to deal with their are always changing his mind. At what point do we have to stop adding new functionality or modifiying whats working? –  guiman Dec 28 '10 at 13:33
add comment

Always start with the client's perspective. E.g, Question: Why change something that works? Answer: Because the technology is in danger of no longer being supported and we may not be able to find developers facile in the technology in the near future.

Avoid the urge to change something because you are enamored with a new technology. Just because they drive a 1967 VB Beetle and you are in love with a Prius, does not mean they see the need to change. Focus on their needs, not your wants.

share|improve this answer
1  
+1 for the line "Always start with the client's perspective" –  Kanini Dec 28 '10 at 3:33
    
I'm quite aware that thing that no need changing should not be changed but, why dont improve them? Some times the client dont really knows what he/she wants until you show something –  guiman Dec 28 '10 at 12:51
add comment

There are 2 sides to it.

  1. It is a great idea to be in direct contact with your client. You get invaluable experience as to how users in real life behave, their pain points, things that they want in the software and stuff you can do for them to get repeat business.

  2. It is also very important to have an adapter guy in this whole thing. Suppose you are doing the accounts software of some govt. agency would you not like to re-use part or whole of this software for another govt. agency too, perhaps one thats located in a different state? Of course you would, and thats where the adapter guy comes in. Its his/her job to map this software to the requirements and pain points of another related entity and ask developers to get the customizations done.

I think both approaches are needed, and complementary.

share|improve this answer
add comment

I think it is important, but here are some instances when it is less:

  1. The developer is a typical user or very experienced working in a particular domain.
  2. You're building the part of the app that the client has little to no interaction.
  3. The developer does not have strong social/communication skills at this point. Don't practice on your clients, but do work on it.
  4. There are other team members to pick up the slack.

Reminds me of a quote, "Programmers would rather write programs to help write programs than actually write programs." I've never felt this way. I'm more like the cat that likes to drop the occasional mouse on your doorstep to show you what I've been up to so I'll get attention.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.