Product Design Experience (iv) -- is Project outsourcing not suitable for "agile "?

I tried to do PM in the past few months (this time the project is not a product), and I personally experienced how a project went wrong step by step. First, let us explain that "agility" here is the "agility" that both parties cooperate with, rather than saying that the outsourcing project itself is not suitable for "agility ".

 

First, let's talk about the background. The project time is too short and the construction period is determined by the commercial negotiation. If the workload is not evaluated in time, we will try to generate a delay. First, we will try to catch up with the progress by working overtime, later, I was forced to inject the "agile" project method, but afterwards I found that the "Project outsourcing" model was not suitable for agility.

 

First, outsourcing makes Party A unwilling to cut down the demand. To be agile and flexible, the company's internal project needs can be cut down to a large extent. This is in line with the agile principle. However, when Party A initiates a request for Project outsourcing, Party A does not want to push any function to Phase 2 as usual, because it does not know where Phase 2 is after the end of the project, therefore, "guaranteed quality" becomes "not guaranteed quality ".

 

Secondly, agility will inevitably lead to incomplete document work, and it is difficult for Party A to adapt to the "Acceptance Test" model beyond the project. In terms of agility, there must be many changes between the products that submit the test and the initial requirements, and the documents are difficult to keep up with. This agility runs well within the company, the reason is that PD, development, and tester can fully communicate with each other during the project process. tester will call PD and Development during the TC (test case) review, some of the detailed design details are directly validated with the development during the review, and assist in the validation of requirement details and iterative testing during the test execution. During project outsourcing, Party A will generate the "Acceptance Test" Tc from a coarse-grained requirement document, and because the acceptance has the "test" nature, therefore, Party B's development is not allowed to participate in Party A's TC review. As a result, Party A's demand personnel can only confirm the details. However, the demand personnel have no requirements for such details. In desperation, they can only follow their own ideas, this will inevitably lead to a gap between the two sides in understanding the needs. On the other hand, the acceptance test is one-time, only the pass or false conclusion, no iteration process, not in line with agile thinking.

 

Finally, Party B has no "agile" experience and awareness. Generally, If Party A does not have independent software R & D capabilities, Party A shall select Project outsourcing (otherwise, more development outsourcing is required ), the professional nature/the current situation of project management in China determines that the habit of outsourcing engineers is to develop/test according to detailed design documents to resist changes in demand, so forcible "agility" will lead to out-of-control. Because there is no complete and detailed design document, developers will code according to their own ideas, testers will also test according to their own ideas, without the awareness of conducting TC reviews, in addition, there is no habit of communicating with the demand personnel in real time, there is no iteration process, and the test intensity is reduced for the dead command of the construction period, the result is that it is too late to find that the operation is not in line with the requirement.

 

There are many causes for negative results, but some of them have not been mentioned yet. In conclusion, we can't do this anymore. We have a rough understanding of agility. Thank you for your correction.