E-commerce projects often have the characteristics of Wolf, and the project managers licking blood on the tip of the knife need to quickly precipitate some agreements and rules in the complex practice, to bring some positive energy to the team.
In the Koala mobile project, we learned from the mistakes we made, and through constant polishing, the team gradually formed some agreements that led to some positive changes. Some agreements are established systems or templates, while others are just oral agreements, passed on by word of mouth. In order to avoid the oblivion of these precious treasures, consolidate the effect of positive changes, and facilitate the understanding of all colleagues, we hereby summarize some agreements in the Kaola mobile terminal project (there are many regular basic agreement norms in actual work, such as: defect cleaning, smoke test, interface test, etc.).
Principles are reviewed and adjusted regularly, tend to take small steps, product development and testing, and project manager cooperation, simple and sincere.
Values focus on face-to-face communication, solve problems according to the situation, and respond positively.
1. Size requirement review
Small review, as far as possible point to point communication, relevant three or five people negotiate to agree on the review date and form. The purpose of the grand review, the final requirements confirmation meeting, is to communicate the global information to all project team members. After the confirmation of the large review, the demand review window closes and demand freezes.
Requirements review window period. As confirmed by the review committee, the date of completion of defect cleaning of each version will be the Open Day of the requirements review window of the next version. In special cases, if the current version needs to be solved immediately, it is a requirement change. Please apply to the mobile terminal Review Committee for confirmation, and only after the confirmation is ok, can the requirements review be initiated.
2. The interactive draft shall be updated and noted with the update record
Make face-to-face interviews and email to all mobile project members.
Updates are recorded on the front page of the document.
3. Demand freezing system
Demand freeze will be entered after confirmation of demand review. After the defect cleaning is completed, the demand review window period will be entered and the demand freeze will be ended.
In order to deliver faster, requirements cannot be changed endlessly in an iteration. Appropriate freezing is required to meet rapid delivery requirements, leaving room for rapid response to new changes in the next iteration.
Requirements freeze refers to a requirement freeze that affects iteration delivery, etc. It is not a refusal to embrace change, but a decision for the team itself. For example, inordinate and undisciplined demand spread and demand change should be prohibited. For example, in the process of iteration, demand change is caused by external emergencies, especially laws and regulations and other policy factors, the team can evaluate by itself and try to embrace such changes to reduce risks.
4. Emergency task application specification
Mobile terminal review committee one vote veto system.
Emergency task request specification. Email title: [Mobile terminal Urgent Task application] [ios+ Android] Task title. Indicate applicant, reason for application, JIRA address, expected online date, source of demand, etc.
An email response format that contains but is not limited to the following content. Development evaluation conclusion email, development time, development impact scope, risk, development conclusion. Test evaluation conclusion email, test time, test scope, test risk, test conclusion.
5. Technical director system
For large function points or key requirements, and any other reasons that require special concern, a colleague will be appointed as the technical lead for that function point or requirement by self-application or team consultation. This can be development or testing. Make it clear in the project scheduling meeting.
Responsible for receiving product colleagues’ information updates, synchronizing information to all ends of the team (ios, Android, background, front-end), collecting feedback as needed and informing product colleagues. If the requirements are changed, it is necessary to supervise the relevant responsibility to issue the change application.
The technical leader has the right to inquire about the progress, coordinate the schedule of the team under his charge, and team members should try their best to cooperate.
The technical owner has an obligation to be aware of risks and transparent about progress.
Technical leader benefits, can apply for project management preliminary knowledge training, etc.
6. Project timeline
It should include key review time point, visual supply time point, externally dependent task time point, raising and testing time point, online time, gray time, freezing time, channel package supply time, etc.
7. Postponement should be communicated in person and notified by email
If a task is expected to be tested later than the agreed time, it is necessary to communicate in person and send an email explaining the delay to all mobile project team members.
Responsible person for delayed mail delivery. Demand changes, inserts, etc., will be known by product colleagues via email; If the development time assessment is wrong and the actual delay is notified by the development colleague via email; If the test time estimate is incorrect and the actual delay is notified by the test colleague via email.
8. Changes to the project need to be applied and sent to the public via email
Changes should be requested by email to the review committee. Only after passing the review by the review committee can the project be started and the email will be sent to all members of the mobile terminal project team. It is strictly forbidden to take private work beyond the review committee.
If other tasks are delayed, it is also necessary to postpone processing.
9. Code freeze
Generally, the date when the server goes online is the date when the client code freezes.
Freeze the code, the code to branch ready for release, but not completely stop the code update. Allow for carefully controlled bug fixes, etc.
It is important to note that the code freeze period, in principle, forbids the creation of any new requirements or development tasks that tweak any feature points.
10. Inform the Marketing Department of the time to provide installation packages for each channel ten days in advance
11. Project review meeting, grouping station meeting and mobile terminal team leader meeting
Borrow “southern Jiangxi township covenant” in the words, and your mutual encouragement. Don’t forget to date!
“Adversity, good exhortation, evil admonishment, litigation stop, speak faith and harmony, good affairs of the people, together into a kind and generous customs. Alas! Although people to fool, responsible people are clear; Though he be wise, he be dim when he blame himself. The old father’s children do not read the old evil of the new people and not with its good, he read and good, that is, the good man; Do not rely on the good people and do not cultivate their body, you read and evil, that is, the wicked; Man’s good and evil, due to a thought between.”
— “Southern Jiangxi Township Covenant”
Author: Guangchuan Lv, CSM, PMP certification, TiD conference lecturer. He used to work for IFlytek of USTC and is now a senior project manager of netease. He has served xiupin, Yinpai, Yanxuan, Kaola.com, Netease Literature and Comics and other products, keeping the loyal and reliable character of veterans and paying attention to the healthy and sustainable development of the team and products. One of the main authors of One Thousand and One Nights of netease.