Outsourcing plus backsourcing minus problems
I know people from corporate developers who are literally “life broke” by outsourcing. Vigorous clap door.
“Everybody needs a programmer,” I said, returning to the boots.
Embarcdero (Borland) does not use the outsourcing model in a “pure form”, however, the scheme of attracting external resources may well be considered useful for consideration, especially in the light of backsourcing. Why doesn't Embarcadero do it all by itself? Why does the base product need addition from technology partners? How to give something to the side, and then pick it up? Is it necessary to think about backsourcing as the inevitable completion of outsourcing? Is it possible to do without it?
Outsourcing by sound itself causes a negative reaction from “own developers”, for what there are a lot of reasons. Now one more single-word word will be added to this - backsourcing. So that this does not become a “second opportunity to slam the door,” let's look at the details. A good team that performs work to order is similar to special forces. Each fighter has several competencies. But where without the "tank"? Soft and pampered corporate developers can not oppose anything to the sales hardened in battles. Such a “little girl” will very quickly wipe your CIO that it’s his team that will make everything much better.
')
There are a lot of outsourcing. One of the first is the following thesis: "we have already done what you need, and we have some groundwork." They hint that for the money of another, previous customer, they have already made a decision, and now they will simply and cheaply finish it before your case. It will be much cheaper than initiating and funding your own direction.
In addition, "own developers" have long been lazy (rastrenirovalis). They would, of course, be encouraged by the scrum th ... (this would be a separate demotivational set). But our solution is not just the same, but also almost (semi-) ready.
Further, of course, eloquence works. Their corporate developers have not painted the picture of the future in bright colors for a long time. The question “where we will develop the system” usually frowns, the hands are tucked away in the pockets, the gaze is set aside. This is understandable, when payment is delayed, why take extra mile? And the external eloquent and balamut is always cheerful, cheerful and optimistic.
The psychology of the external team is well illustrated by dacha construction. Any brigade that replaces the dismissed one begins to scold the results of the work of previous figures. They have no chance to fight back.
The battery of optimism in the head of the CIO after such a “charge” generates the energy of creativity, but the contours of the internal developers are tuned to a completely different frequency. But this is exactly the reason for outsourcing!
In very many cases, “project reversal” is caused precisely by the loss of control over one’s 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, but their own will always be. A little bit at the expense of "outsourcing" to pre-tension one’s own, in order not to feel one’s irreplaceability / uniqueness, but one really doesn’t have to anger / humiliate.
The problem in the controllability of the development team (“how to feed cats”) is solved by “outsourcing” easily. But only in theory and only when talking with their salesman. For a good contract, they promise almost a webcam 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 collapse of the project is, first of all, a blow to the customer, since he also has his boss. Moreover, the CIO is forced not only to take the project / pay money, but also to implement it and use it for many years. If your own project is to be written off, it can be justified by an “objective reality” in terms of changing business processes (business ideas) and the needs of managers. And if the result of the work of the outsourcers is not needed, it means that they have not been given the right task. Who is guilty? Who set the task.
Upon delivery of the project, you can unscrew the hands of the customer so much that he even closes his eyes to the deficiencies.
And now, under the malevolent giggles of corporate programmers, “and we warned” their chief decides on backsourcing.
Myths about cheapness and quality of “external development” are easily dispelled, if we digress a little from coding thoughts and think about money (with all the disgustingness of this idea). Who still can’t make them think about the meaning of programming in the context of payment, I strongly recommend getting married and having children.
If you invert the above points, you can easily justify the need to keep the development within the creative team. Just do not needlessly to aggravate relations with your IT-bosses, so that outsourcing does not become an instrument of retaliation for disobedience.
But outsourcing has more adequate reasons, in particular, the desire to help a congenial team. No matter how friendly the team is, objective reasons for saving will lead to the fact that the project made on the side will be a “black box with flies”. Open it and there will be a whole swarm of self-erupting fast-cracking bugs.
Most experts will immediately say - you need good / correct documentation! Writing 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. returning the project to the parent company. It is best to be prepared for this at any stage.
Of course, you can take advantage of the arguments against outsourding and bury it. But how would you not have to dig it (yes, as in a joke).
Proper outsourcing must always imply 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 necessary competence of their team. Is outsourcing at all needed then? Of course, need. It allows you to smooth the peaks of the load on the main team. This is what we (Embarcadero) do in the period of intensive release preparation.
There are examples where the involvement of external teams had a negative impact. Take the scheme characteristic of Delphi, when there is a mother product, but there is - satellite technology, which can be included in the same package with the basic package. So it used to be with "report generators." It was clear that there was a desire to “not get involved” in the side direction, which is de facto ideologically isolated from the main toolkit. The core team could concentrate on code generation and component content, while independent teams could supply their solutions. It seems that such a good competitive scheme subsequently gave rise to problems.
Initially, when the technology partner is fighting for the right of entry into the supply, it literally breaks the traces. But there is no single synchronization strategy here, so the main and additional technologies are developing in disagreement. We have already gone forward to three releases, and our partner has just woke up. It turns out that we are his locomotive, 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 sustain the release race. And only from the fourth time, we found a partner of Fast Reports, which releases synchronous releases, practicing new frameworks and multiplatform.
I would like to especially note that for FastReports there is a niche for up-making money. In principle, such a scheme is applicable for outsourcing as well. The team does something super-TZ and has for it a separate income. The very fact of having the opportunity to receive money stimulates the external team not to close 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 Delphi’s openness gave a chance to produce an external solution. But you can observe the "redemption" technology, followed by re-branding in FireDAC. This allowed again to synchronize the development of basic and additional technology in the period of the revolutionary development of a multiplatform approach.
The implementation of contractual initiatives occurs when there is a supervisor. On outsourcing goes - yes - the classic TK, but under the supervision and guidance from the inside. Thus, unity and quality control of components at the level of source codes, including style, is observed. Here you can already talk about pure "outsourcing" and the initial planning of "backsourcing".
Most importantly, the reasons that initiated 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 management level offers advantages:
Less personal factors, more objectivity.
Now comes for many corporate teams a difficult moment. Mobile development requires new competence. Outsourcers are ready to break straight for a contract for a mobile business solution. If this is due to a lack of own competence, then the developers become a victim, even if it was not originally planned. Pay attention to the multiplatform mobile application development tools for Android and iOS based on a single source database. Do not separate or blur your own competence. Otherwise, others will.
“Everybody needs a programmer,” I said, returning to the boots.
Embarcdero (Borland) does not use the outsourcing model in a “pure form”, however, the scheme of attracting external resources may well be considered useful for consideration, especially in the light of backsourcing. Why doesn't Embarcadero do it all by itself? Why does the base product need addition from technology partners? How to give something to the side, and then pick it up? Is it necessary to think about backsourcing as the inevitable completion of outsourcing? Is it possible to do without it?
Outsourcing by sound itself causes a negative reaction from “own developers”, for what there are a lot of reasons. Now one more single-word word will be added to this - backsourcing. So that this does not become a “second opportunity to slam the door,” let's look at the details. A good team that performs work to order is similar to special forces. Each fighter has several competencies. But where without the "tank"? Soft and pampered corporate developers can not oppose anything to the sales hardened in battles. Such a “little girl” will very quickly wipe your CIO that it’s his team that will make everything much better.
')
There are a lot of outsourcing. One of the first is the following thesis: "we have already done what you need, and we have some groundwork." They hint that for the money of another, previous customer, they have already made a decision, and now they will simply and cheaply finish it before your case. It will be much cheaper than initiating and funding your own direction.
In addition, "own developers" have long been lazy (rastrenirovalis). They would, of course, be encouraged by the scrum th ... (this would be a separate demotivational set). But our solution is not just the same, but also almost (semi-) ready.
Further, of course, eloquence works. Their corporate developers have not painted the picture of the future in bright colors for a long time. The question “where we will develop the system” usually frowns, the hands are tucked away in the pockets, the gaze is set aside. This is understandable, when payment is delayed, why take extra mile? And the external eloquent and balamut is always cheerful, cheerful and optimistic.
The psychology of the external team is well illustrated by dacha construction. Any brigade that replaces the dismissed one begins to scold the results of the work of previous figures. They have no chance to fight back.
The battery of optimism in the head of the CIO after such a “charge” generates the energy of creativity, but the contours of the internal developers are tuned to a completely different frequency. But this is exactly the reason for outsourcing!
In very many cases, “project reversal” is caused precisely by the loss of control over one’s 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, but their own will always be. A little bit at the expense of "outsourcing" to pre-tension one’s own, in order not to feel one’s irreplaceability / uniqueness, but one really doesn’t have to anger / humiliate.
The problem in the controllability of the development team (“how to feed cats”) is solved by “outsourcing” easily. But only in theory and only when talking with their salesman. For a good contract, they promise almost a webcam 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 collapse of the project is, first of all, a blow to the customer, since he also has his boss. Moreover, the CIO is forced not only to take the project / pay money, but also to implement it and use it for many years. If your own project is to be written off, it can be justified by an “objective reality” in terms of changing business processes (business ideas) and the needs of managers. And if the result of the work of the outsourcers is not needed, it means that they have not been given the right task. Who is guilty? Who set the task.
Upon delivery of the project, you can unscrew the hands of the customer so much that he even closes his eyes to the deficiencies.
And now, under the malevolent giggles of corporate programmers, “and we warned” their chief decides on backsourcing.
Myths about cheapness and quality of “external development” are easily dispelled, if we digress a little from coding thoughts and think about money (with all the disgustingness of this idea). Who still can’t make them think about the meaning of programming in the context of payment, I strongly recommend getting married and having children.
- When we consider the money of an external project, then the cost of time of internal employees to help outsourcers, at least for the preparation of TK, is not entered.
- The cost of development is determined by the quality of the code. The quality of the code is needed to reduce the cost of maintenance / modification / development of the system. But you need this "your", and not "external."
- The quality of development depends on the degree of testing. In application development, only a person familiar with the subject area can write case studies. Here, as it were, it is already indecent to demand such from outsourcers.
- The duration of a typical project is commensurate with the period of generation of new business ideas, so the probability is high (the farther, the more likely), that in the final you will be given a system that is outdated in advance.
- The flexibility and modifiability of the system is determined by the architecture. The architecture of external solutions is often one-time. There is a great temptation to make a “hard-welded” construction of rods than to sharpen universal reusable knots on a machine.
If you invert the above points, you can easily justify the need to keep the development within the creative team. Just do not needlessly to aggravate relations with your IT-bosses, so that outsourcing does not become an instrument of retaliation for disobedience.
But outsourcing has more adequate reasons, in particular, the desire to help a congenial team. No matter how friendly the team is, objective reasons for saving will lead to the fact that the project made on the side will be a “black box with flies”. Open it and there will be a whole swarm of self-erupting fast-cracking bugs.
Most experts will immediately say - you need good / correct documentation! Writing 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. returning the project to the parent company. It is best to be prepared for this at any stage.
Of course, you can take advantage of the arguments against outsourding and bury it. But how would you not have to dig it (yes, as in a joke).
Proper outsourcing must always imply 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 necessary competence of their team. Is outsourcing at all needed then? Of course, need. It allows you to smooth the peaks of the load on the main team. This is what we (Embarcadero) do in the period of intensive release preparation.
There are examples where the involvement of external teams had a negative impact. Take the scheme characteristic of Delphi, when there is a mother product, but there is - satellite technology, which can be included in the same package with the basic package. So it used to be with "report generators." It was clear that there was a desire to “not get involved” in the side direction, which is de facto ideologically isolated from the main toolkit. The core team could concentrate on code generation and component content, while independent teams could supply their solutions. It seems that such a good competitive scheme subsequently gave rise to problems.
Initially, when the technology partner is fighting for the right of entry into the supply, it literally breaks the traces. But there is no single synchronization strategy here, so the main and additional technologies are developing in disagreement. We have already gone forward to three releases, and our partner has just woke up. It turns out that we are his locomotive, 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 sustain the release race. And only from the fourth time, we found a partner of Fast Reports, which releases synchronous releases, practicing new frameworks and multiplatform.
I would like to especially note that for FastReports there is a niche for up-making money. In principle, such a scheme is applicable for outsourcing as well. The team does something super-TZ and has for it a separate income. The very fact of having the opportunity to receive money stimulates the external team not to close 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 Delphi’s openness gave a chance to produce an external solution. But you can observe the "redemption" technology, followed by re-branding in FireDAC. This allowed again to synchronize the development of basic and additional technology in the period of the revolutionary development of a multiplatform approach.
The implementation of contractual initiatives occurs when there is a supervisor. On outsourcing goes - yes - the classic TK, but under the supervision and guidance from the inside. Thus, unity and quality control of components at the level of source codes, including style, is observed. Here you can already talk about pure "outsourcing" and the initial planning of "backsourcing".
Most importantly, the reasons that initiated 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 management level offers advantages:
- reducing the load on the main team;
- faster rapid development of technology;
- respect for the interests of the quality of the underlying architecture / framework;
- uniformity of technological implementation;
- prevention of separation of competences in a team;
- another degree of freedom in the redistribution of resources.
Less personal factors, more objectivity.
Now comes for many corporate teams a difficult moment. Mobile development requires new competence. Outsourcers are ready to break straight for a contract for a mobile business solution. If this is due to a lack of own competence, then the developers become a victim, even if it was not originally planned. Pay attention to the multiplatform mobile application development tools for Android and iOS based on a single source database. Do not separate or blur your own competence. Otherwise, others will.
Source: https://habr.com/ru/post/207888/
All Articles