電商的專案往往具有狼性的特性，而在刀尖上舔血的專案經理們需要錯綜複雜的實踐中快速沉澱一些約定、制度，給團隊帶來一些積極的能量。
在考拉移動端專案中，我們吃一塹長一智，通過不斷地打磨，團隊逐步形成了一些約定，帶來了一些積極的改變。有些約定已經形成制度或模板，而有些還只是口頭約定，口口相傳。為避免這些寶貴財富湮沒，鞏固積極改變的效果，也方便所有同事知悉瞭解，特此彙總考拉移動端專案中的一些約定（實際工作中還有許多常規性基礎的約定規範就不一一列入了，如：缺陷大掃除、冒煙測試、介面測試等）。
原則定期反思並調整，傾向於小步快跑，產品開發測試及專案經理合作共贏，簡單真誠。
價值觀注重當面溝通，就事論事解決問題，正向積極應對。
1. 大小需求評審
小評審，儘可能點對點溝通，相關的三五人協商約定評審日期及形式。大評審，最終需求確認會，意義在於將全域性資訊傳遞到全體專案組成員。大評審確認會後，需求評審視窗期關閉進入需求凍結。
需求評審視窗期。經評審委員會確認，以每個版本的缺陷大掃除完成日為下一版本需求評審視窗期開放日。特殊情況需當下版本立即解決響應的屬需求變更，請先向移動端評審委員會發起申請確認，確認ok後方可發起需求評審。
2. 互動稿更新周知並註明更新記錄
相關人當面約談並郵件周知所有移動端專案組成員。
文件首頁標註更新記錄。
3. 需求凍結制度
需求大評審確認會後進入需求凍結。待缺陷大掃除完成後進入需求評審視窗期，結束需求凍結。
為了更快速完成交付，在一個迭代期內需求不可能無休無止的改來改去。需要適當凍結以滿足快速交付的要求，為下次迭代中快速響應新變化留有餘地。
需求凍結指的是影響到迭代交付等的需求凍結，並不是拒絕擁抱變化，具體需要團隊自身去評判。例如無節制無節操的需求蔓延需求變更則需禁止，再例如，迭代進行中因外界突發情況特別是法律法規等政策因素導致需求變更，則可團隊自身評估，儘量去擁抱這個變化降低風險。
4. 緊急任務申請規範
移動端評審委員會一票否決制。
緊急任務申請規範。郵件標題：【移動端緊急任務申請】【ios+android】任務標題。註明申請人、申請原因、jira地址、希望上線時間、需求來源等。
郵件回覆格式，包含以下內容但不侷限於以下內容。開發評估結論郵件，開發用時、開發影響範圍、風險、開發結論。測試評估結論郵件，測試時間、測試範圍、測試風險、測試結論。
5. 技術負責人制度
針對大塊功能點或重點需求，及其他任何需要特殊關切的原因，由自主申請或團隊協商任命一名同事擔任該功能點或需求的技術負責人。可以是開發也可以是測試。在專案排期會中明確公示。
負責接收產品同事資訊更新，並向所轄團隊各端（ios、安卓、後臺、前端）同步資訊並按需收集反饋，告知產品同事。如涉及需求變更則需監督相關責任發出變更申請。
技術負責人有權力詢問進展，協調所轄團隊進度安排，團隊成員需盡力配合。
技術負責人有義務周知風險，透明進展情況。
技術負責人福利，可按需申請專案管理初步知識培訓等。
6. 專案時間軸
需包含關鍵評審時間點、視覺提供時間點、外部依賴任務時間約定、提測時間點、上線時間、灰度時間、凍結時間、渠道包提供時間等。
7. 延期需當面溝通併發郵件周知
如已預計某項任務會晚於約定時間提測，需當面溝通，併傳送延期說明郵件周知所有移動端專案組成員。
延期郵件傳送責任人。需求變更、插單等，由產品同事郵件周知；開發時間評估有誤實際延遲的，由開發同事郵件周知；測試時間評估有誤實際延遲的，由測試同事郵件周知。
8. 專案變更需申請，通過後郵件周知
變更需向評審委員會發起郵件申請。評審委員會稽核通過方可開工並郵件周知所有移動端專案組成員，嚴禁越過評審委員會接私活。
如造成其他任務延誤，也需走延期處理。
9. 程式碼凍結制度
一般伺服器上線日為客戶端程式碼凍結開始日。
凍結程式碼，程式碼另起分支準備發版之用，但並不是完全就停止程式碼更新。允許謹慎可控的缺陷修復等。
需特別強調的一點是，程式碼凍結期，原則上講是禁止新增任何需求或者任何調整功能點的開發任務的。
10. 提前十天再次知會市場部各渠道安裝包提供時間
11. 專案回顧會，分組站會及移動端組長以上各方站會
借用《南贛鄉約》裡的話，與君共勉。勿忘相約！
“患難相恤，善相勸勉，惡相告戒，息訟罷爭，講信修睦，務為良善之民，共成仁厚之俗。嗚呼！人雖至愚，責人則明；雖有聰明，責己則昏。爾等父老子弟毋念新民之舊惡而不與其善，彼一念而善，即善人矣；毋自恃為良民而不修其身，爾一念而惡，即惡人矣；人之善惡，由於一念之間。 ”
—— 《南贛鄉約》
作者：呂廣川，CSM、PMP認證，TiD大會講師。曾任職科大訊飛，現為網易資深專案經理，先後服務於網易秀品、印像派、嚴選、網易考拉海購、網易文學漫畫等產品，保持退伍軍人靠譜忠誠的本色，關注團隊及產品的健康可持續發展。《網易一千零一夜》主要作者之一。