作為程式設計師，擁抱敏捷是一種心態。靈活的接受來自各個方面的需求是我們這種產品多變化，團隊小的公司的利器。但是我們也要去注意需求的質量。這裡要談到《構建之法》的第八章，需求分析。

        需求的獲取渠道有多種：（請記住上一篇博文的一句話，每一個流程必須要結果）

        1.經驗

        2.焦點小組

        3.人類學調查（同吃同住同玩）

        4.快速原型調研

        以上前三個我們都有去嘗試，也是做成我司產品的重要需求來源。這裡代入一個場景；

        我司星星是一個PM，最近做一個後臺管理系統，後端前端。火急火燎的設計開發。老闆驅動，寫了再改的工作模式。在完成預期目標大部分的情況下，上週交付運營冰冰試用。冰冰反饋問題太多，不合理，想要的東西不出現在想要的地方。星星說：沒事產品馬上改版。what，我還沒寫完成，要不你把新的設計給我，我做了？

        上述事件我想說：

        請學會快速原型調研，在產品設計初期，你們可以將設計呈現給使用者（如果可以），就像上文的產品設計之初將原型交付運營評審。而不只是給技術評審。這樣減少成本與人力的浪費。

        為什麼要做這個需求，其實是產品出需求前要捫心自問的。

        技術接到需求的時候，要去計劃與估算時間。技術們，請了解目標，估算，決心的不同點。需求的不完善，技術的盲目樂觀都會有排期不可控的風險。但是我想說，排期不可控沒關係，請如實的報告進度。這才是最重要的，對於我們這樣的團隊。

        最後，我提議，產品要擔風險，整個過程哪一個步驟出問題，你們都要負責，責任人負責，產品也要負責。產品不僅僅是出需求。PM要負責，要有推動力。驅動流程，組織會議，實踐敏捷，保證進度。