Offshore Masters
It is not enough to write good software. Many people know how to do this, and in fact they pay you for it. But whether you like it or not, working in IT requires not only appropriate 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 a customer by thousands of kilometers, this rule becomes even more important.
The purpose of this article is to draw attention to the specific moments that accompany the writing of programs by offshore teams, as well as the features of task scheduling and communication with customers.
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 make it possible to avoid, or at least minimize, the “float” with customers, which inevitably arise during remote communication.
All recommendations are based on personal experience with customers from Western Europe and the USA. Probably, work with customers from other regions will have its own specifics, but perhaps some of the conclusions will be true for this case.
')
So, consider the option of working an offshore team: the team is technically savvy, writes good code, but communication with customers is not organized at the proper level. Result: sooner or later, such cooperation stops.
Here are tips / comments that will help an offshore team look good in the eyes of the customer.
1. Be active
This may not seem important at the beginning, but in fact it has a great influence on the impression from the development team. Activity is manifested in constantly looking at a project from the point of view of a project manager or a person who pays you money.
That is, you are not only developing the project, but also trying to improve the speed of development, find out how to integrate different components together more efficiently, think over a more optimal architecture, or, in the simplest case, how to speed up the project assembly.
Thereby you take on a part of the tasks of managing / understanding the project, and among other things, show the customer your interest in the project.
2. The flow of completed tasks
One of the most important moments of communication with the customer is information about the tasks performed.
On an active project, tasks arrive continuously, and if you give a “balanced” report on what has been done, then the expectations will be formed correctly. For example: if you have tasks for the UI and server side, then the weekly report / release should contain tasks from both parts.
Another point is the speed of task execution. You do not have to do them very quickly, because the client, as a rule, does not understand that it takes an hour for one task, and another week for another. Client all tasks are of the same complexity. Therefore, large tasks are performed in the background, while small tasks are “shown” to the client.
To paraphrase what has been said, then you need a “positive flow” towards the customer.
3. Do not change people on the project.
As a rule, offshore companies do the following. At the beginning of the project in place of the developers put very experienced people. The manager is accustomed to the high quality and speed of the tasks, and expects that this level will be maintained further. But over time, experienced developers are transferred to other projects, and weaker (read, cheap) are put in their place. As a result, the speed and quality of development fall. India is especially famous for this approach.
When the project manager is aware of this situation, he can’t do anything, because there is not enough time left before the project is handed over, and the transfer of affairs to another company will disrupt the project. In addition, it is not so easy to redirect the cash flow to another company (to sign papers, enlist the support of management, etc.). In addition, there will be uncomfortable questions 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 lead to their rupture.
4. Metrics / Development Environment
By default, a build server, unit test coverage, Jira, etc. should be installed. Using this information, it will be easier for the project manager to show the progress of work to the higher management. That is, we care about how the manager “looks” in front of the management.
In addition, these metrics are objective assessments of project progress.
5. Choose the right technology.
Ask more questions about the future of the project. From the answers it will be clear what 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 should be set to 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 on what was done last week, what is planned for the next one and what problems arose during the execution of tasks.
In this case, the project manager will be able to change the priority of tasks and notify clients 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 an offshore team there should be people who speak to the client (as a rule, fluent in the language of the client) and are able to solve problems by telephone.
These are people who work in the company for a long time and who will not leave the company at the first opportunity. This is the "face" of the company.
The working scheme looks like this: two people are allocated for a large project. One manager and one technician who are able to solve all the questions on the project.
There must be another person (escalation person) whom the client will be able to “complain” if they could not agree.
The access of developers to communication with the client will sooner or later lead to the fact that the developer will try to “lead” the client. I have been in such a 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 occur through one person is control over the situation: this selected person will know the current state of the project, problems that arise, questions, etc. at any time.
8. Email
Email is the document on which decisions are made. Emails on the project are not deleted, so that at any time you can raise the full chain of discussion. It is advisable to confirm all telephone discussions with a letter in which you describe everything that has been discussed and planned steps.
In fact, an explanation of what should be done to a person who sits on you at ten o'clock in the summer is not a simple thing. I do it like this. I am writing a small document with the basic requirements, then recite all the details on the phone. After discussion, the developer writes a document in which he describes how he understood all this. If after reading a “picture” is created for me that is similar to what I originally wanted to convey to the developers, then the task goes on. Otherwise, we continue to discuss.
It may seem that this is an additional red tape, but in the end it turns out faster than done, without understanding the essence of the task and then redoing everything. After a month of this practice, everything happens quite quickly.
9. Run Down Script
Run Down Script is a useful thing, but I did not understand its purpose until I went to work at the bank.
A bank is a large organization, and the installation of a new version of a product occurs at a certain time, the so-called “window” (release window). At this time, many will exhibit 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 “crashes”, how it can be rolled back to the previous stage. Everything should be described, right down to the commands to be executed.
10. Technical support
Do not be afraid to take the project for support / maintenance. The software company receives the main money from those. support, not from development.
For support, you can hire less experienced developers to study, while more experienced ones make a new project.
11. Punching the solution
Customers like to “push through” additional system requirements, especially when 90% of the work has already been done and conditionally free time has appeared.
Here are two solutions:
* show the execution of tasks in such a way that it seems that we do not 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 have all the letters and documents that were discussed, and consent to perform the work in this volume was received.
12. Forbidden words
Do not use forbidden words in communication. For example, the phrase “we will rewrite the system in a week” is fundamentally wrong. If you say “rewrite”, the next question will be “what have you been doing all this time?”. Such moments may arise due to ignorance of the customer's language at the proper level. It is 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 in fact nothing is clear. But when it comes to completing the 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 to provide a product on a specific date is important because the release is not only written software, but also hardware, admins, etc., etc.
On this date, a lot of parameters must be synchronized.
For example, if the iron is purchased and works at idle, then the customer pays for it. If there was software, then the service would bring revenue, and so the iron is just worth it.
Please schedule tasks correctly and provide software on time.
Comments are welcome.
The purpose of this article is to draw attention to the specific moments that accompany the writing of programs by offshore teams, as well as the features of task scheduling and communication with customers.
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 make it possible to avoid, or at least minimize, the “float” with customers, which inevitably arise during remote communication.
All recommendations are based on personal experience with customers from Western Europe and the USA. Probably, work with customers from other regions will have its own specifics, but perhaps some of the conclusions will be true for this case.
')
So, consider the option of working an offshore team: the team is technically savvy, writes good code, but communication with customers is not organized at the proper level. Result: sooner or later, such cooperation stops.
Here are tips / comments that will help an offshore team look good in the eyes of the customer.
1. Be active
This may not seem important at the beginning, but in fact it has a great influence on the impression from the development team. Activity is manifested in constantly looking at a project from the point of view of a project manager or a person who pays you money.
That is, you are not only developing the project, but also trying to improve the speed of development, find out how to integrate different components together more efficiently, think over a more optimal architecture, or, in the simplest case, how to speed up the project assembly.
Thereby you take on a part of the tasks of managing / understanding the project, and among other things, show the customer your interest in the project.
2. The flow of completed tasks
One of the most important moments of communication with the customer is information about the tasks performed.
On an active project, tasks arrive continuously, and if you give a “balanced” report on what has been done, then the expectations will be formed correctly. For example: if you have tasks for the UI and server side, then the weekly report / release should contain tasks from both parts.
Another point is the speed of task execution. You do not have to do them very quickly, because the client, as a rule, does not understand that it takes an hour for one task, and another week for another. Client all tasks are of the same complexity. Therefore, large tasks are performed in the background, while small tasks are “shown” to the client.
To paraphrase what has been said, then you need a “positive flow” towards the customer.
3. Do not change people on the project.
As a rule, offshore companies do the following. At the beginning of the project in place of the developers put very experienced people. The manager is accustomed to the high quality and speed of the tasks, and expects that this level will be maintained further. But over time, experienced developers are transferred to other projects, and weaker (read, cheap) are put in their place. As a result, the speed and quality of development fall. India is especially famous for this approach.
When the project manager is aware of this situation, he can’t do anything, because there is not enough time left before the project is handed over, and the transfer of affairs to another company will disrupt the project. In addition, it is not so easy to redirect the cash flow to another company (to sign papers, enlist the support of management, etc.). In addition, there will be uncomfortable questions 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 lead to their rupture.
4. Metrics / Development Environment
By default, a build server, unit test coverage, Jira, etc. should be installed. Using this information, it will be easier for the project manager to show the progress of work to the higher management. That is, we care about how the manager “looks” in front of the management.
In addition, these metrics are objective assessments of project progress.
5. Choose the right technology.
Ask more questions about the future of the project. From the answers it will be clear what 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 should be set to 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 on what was done last week, what is planned for the next one and what problems arose during the execution of tasks.
In this case, the project manager will be able to change the priority of tasks and notify clients 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 an offshore team there should be people who speak to the client (as a rule, fluent in the language of the client) and are able to solve problems by telephone.
These are people who work in the company for a long time and who will not leave the company at the first opportunity. This is the "face" of the company.
The working scheme looks like this: two people are allocated for a large project. One manager and one technician who are able to solve all the questions on the project.
There must be another person (escalation person) whom the client will be able to “complain” if they could not agree.
The access of developers to communication with the client will sooner or later lead to the fact that the developer will try to “lead” the client. I have been in such a 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 occur through one person is control over the situation: this selected person will know the current state of the project, problems that arise, questions, etc. at any time.
8. Email
Email is the document on which decisions are made. Emails on the project are not deleted, so that at any time you can raise the full chain of discussion. It is advisable to confirm all telephone discussions with a letter in which you describe everything that has been discussed and planned steps.
In fact, an explanation of what should be done to a person who sits on you at ten o'clock in the summer is not a simple thing. I do it like this. I am writing a small document with the basic requirements, then recite all the details on the phone. After discussion, the developer writes a document in which he describes how he understood all this. If after reading a “picture” is created for me that is similar to what I originally wanted to convey to the developers, then the task goes on. Otherwise, we continue to discuss.
It may seem that this is an additional red tape, but in the end it turns out faster than done, without understanding the essence of the task and then redoing everything. After a month of this practice, everything happens quite quickly.
9. Run Down Script
Run Down Script is a useful thing, but I did not understand its purpose until I went to work at the bank.
A bank is a large organization, and the installation of a new version of a product occurs at a certain time, the so-called “window” (release window). At this time, many will exhibit 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 “crashes”, how it can be rolled back to the previous stage. Everything should be described, right down to the commands to be executed.
10. Technical support
Do not be afraid to take the project for support / maintenance. The software company receives the main money from those. support, not from development.
For support, you can hire less experienced developers to study, while more experienced ones make a new project.
11. Punching the solution
Customers like to “push through” additional system requirements, especially when 90% of the work has already been done and conditionally free time has appeared.
Here are two solutions:
* show the execution of tasks in such a way that it seems that we do not 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 have all the letters and documents that were discussed, and consent to perform the work in this volume was received.
12. Forbidden words
Do not use forbidden words in communication. For example, the phrase “we will rewrite the system in a week” is fundamentally wrong. If you say “rewrite”, the next question will be “what have you been doing all this time?”. Such moments may arise due to ignorance of the customer's language at the proper level. It is 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 in fact nothing is clear. But when it comes to completing the 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 to provide a product on a specific date is important because the release is not only written software, but also hardware, admins, etc., etc.
On this date, a lot of parameters must be synchronized.
For example, if the iron is purchased and works at idle, then the customer pays for it. If there was software, then the service would bring revenue, and so the iron is just worth it.
Please schedule tasks correctly and provide software on time.
Comments are welcome.
Source: https://habr.com/ru/post/143849/
All Articles