Some impressions of outsourcing in Huawei

I have worked as a partner project management assistant and technical architect role in a Huawei project. Here is a discussion of technical and managerial sentiments.

1. Technology

Huawei is developing its own cloud platform technology. It is called Huawei Application engine. It is a cloud platform based on the Java EE, there are a lot of Huawei custom front-end controls, the front-end control is quite complete. Rest services can be built without having to write Java code, and you can configure some SQL statements. Only the underlying is WebSphere-based, and the platform transparently adds complexity to these deployments, and the user does not need to know the specifics. Hundreds of of people are developing these platforms. The power of input is still quite large. The downside is that these front-end controls are inflexible and do not meet all requirements, and the application team must use the Huawei Application engine team to modify these controls. The call relationship between background services is complex, the first caller and the callee are rest services, there is a problem with performance, and the calls between Java classes are much faster. There is basically no call between Java classes, and in extreme cases, Java code can even be completely non-writable, writing only JavaScript code. Because background code can be implemented in a way that configures SQL statements. The application team thought of the localization approach and could write more Java code. However, there is still a need to improve the complexity of calling relationships between backend services. The Huawei application engine has a lot of limitations on unit testing, and the application team is thinking of ways to write unit tests, but some scenarios still can't write unit tests. Therefore, unit test coverage is not high. Code quality is difficult to guarantee.

In addition, the platform is based on Huawei's own secure login system W3. But from the experience gained in the past, some security flaws have been identified and the security issues are pointed out to Huawei. Huawei's architects have also accepted it. The W3 login system is widely used as a platform within Huawei. Or try to minimize security problems and pitfalls. As an architect, consider meeting functional requirements, scalability, maintainability, scalability, security, robustness, and so on. So there's a lot of work to do.

The Huawei application engine still has a long way to go.

2. Management

The team is large and there are more than 100 people. The team is trying to adopt an agile methodology, but what is actually done is not agile. The Huawei Project manager is working with the supply-side project manager to manage such a large team. Divided into a few small teams. Take each small team as an agile team. Sometimes these small teams are around 10 people and sometimes 20 people. In fact, this number is not suitable for agile. Generally 7 to 8 people are more suitable. There is no real agile definition of the PO (Product Owner), its organizational form or waterfall-style organization. BA (Business Analyst) is reluctant to act as a PO.

The risk in the project is varied, the risk of personnel, the turnover rate is higher, need to arrange work handover. The risk of technology, such as some features of the Huawei application engine itself needs to be modified, we must ask the Huawei application engine team to modify, but the Huawei application engine team to serve multiple projects, need to coordinate resources. This piece of work is quite a lot. The need to understand the risks, development and testing of the BA-given requirements of the understanding may appear biased, the demand is not well-versioned, so sometimes the appearance of BA changed the requirements of the document, forgot to inform the development and testing, or only informed the development, no notification test, or only informed the test, no notification development, The parties ' understanding of the demand is inconsistent, which leads to the late project wrangling. The last item was postponed. At that time, the Huawei application engine was not robust and stable, and often had problems, which cost the team a lot of time. Risk management was once managed. But the team didn't insist on managing it.

Huawei Application engine platform was not yet implemented tag, so version management is very difficult, configuration management is a very headache. Do a build, then deploy. It's been a long time. Not lack of this is the lack of that, the code version is not the same thing often. This should be a good way to identify all the configuration items, the requirements of the platform, its configuration is much, it must be recognized, well managed. This piece of work has not been done well enough, and there are some configuration items that always let developers of some development teams in the pipeline. Even deploying to a production environment is also a pipe for these developers. A large number of deployment steps are manual, without scripting. Error prone. Even with scripts, the quality of the scripts is worrying. This is better than the project we've done in the past. Far away.

It can be said that the team applied a small part of the agile form, but there is no essence of agility. The essence of agility is the active delivery commitment of the Agile team to the PO. It is the agile team's understanding of demand, after analysis, the need to disassemble, understand its complexity, to the PO to do the active delivery commitment. The reality is that the team has no active commitment, are the Huawei Project manager and BA hard plug to the team's scope, requirements and duration. Then there is no way, only a passive commitment, but most of this commitment has not been fulfilled. Quality, duration, scope are not up to Huawei side requirements. To be truly agile, this requires both Huawei and the supply side to become agile thinkers.

Some impressions of outsourcing in Huawei