專案外包和開發外包的模式有明顯區別，手頭經歷了乙個概念不清的專案，結果一路坎坷，體會如下。
合作模式、分工一定要在開始的時候明確。這次的專案外包，乙方又把開發外包，誰對誰負責，什麼事情誰做一直沒有明確界定。乙方會本能的傾向於開發外包，導致甲方投入越來越多，產生障礙。
既然專案外包了，專案管理方法應該乙方定。當時間緊的時候，乙方或投入資源或和甲方重新商業談判來解決，甲方強行改變專案管理模式是風險極大的。比如這次雙方對「需求à設計
à編碼」環節的理解有差別，乙方是教科書裡的軟體工程，而甲方的「需求」包含了很多「設計」的內容，「編碼」也包含了部分「設計」，「需求」完了直接進入「編碼」。說法不同，實質一樣，不過後來採用甲方的模式，導致乙方真的跳過了「設計」階段，沒有產出相應的文件。
專案外包的需求如何配合？乙方應該push，向甲方收集需求，並維護《需求說明書》，當然甲方要積極配合並即時告知最新變動並走乙方的流程進行評估，而開發外包就是甲方push更合適，走甲方的需求流程，不斷給外包的工程師更新需求。
專案外包的測試如何配合？甲方肯定會有驗收測試，但是乙方一定要在專案範圍內安排比驗收測試更詳細的測試，前外不能把「找bug」的測試部分寄託在甲方的驗收測試上，而這次到專案提交的時候，專案組內部做過的測試還遠不如驗收測試詳細，這和驗收的原則顯然是不一致的。
另外外包的專案會有甲方乙方兩個pm，這次也聽乙方的中年pm談了很多兩種pm的不同，受益很多。
產品設計體會（五五） 專案Kick Off
今天說一下專案 kick off 會議 簡稱 ko 的作用，會有人覺得這很形式化，但我認為很重要，其實 ko只需要 15min 左右的時間，我會安排在需求評審 參加人與 ko基本重合 之前，成本很低。在這 15min 內，需要傳達的資訊有如下幾點。專案的背景與意義 說過去，做專案之前的情況，為什麼要...
產品設計體會（五八） 《專案化管理》培訓記錄
上週5 6又培訓了，專案化管理 每週上4天班上2天課還是有點累的，不過培訓的收穫也不小，整理一下。整體感覺這個老師還是很不錯的，授課技巧很好，在專案管理方面也確實資深 十幾年前在李嘉誠乙個淨利潤1k多億的專案中，就已經是乙個子專案的高階pm 課程講了較多 道 的東西，較少 術 的內容，需要聽者有很深...
專案管理和產品設計學習體會
在本次小組專案中，我擔任的角色是專案經理和客戶經理。而且我參與了整個產品設計工作。下面是一些零碎的學習經驗與感悟。確定產品定位 核心功能等問題已是老生常談，下面我來說兩個小方面的感悟。在產品初期進行市場調研的時候，問卷調查法是最常用的方法。但是設計問卷看似簡單，實際需要對產品很深的理解和清楚的產品定...