Outsourcing plus backsourcing minus problems

I know people from corporate developers who outsourcing literally “broke their lives”. Vigorous cotton door.
“Everyone needs a programmer,” I said, returning to the boots.

Embarcdero (Borland) does not use the “outsourcing” model in its “pure form,” however, the scheme for attracting external resources may well be considered useful for consideration, especially in the light of backsourcing. Why doesn't Embarcadero do everything herself? Why does the base product need to be complemented by technology partners? How to give something to the side, and then pick it up? Should I think of backsourcing as the inevitable end of outsourcing? Is it even possible to do without this?

Outsourcing by the sound itself causes a negative reaction from the “own developers”, for which there are many reasons. Now one more root word is added to this - backsourcing. So that this does not become a “second opportunity to slam the door,” let’s take a look at the details. A good team doing custom work is like special forces. Each fighter has several competencies. But where without the "tank"? Soft and pampered corporate developers can not oppose anything hardened in battle sales. Such a “charm” will very quickly rub your CIO that it is his team that will do everything much better.





There are many approaches to outsourcing. One of the first is the following thesis: "we have already done what you need, and we have achievements." As if they hinted that for the money of another, previous customer, they had already made a decision, and now they would simply and cheaply finish it to your case. It will be much cheaper than initiating and funding your own direction.



In addition, the "own developers" have long been spilled (unraveled). They would, of course, be cheered up by scrum ... (this will be a separate demotivation set). But our solution is no longer just similar, but also almost- (semi-) ready.



Further, of course, eloquence works. Their corporate developers no longer paint a picture of the future in bright colors. To the question “where are we going to develop the system”, eyebrows are usually frowned, hands are put into pockets, eyes are turned away. This is understandable when payment is time-bound, why take extra mile for yourself? And the external rubbish and balamut are always cheerful, cheerful and optimistic.



The psychology of the external team is well illustrated by summer cottage construction. Any team that replaced the dismissed one begins to scold the results of the work of previous leaders. They have no chance to fight back.



The battery of optimism in the head of the CIO after such a “charge” generates energy of creativity, however, the contours of internal developers are tuned to a completely different frequency. But this is precisely the reason for outsourcing!



In so many cases, “giving the project to the side” is caused precisely by the loss of control over its own team. Our boss has never been a good developer! He constantly climbs into our affairs! He does not understand what he is talking about! Let's continue in the same vein. Then the chef will respond in the style of Machiavelli. Will take the second external team.

Although the boss may behave more diplomatically. Aliens come and go, and theirs will always be. At the expense of “outsourcing”, a little harness is necessary for our own people so that we don’t feel our indispensability / uniqueness, but you don’t need to anger / humiliate us.



The problem is the controllability of the development team (“like grazing cats”) is easily solved by “outsourcing”. But only in theory and only in conversation with their "salesman." For a good contract, they will promise almost webcams behind the backs of developers.



But the situation will be completely different at the completion of the project. Only genetically naive people think that the customer decides everything. The blockage of the project is, first of all, a blow to the customer, because he also has his own boss. Moreover, CIO is forced not only to take a project / pay money, but also to implement it and use it for many years. If your own project is subject to cancellation, then you can justify the "objective reality" in terms of changing business processes (business ideas) and the needs of managers. And if the result of the work of outsourcers is not needed, then they have not been assigned the task. Who's guilty? Who set the task.



Upon delivery of the project, you can so twist the hands of the customer that he even turns a blind eye to the imperfections.



And now, under the malevolent giggles of corporate programmers “and we warned”, their boss decides on backsourcing.



Myths about the cheapness and quality of "external development" are easily dispelled, if you take a little distraction from thoughts about coding and think about money (for all the hideousness of this idea). Who still can not make himself think about the meaning of programming in the context of payment, I highly recommend getting married and having children.

1. When we consider the money of an external project, they don’t put the cost of time for internal employees to help outsourcers, at least to draw up TK.
2. The development cost is determined by the quality of the code. The quality of the code is needed to reduce the cost of maintaining / modifying / developing the system. But it is necessary to "their" and not "external."
3. The quality of development depends on the degree of testing. In applied development, only people familiar with the subject area can write cases. Here, as it were, it is indecent to demand such an outsourcing.
4. The lead time for a typical project is commensurate with the period of generating new business ideas, so it is likely (the farther, the more likely) that in the final you will be given a pre-outdated system in terms of functionality.
5. The flexibility and modifiability of the system is determined by the architecture. The architecture of external solutions is often disposable. It is very tempting to make a “hard-welded” construction from rods than to grind universal reusable units on the machine.

If you invert the above points, then you can easily justify the need to keep the development within the creative team. Just do not needlessly aggravate relations with your IT authorities so that outsourcing does not become a tool of retaliation for rebellion.

But outsourcing has more adequate reasons, in particular, the desire to help a close-minded team. No matter how friendly the team, objective reasons to save will lead to the fact that the project done on the side will be a "black box with flies." Open it and a whole swarm of self-breaking quick-breeding bugs will appear.

Most experts will immediately say - you need good / proper documentation! Recording the moves of a chess game never prevented a fight, but provoked it.



Getting involved in outsording, you need to think about backsourcing, i.e. return the project to the fold of the parent company. It’s best to be prepared for this at any stage.



Of course, you can take advantage of the arguments against outsourding and bury it. But no matter how you have to dig it out (yes, as in a joke).



Proper outsourcing should always mean backsourcing. It is not necessary to pronounce / prescribe, but keep in mind. Then the goal of autsourcing will never be to compensate for the lack of competency in your team. Is outsourcing at all necessary then? Of course you need it. It allows you to smooth the load peaks on the main team. We (Embarcadero) do this during the period of intensive preparation for the release.

There are examples where the involvement of external teams had a negative impact. Take the scheme typical for Delphi, when there is a parent product, and there is a satellite technology, which can be included in the same package with the base package. This was usually the case with "report generators." The desire “not to get involved” in the lateral direction, which is de facto ideologically isolated from the main tools, was understandable. The core team could concentrate on code generation and component filling, while independent teams could deliver their solutions. It seems that such a good competitive scheme subsequently created problems.

At first, when a technology partner fights for the right to enter the supply, he literally breaks the lines. But there is no single synchronizing strategy here, so the main and additional technologies are developing uncoordinated. We have already gone ahead for three releases, and our partner has just woken up. It turns out that we steam it, and he converted the second locomotive into a sleeping car.

This went on several times, old-timers remember ReportSmith, QuickReport, Rave Report. Each time the technology fired, and then did not withstand the release race. And only the fourth time we found a partner Fast Reports, which produces synchronous releases, working out new frameworks and multi-platforms.

I would especially like to note that for FastReports there is a niche for pre-making money. In principle, such a scheme is also applicable to outsourcing. The team is doing something over-TK and has separate revenues for it. The very fact that there is an opportunity for pre-receipt of money stimulates an external team not to focus on the basic functionality and keep their decision in a potentially developed state.

In the case of the AnyDAC data access library, we do not see outsourcing, except that the openness of Delphi gave a chance to release an external solution. But you can observe the "buyback" of technology with subsequent re-branding in FireDAC. This allowed again to synchronize the development of basic and additional technology during the revolutionary development of a multi-platform approach.

Implementation of contractual initiatives takes place in the presence of a supervisor. Outsourcing takes - yes - the classic TK, but under the supervision and guidance from the inside. Thus, the unity and quality control of components at the level of source codes, including style, is respected. Here we can already talk about pure “outsourcing” and the initial planning of “backsourcing”.

Most importantly, the reasons behind outsourcing with a minus sign are not grounds for backsourcing. These are two related solutions, and the ability to correctly implement them at the process control level provides advantages:

• reducing the load on the main team;
• faster extensive development of technology;
• Compliance with the quality interests of the main architecture / framework;
• uniformity of technological implementation;
• prevention of separation of competencies in the team;
• another degree of freedom in the redistribution of resources.

Less personality factors, more objectivity.



Now comes a difficult moment for many corporate teams. Mobile development requires new competencies. Outsourcers are ready to break directly for a contract for a mobile solution for business. If this is due to a lack of competence, then developers become a victim, even if this was not originally planned. Pay attention to the multi-platform mobile application development tools for Android and iOS based on a single source code base. Do not separate or erode your competence. Otherwise, others will do it.