本周的主題是立項與組隊，主要是在產品的策劃階段完成之后，開始組建團隊來推進后續的設計、開發、測試、上線、運營等工作，是后續一系列工作的起點。
這部分的工作，更多的是跟不同的團隊、不同的人打交道，在沒有管理權力的情況下，影響項目相關成員，以實現產品在保質、保量、按時、成本可控的條件下完成。這些工作都是管理的工作，我想這也是產品經理之所以叫產品經理，而不叫產品策劃或需求分析師的原因。
說到了組建項目團隊，就必不可少的提到另一個職位：項目經理。項目經理負責的工作是推動項目按時保質的完成，其關注的點為：項目范圍、質量、進度、成本。這四項要素互相影響，一項變動，另外三項中至少有一項要跟著變動。項目經理的職責是把事情做正確，強調的是執行力。
而產品經理，最重要的職責是定義產品：做正確的事情，強調解決用戶問題。這樣就產生了一個矛盾：
項目經理要把事情按時完成，所以不希望在項目進行中有太多的需求變化，最好沒有變化，這樣項目就會可控；
產品經理要做正確的事情，而如何定義正確的事情？隨著時間的推移、內外部環境的變化，對“事情是否正確”的認知也會發生變化，所以產品經理就希望能快速的響應這種變化，對需求進行變更。
矛盾如何解決呢？
控制項目的大小，一個項目中發生了變化的事情，在下一個項目中體現，而不在當前項目中進行變更，也就是敏捷項目管理，把每一個迭代都當成一個項目來管理，這樣基本可以平衡不太大的變化了。但是如果是從根本上發生變化，那么整個項目也許就可以停下來，然后再來確實是否需要重新開始了。
當產品經理同時擔任了項目經理角色時，如何平衡做正確的事情和把事情做正確呢？
有句話說：在錯誤的方向上前進，執行力越強，錯得就越離譜。既然如此，那么是否應該一發生變化，就修改產品需求，并且立即實施呢？
我理解不是。原因如下：
1、變化快速的發生，我們提出的解決方案是否可以解決變化帶來的問題？這需要我們去深入思考，不能草率的拍腦袋決定；
2、習慣了隨時改需求，那么對需求的思考也就不會深入，對用戶需求的把控就不強，就會帶來更多的變動，形成惡性循環；
3、需求變動會給ue、開發等團隊帶來大量工作，頻繁變動會導致周邊團隊怨聲載道，影響產品經理的威信，后續你在提需求，周邊團隊都會持懷疑的態度，等等。
所以，在下一個迭代中來體現這些變化，給我們自己深入思考的時間，也不會輕易的干擾周邊團隊的工作節奏，這樣才是一個良性的循環，這樣也給迭代提出了一個要求：周期不能太長，如果以3個月為一個迭代周期，那么按照上面的做法，也許就黃花菜都涼了。
