1. Before coding, understand the requirements clearly with as much details as possible. Ask questions to cover all conditions, data relationships, end-to-end data flow, inputs, outputs, rules, interactions, hand-offs, access controls, response time etc.
2. Question assumptions continuously and confirm the details to minimize them.
3. Define, analyze and refine a micro-service based architecture with near endless possibilities for new modules or new channels or new interfaces. Focus maximum on design to make screens and other components user-configurable, where possible.
4. Define, analyze and refine a micro-service based architecture with near endless possibilities for new modules or new channels or new interfaces. Focus maximum on design to make screens and other components user-configurable, where possible.
5. Follow coding standards for the chosen language, framework, and the tools. Keep the code secure by adopting security best practices to ward off OWASP threats (broken access control, broken configuration, technical error message with internal details, injection, CSRF, XSS etc).
6. Adopt a simple yet effective design with a collection of short programs. Only simple design and code can be maintained by a team. However, maintain confidentiality measures adequately so that unauthorized users cannot break/steal the source code.
7. Adopt a simple yet effective design with a collection of short programs. Only simple design and code can be maintained by a team. However, maintain confidentiality measures adequately so that unauthorized users cannot break/steal the source code.
8. Analyze and plan your project / work in collaboration with your team consisting of members from different backgrounds with different types of expertise and experience levels.
9. Get clarity on scope and exclusions with priorities, urgencies, and schedule constraints. For fixes and changes on existing code, review dependencies thoroughly, analyze impact of your action on various other parts, think of multiple use cases, and then only start making changes with appropriate comments.
10. Negotiate schedule, budget, quality, and features without disappointing stakeholders.
11. Create a test plan and add/ enhance scenarios and test cases before coding or code changes.
12. Professional programmers take responsibility for their career, their estimates, their schedule commitments, their mistakes, and their workmanship. A professional programmer does not pass that responsibility off on others.
13. Create a checklist for prerequisites, configuration, test data, pre-release activities, post-release activities in development environment and user environments etc.
14. Professional programmers expect QA to find nothing because they don’t release their code until they’ve thoroughly tested it. Maintain a test case library and use them extensively.
15. Professionals are team players. They take responsibility for the output of the whole team, not just their own work. They help one another, teach one another, learn from one another, and even cover for one another when necessary.
16. Professionals do not tolerate big bug lists. This only confirms carelessness and lack of professionalism.
17. Good programming lies in taking a systematic approach (Agile Secure SDLC), and wanting to write the best software you can, within the real-world constraints and pressures of the software factory.
18. Always focus on Functionality, Usability, Reliability, Performance, Security (FURPS), Maintainability and Schedule.
19. Don’t comment the trivial, but do comment briefly on functionality, parameters, and assumptions for every major methods/classes.
20. Create and maintain documentation of all development/ fixes and changes at the right level of details with checklists, SOPs, design considerations, directory structures/paths, component lists with pointers to specifics, troubleshooting FAQs, credentials etc so that technical support can be provided efficiently and effectively.
21. When in doubt, over communicate all concerns with your team.
22. UI is the gateway of the system to the users. Aim at flawless UI design, development and deployment with proper choice of color, font, responsive yet compact layout, smart utilization of space, balanced spacing, font style, font color, font size, alignments, appropriate Initcap text labels or master data with zero spelling mistakes, correct punctuation, smooth navigation and accurate processing of user requirements.
23. 80% of the blood, sweat, and tears of software occurs after it has been released—that’s when you become a world weary, but wiser “professional.”
24. Log exceptions, errors or failures 100% and the rest only for debugging (temporary basis). Analyze the log file daily for a chronic warning or a new issue. Raise a ticket for your problems and track it to closure. After you fix the problem with adequate QA, reflect on why it happened and what should be done about it. Document the solution at high level with pointers to specifics.
25. Agree on a weekly or fortnightly schedule for a formal meeting so as to raise your concerns, update others about your progress and challenges, seek feedback, and monitor progress against plans and plan for corrective actions.
26. Spend maximum 40% of your time on coding. Rest should be spent on analysis, planning, designing, testing, environment management, user support, documentation etc.
27. Use industry-standard tools (postman for APIs, Katalon or Selenium for test automation, Pen Test, ZAP for VAPT, JMeter for Performance Testing etc) for functional, security and performance testing.
28. When in crisis, maintain calm, talk less but talk sensibly and respectfully, replicate the error scenario, analyze logs, think deep with clarity, collaborate, research on net, focus all your effort on the solution, discuss probable fixes with seniors and fix the problem. Update the ticket with the solution details and discuss on lessons learned in the next team meeting.
29. Code is useless even after it is completed 99% , unless it is put to users in production. Users are our best judge.
30. ) Do version control through Git
31. Take responsibility for all aspects of the technology solution – starting from infrastructure, OS, Databases, Application Architecture, individual modules, screens, file transfers, interfaces. Users cannot be responsible for technical failures of the solution.
32. For every production issue, log it on the system with as much details as possible, and interact with users politely even if they abuse, understand what they did (screenshot with sequences), update them on the status regularly, but never discuss technical details with them. Manage technical complexity yourself. Don’t talk more than what is needed. Problems may be due to internet disturbances at user end, infrastructure issue at Data Center, laptop/PC/End-user device issue, data issue, user input errors, user understanding issue, system limitation/feature issue or technical bugs. Understand the root cause quickly to devise a remedy. Only bugs, if any, are our immediate actionable items. New requirements are Change Requests which we need to plan after getting the commercial authorization from the user management. Rest to be managed at the other end with our hand-holding. After every interaction, users must get a perception that they are dealing with a top-class professional and a specialist who knows his job well. Every support scenario can become an opportunity for us to impress them on our professional capability and commitment, which can help us in cross-selling and up-selling.
33. Read user guides, blogs on leading ERP and GRC products, their user manuals etc regularly to master the business understanding and benchmarking the platform against other products.
34. Define and maintain checklists on company for most routine jobs including system administration, database administration, work accomplishment etc.
35. Make data migration templates and prepare scripts for data migration. Do reconciliation based on sum of numeric fields and count of records.
36. Try to enrich the platform continuously based on the user issues so as to reduce support effort progressively and empower users for self-service incrementally.
37. Coordinate with users, team members, partners on the basis of their roles. No need to share information with them that is not absolutely required for their role.
38. Never commit on schedule without a discussion at the team level. Minimum time to fix a problem after regression testing or implement a change after proper analysis, and testing in user’s environment is 2 working days for users. Doing a sloppy job in short time is a recipe for disaster.
39. Always greet users and show helpful solution-oriented mindset to them. Give them confidence that you will be able to solve their problems.
40. Never discuss religion, politics, gender or any other contentious topic with users or colleagues. Be friendly and politically correct all the time.
41. Never do anything without thinking and understanding it completely. Else you risk facing the consequence alone. Remember Doing things comes only after Planning in PDCA cycle.
42. Mangers make things happen through planning. If you fail to plan, you are only planning to fail.
43. While rework because of wrong requirement is a pain, continuous improvement for the same or new requirement is a part of all professions. There is nothing in life that cannot be improved but improvement can happen only when we follow the DMAIC (Define the problem, Measure the Performance Indicators, Analyze the root causes, Implement the Improvement and Control Variance regularly) approach.

Client Coordination Guidelines for Support

1. Never say “I don’t know” or “I am not aware” if it is related to a technical issue. Say “We will come back soon” and check with the team who is handling it and notify him along with his manager about the need to respond to the client soon. We must work as team Company, not as individuals.
2. Never say that the solution is fine if it is not ready for clients to test or if the details are not understood/tested by yourself properly. Before sending it to client, please verify it yourself at least once.
3. Never say it is pending with the client if even a single action item is pending with us.
4. Never fail to do homework before talking to the client. Homework means checking details and anticipation of the queries posted by the client and the preparation. Queries from the client generally include the following:
   • What I am expected to do? (Ask him relevant details to understand the problem better and ask him to send screenshots/ specifics/ other evidences as applicable etc by mail. Verbal discussion onveys half-truth and cannot be the only mechanism for input collection.)
   • Who will do what? (Clarity on this facilitates input collection and testing. Some testing requires back end check which client cannot do. In that case, we should make a report with data that clients understand and send it to him for his verification)
   • Where do I test/ check? (Test Environment Link).
   • Why do I do this (your suggested action)? (Understand the rationale behind the change; The originator of the problem/change/ query may not be the person testing/ concluding it- we may be the bridge sometimes)
   • When do I test/ do the next action? (Mutually agreed date & time. Testing may require EOD/ batch execution, post EOD/ batch analysis – so high-level planning of date and time brings clarity to both client and yourself).
   • How do I Test? (Understand the client’s process and then the technology element precisely. Communicate – which screen/fields/reports/values to look for/enter, what steps to follow and in what sequence; Also tell him/her to include more test scenarios to make the testing robust.
   • What to test? (The change item / Fix ).
5. Never increase the uncertainty about a problem while communicating with client on your issue. If we give the impression that the system does not behave reliably and we cannot control it, we have no business sitting here. In the genuine case, we can say “We are working with Vendor to resolve this. It appears to be more complex than the usual cases but we should be able to revert to you soon.”
6. Greet, smile and make clients feel good while talking to them. We need their positive feedback badly.
7. If we detect that the client’s inputs are not reliable, we raise it firmly and politely.
8. We resolve the problem that is reported. If client expects a solution to his problem that is not sent to us, he/she must send it to our Service Desk first before our action. For cases where senior members in the client firm are talking about it, ask them politely about the issue number. If there is no issue number, chances are there that it has not been sent. Request them to send it to Service Desk with details (screenshot, action sequence etc).
9. Never fail to give an impression (supported by action) that how seriously involved we are with the client’s problem. Anything other than this, shows a casual, laid back, unprofessional attitude.
10. Never get into confrontation or argument. Please escalate it to Line Managers in case such situation arises.
11. Never communicate to client with technical jargon or technical details. We must translate it into business terms which clients can find easy to follow.
12. Urgent issues first – we must prioritize them and make sure that is delivered within the expected timeframe (SLA/client’s time band). We must provide workaround immediately.
13. After every discussion, always send client a mail with gist of discussion.
14. The mail should not have any grammatical or spelling mistake. Non-technical people evaluate us on the basis of non-technical areas such as communication.
15. While enquiring the clients about the issue details where the problem is unexpected, ask relevant details. “This appears to be little strange. Has your team done the input correctly? What did you try to do on the system and in what sequence? Do you have the screenshot for the same and sent us in the same sequence? Have you abruptly closed the screen without getting the transaction confirmation message? Has he got any error message? If so, have you sent the error message to us?” Queries may differ based on the situation but important thing is to ask relevant questions in the beginning itself to ascertain if the source of problem lies outside system.
16. If the problem is attributable to causes outside the system (after thorough analysis and getting objective evidence), make it clear in the opening sentence of the mail or within first 3 statements in the conversation (without blaming anyone).
17. Bottom-line is that the impression the client should get about us in each interaction is “A responsive (efficient in time and effort), knowledgeable, multi-skilled (with complete understanding of interdependencies, system, processes), methodical (process-oriented), dependable (effective/ high-quality), courteous, and supportive specialist aligned with business, making critical contribution to our pursuit of excellence by leveraging IT.” This needs to happen every time.