Technology Management Sequence 1--"uncertainty" & Risk Control

As a programmer, in the course of his career development, project experience and technical ability will increase with the increase of working years. And in this process, there is no problem: technical management.

Technical management, said the popular point, is how you lead a team to complete the iteration of the product, a project development. There are a lot of things involved in this, including research and development, testing, operations, product, project management, data analysis. There are different types of projects, different corporate cultures, and there will be differences in the way things are done.

But regardless of these differences, there are some common ideas, or methodologies, that are interlinked. And starting with this sequence, I'll share some of my own experience and thoughts on this.

In my opinion, the first step in technology management is to deal with the problem of "uncertainty". In terms of human cognition, to do anything, your thoughts are from a "hazy" to a gradual "clear" process, the progress of the project is a step from the idea, to the program, to the ground of a gradual refinement process.

In this process, there are inevitably various "shades", or "uncertainties". and management, is to prevent the various "uncertainties" in advance, and take corresponding measures, so that the entire team, the entire project through a lot of interference, to reach the end.

What are the "uncertainties"? Here are some of my concluding sums: The uncertainty of demand

Product managers or big bosses, or other stakeholders, have a lot of "ideas" when it comes to making a product or doing a project.

Some ideas are mature, logically rigorous, and systematic, while others are less than heat and require further refinement, and some ideas are purely brainstorming, just think about it.

and due to various external conditions, such as the constraints of the duration of the performance of the Chase, the boss of the pressure ... It is very likely that an idea was not fully thought out, and it began to be implemented.

This is a significant "uncertainty". In this case, as a technical leader, need to go and product managers, and related business parties, superiors, etc., to carry out a wide range of communication, and ultimately in this matter, to achieve a "consensus": in the end what things clear, we can open, and which need further thinking, refinement. the uncertainty of technology

When you're working on a new project, you may have problems with technology selection, a framework that members of the team haven't mastered, or an open source library, a docking 3rd party open API, and so on.

In this case, you must do as much research and testing as possible in the early stages of the project. Introduction of the technical framework, what features can support, what special effects are not supported, technology selection, the advantages and disadvantages of different programs.

In particular, some of the key technical details, if not research in the early stage, until the middle and late, only to find a feature support, or have problems, may be the entire technical framework and project progress, have a serious impact. uncertainty of personnel

System coupling high, a key module of the developer's sudden departure, the new members of the project is not familiar with, and then slowly touch ripe, the road, such as the completion of the final project, from the scheduled period has been a big cut.

In this case, a coping strategy is: Do not put the project at the core of things, so that a person to develop maintenance, others can not intervene. To spread the risk, at the technical architecture design level, to ensure that the overall system coupling is not too high, according to the level of team members, everyone can cover a piece of things. So that a person leaves, there is a corresponding person can fill up. uncertainty of the organization

The larger the company, the more complex the business, the more departments. Any project can be done with several business units. These departments may still be off-site, usually only instant communication, or remote telephone communication.

For this situation, we must do as much communication as possible, research the other side to provide the business capabilities, which currently has, which are currently in development, which has not.

On the basis of full communication, with each other to finalize the schedule, irregular synchronization progress, push each other, to ensure the progress of each other and their own in a rhythm. A legacy of history

Generally when you enter a company, in addition to start-up companies, very few will be on the first to do a new project. The first is to take over the old projects left by the predecessors, on the basis of the iterative upgrade.

Good luck, old project technical structure is clear, clear documentation, business clear, and other familiar colleagues;

Bad luck, the legacy project owes a lot of technical debt, before the developers have gone, the business is not familiar.

In this case, you need to complete the project to comb: from the product to the technology, to find the interface person to chat, perhaps after two or three months, you have a whole system has a global control. finally

The above lists the team to do the project process, encountered a few common "uncertainty" problems, the real process, the different projects will have a difference.

Here the main thing to emphasize is: to have this "risk control" awareness, with this awareness, you in the early stages of the project, will naturally try to think of a variety of "uncertainty", and then plan ahead, prepare for a rainy day.