以下是我對2016年的反省

　　一、對需要整理的一些“想當然”

　　整理需求的階段，對需求的描述需要清晰明了。但往往會“想當然”的覺得這個需求本來規則就有，開發應該知道怎么做。從而需求描述個大概，沒有細節描述。

　　合同改版的時候，我覺得合同就是我們能拿到什么數據就顯示什么數據。但測試階段我們發現，因為添加了查看步驟就要參考合同簽約方式。合約簽訂日期以及每個階段顯示什么數據，都有時間性的規則。這是改版之前沒有的規則。因為所謂的“想當然”就應該這樣，導致測試階段開發的修改任務加重。

　　二、對需求流程管理的一些“想當然”

　　需求流程管理上我“想當然”的認為，迭代評審會上，我們把需求講清楚就可以開發了。事實上我一直是這么做的。但是下半年產品部獨立，開始放手讓新人自己去整理需求和設計、特別是有交互設計師和產品經理的配合組合。迭代評審會上測試和開發對需求和設計本身提出了不少建議和缺失點。后續就要去做一些修改，然后再次評審。一定程度上會拖延開發時間。

　　接下來我們需要重新定義評審會，在產品需求階段，先有需求評審會，需求評審會必須在上個迭代結束之前開啟。上個迭代結束后開始迭代評審會，使每個迭代銜接更順暢。

　　三、對團隊管理的一些“想當然”

　　團隊管理可能對我來說是一個新課題。因為我們互聯網行業講究的是團隊協作和扁平化管理。在產品部里面我們所有同事其實就是對一個大項目（紅天桃）細分成各個小板塊，用迭代流程去完成里面的各個組成部分。所以在我的概念里，只要有迭代流程，大家各自就可以運作。

　　但事實上，計劃的變更要及時掌握；流程的合理性要去跟蹤，臨時任務需要分配。部門還需要核查機制，迭代文檔核查，任務計劃執行情況核查。

　　所以我們除了需要一個工作流程，還要有很多配套的機制去管理這個流程是否順利推進。這是一個課題要去研究，而不是我想象的流程是這樣他們去做應該就沒有問題了。