Masters of Offshore Affairs
It’s not enough to write good software. Many are able to do this, and actually for this you are paid money. But whether you want it or not, working in IT requires not only relevant technical skills, but also the ability to work with people, and especially with the customer. For an offshore team, when a team is separated from the customer by thousands of kilometers, this rule becomes even more important.
The purpose of this article is to draw attention to the specific points that accompany the writing of programs by offshore teams, as well as to the peculiarities of task planning and communication with clients.
It so happened that in the course of my work I have been working with offshore for many years, both on the one hand, on the part of the manager of the offshore team, and on the other hand, on the part of the customer. During this time, many observations and conclusions have been made that allow avoiding, or at least minimizing the “graters” with customers that inevitably arise from remote communication.
All recommendations are based on personal experience working with customers from Western Europe and the United States. It is likely that work with customers from other regions will have its own specifics, but perhaps some conclusions will be true for this case.
So, consider the option of an offshore team: the team is technically savvy, writes good code, but communication with clients is not organized at the proper level. Result: sooner or later, such cooperation ceases.
Here are tips / comments to help an offshore team look good in the eyes of the customer.
1. Be proactive.
This may not seem important in the beginning, but it actually has a big impact on the impression of the development team. Activity is manifested in constantly looking at the project from the point of view of the project manager or the person who pays you the money.
That is, you are not only developing a project, but also trying to improve the development speed, find out how to integrate different components more efficiently together, think out a more optimal architecture, or, in the simplest case, how to speed up the assembly of a project.
By this, you take on part of the tasks of managing / understanding the project, and, among other things, show the customer your interest in the project.
2. Flow of completed tasks
One of the most important points in communicating with a customer is information about completed tasks.
On an active project, tasks are received constantly, and if you give a “balanced" report on what has been done, then expectations will be formed correctly. For example: if you have tasks on the UI and server side, then tasks from both parts should be present in the weekly report / release.
Another point is the speed of tasks. You should not do them very quickly, because the client, as a rule, does not understand that one task takes an hour, and another week. All tasks are presented to the client of the same complexity. Therefore, large tasks are performed in the background, while small tasks are "shown" to the client.
If you rephrase what has been said, then you need a “positive stream” towards the customer.
3. Do not change people on the project
As a rule, offshore companies do as follows. At the beginning of the project, very experienced people are put in place of the developers. The manager gets used to the high quality and speed of tasks, and expects that this level will continue to be maintained. But over time, experienced developers are transferred to other projects, and weaker ones (read, cheaper) are put in their place. As a result, development speed and quality are falling. India is especially famous for this approach.
When the project manager is aware of this situation, he can’t do anything anymore, because there is not enough time left before the project is handed over and transferring the affairs to another company will disrupt the project. In addition, redirecting cash flow to another company is not so simple (signing papers, enlisting the support of management, etc.). In addition, uncomfortable questions will arise like “where did you look when you signed an agreement with them”, etc.
All this leads to tension in the relationship, and sooner or later will lead to their break.
4. Metrics / development environment
By default, a build server, unit test coverage, Jira, etc. should be supplied. Using this information, it will be easier for the project manager to show the progress to the higher management. That is, we care about how the manager "looks" in front of management.
In addition, these metrics are objective assessments of the progress of the project.
5. Choose the technology correctly
Ask more questions about the future project. From the answers it will become clear which technology to choose. For example, if the initial demo was done on .Net and everyone was happy, and at the end of the project it turns out that all this needs to be installed on unux, an awkward situation will arise.
Understanding the future will help you better complete the task and plan your production environment.
6. Constantly remind you of your existence.
Every week, send the status of current tasks, for example, on Friday. The report should include information about what was done last week, what is planned for the next, and what problems arose in performing the tasks.
The project manager in this case will be able to change the priority of tasks and notify customers if necessary.
A good addition to the report will be a demo of the current state of the system.
7. Direct contacts
On the side of the offshore team should be people who speak with the client (usually fluent in the client’s language) and are able to solve problems by phone.
These are people who work for a long time in the company and who do not leave the company as soon as possible. This is the "face" of the company.
The working scheme looks like this: two people stand out for a large project. One manager and one technical specialist who are able to solve all issues on the project.
There should be one more person (escalation person) to whom the client will be able to "complain" if they could not agree.
Access of developers to communicate with the client sooner or later will lead to the fact that the developer will try to "lead" the client. I have been in this situation many times: the developer simply dumps (and he can afford it, while the company cannot) and the company loses the customer.
An additional advantage of the fact that all communication with the customer will take place through one person is the control over the situation: this selected person at any time will know the current state of the project, problems encountered, questions, etc.
8. Email
Email is the document on the basis of which decisions are made. Email on the project is not deleted, so that at any time it is possible to raise the full discussion chain. All telephone discussions should preferably be confirmed by a letter in which you describe everything that has been discussed and the planned steps.
In fact, the explanation of what needs to be done to the person who sits from you at ten in the summer is not a simple thing. I do it as follows. I write a small document with the basic requirements, then we pronounce all the details by phone. After discussion, the developer writes a document in which he describes how he understood all this. If after reading this, I create a “picture” similar to what I originally wanted to convey to the developers, then the task goes to completion. Otherwise, we continue to discuss.
It may seem that this is an additional red tape, but in the end it turns out faster than doing it without understanding the essence of the task and then redo everything. After a month of such practice, everything happens quickly enough.
9. Run Down Script
Run Down Script is a useful thing, but I did not understand its purpose until I went to work in a bank.
The Bank is a large organization, and the installation of a new version of the product occurs at a certain time, the so-called “release window”. At this time, many will be exhibiting their versions, and coordination is very important.
Run Down Script just solves this problem. This document describes who, when and what will be installed, on which servers, and if something “falls off”, how it can be rolled back to the previous stage. Everything should be described, down to the commands that need to be executed.
10. Technical support
Do not be afraid to take a project for support / support. The software company receives the bulk of money from those. support, not development.
Less experienced developers can be hired to support them, while more experienced ones are doing a new project.
11. "Pushing" solutions
Customers like to "push through" additional requirements for the system, especially when 90% of the work has already been done and there is a conditional free time.
There are two solutions:
* show the execution of tasks in such a way as to give the impression that we won’t have time to do 10% of the functionality, and only with the help of "incredible" efforts and teamwork, we did it all the same
* fight back using the initial requirements for the project - you all have letters and the documents that were discussed, and consent to perform work in this volume was obtained.
12. Forbidden words
Do not use forbidden words in communication. For example, the phrase “we will Rewrite the system in a week” is fundamentally incorrect. If you say “rewrite”, the next question will be “what have you been doing all this time?” Such moments may arise due to lack of knowledge of the customer’s language at the proper level. It’s better to write “improve the system” or “tune the system”.
13. Not sure - ask again
Many are afraid to ask, so as not to show that nothing is really understood. But when it comes to completing a task, problems begin.
Everyone understands that it is impossible to know everything and questions / discussions show that a person wants to understand, and this is always welcomed and supported.
14. Release
The release date is very important, and it is important to provide a product for a specific date because the release is not only written software, but also hardware, admins, etc., etc.
A lot of parameters must be synchronized on this date.
For example, if iron is purchased and idles, the client pays for it. If there was software, then the service would be profitable, and so the hardware just costs.
Please plan tasks correctly and provide software on time.
Comments are welcome.
The purpose of this article is to draw attention to the specific points that accompany the writing of programs by offshore teams, as well as to the peculiarities of task planning and communication with clients.
It so happened that in the course of my work I have been working with offshore for many years, both on the one hand, on the part of the manager of the offshore team, and on the other hand, on the part of the customer. During this time, many observations and conclusions have been made that allow avoiding, or at least minimizing the “graters” with customers that inevitably arise from remote communication.
All recommendations are based on personal experience working with customers from Western Europe and the United States. It is likely that work with customers from other regions will have its own specifics, but perhaps some conclusions will be true for this case.
So, consider the option of an offshore team: the team is technically savvy, writes good code, but communication with clients is not organized at the proper level. Result: sooner or later, such cooperation ceases.
Here are tips / comments to help an offshore team look good in the eyes of the customer.
1. Be proactive.
This may not seem important in the beginning, but it actually has a big impact on the impression of the development team. Activity is manifested in constantly looking at the project from the point of view of the project manager or the person who pays you the money.
That is, you are not only developing a project, but also trying to improve the development speed, find out how to integrate different components more efficiently together, think out a more optimal architecture, or, in the simplest case, how to speed up the assembly of a project.
By this, you take on part of the tasks of managing / understanding the project, and, among other things, show the customer your interest in the project.
2. Flow of completed tasks
One of the most important points in communicating with a customer is information about completed tasks.
On an active project, tasks are received constantly, and if you give a “balanced" report on what has been done, then expectations will be formed correctly. For example: if you have tasks on the UI and server side, then tasks from both parts should be present in the weekly report / release.
Another point is the speed of tasks. You should not do them very quickly, because the client, as a rule, does not understand that one task takes an hour, and another week. All tasks are presented to the client of the same complexity. Therefore, large tasks are performed in the background, while small tasks are "shown" to the client.
If you rephrase what has been said, then you need a “positive stream” towards the customer.
3. Do not change people on the project
As a rule, offshore companies do as follows. At the beginning of the project, very experienced people are put in place of the developers. The manager gets used to the high quality and speed of tasks, and expects that this level will continue to be maintained. But over time, experienced developers are transferred to other projects, and weaker ones (read, cheaper) are put in their place. As a result, development speed and quality are falling. India is especially famous for this approach.
When the project manager is aware of this situation, he can’t do anything anymore, because there is not enough time left before the project is handed over and transferring the affairs to another company will disrupt the project. In addition, redirecting cash flow to another company is not so simple (signing papers, enlisting the support of management, etc.). In addition, uncomfortable questions will arise like “where did you look when you signed an agreement with them”, etc.
All this leads to tension in the relationship, and sooner or later will lead to their break.
4. Metrics / development environment
By default, a build server, unit test coverage, Jira, etc. should be supplied. Using this information, it will be easier for the project manager to show the progress to the higher management. That is, we care about how the manager "looks" in front of management.
In addition, these metrics are objective assessments of the progress of the project.
5. Choose the technology correctly
Ask more questions about the future project. From the answers it will become clear which technology to choose. For example, if the initial demo was done on .Net and everyone was happy, and at the end of the project it turns out that all this needs to be installed on unux, an awkward situation will arise.
Understanding the future will help you better complete the task and plan your production environment.
6. Constantly remind you of your existence.
Every week, send the status of current tasks, for example, on Friday. The report should include information about what was done last week, what is planned for the next, and what problems arose in performing the tasks.
The project manager in this case will be able to change the priority of tasks and notify customers if necessary.
A good addition to the report will be a demo of the current state of the system.
7. Direct contacts
On the side of the offshore team should be people who speak with the client (usually fluent in the client’s language) and are able to solve problems by phone.
These are people who work for a long time in the company and who do not leave the company as soon as possible. This is the "face" of the company.
The working scheme looks like this: two people stand out for a large project. One manager and one technical specialist who are able to solve all issues on the project.
There should be one more person (escalation person) to whom the client will be able to "complain" if they could not agree.
Access of developers to communicate with the client sooner or later will lead to the fact that the developer will try to "lead" the client. I have been in this situation many times: the developer simply dumps (and he can afford it, while the company cannot) and the company loses the customer.
An additional advantage of the fact that all communication with the customer will take place through one person is the control over the situation: this selected person at any time will know the current state of the project, problems encountered, questions, etc.
8. Email
Email is the document on the basis of which decisions are made. Email on the project is not deleted, so that at any time it is possible to raise the full discussion chain. All telephone discussions should preferably be confirmed by a letter in which you describe everything that has been discussed and the planned steps.
In fact, the explanation of what needs to be done to the person who sits from you at ten in the summer is not a simple thing. I do it as follows. I write a small document with the basic requirements, then we pronounce all the details by phone. After discussion, the developer writes a document in which he describes how he understood all this. If after reading this, I create a “picture” similar to what I originally wanted to convey to the developers, then the task goes to completion. Otherwise, we continue to discuss.
It may seem that this is an additional red tape, but in the end it turns out faster than doing it without understanding the essence of the task and then redo everything. After a month of such practice, everything happens quickly enough.
9. Run Down Script
Run Down Script is a useful thing, but I did not understand its purpose until I went to work in a bank.
The Bank is a large organization, and the installation of a new version of the product occurs at a certain time, the so-called “release window”. At this time, many will be exhibiting their versions, and coordination is very important.
Run Down Script just solves this problem. This document describes who, when and what will be installed, on which servers, and if something “falls off”, how it can be rolled back to the previous stage. Everything should be described, down to the commands that need to be executed.
10. Technical support
Do not be afraid to take a project for support / support. The software company receives the bulk of money from those. support, not development.
Less experienced developers can be hired to support them, while more experienced ones are doing a new project.
11. "Pushing" solutions
Customers like to "push through" additional requirements for the system, especially when 90% of the work has already been done and there is a conditional free time.
There are two solutions:
* show the execution of tasks in such a way as to give the impression that we won’t have time to do 10% of the functionality, and only with the help of "incredible" efforts and teamwork, we did it all the same
* fight back using the initial requirements for the project - you all have letters and the documents that were discussed, and consent to perform work in this volume was obtained.
12. Forbidden words
Do not use forbidden words in communication. For example, the phrase “we will Rewrite the system in a week” is fundamentally incorrect. If you say “rewrite”, the next question will be “what have you been doing all this time?” Such moments may arise due to lack of knowledge of the customer’s language at the proper level. It’s better to write “improve the system” or “tune the system”.
13. Not sure - ask again
Many are afraid to ask, so as not to show that nothing is really understood. But when it comes to completing a task, problems begin.
Everyone understands that it is impossible to know everything and questions / discussions show that a person wants to understand, and this is always welcomed and supported.
14. Release
The release date is very important, and it is important to provide a product for a specific date because the release is not only written software, but also hardware, admins, etc., etc.
A lot of parameters must be synchronized on this date.
For example, if iron is purchased and idles, the client pays for it. If there was software, then the service would be profitable, and so the hardware just costs.
Please plan tasks correctly and provide software on time.
Comments are welcome.