作為常年跟軟件團隊打交道的產(chǎn)品人我見過太多“需求管理”最后變成“需求事故”的例子。項目做到一半才發(fā)現(xiàn)需求對不上、開發(fā)做完的功能被業(yè)務說“根本不是我要的”、同一個需求被不同部門反復提了三四遍……這些問題往往不是某個人的能力問題而是需求承載的容器出了問題。今天聊聊我一直在用的思路把需求管理做成“產(chǎn)品待辦列表管理化”——也就是讓所有需求都進入一條統(tǒng)一、透明、可排序、可持續(xù)維護的待辦隊列讓需求不再靠腦子記、靠嘴傳而是靠一套流動的管理機制來承載。這條思路適合誰適合正在從“文檔驅(qū)動”過渡到“敏捷節(jié)奏”的研發(fā)團隊適合需求雜亂無章的產(chǎn)品經(jīng)理、項目經(jīng)理也適合想讓自己接手的項目更可控、更抗變更的團隊負責人。它不要求你引入多復雜的體系只要求你把“需求”當成“待辦”來管并且堅持下來。下面我把這套方法從底層邏輯到實操步驟再到踩坑經(jīng)驗完整拆給你看。1. 為什么需求管理會亂以及待辦列表為什么能救場1.1 傳統(tǒng)需求管理的三個坑我們先說痛點別急著上方法論。第一個坑是文檔式管理。很多團隊習慣在項目啟動時寫一份幾十頁的《需求規(guī)格說明書》寫完后丟給開發(fā)然后大家默認“按文檔做”。問題是文檔是靜態(tài)的需求卻一直在變。文檔里第3章第2節(jié)寫著“支持導出Excel”實際業(yè)務場景已經(jīng)變成“支持導出PDF且包含圖表”但文檔沒人更新開發(fā)就照著舊文檔做了。等測試提bug產(chǎn)品才一拍大腿說“忘了改文檔”。產(chǎn)品待辦列表的好處是需求不是一次性交付物而是持續(xù)維護的條目每條都有狀態(tài)和負責人變更時會直接反映在待辦條目上不需要靠維護一個巨型文檔來同步。第二個坑是傳話筒式管理。需求散落在各個地方微信群里老板發(fā)的一句話、客戶電話里的臨時反饋、測試人員在評審會上提出的疑問……這些需求如果不進同一個池子就會在口口相傳中失真。A同事聽到“做一個篩選”B同事聽到“做一個高級篩選”最后開發(fā)實現(xiàn)的是普通篩選誰都沒錯但需求被傳歪了。待辦列表解決的是“單一事實源”問題任何來源的需求都先落到隊列里經(jīng)過結(jié)構(gòu)化描述后再進入評估失真的可能性被壓到最低。第三個坑是重復造輪子式管理。一個平臺不同業(yè)務線都在提“用戶權(quán)限管理”的需求但因為各自為戰(zhàn)根本不知道別人已經(jīng)在做了。以至于同樣的功能被開發(fā)了兩遍測試還要維護兩套用例。待辦列表強制所有需求在同一個池子里可見大家排需求優(yōu)先級之前先去列表里搜一下有沒有類似條目避免重復建設。1.2 待辦列表是一條流動的需求河不是靜態(tài)的文檔堆很多沒接觸過敏捷的同學會把“產(chǎn)品待辦列表”誤解成“一個記錄需求的Excel表”確實形式上可能就是個表但本質(zhì)上它是一個動態(tài)隊列有來源、有流向、有出口。我習慣把它比喻成一條河流。上游是需求收集什么都往里面倒但下游有篩選網(wǎng)優(yōu)先級排序、有分流迭代計劃、有沉淀池暫緩或歸檔。河流是流動的所以需求不能像文檔一樣不斷往抽屜里塞而是要持續(xù)被評估、被排序、被消耗。產(chǎn)品待辦列表Product Backlog在敏捷框架里是唯一的需求來源它里面的條目通常叫“用戶故事”或“PBI”Product Backlog Item它不一定要求每條都寫得盡善盡美但一定要保證“堆頂”的條目即將進入迭代的條目足夠清晰。這也引出了核心思想漸進明細。需求不需要在一開始就死摳細節(jié)而是隨著臨近開發(fā)逐漸細化。這能節(jié)省大量前期文檔工作也不會扼殺需求在探索期該有的彈性。為什么這個思路能有效我認為有三個原因第一可視化讓一切問題無處藏身需求不再藏在某人的電腦里第二優(yōu)先級排序是強制性的逼迫團隊不斷做取舍第三它自帶節(jié)奏感每個迭代都有從待辦到完成的過程需求管理被植入到了團隊的工作節(jié)拍里而不是事后補一篇報告。2. 用待辦列表承載需求先搭好這四根柱子想真正落地待辦列表不是建一張表就完事你需要先把四個基礎打牢條目格式、字段設計、工具選型、粒度控制。這四個柱子缺一根待辦列表就容易變成另一個沒人看的文檔。2.1 需求條目的標準格式讓返工率降下來需求條目別隨便寫格式最好統(tǒng)一。我最常用的是標準用戶故事格式“作為某類用戶我希望做某件事以便獲得某種價值?！边@個格式看起來簡單但作用不小。舉個例子以前團隊收到的需求是“登錄頁增加驗證碼功能”。這句話信息量嚴重不足誰要用驗證碼解決什么場景為什么現(xiàn)在要做改成用戶故事后是“作為注冊用戶我希望在登錄時通過驗證碼驗證身份以便在密碼泄露時保護我的賬戶安全”。這樣一來開發(fā)就知道為什么要做且能在實現(xiàn)方案上給出更好的建議比如是短信驗證碼還是圖形驗證碼要不要加防重邏輯。并不是所有需求都能套用用戶故事格式比如缺陷、技術債、合規(guī)風險。但是這些條目也可以借用“描述價值”的框架例如“作為運維我希望升級基礎組件版本以便消除已知安全隱患”。這個思路是讓每條都回答“對誰有價值”防止一堆失效需求壓垮團隊。另外我強烈建議每個待辦條目都跟著一條“驗收標準”。沒有驗收標準的需求就是一張空頭支票。例如用戶故事是“支持第三方登錄”驗收標準可以寫“在登錄頁點擊微信圖標后跳轉(zhuǎn)授權(quán)頁授權(quán)成功時返回首頁并顯示微信昵稱授權(quán)失敗時展示錯誤提示并返回登錄頁。”開發(fā)、測試、產(chǎn)品對齊同一份驗收標準比幾千字的需求描述管用得多。條目的質(zhì)量可以用經(jīng)典的INVEST原則來檢視獨立的Independent可協(xié)商的Negotiable有價值的Valuable可估算的Estimable足夠小的Small可測試的Testable。每次往待辦列表里加新條目時對照這六個字母過一遍。容易卡住的是“Independent”和“Testable”。不獨立的故事會讓優(yōu)先級排序失效因為你以為在對待辦A其實還隱含著待辦B不可測的故事會導致“我以為完成了但大家無法驗證”的尷尬。2.2 字段設計不是越多越好但有幾個不能少待辦列表的本質(zhì)是數(shù)據(jù)字段設計決定了這個數(shù)據(jù)容器的質(zhì)量。我見過一些團隊上來就建二十多個字段搞狀態(tài)機、審批流結(jié)果光填表就累死人后來干脆棄用。我的建議是先用最少必要字段跑起來后面不夠再加。常見的最小字段集包括ID或編號方便引用和排錯。標題用一句話概括需求清晰即可。詳細描述通常是用戶故事正文和補充說明。優(yōu)先級建議用P0、P1、P2、P3或Must/Should/Could/Won‘t。估算故事點或人日用于迭代規(guī)劃。驗收標準明確“怎樣算做完”。狀態(tài)待處理、已排期、進行中、已完成、已取消。負責人當前誰在跟進便于追責但注意別把待辦經(jīng)理當圖書館管理員。來源記錄需求誰提的解決“這需求是誰說的”爭議。日期創(chuàng)建日期、目標日期如果有。這十個字段已經(jīng)能覆蓋大多數(shù)團隊的需求再多的字段屬于錦上添花。不要一開始就強制所有人填寫“業(yè)務價值”“用戶價值”“風險等級”等容易空泛的字段因為你很快會發(fā)現(xiàn)大家會為了填而填反而失去意義。真正該花精力維護的是“描述”“驗收標準”和“優(yōu)先級”這三個字段決定了后面的開發(fā)和測試能不能快速進入狀態(tài)。2.3 工具選型從白板到電子表格的輕量起步工具永遠不是核心但是一個用不順手的工具會加速流程破產(chǎn)。根據(jù)團隊體量不同我推薦三種起步方案。最輕量的是物理白板加便利貼。團隊人少、辦公地點在一塊時一張白板分三列待處理、進行中、已完成。每個需求寫在一張便利貼上貼到“待處理”區(qū)。好處是透明、零學習成本、順手就能調(diào)整優(yōu)先級壞處是沒法遠程協(xié)作也不方便統(tǒng)計歷史。第二個階段是共享電子表格。所有需求按行排列按優(yōu)先級降序排列每個人都能在線查看和編輯。這個方案非常適合小團隊起步成本接近零。我甚至見過很多幾百人規(guī)模的團隊也在用電子表格跑待辦只要維護得好效果不輸專業(yè)工具。代價是沒有自動估算匯總、燃盡圖、工作流管控全靠人工。第三個階段是真正上敏捷項目管理工具。市面上的成熟工具都支持產(chǎn)品待辦、迭代規(guī)劃、看板、燃盡圖等功能適合分布式團隊和復雜協(xié)作。工具本身不是越強大越好而是越貼合團隊節(jié)奏越好不要讓工具成為行政壓迫的工具它唯一目的是讓你的需求流更透明、更高效。很多人覺得從Excel遷移到專業(yè)工具很麻煩其實沒必要一步到位。我建議先在電子表格里把格式跑順跑三個月等團隊確認這套邏輯真正有用再遷移到專業(yè)工具。如果連電子表格都維護不好換什么工具都是死。2.4 粒度控制拆到能“吃”下去為止待辦列表里最大的災難是一眼望去全是“跟企微打通”“重構(gòu)首頁”這種龐然大物。這類需求扔給開發(fā)根本排不進迭代就算勉強排進去了也會因為無法拆分導致延期或需求蔓延。經(jīng)驗法則是一條待辦應能在單個迭代內(nèi)完成且在完成時能交付獨立價值能被一條明確的驗收標準驗證。如果滿足不了就說明太大需要拆。拆分可以按幾個維度來按用戶操作流程拆、按數(shù)據(jù)維度拆、按用戶角色拆。比如“實現(xiàn)登錄”可以拆成“手機號驗證碼登錄”“微信授權(quán)登錄”“記住登錄狀態(tài)”“忘記密碼重置”這樣每一條都能獨立驗收、獨立排期不會因為“登錄”整體風險太大而卡住整個迭代。如果“手機號驗證碼登錄”還涉及到短信服務接入、前端倒計時、后端驗證接口、風控策略那還可以繼續(xù)拆成更細的支持性任務。關鍵是待辦列表頂部的每條需求要能在一個迭代內(nèi)被“吃下去”而不是一句話驚醒所有開發(fā)。拆分的時候有一個很實用的技巧跟團隊一起拆。不要產(chǎn)品經(jīng)理自己悶頭拆完再扔給團隊確認。開發(fā)對實現(xiàn)細節(jié)和技術風險的理解能幫你把需求拆得更合理。比如你原本打算按頁面拆分開發(fā)過來告訴你某個底層服務一定要先做否則每個頁面都做不出來。讓團隊一起參與拆解既提高了估算準確度也提前暴露了依賴關系。3. 需求從進庫到出庫的全流程管理搭好基礎之后關鍵就看日常怎么運轉(zhuǎn)了。這里我把需求的完整生命周期分成五個環(huán)節(jié)收集、排序、估算、排期、變更。每個環(huán)節(jié)都有對應的實踐心得。3.1 收集漏斗讓所有想法都進得門來需求收集環(huán)節(jié)最容易犯的錯誤是設門檻。老板說“你先做個方案看看”客戶提了一句“如果頁面能導出就好了”于是產(chǎn)品經(jīng)理記在自己的小本本上然后就沒有然后了。這樣做的問題在于需求沒有進入統(tǒng)一池子后續(xù)無法追蹤也無法判斷是不是會影響當前迭代目標。我建議團隊開通一個“任意門”任何人都可以把需求放進待辦列表不需要預先審批。不管是老板的宏偉藍圖、客服收集的用戶反饋、運營發(fā)現(xiàn)的轉(zhuǎn)化卡點還是開發(fā)在寫碼時遇到的技術債通通先記成為一條待辦。不一定每條都要按完整的用戶故事格式寫但至少要包含“場景”“期望”“為什么”三要素。哪怕只有一句話也沒關系后續(xù)梳理會上可以慢慢完善。收集之后的梳理會很重要我習慣每雙周安排一到兩小時的待辦梳理會。會上不是逐條念過去而是做三件事過濾明顯無效的需求歸并重復需求把有潛力的需求補充完整描述。這個會議的產(chǎn)出不是“報告”而是更新后的待辦列表。一定要讓列表成為會議的主角而不是PPT。你不要擔心列表變得太長太亂收集階段本就允許雜亂“漏斗”的寬口就是為了不遺漏。真正的篩選發(fā)生在后面的優(yōu)先級排序階段。3.2 優(yōu)先級排序別用感覺用規(guī)則優(yōu)先級排序是需求管理中最容易撕扯的環(huán)節(jié)。業(yè)務方都覺得自己手里的需求最重要產(chǎn)品如果只會說“我們再評估評估”遲早要被口水淹沒。所以一定要建立一套大家都認的排序規(guī)則讓“為什么做這件事”盡量客觀化。最簡單的規(guī)則是MoSCoW法Must必須做、Should應該做、Could可以做的、Won’t這期不做。非黑即白的分類能快速暴露團隊的分歧兩個人對同一個需求的歸類不一致恰恰說明需求描述或價值還不清晰需要進一步對話。稍微高級一點的是WSJFWeighted Shortest Job First也就是加權(quán)最短作業(yè)優(yōu)先。它的核心思想是優(yōu)先做“延誤成本高”且“工作量相對小”的需求。簡化版公式是WSJF值 用戶業(yè)務價值 時間緊迫性 風險降低機會 ÷ 工作量大小。舉個例子兩個需求估算都是5個故事點需求A能帶來50萬新增收入且涉及監(jiān)管合規(guī)需求B只是一次體驗優(yōu)化那么A的分子遠高于B所以A先做。如果B工作量只有2而A是13那就要拿捏一下可能B先做更劃算。實際工作中不必算得很精確給每一項打個分讓團隊討論排序依據(jù)就已經(jīng)比“因為重要所以要做”的力度強得多。這里還有個反直覺的經(jīng)驗高優(yōu)先級條目需要控制數(shù)量。如果整個待辦列表里有一半都是P0那等于沒有優(yōu)先級。我給團隊定的原則是“進入當前迭代后P0不超過三到五條”其他都是P1/P2。這樣既給了方向感也保留了彈性。3.3 估算與拆分讓團隊有參與感估算往往會激起開發(fā)的反感“需求都還沒說清楚憑什么讓我估時間”所以我們要把估算的目標從“承諾日期”扭轉(zhuǎn)為“理解需求、拆解復雜度”。我最推薦故事點估算因為它是相對度量。團隊先選一個大家都熟悉的基準故事比如“修改用戶昵稱”是2點然后拿著其他需求跟它比較。它不算人天不承諾具體日期卻能比較出相對大小。用撲克牌估算也很方便每個人從0、1、2、3、5、8、13這些數(shù)字里選一張表示自己對復雜度的判斷然后同時翻牌偏差大的進行討論。這樣能有效避免“專家一言堂”或“跟風估算”。估算和拆分是相互強化的。當你對一個模塊估算出13點時所有人都會覺得太大那就趕緊拆開。拆開之后每條小故事可能有3、5、8點整體也就更可控了。我要求產(chǎn)品經(jīng)理不要替團隊做估算而是讓開發(fā)團隊自己估因為后續(xù)為估算買單的是開發(fā)。產(chǎn)品經(jīng)理在估算會上的職責是解釋需求上下文、回答各種為什么不是給標準答案。3.4 迭代計劃與進度追蹤從待辦到完成待辦列表不是擺著看的它的價值在于被“消費”。每個迭代開始前團隊要在一起做一輪迭代計劃從待辦列表的頂部按優(yōu)先級往下選選出一個迭代能完成的需求集合并承諾一個迭代目標。選擇的標準不是簡單“能塞多少就塞多少”而是圍繞迭代目標挑選最有協(xié)同效應的需求。比如這個迭代目標是“提升用戶注冊成功率”那就優(yōu)先選跟注冊流程、第三方登錄、驗證碼優(yōu)化相關的故事而不是順手塞一個“個人中心皮膚改版”。這樣即使中途有調(diào)整迭代目標的輪廓也依然清晰。迭代啟動后就把看板用起來列別設為“待開發(fā)-開發(fā)中-待測試-已完成”。每日站會時大多數(shù)人會對著看板說進展而不是對著文檔虛空匯報。這看起來樸素但效果奇好。我自己最關注的是燃盡圖Burndown Chart它會根據(jù)已完成工作量畫出剩余工作線。如果迭代過半但燃盡圖還有大段尾巴說明進度風險很高產(chǎn)品經(jīng)理就要趕緊介入是砍范圍還是加人手要趁早做決定。許多團隊只在迭代結(jié)束時更新待辦列表這是錯誤的。完成一個故事之后應該立刻更新狀態(tài)讓列表反映當下的事實。否則過了三天列表就成了“僵尸遺體”沒人信它自然也不會維護它。3.5 變更管理需求變了待辦怎么跟著變需求變更本身不是問題的核心問題是如何讓你的待辦列表依然有序。很多團隊一變就亂是因為沒有建立清晰的“待辦操作規(guī)則”。我定的規(guī)則很簡單變更分為三種新增、暫停、重排序。新增需求走收集漏斗先落到列表底部或?qū)獌?yōu)先級位置等下個迭代規(guī)劃窗口再評估不直接塞進當前迭代。暫停需求將狀態(tài)標為“暫?！弊⒚髟蚝蜁和Ｈ掌诘磺宄龡l目因為有可能后面還會撈回來。重排序則是直接在列表里調(diào)整位置但要在變更欄里記錄一下是誰、什么時候、為什么調(diào)整。最怕的情況是當前迭代進行到一半老板突然說“下周三必須上線某個新功能”。如果這個功能真的牽扯到線上風險或客戶合同那就走緊急流程但必須從當前迭代里換出相同工作量或更低保級的需求來保證團隊產(chǎn)能不過載。這里有一句我常對團隊說的話不是不能插隊但插隊必須有人被擠下飛機。變更管理不是拒絕變而是讓每次變都付出可見的成本別讓待辦列表成為被改得面目全非的自動承諾機。4. 常見問題與排查技巧實錄最后說說實際運行中我最常遇到的問題和對應解法每一條都是我或身邊團隊真實踩過之后摸索出來的。4.1 待辦列表越長越?jīng)]人看怎么辦列表膨脹是很自然的事。你辛辛苦苦收集了500條需求最后所有人打開列表都眼花繚亂干脆不看。解決思路不是限制收集而是讓列表有“分層視圖”。我習慣為待辦列表配置三個視圖當前迭代視圖只顯示本迭代條目近排期視圖未來一到兩個迭代可能進入的條目數(shù)量控制在30條以內(nèi)年度遠景池視圖所有遠期、模糊、未決的想法。也就是說物理上所有需求在同一個列表里但大家在日常協(xié)作中只關心前兩個視圖遠景池每月批量梳理一次即可。如果某條需求在遠景池里躺了超過一年又沒有任何行動直接刪除或歸檔別心疼。另一個很有效的機制是定期“清淤”。每個迭代結(jié)束后用10分鐘掃一遍列表把狀態(tài)混亂的條目理一理把明顯過時的需求移動到“已取消”或備注說明。列表和房間一樣不定期打掃就會變成垃圾堆。4.2 需求在迭代中途被硬插怎么辦這幾乎是所有團隊的痛。處理這個問題的核心不是向上管理而是給“插隊”設計明確的成本表。當有人提出“這個迭代必須加上某某需求”時我不是直接說不而是反問“那我們從當前迭代里砍掉哪條把這個讓出去”操作上先讓提出方明確該需求的緊急等級和業(yè)務價值再讓交付團隊快速估算工作量最后就“替代哪條需求”達成一致。有次客戶硬要加一個導出功能開發(fā)估了一下要8人天那我們就跟客戶商量把原本計劃里的報表優(yōu)化砍掉6人天再削減一個非核心UI調(diào)整2人天寧可這個迭代交付少一點也要保證團隊不超負荷。那次聊完之后客戶自己也意識到“還是要尊重節(jié)奏”往后插隊就謹慎多了。還有一點很重要迭代中確定范圍內(nèi)的需求如果發(fā)生變化一定要重新定義“完成標準”。而不是一句“簡單調(diào)一下”最終讓團隊加班買單。4.3 驗收標準寫得像廢話怎么破很多新手產(chǎn)品在驗收標準欄寫上“功能正?！薄绊撁婷烙^”這種不可驗證的話等于沒寫。解決方法是引入“Given-When-Then”格式。用它來寫登錄功能Given給定用戶已注冊且處于未登錄狀態(tài)When當輸入正確手機號和驗證碼并點擊登錄按鈕Then那么系統(tǒng)跳轉(zhuǎn)首頁并展示用戶昵稱與頭像。再如Given 用戶輸入錯誤驗證碼When 點擊登錄按鈕Then 系統(tǒng)顯示“驗證碼錯誤”提示且不跳轉(zhuǎn)頁面。把驗證碼錯誤、重復提交、網(wǎng)絡超時、賬號鎖定這些邊界情況都寫出來開發(fā)和測試工作重心就從“理解我猜你想要什么”變成“核對一條條具體行為”返工率直線下降。寫驗收標準還有一個技巧讓測試人員參與。測試最懂怎么把需求搞掛他們提的邊界情況往往是你壓根沒想到的。驗收標準在進入迭代前最好能拉到開發(fā)測試一起過一遍這叫“三人成虎”這里就是“三人成標準”。4.4 相關方覺得待辦列表是行政負擔怎么破技術團隊覺得要花時間維護列表老板覺得流程太慢運營覺得表格太難用。這些多半是因為他們沒看到列表給自己帶來的好處。要讓待辦管理化真正立住關鍵是把收益展示出來。比如老板上次提的需求你可以在一個月后向他展示“這條您提的需求在X月X號進入優(yōu)先級評估Y月X號排進迭代當前已經(jīng)上線數(shù)據(jù)提升了X%?！崩习蹇吹阶约旱囊庖姳煌该鞲櫨蜁斫馀抨牪皇欠笱芏秦撠熑蔚牧鞒?。開發(fā)團隊也會看到因為待辦列表清晰自己不用再去群里翻聊天記錄猜需求加班變少了。我還有一招“透明化儀式”每周發(fā)一封極簡的“待辦周報”內(nèi)容包括本期新增X條、排入迭代Y條、完成Z條、當前積壓TOP5是什么。不用寫花哨的正文用數(shù)據(jù)說話。幾次下來你可能會發(fā)現(xiàn)主動來維護列表的人反而多了。4.5 三個低成本排查技巧待辦列表管理得久了很容易出現(xiàn)“看起來一切正常其實暗流涌動”的情況。我經(jīng)常用下面三個技巧來排查健康度。第一看“卡住”的位置。如果待辦列表某一欄長期不變比如“開發(fā)中”的故事一周都沒動過說明有阻塞或技術問題趕緊約人聊聊別等問題發(fā)酵。第二做一次“待辦健康度檢查”隨機抽10條高優(yōu)先級條目看看有沒有超過兩個月沒動過的如果有要么說明優(yōu)先級排序是假的要么說明團隊根本不認可這個優(yōu)先級。第三做“反饋閉環(huán)抽檢”從已完成的需求里抽查對應的驗收標準是否全部通過、業(yè)務指標是否達到預期。如果很多已完成條目沒有實際產(chǎn)出價值說明需求進入待辦時的價值判斷出了問題下一輪排序要提高門檻。這幾個排查技巧的成本都很低但往往能讓我們在問題爆發(fā)前就把根子挖出來。最后再分享一點個人體會。把需求管理做成產(chǎn)品待辦列表管理化最難的從來不是工具或流程而是堅持“所有需求都要有入口所有入口都要變成條目所有條目都要有輸出”的心法。我從一開始的手忙腳亂到后來形成固定的節(jié)奏前后大概花了三個迭代周期。一旦團隊適應了這種可流動、可排序、可追溯的待辦列表你會發(fā)現(xiàn)很多之前吵不完的架都變成了數(shù)據(jù)上的對比和取舍而不是個人立場的博弈。如果你正在被需求混亂折磨不妨從今天起拿起一張白板或一張電子表格把最近能想到的需求全部倒進待辦列表里然后開始第一次優(yōu)先級排序。先跑起來你很快就會感受到這套管理方式的威力。