Project management - "people" and "methodology" that you don't realize - Project Management

Recently, i have been slowly doing one thing: turning some of the work content into a knowledge graph around keywords. of course, i know, it's a very big pit that takes an entire career to keep filling.

but i think this is still very meaningful, not only for yourself, but also for others. and i think, maybe can find a group of friends who have the same idea, do knowledge graph together, and share with each other?

it took two afternoons to simply sort out a sheet of relevant content about project management on the internet, including:

simple definition of the project;
simple classification of items and the significance of item classification;
the stages involved in project management and the points of attention required in each phase;
the specific large map is as follows: click to enlarge or download the original picture to see clearly, as to whether to collect, it is arbitrary.

looking at the children's shoes in the picture, they should find that the above figure, which mainly describes the relevant content of the project process in project management, should help the following types of children's shoes:

children's shoes that have no concept of the project process, popularize the basic knowledge;
children's shoes that have a basic understanding of the project process, but only know the "point" and do not know the "line", and have doubts about certain parts in their hearts;
children's shoes that have a complete concept of the project process and are only used as a combing point of attention to each process;
of course, the ultimate goal of sorting out the project management knowledge map is not to sort out the project process, but to classify and sort out the projects of different dimensions, and find out what the core and characteristics of the respective are, so as to facilitate cross-reference in practical work. and this part, not to share in the above big picture, one is too much content is too complicated, two even if it is shared may not be understood, the third is that they have not sorted out too many classifications, temporarily do not sacrifice ugly.

in addition to the content of some of the above figures, i would like to highlight a few points that seem to be relatively "empty", but are very "dry" when you think about it:

first, the people in the project should be paid the most attention

after the project is established, "people" are needed to promote and implement it. some projects require only one person to complete, and some projects require many people to work together. of course, in the internet, there are not many things that can be done by one person as well as the all-round warriors. then, many different people together, it is easy to have a lot of problems, such as:

each other does not understand what the other party is saying, and needs a "translator" who can communicate between the two sides;
mutual disapproval of each other's views requires a "balance beam" that can consider the ideas of all parties;
people will be lazy, lazy, will not think of enterprising, and need a "propeller" that can reasonably spur everyone;
people will be confused, will have no goals, will be insecure, and need a "guiding sign" that appears at any time;
people will be angry, angry, scolding each other and stupid, and need a "purifier" that can eliminate bad emotions;
... there are many other situations...

above, it is possible that different combinations may appear in different projects or appear in different stages of the same project multiple times, of course, depending on different projects and different project team members:

some are not solved, the project can not be moved forward, such as the above a;
some are not solved, the project can be advanced but relatively slow, such as the above c, d;
some can be solved temporarily, but it may be dangerous to erupt at a certain moment, such as b, e above;
if it is said that the "everyone" in the project can only consider the problem from their own point of view, but as a person who manages the project, you must not only think of yourself as one of them, but at the right time, you must withdraw, perceive everyone's emotional changes, and make corresponding solutions.

it is a cliché to compare everyone in the project to water, the project to a boat, and water to carry a boat and overturn a boat.

second, the appropriate methodology and tools are the best

this is used to intimidate tools, methodologies-oriented businesses, teams, or individuals. many articles on the internet, many people are advocating good tools and easy to use methodologies, but they never combine specific backgrounds and application scenarios, which is simply a hooligan.

of course, the tools and methodologies themselves are not wrong, but what is easy to be wrong is the people who use them. remember the story of dong?

He is sick and sick in it, and the ugly people in it are beautiful when they see it, and they also hold their hearts and embrace it. when the rich see it, they will not come out behind closed doors; the poor will see it and take their wives and go away. he knows the beauty, but he does not know why the jaw is beautiful.

beauty frowns, still beautiful; ugly people frown, even uglier. the same kind of behavior can be very different in different people, and the same is true for the use of tools and methodologies.

different companies, different projects, project processes, participants and the results that need to be obtained will be very different, there is no way to use "standard" and "unified" methods to solve them all? depending on the project conditions is king.

methodologically, the classic example is agile development. many teams are very much advocating agile development, because agile development is fast, efficient, short and fast, can make the rational use of resources and communicate more closely with the team. but teams that have really used agile development know how big the pit is. with that in mind, you can dedicate an article to the use of agile development in product iterations. (ps: i say that the pit is big, does not mean that it is not easy to use, but to do appropriate adaptive changes)

In terms of tools, there are too many examples, for example: product managers must use Axure, Sketch to draw prototypes, team collaboration tools must be Jira, Zen tao is the best to use, etc., here will not be described more.

i know your depth, you know my length, and the one who suits you is the best. well, i'm talking about tools and methodologies.

third, there is reference significance between different projects

i don't say this very well, but i can only describe it briefly. there can be many categories of projects: industry, user group, scale, complexity, dominant bias, and so on. seemingly completely different projects, it is likely to be the same in a certain dimension, then there is something to learn from.

to take a look at the difference between traditional and internet approaches:

mobike, ofo, has always been very popular, in fact, from the concept of public bicycles, is not completely new, n years ago many local governments have launched government public bicycles, with bus cards fixed parking points to borrow and deduct fees.

but from another concept, it is fresh, through the internet to precipitate funds, as for what the funds are used for, there are many stories that can happen~

this is still what i said at the beginning, summarizing the core and characteristics of different projects, linking different projects with the same dimension or through the same core and characteristics, and then making a breadth of reference, which has essential significance for actual work.

fourth, everyone is a project manager

according to the past, project management should be done by a dedicated project manager, but in fact, many internet companies do not have a dedicated project manager. whether it is a large company or a small company, it is composed of a project team, and different groups do what they need to do, more often, in fact, it is taken care of by colleagues in a certain position or several positions (together).

then a good question arises, who will take care of it? without him, two factors determine

attributes of the project: more technical, business or operational? complex or simple? big or small?
attributes of project members: are they more collaborative and scheduled? is the ability to be timely and powerful?

to give a relatively "complex" example:

a product iteration, lasting 1 month, the main iterations include:

add 2 new business functions and optimize 2 business functions on the mobile terminal;
ADDED 1 FUNCTION IN THE FRONT END, AND TECHNICAL RECONSTRUCTION OF A LARGE MODULE A;
ADDED 3 NEW FUNCTIONAL INTERFACES AND TECHNICAL RECONSTRUCTION OF A LARGE MODULE B IN THE BACK END;

how many project managers do you think are more suitable? i think there are at least 3:

1 mobile terminal is responsible for the management of small projects on the mobile terminal;
1 FRONT END IS RESPONSIBLE FOR THE RECONSTRUCTION OF A'S SMALL PROJECT MANAGEMENT;
1 BACKEND IS RESPONSIBLE FOR THE SMALL PROJECT MANAGEMENT OF THE RECONSTRUCTION B;

as for the overall product iteration, it may be one of the above three people, and there may be a fourth person: the product manager.

of course, in the actual situation, the above example may also be a situation where only one person holds it, but i will never advocate it.

taking the above example, i would like to illustrate a few points:

it seems that no matter how small the project is, it is possible to subdivide into small projects, and i hope that everyone can subdivide the need to subdivide as much as possible, so that more professional people can do this part of the project management, after all, even the most powerful people cannot understand all the subdivisions;
for a project, the project manager can be a group, not a group, and i recommend trying to be a group;
of course, a group of project managers will have a coordination problem, but generally there will be one person in the group to lead the management of the entire large project, if not, then there needs to be such a person;

come, shout at me:

ah ~ ~ run, someone threw rotten eggs ~

write at the back:

in fact, why do you give birth to your own knowledge graph, there are several considerations:

i need to summarize one stage after another, and i used to write more points in the form of articles instead of framework systematic knowledge. now i want to write a framework, but i feel that it is more time-consuming to write basic knowledge in the form of an article, or the map is fast and simple, and it does not need to be too entangled in wording and can be added and changed in time;
many children who are less experienced than me sometimes need a framework that can clarify a keyword to understand the overall situation, and i think there is no particularly good content on the market;
of course, i would prefer to find a few people who are willing to write a knowledge graph and contribute their own graph, whether it is product, operation or development, or even people in other industries, such as finance, etc., who can share knowledge through the graph and give others the breadth or depth of open thinking.