幾個疑問：
沒有業務方講得清業務？有沒有搞錯？那還調研個屁？
對，沒錯。如果能講得清，就不需要產品經理了。
其中首要原因就是：他（她）只是乙個螺絲釘，而企業的運轉則是一支鏈條。
所以進行需求調研最首要的就是確定業務流程
乙個方法：1-4級流程規劃：戰略層–跨流程–跨部門–跨崗位
先丟擲三個問題：啥叫非功能性需求？誰需要關注？什麼時候來做？
效能、安全、擴充套件性、穩定性、資料遷移、異常處理、問題跟蹤
舉個例子：蔚來汽車長安街「趴窩」，這個鍋誰來背？
這個事件可能會導致蔚來需要從系統架構底層開始考慮如何做到安全公升級。
戲劇性的事情還是發生了，專案過程中，客戶負責人變更。多虧了我這個反方觀點避免了一次扯皮大戰。
讓我確認？簽字畫押？開什麼玩笑，我是甲方。
坦白講，我所有的客戶都是這樣的，越是大廠越是如此。所以，我做過最好的專案賠了20幾萬。
回想過來，可以反問幾個問題：
專案管理心得
做專案，和做其他任何事情一樣，對於我們面前的專案，在行業認知上我們多少都是無知的，不過我們可以根據經驗，用這世界乙個相同的東西 相似性 去分析它，細化它，抽象出來，一層一層，一塊一塊的實現出來。所以在我們的專案團隊中，我認為以下幾個原則非常重要 1，先慢後快。團隊的合作往往是磨合再磨合的合作在用，在...
專案管理心得和10條專案管理心得
在從產品部轉到交付部後，經歷過企業版的幾個專案後，逐漸意識到，企業版的專案往往周期短 資源緊張 需求變動大，而作為乙個專案管理的新人，在資源不足的情況下，經常要自己參與功能的設計開發 需求分析 制定專案計畫 培養新人等等 經常要既當爹又當媽。作為一名技術人員，常常會因為參與某些技術難點的討論而絞盡腦...
軟體專案管理 三 軟體專案範圍管理
專案範圍對專案的影響是決定性的，它確定了軟體專案工作內容的多少。有效的範圍管理可以保證專案只做必須做的事情，避免範圍蔓延和做無用功，同時也避免不清晰的需求所導致的嚴重的系統缺陷 需求獲取工作的任務就是收集專案干係人的需求資訊，為定義專案的範圍奠定基礎。需求獲取工作只能通過使用者與開發人員之間進行高度...