Have you ever outsourced a software development team? Or have you ever provided Customers with your services remotely? Of course, a lot of people and companies have had this experience. Outsourcing has become a common trend in information technology as well as in other industries. This article looks at the benefits of outsourcing services and the valuable advice offered by Yulia Bulakhova who had worked on the Customer's site for several months.
In the following article I would like to share what I learned from my very first business trip on whether it is good or not to be an analyst sent abroad and what particular pros and cons there are. In October 2015 I along with one of the backend developers from Media Project (music sharing social network) were sent on a business trip to the US to work shoulder to shoulder with our Customer's team members. That was a unique experiment for our company and not only because of its duration.
Initially it was planned for us to spend 2 months (from the end of October to the end of December) working together with our colleagues from Missouri state. In fact I spent there more than 5 months. Since October 2015 I managed to meet and say goodbye to more than 3 developers from ISS Art on a mission and get acquainted with almost 20 members of our Customer's team. And we are still friends with some of them.
Until recently I haven't thought about that experience as of something truly epic, but eventually I realized how important that experience was not only for me but on the company's scale as well.
Here I would like to share with you what personal knowledge I gained from that mission, what advantages and disadvantages I experienced first-hand and maybe to give some tips to my co-workers who would be lucky enough to get such opportunity in the future. I understand that all pros and cons that I have noticed may be of arbitrary nature, but that is all I'm able to share with you at the moment.
In my article I'm not inclined to be anyhow descriptive on preliminary executive matters considering that I did little else than simply supply a set of documents for my B1/B2 business visa, fill up an application and get appointment in the US consulate followed by the very business trip.
Neither am I going to spend my time describing specifics of the project. It has been a while since we got that project and it is just too unique in too many ways to be repeated in the near future. I can only say that the project is huge with a distributed product development team. Therefore, there is a lot of misunderstanding on a daily basis on vital matters such as user requirements facilitation and terms of our team collaboration.
Benefits of working in Customer's office
When it comes to selecting what is the most important benefit of such a thing as to be an analyst on a mission I would pick the ability to win your Customer's confidence within a relatively short period of time and with easiness. Why "relatively"? Because it is never fast enough for both sides and there's nothing easy about winning someone's confidence. Speaking closely to the topic, for the first time we got the access not only to user requirements as their end-readers but to their editing and proof-reading. Yes, well, I received a bunch of requirements management tasks from the product team as a load but we got that access and the workflow got more transparent to me, because I became a part of the product team, even though as a junior member with less freedom in decision making. So, winning the Customer's confidence is the first benefit.
Right next to the confidence for me there is a prompt reaction to our team's questions and overall simplification for anything you have to explain.
![Working in Customer's Office](/static/img/2016/09/T4CkpnmvcBg.jpg)
Even though the product team was distributed, because two of its members were out of Grandview, where we were sent to, we managed to achieve understanding more often than we had to. A rare opportunity to track your foreign colleagues' contribution to the project and monitor their productivity.
With that knowledge you can plan your own daily activities better, schedule any reporting on your tasks progress and make some predictions on how fast your problem would be solved if you refer it to the right person and maybe it would be easier for you to readdress the question after all. Finally yet importantly I want to mention the unique opportunity for me as an analyst to co-exist in the same information space with our backend and frontend developers on a daily basis for 5 months solid. Those user requirements that I was proof-reading and editing on a daily basis did nothing with the backend developer's needs (since all technical documentation on the project is supposed to be provided by the CEO) neither did I have that much of collaboration with our frontend developers. By any measure, my main collaborators on the project were QA engineers who tested user requirements and informed me about their flaws, so I could fix them after the product team's confirmation.
Some cons and my recommendations
It is harder to tell what exactly can be considered as universal cons for that concept granted my limited amount of experience.
Too many things were kept hidden from me because of the not really transparent business-processes on the project.
– Even with my arrival the most part of the product team was unreachable, which means I couldn't get an answer the moment I needed it, because the product team was busy communicating with business side outside of the office on a daily basis.
– What I didn't like the most was my permanent lateness. I technically couldn't give an answer to QA or mobile client developers right that instant, even if I had it because of the different time zones.
– There were no instructions or suggested workflow for me on how to collaborate with anyone from the American part of the project except the product team, so in the beginning of my business trip it was more like a process of finding someone who could help me in the future to work through some difficulties existing between the product team and the rest of the project.
Even though I got a part in the product team activities, there was a noticeable period of time when I had to reschedule my common activities because I had to prove my skill set to the product team before getting the right to comment on their decisions and make any alternations to the requirements documentation.
What I would like to recommend for the future reference to make your business trip more efficient:
– prior to your business trip get your task list confirmed by both your CEO and your Customer. There supposed to be a very detailed list of tasks that you will need to resolve directly connected to the global business aims of your company in regards to collaboration with your Customer's team.
– get a detailed scheme of interaction between you and the other concerned parties on the project. You can fix it later with its further confirmation if something will go wrong. Upon its fixing you need to confirm it to keep it relevant.
– you need to understand that the key to getting what you need while you are abroad is to communicate as more as you could with anyone on the project. It is not only about office talks, you need to get acquainted with as many people from the team as possible. Because in the future those would be your informal information channels.
– based on your task list you need to contact your executive on a weekly basis telling how much has been completed and what is next on your task list.
– never forget that you are representing the whole company while you are being abroad, therefore, you can't be less than a highly qualified expert all the time you are contacting both your side of the project and your customer's team regardless of the importance of your question as it may seem to you. In conclusion I would like to say that I'm grateful for that opportunity to test my professional and personal skills.
I want to think that our company consider such experiment as a successful one and can see it not as a single event but as a new form of collaboration between us and our customers in the visible future.