This article from the flying pigs front-end @ 9 屻 classmate (also called the elder brother of the dog), deep side of business development for many years, there is a profound PM in the project experience, give new classmate combed the pig flies that the front-end PM handbook, borrow the flying pigs front-end team WeChat public share to the development of the front-end students, looking forward to can give you guys some ali some input in the process of project control, communicate welcome!

Front-end PM anti-DISS guide

Guide from start flying pigs front-end business project has been more than a year, under the large and small needs the baptism from think well control of front end demand degree, but when received individual demand or there will be some not in control, complicated feeling, afraid of missing the docking or review, some should do also encountered some problems outside the condition, There will be “ambiguous” multiple choice questions, especially for people like me who are more conflicted, such as:

• We’ve seen so many similar scenes, why don’t we just skip them?
• It has been made clear in the requirements review, and the demand is not large, so do we still need to do the technical review? Can we directly arrange the schedule?
• Technical review If a student did not attend the meeting, I do not directly rely on him, is it ok not to come?
• This function point is not finished by the scheduled time, just push the progress, okay?
• Should I send the weekly project report? It seems that I can do without it?
• .

Is there a “to do” list to check when you’re anxious about missing something? Is there a “guide” to learn when it comes to problems outside the situation? When faced with the above multiple choice questions, is there any previous experience to help you make decisions? What are the unchanging conclusions and what are the considerations that need to be adapted to local conditions? What is the criterion? In fact, the existing definition of technical PM already contains the answer: • Technology: provide technical solutions to solve the usability and ease of use of products, while ensuring technical robustness and system, responsible for user experience and effective implementation process. PM: ensure that members of the Task clear understanding, border and clear, the time limit for a project expected, organized for landing, mobilize resources, dissolve the risk, is responsible for the quality of deliverables “Definition”, however, are usually abstract and representational to guide realistic scenario for what should we do, where to have a clear answer, even experience? In order to prevent myself from falling into these problems in the future, I summarized a front-end PM Manual based on my previous experience and lessons as well as existing Alibaba business projects. If you are a partner of other business lines, you can substitute your own business and tools for reading. I hope this manual will be of some help to me and other students in the future work, and also hope to inspire students in other business lines. I welcome your criticism and correction.

Requirement review

Preparation before review

Ability to prepare

• Familiar with the corresponding business, have their own sense of business, clear business scope and boundary
• Proficient in common business tools: such as dependent building platform, business logic processing tools (circle specific people, select the appropriate products), template building tools; Algorithm rule configuration and so on
• Familiar with daily tools of the project: requirement cycle management platform, data buried point platform, ABTest tool, gameplay activity platform, etc

Communicate product intentions with PD in advance (PD will usually communicate with the lead developer before initiating the review)

• For scenarios that are not solved by the general capability, make clear comments and suggest PD to re-examine requirements and resources
• For those who are not familiar with the current business operation tools and implementation process, it is necessary to popularize science
• For PD who is not familiar with the project history (referring to the updating iteration of the existing project), it is necessary to popularize science and provide their own insights
• Comment on repeated experimental changes that have been made in the past but have not worked as well, especially if the background is not very different from the goal
• We should fully listen to PD’s change background, design ideas and product expectations, and give our own suggestions or opinions (in technology or business) based on the proposed intentions, so as to have certain input to PD and business
• If you are not familiar with PD and need to involve resources, you should timely give the person in charge, scope or direction, so that PD can have a general sense of body

Communication after the work

• Read the PRD carefully and get a clear sense of what capabilities are used in each module
• The required business objectives must be clear and reasonable, and the input-output is too low and the objectives are vague, which need to be fed back to PD for reconsideration
• Keep up with the information when it comes to areas you are not familiar with

  • For example: This activity page needs to use the seckill function, do you know the corresponding activity gameplay system?
  • For example: this time there is the investment of commodities into, investment process, investment of commodities and the difference between ordinary goods do you understand?
• Do not cover the requirements within the business scope of their own understanding, to timely communicate with the boss business scope and boundary, and then feedback to PD
• If a functional change is involved and the developers are not clear about it, consult them in time to prevent them from missing during the review
• New technology, new tools to challenge, to timely technology reserves

Requirements Review invitation

• The requirements review meeting invitation is sent by PD, and PM needs to check whether all necessary personnel are included in the meeting and whether necessary personnel can attend on time
• If PD does not have a project nail group, it needs to pull the nail group. PD is responsible for explaining the requirement background, etc., and the PRD address of the requirement needs to be put into the group announcement
• If PD does not communicate the requirements in advance, if there is any doubt after reading the PRD carefully, decide whether to communicate with PD immediately according to the impact on the project

  • For business boundaries, resource priorities, and so on
    Issues that directly affect the development of the project, we need to communicate with PD immediately, and PD needs to clarify boundaries and coordinate resources
  • Part of the moduleIssues such as technical infeasibility and current tools can not be undertaken can be discussed during the review

review

Requirements review meeting

• Make sure all necessary personnel are present
• The business objectives of the requirements must be clear, reasonable and quantifiable

  • For example, in this issue, we will focus on the click-through rate. We need to determine how much the click-through rate has reached over a period of time and how much it has increased over a period of time
• The key point of requirements review is to evaluate the rationality of requirements, subject to the approval of the relevant parties, there is no need to discuss too much in technical details, such problems can be recorded and determined in the technical review

  • For example, the question of whether a certain commodity field can be obtained can be recorded first as long as it is not the field of special concern in this issue, because it may be that the interactive draft is just a schematic diagram, which can be confirmed during UI review and determined during technical review
• The need points must be completely clear, not taken for granted, the solution must be identified by all parties and the feasibility of the solution must be confirmed
• If the requirements are reviewed using interactive drafts, it is necessary to pay attention to the interaction problems at the front end and raise them during the requirements review to avoid slowing down the UED progress
• ** There are requirements for modules identified after discussion, or special module requirements, which need to be documented **

  • For example: the countdown requirement of seckill module, whether it is the time point to fill in the countdown or the interface to read the activity, what content to update the module after the end of the countdown, and how to deal with the exception. The consensus formed after communication on products, operations and technologies must be recorded
• For points that need to be confirmed after the meeting, make a note of the question, the person to be appointed, and when will it be confirmedAfter confirmation, give feedback (in UI review or group)
• Determine the timing of subsequent UI reviews, except when resources are uncertain

After the requirements review meeting

• Send the recorded conclusions and questions in the form of an email in the form of minutes of the meeting to be synchronized to the comments of the nailing group and the PRD, and ask for immediate feedback when in doubt. For items that must be concluded by a certain point in time for a certain person, be sure to label the problem, the person and the time
• If there is no reply to the confirmed deadline, contact the person in charge of the problem to confirm the progress and inform all parties of the progress

The UI reviews

Preparation before review

Preview design draft

• Preview the design draft, which focuses on common problem points

  • Titlebar is normal or alien and currently supported
  • Whether the current technology stack is unavailable with special typography
  • Each card field value source
• Significant differences between the module and the required design should be recorded and presented during the review

UI Review Invitation

• Requirements review meeting invitations are sent by PD or UED. PM needs to check whether all necessary personnel are included in the meeting and whether necessary personnel can attend on time
• UI draft address needs to be put into the program announcement

review

UI Review Meeting

• Make sure all necessary personnel are present
• Requirements review items to be confirmed synchronization

  • All pending requirements must be confirmed at this time
• If the modules differ greatly from the required design, it is necessary to communicate with PD and relevant parties for confirmation and record
• The design draft interaction, layout is unreasonable or can not be realized, or the realization of high cost but low business efficiency needs to communicate, and the final result recorded
• The review of UI draft should be accurate to the fields of commodities or content, especially when it involves unusual fields, we must pay attention to it. We need to communicate with the students of the server side at the meeting to determine whether it can be obtained. If it is uncertain, we need to record the person in charge of the follow-up and the time point of the problem
• You need to be able to understand who the backend, algorithm, and other developers are for each moduleThe absence of the developer’s dependent party needs to be documented to ensure that no relevant party is omitted from the technical review
• In the meeting, except for the pure interaction and typesetting that cannot be confirmed, other matters need to be determined. For the simple UI problem, when should the person in charge and the time point be confirmed should be recorded before the technical review

After the UI review meeting

• Send the recorded conclusions and questions in the form of an email in the form of minutes of the meeting to be synchronized to the comments of the nailing group and the PRD, and ask for immediate feedback when in doubt. For items that must be concluded by a certain point in time for a certain person, be sure to label the problem, the person and the time
• If there is no reply to the confirmed deadline, contact the person in charge of the problem to confirm the progress and inform all parties of the progress

Technology review

Preparation before review

Psychological preparation

• Are the parties who need to be present clear and clear
• PM must know your development and business positions

  • Such as: A typical sales promotion page, commodity pools is who provides (or operation), commodity field who will complement (server or algorithm to calculate output values), what was on the way (operating configuration entry or personalized algorithm), what is the way of production or operating configuration (algorithm), what are the entry case, Each entry shows which fields are required
• Whether the requirements and UI are well understood, and whether the function points that each module needs to communicate are already in mind
• Whether all the pending matters left over in the early stage have definite results
• What are the key issues and what are the passing points

  • The common function point is secondary, and the new function point is primary
  • Simple modules are secondary, complex modules are primary
  • Modules that are self-sufficient by a single developer are secondary, while modules that are implemented by multiple partners are primary
• The main purpose of the technical review is not to schedule, but to exchange information, determine technical solutions, clarify the boundaries between developers and the way to cooperate

Invitation for Technical Review

• Requirements review meeting invitations are issued by the TECHNICAL PM, who needs to check whether all necessary personnel are included and whether necessary personnel can attend on time

review

• All developers & testers &PD must be presentIf necessary, the operation student must also be present
• Review with reference to UI visual draft module by module
• Who provides each field of each module and how to achieve it

  • For some special fields, need to copy record value logic, who to achieve, how to achieve the need to remember clearly
• For function points that have not been touched before, technical solutions need to be documented
• For modules that require multi-party cooperation

  • The parties need to reach a consensus on the technical solution, to explore the specific implementation process, there is no ambiguity for granted

    • For example, who will give the data to the data dependent party, where the data comes from and in what way will the data be given to the dependent party, whether it is event notification, SQL or offline table, what is the requirement of real-time data and what is the requirement of stability
  • It needs to be clear what each developer is responsible for, what they provide, and who is upstream and downstream
• For boundary issues that are difficult for all parties to make decisions on, leaders of relevant parties shall be called upon to confirm boundary demarcation in a timely manner
• After clear communication of the scheme of each module, negotiate the schedule

  • For general requirements, if the backend needs to provide function coordination, the time points to be confirmed are in the positive order of the timeline:

    • Kickoff time
    • Data protocols of the front and back ends
    • Back-end mock data is provided
    • Real data is provided in the back end
    • Time adjustment of front and rear ends
    • To measure time
    • Acceptance time
    • Online time
  • For general construction requirements, the time points to be confirmed are in the positive order of the timeline:

    • Kickoff time
    • Module creation time
    • Operation classmate product pool creation time
    • Run the event of completing the configuration of the student data release platform
    • To measure time
    • Acceptance time
    • Online time
  • There are also dependent changes in the backend. In addition to the necessary time points for general requirements, it needs to be clear when each dependency can provide data or capability, and it must meet the development schedule of the dependent party
• There needs to be a clear development schedule after the meeting

Project progress tracking

Project start

Do you need Kickoff mail

• Kickoff mail is required for all projects except daily iterations

Kickoff email content

• Basic elements: project background, project objectives, project pace, project members, project data
• The scope of the project and the development content shall be clearly stated. The subsequent development scope shall be subject to this criterion, and any change outside the scope shall be considered as demand change
• Email recipients should be all project members, and cc should be sent to the supervisors of the main relevant parties (PD, operation, UED, front and back end, algorithm, and test) + project members of their own team. For important projects, CC should be sent to the leaders of each team or BU that promotes the project

Project weekly and daily report

Whether the project weekly or daily report is required

• Weekly project reporting is encouraged in principle
• Important or special projects (e.g., projects involving multiple stakeholders, across teams or even across BU; If there are many relevant parties and information is difficult to synchronize), it must be known in daily newspapers
• For daily iterations within two weeks of development, there may not be a weekly or daily project report, but it is necessary to monitor each developer’s progress on a daily basis
• For daily iteration projects within two weeks of development, if the development schedule is blocked due to non-resource issues and the project is not tested on time, it is necessary to have a project daily report to inform the progress
• Projects other than the above types require weekly project reports

Contents of weekly and daily reports

• Work progress of this week/day: specific to each item and the person in charge corresponding to the item
• Overall progress: Identify the progress percentage and outline the functionality currently completed
• Problems & Risks

  • Problem: Unresolved problem found this week/day but with a solution
  • Risks: Items that may affect the content or schedule of the project should be flagged in red
  • Uncontrollable risks: Basically determine the items that affect the project content or schedule, and put them on the top with red warning
• Next week/tomorrow’s work arrangement: specific to each item and the person in charge corresponding to the item

Risk & Delay

• The risk must be synchronized with PD as soon as possible
• For uncontrollable risks, immediately pull PD and relevant developer meetings to communicate solutions
• Resource input problem

  • The function of the input and output low point, give priority to have alternative or remove the feature (for example: a field value logic of commodity card problem, according to the predetermined logic need to involve multiple changes, whether can use other values instead of existing), needs and PD, development, testing, agree, send the inform to demand changes
  • It can be solved by replenishing manpower

    • PM mobilizes and coordinates project members, and organizes overtime work. If overtime work is required, there should be overtime mail, such as daily mail
    • If the relevant developer team has spare manpower, the developer can communicate and coordinate within the team
    • If it cannot be coordinated, PD will coordinate human resources
  • If it cannot be solved, consider whether there is an alternative to the requirements, and reach an agreement with PD, development and testing, and send a requirement change notification
  • If a function is delayed but the priority of the function is not high, consider whether the requirements can be divided into the second phase. It is necessary to reach an agreement with PD, development and testing, and send a notice of requirement change
  • None of the above is feasible. Considering the project delay, the delay should be agreed with PD, development and test, and the project delay notice should be sent
• Function realization problem

  • For function points with low input and output, the priority should be given to whether there is an alternative or even ignore the function. The agreement should be reached with PD, development and test, and notification of requirement changes should be sent
  • There is a technical implementation plan, but the implementation requires the participation of the established member students, PM and PD to coordinate manpower or PD to specify sub-requirements, PM and related development students to confirm the feasibility of the technical plan
  • If it cannot be solved, consider whether there is an alternative to the requirements, and reach an agreement with PD, development and testing, and send a requirement change notification
  • There is no alternative and it cannot be implemented. Considering removing this function, we need to reach an agreement with PD, development and testing, and send notification of requirement changes

Mention test specification

Check email content

• Basic elements: functional completion, self-test completed, test package (if required), offline package (if required), page address, QR code, project information
• If there is any requirement change in the middle, it should be reminded emphatically in the testing email
• Special requirements for the test content should be indicated in the test email
• If there are special requirements for the test method, the address of the test method document should be indicated in the test submitting email

Release the premise

• It has to pass the tests
• The business party must pass the acceptance

Things to do after release

Monitoring & Performance

• Monitor the stability indicators of the platform
• Pay attention to whether there is public opinion feedback
• Collect performance data, and compare the performance changes before and after the new version

Whether Release mail is required

• Any project that has a Kickoff, you need a Release

Release Email Content

• Completion of business objectives, analysis of business data to explain their own understanding

  • For example, if a module has a significant increase in click-through rate, analyze whether the decrease in exposure caused the increase or the real click-through rate
• Online performance display

  • Online page display
  • Revision project, compare the old and new version page
• Summary of technical Achievements
• The email recipient is the Kickoff email recipient

Last but not least

Above is the “front-end PM anti-DISS guide” all content, is also a microcosm of the project development process in the flying pig side, if there is no clear place, welcome to comment communication, also welcome to point out the wrong place ~

At present, we have a lot of construction in Serverless, micro front-end operation bench, end rendering, interactive marketing, recruitment, selection, investment, intelligence, experience technology and data measurement. We welcome students with ability to come in and create business value with technology. If you want to bring students to direct a direction, it is ok. Welcome to follow the wechat public account to contact!

This article was typeset using MDNICE