Being a consultant developer
1 like1,090 views
This document provides advice for software consultants working directly with clients. It emphasizes the importance of gaining client trust by understanding their needs and business domain, suggesting alternatives tactfully rather than saying no directly, being prepared to answer questions about practices and estimates, avoiding surprises, and communicating technical topics clearly for a non-technical audience through demos and examples rather than jargon. The overall message is that consulting requires diplomacy and relationship-building more than just technical skills.
Being a consultant developer
- 1. Being a Consultant Developer - Prasanna N Venkatesan Not a tech talk ! 1
- 2. Disclaimer: All the below menoned points are my experiences, views and opinions. Got out of working in di erent kind of projects. Purely O Shore without client interacon. O -Shore TW dev team along with Client Dev Team, at client's place and as a tech consultant.
- 3. So What?? What is the big deal, anyways? I am gonna code where ever it is. Sounds perfect, but the only problem here is that the challenges you are going to face is there is slightly different and the way you are going to react to them is gonna be the deciding factor. To start with, talking to with TW BA about a functionality is not the same as talking with a client. Even arguing with BA @ the client place will not give good impressions.
- 4. Gain the trust and confidence of the client that you know what you are building. The client side BAs and Program managers are experts in their fields. You can't simply walk into the place and ask them to change everything. Best place is to start is to understand about the client, understand the product they are planning to build, understand why they need it. Get a high level overview of what you are building. You don't need to be a BA to do these, developer has to get these context too.
- 5. Be Subtle in expressing yourself !! If you want to change some business flow or suggest a new one be subtle in expressing it. Most of the times the argument whether a feature is an MVP or not will arise. It's more of a how.
- 6. May be due to some tech difcules or due to some other reason, you may not like what the client is asking for. Instead of saying a direct 'No' try to understand what the client needs and try to suggest alternaves. It gives Client more confdence on you and a straight 'No' will defnitely upset him.
- 7. Queson their pracce but don't be adamant in changing them. Most of the mes the client pracces around Code CheckIn, Tesng, Working on Stories, Deployment, Environments will arise. Remember 'Rome is not built in a day'
- 8. If you queson them, then beter be ready to be quesoned about the pracces. Understand what you are doing and you should be ready in explaining it to a stranger at any me. Most famous queson that I get is always around velocity, story points, esmates etc. Don't shy away in answering them.
- 9. Don't try to surprise a client. It may have a posive impact or negave impact on the team. The client may lost trust in you, and always think you are working on something else rather what has to be done. Surprises may turned out to be a shocker. Never try to surprise, don't work secretly, always keep the team informed about your work.
- 10. Tech suggestions form HackerNews?? Suggest Tech Alternaves. But be sure and ready to be quesoned. Don't be random about the technologies. Read it in HN and proposing it to the client?? Nah.. Try out the tech and show a demo, that might be more helpful and more appealing than just random suggeson.
- 11. If there is a problem, Don't panic. Its quite usual. And keeping yourself cool will help you to concentrate on the problem, and also relaxes others around you. During panic never get into a blame game rather focus on what has to be done. Be more construcve.
- 12. Don't confuse ! “You are just too confusing” - Most of the client have this for us. All your tech jaargons, explaining things in a non-business way will make the client to lose interest on what you are saying. Understand the audience and try to speak accordingly.
- 13. Brace yourself for this Can you elaborate more on this in mail? Improve the vocabulary, and be more precise. Know the audience, and compose accordingly.
- 14. And for this too !! Be ready to present what you have done. Most of the times, it will be to demo the app that you have built. Be confident, prepare for the demo and execute the plan.