The author | seed

preface

background

Induction ali from double tenth a front-end PM the venue to platform project, PM for many large and small, thought is old driver, don’t want to, or on the pit under this paragraph of time to recall the some problems in this project, according to personal experience, this article has been compiled convenient and subsequent review can help people who have the same problem.

define

First, let’s briefly define what cross-team collaboration projects are: cross-team collaboration refers to the coordination and cooperation between different departments and individuals to complete an independent task with a clear goal within a specified time constraint.

Generally speaking, the process of a project can be divided into five stages: “Project launch” -> “Requirements Review” -> “Development” -> “Test (Acceptance)” -> “Release and launch”. Roles involved in the process include “PD(and Business)”, “PM”, “design”, “development” and “test”. The specific process can be seen in the figure below

Project flow chart

In project operation, from the beginning from the business or product planning, focus and a clear division of responsibilities to demand, and the role of PM in advance to the final online the whole link has played a very important link, technical PM not only need to know a rough idea of the project management process, also need to understand the business and technology solutions, can promote the smooth landing of project in the middle.

The following chapters will focus on the “initial stage of the project”, “middle stage of the project” and the end of the project after aggregation, focusing on the description of the work to be done in these three major stages and the key things to pay attention to.

The beginning of the project

1.1 KO project

When a project is launched and the filtering process finally reaches you, it is recognized by everyone at least from the strategic point of view (of course, you still need to retain your own subjective consciousness to make judgment). As PM, I need to know this project before the project is launched. Why do I do this? What is the goal? What roles might be involved? As a project PM, if I can’t figure out the first three questions by myself, there is a high probability that the project will fail. Only by sorting out the questions can I better coordinate resources and make clear goals and get the results together with other students in the project team.

In a clear understanding of these 3 problems, the first thing to do is KO project

May have KO to see in the eyes of students, as above, a project KO is very important, by KO to associated classmates together, share the project background and target consensus, and can also clear boundary division of labor and convenient milestone subsequent projects driven by the sense of ritual to thank participation students exist and recognition, What to prepare for that KO:

  • The roles involved in the project are sorted out and the person in charge of the associated domain is agreed offline, and the sub-domain interface person is defined

  • KO PPT preparation (” Background Description “, “Target Value”, “Project Introduction”, “Product Architecture”, “Technical Architecture”, “Milestone”, “Division of Personnel”, etc.)

  • A formal meeting invitation is worth every penny

1.2 Requirement Review

KO purpose is to let everybody has the first impression and consensus on this project, can let everybody understanding through requirement review project, a project needs review may have more than 2 times, the first draft of the judges, there is not all products are thinking, as a PM one of the most important in addition to understand the demand itself need to customize requirement deadline, let the demand of quick review to determine, In order to facilitate the normal operation of the subsequent process, the requirements review needs to know more details and ask more why, thinking about business beyond the identity of technology, and thinking about implementability with the identity of technology.

After the completion of the review, the most important step is to plan output according to the KO major milestone according to the time schedule, in addition to the task and priority disassembly, as well as resources, cost estimation and risk assessment. The subsequent project promotion will focus on the implementation of this time schedule.

1.3 Task Disassembly

During the requirements review is completed, need to start doing sub-domains division and task disassemble, avoid above power is a mess of problems, tasks and dismantling in project management has a similar term called “work breakdown structure (WBS), where a project, according to certain principles of decomposition, project is decomposed into tasks, task pieces into work again, Pieces to the work assigned to each person, until the decomposition does not go down, when doing project decomposition can do demand priority apart, by the way, the demand of the business or product is always a lot of things, in the actual implementation can’t do it at once perfect landing, because to do priority apart can be done in installment according to the version, Priority and dismantling can be according to the correlation functions and is a main process and project objectives and business value as the basis, and the magnitude of the task disassemble to fine as far as possible avoid because too thick lead to inadequate assessment and neglect the problem affects the whole project schedule, task apart we can according to the subdomain and the project of the function modules to disassemble, such a comparison, After the task is disassembled, it can be managed by tools such as gantt chart.

In addition, in actual projects, due to the large number of personnel involved, most tasks are dismantled by the sub-domain leader, so it is very important to clarify roles and division of responsibilities. Unclear role definition is also a major factor that often affects the implementation of our projects.

1.4 Technical Review

Any project technical review is an essential part of, the demand and task after dismantling, multi-zone do technical review on upstream and downstream rely on formal review, can be found in the task split or demand review does not take into account the details, in the early risk will kill in the bud, in the technical cost estimate must add buffer time, The buffer time can be multiplied by 0.3 as a coefficient based on previous experience, because the scheme review cannot consider all the details at one time, do not include your own overtime hours, which is already a project risk.

What is required for technical review?

  • Business Flow chart (business perspective of the processes and user operations in your domain)

  • Technical framework (architecture or layering to understand your domain and surrounding dependencies)

  • The project design

  • Mission disassembly & Timeline

  • Upstream and downstream dependence & Risk

The interim

2.1 Communication

Communication in project management is one of the most important link, after the start of the biggest obstacles in communication, a complete project will be broken down into many sub domains, there will be dependent on each subdomain, probably because in dealing with the information and communication is not timely or understanding deviation, the issues that led to the design how to put these people together project chamber is a more effective solution, The project room can be used to maintain effective communication with project members during the project execution process to ensure consistency in project design and understanding.

Set up the mechanism of weeks and days will, according to the different stages of project running, at the beginning of the development of runtime can through the way of weeks, one week synchronization under the current progress and risk as well as the key plan next week, ensure timely execution of the project, run to the middle and later will need to start day mechanism, strengthen communication, convenient risk and synchronization problems in time, the main content of the meeting can be as follows:

  1. Main thing to do today & overall progress

  2. Whether there are risks and dependencies

  3. Tomorrow’s plan

  4. Yesterday risk whether exposure

2.2 Risk control

Early needs to understand the main source of risk, such as inconsistent, unreasonable project plan or requirements change and so on, can’t completely avoid risk, but we can through the historical experience or project management to early discovery, minimize risk, the project is at the core of this part, the size of the risks and exposure of will directly affect the success or failure of the project, Therefore, it is necessary to maintain sufficient acuity for the problems exposed in the project, follow Murphy’s Law, and strengthen communication, management and communication to maintain the effectiveness of information acquisition.

A project

3.1 Test questions advance

To the last stage of finishing a project, the biggest problem is the issue of the question of whether fix and test coverage is complete, the repair could be exposed for each new problem, the problem of repair earlier, will tend to take a test and project, so in the development of China unicom mention before need to start the test cases of carding and review, to ensure that the process of test coverage, Attention should be paid to problem progression and repair after the start of testing, and try to ensure that problems become clearer.

3.2 Project Acceptance

The last link of the project is acceptance, acceptance of the two way points, and a rehearsal for group meeting, another to promote products (business) and visual inspection (walkthroughs), the first is easier to understand, that is to apply for a formal meeting to draw the related project team members and business students to do preview function, to ensure that products and business understanding as well as the function is perfect, The second kind is checked by product, business and design students in their own domains to ensure the consistency of visual restoration, product logic and product copywriting.

In addition, the most important point is that if the project plan involves the alternation of new and old versions, it must take into account the compatibility of the two and the impact on users as well as the plan to avoid affecting users. If it is a block change, it needs to ensure sufficient stability, with users as the first priority

Common misconceptions about

  • Excessive pessimism or optimism: both are based on insufficient control of the project, which will lead to misjudgment of the project. Excessive pessimism will affect the enthusiasm of students in the project team, and on the contrary, will lead to risk exposure in the later stage.

  • Ignore details: Namely, Murphy’s law, anything that is likely to go wrong or has a small probability of going wrong will go wrong. When problems are found in review, it is necessary to go into details to understand and promote, so as to avoid problems being exposed online.

  • Information fault: There are many people involved in cross-team projects, and the information you get may be wrong or missing because different students have different judgment and thinking ways in information transmission. You need to ask more questions and learn more.

  • Incomplete consideration: Everyone has his own original role when leaving the project PM, such as front-end and certain platform development. As a result, he will subconsciously look at the current domain and lose other aspects. As a project PM, he needs to put aside his own identity and think in a broader domain.

  • Dare not make a choice: after the project is started, the project needs to make a choice because of various external factors. In view of the clear project objectives and plans, we need to understand the nature of the requirements and dare to say no.

  • Loose at the beginning and tight at the end: Unreasonable planning will lead to the project falling into this state, resulting in too many problems during testing, poor quality of self-testing in development, etc

Q&A

The following questions are mainly personal opinions and not necessarily best practices.

5.1 How to advance if upstream and downstream do not cooperate?

  • Transposition: Everyone and each Team have their own planned things. When we transposition to understand the current planning and direction of the Team we rely on, whether there are other partners with the same direction around us, we can better enter into the promotion and cooperation

  • Altruism & mutual benefit: this two word can synthesize a prerequisite to do one thing must be everybody direction consistent aim, in this way can the long-term normal operations, altruism alone can form the good operation mode, throw butt consciousness is particularly important to avoid short-term interests, find another upstream and downstream for help in the former must want to know in advance what does he want? What can I offer? I am not sure if I am looking for the right person and doing the right thing

  • Taking advantage of the situation: it can be divided into two situations. First, it is bound to the direction and goal of the current big team or group and moves forward with the big background. Second, seek help upward, personal strength and can mobilize resources are always limited, to learn to seek help upward management

5.2 How to control project risks well?

  • Prior to the start of the project: risk tends to occur in the perspective of no concern to you or dependent on upstream and downstream parts, and the scheme of a complex project involving will more, different domain solution is not the same as a person’s energy always limited, this case open domain reduction with clear division of responsibilities and interfaces is particularly important, good segmentation domain subdomain classmates out responsibility;
  • In the project: “Communication” is the core of collaborative project management. Keep information communication with the person in charge of the sub-domain, focus on progress and risks regularly (daily and weekly meetings, etc.), so as to find problems in advance. In addition, avoid limiting yourself to your own domain, and better understand the details and technical solutions. In program evaluation, I can control the timing buffer freely, discover risks in advance and promote solutions;
  • When the project is launched: As the last link of the project, many problems are mainly caused by the neglect of the occasional difficult troubleshooting problems and the failure to consider the emergency plan. In accordance with Murphy’s law, the problems you do not care about may become the last straw that will overwhelm the project. Before going online, prepare the check list and plan manual

conclusion

Any thing or project can not be guaranteed by a single document, or need more precipitation, accumulation and follow-up, do more to follow closely to ensure that there is no problem and precipitation of their own methodology, it is up to the human.

Author’s team: ali tao front-end team marketing activities, the leading group very large double 11 world carnival marketing activities, responsible for department of electricity every year thousands of field marketing activities, and support the system structures, technology products, the service thousand level operation, all businesses, consumer, offer silky smooth online shopping browsing experience.

Welcome people with lofty ideals to join, resume delivery [email protected] note [resume]