產品通過定時迭代版本來新增和優化功能，乙個產品、版本或功能都是乙個個內部專案，如何在乙個確定的有限的時間段內，準時高效地交付高質量產品，就顯得格外重要。大部分的公司沒有內部專案經理，產品經理算是研發團隊中最懂管理的人，並且是產品 owner，所以責無旁貸的需要負責內部專案管理的職責。
如果乙個產品經理沒有專案管理的經驗、也沒有系統性學習過專案管理的知識，那麼內部專案可能面臨很大的失敗風險。下面總結了幾點專案管教心得！！！
專案開始時基礎共識沒有達成，定位模糊不清；之後的設計、開發因此頻繁改動變化；再加上所有人對準出標準目標要求不統一，這些不確定性足夠讓專案失敗。開始乙個新的版本迭代，或開發乙個新功能，需要在專案開啟的時就確定以下問題：
功能價值：實現該功能改變了什麼現狀，解決了什麼問題，能夠帶來什麼價值。如果無法回答或不清晰，那麼需要從新調研，甚至停止專案，因為不清楚價值，等於做了沒有回報。
功能定位：你做的乙個什麼樣功能，比如基礎功能， 魅力功能等。
功能目標：專案結束後，實現哪些功能，這些功能的標準是什麼。
開發資訊：該功能在哪個版本開發（當乙個產品有多個版本時），該功能是內建還是外掛程式等資訊。
專案負責人：確定專案負責人是誰，避免因角色不清晰，導致專案無人負責。或者說確定產品經理是不是專案的負責人。
當上述資訊清晰確定後，就可以 kickoff 了，將上述資訊傳達給相關人員，作為專案負責人一定要主動、頻繁、大範圍的傳播，讓每個人都了解，盡量降低專案的不確定性。
乙個專案的成員不足，加班加點還是可以準時完成。但是如果乙個專案成員頻繁變動，那麼這個專案失敗的可能性就很大，主要是兩方面原因：一是重複對接和溝通，需要告知新成員的工作內容及各種工作交接；第二是新成員不適合當前空缺或做不必要工作，比如整體**架構不熟悉，甚至需要修復上一位遺留的 bug。
工作任務的評估難以量化，所以大部分專案成員都不仔細評估工作量，認為評估有什麼用，只要準時完成就可以，最後完成不了又說時間不足。
專案前期需要認真評估各階段所需的時間，並在總評估時長上留出 10% 緩衝時間，再作出詳細的專案計畫。比如我們經常會低估需求和設計工作量，但是乙個正確的研發週期，需求設計和技術設計時間要佔整個專案時長的 30% ，如果低於這個時間，那麼前期設計工作做的肯定不充分，後期很有可能會頻繁修改設計、介面等。
乙個專案計畫時間少則兩周、多則幾個月，所以不能最後統一交付，因為最後的交付的可能是一坨?，甚至連屎都交付不出來。所以需要指定專案時間節點，並制定每個節點的交付物，比如使用 tr1-tr7 的研發流程：
計畫：需求可行性分析、人員安排、時間安排、形成任務書。
系統設計：prd、技術詳細設計（api 、架構圖）。
研發：初版本的軟體和交付文件，研發盡量分多個階段進行驗收，比如幾個子功能乙個 rc 版本。
測試與版本迭代：測試進行功能測試，研發進行迭代開發。
封板驗證：測試進行回歸測試，重要問題需進行評估是否修復。
專案負責人需要每週對這些時間節點的交付物進行進度跟蹤和更新，如果發現某個節點出現延期、或交付物質量不符，應該及時找人協助，也要對專案時間進行調整。
專案中會遇到很多問題，不要裝作看不見問題，也不要想著只憑藉自己一己之力解決問題。專案是乙個團隊合作的結果，我們需要直面困難，專心去學習解決問題，如果專案成員無法解決，需要及時對外丟擲問題，找更有能力的人解決，至少讓相關人員知道目前的問題，而不是專案成員默默等待。問題和困難不會因為時間而消失，最終還是需要解決，及時丟擲和專心解決才是王道。
設計被修改是正常的事情，比如互動、樣式，或者部分 api。但如果按照設計稿一比一開發，但在功能開發完成後，說設計不對，需要修改。那麼各個評審會的時候幹嘛呢？我認為主要以下原因導致評審會沒有提出問題：
設計稿沒有分享傳播，可能是忘記、也可能是怕他人提出問題，僅在評審會過了一遍。評審會人員在簡短的時間內只會檢視主流程是否可行，不會對細節進行深究，所以不會提出更細節的問題。
設計稿和真正使用體驗不同，有的問題只有在真正使用後才會發現問題，盡量做到高保真且具備互動的設計
交付物的輸出標準不同，可能評審人員認為可通過，但是以老闆的標準，可能就會被駁回。
產品對問題沒有考慮完善，害怕頻繁修改設計稿被開發懟，忍受了一些已知的問題，但在最後交付時被全部暴露。
從需求——設計——開發整個過程，一定要正式認真開好每乙個評審會。評審會的資料需要準備充分，考慮詳細；在開會之前將資源進行分享，提前找相關人員 review，更要多找老闆、或經驗更豐富的同事把關；最後就是發現問題及時修改，不要敷衍過去。評審會過完，一定要確保所有問題都解決了，且通知到相關人員。
專案負責人、產品經理、開發人員在一定程度上會有知識盲區，會忽略一些問題。所以專案需要更多經驗豐富的人員來把控產品質量，比如高階研發工程師或架構師把控架構、元件、api、高可用等問題；設計師把控介面樣式、互動邏輯。如果考慮不周，輕度影響後期拼命修改設計，驗證可行性，改架構；更嚴重的是這些問題在測試發布時都沒有顯露，在客戶環境發現問題，出現事故。
專案應該遵循各時間節點的交付物，準時進行驗收。驗收發現問題時，重新評估問題風險是否影響專案整體進度，如果有影響，需及時反饋和調整。永遠不要在專案結束對外解釋因為未知問題導致延期。比如某子功能完成後，產品經理需對功能進行驗收，設計師需對介面布局樣式和設計稿進行對比，測試進行功能測試。一定要避免所有問題在最後發現， 在最後提出。
某個專案是在測試階段發現很多問題，導致專案成員加班一周才解決，搞得大家身心疲憊。不只是加班累，更重要成員失去信心，對自己的付出產生了懷疑，乙個好的產品怎麼會後期大量修改呢？
另外乙個專案是因為專案定位、目標不明確，又遇到無法解決的問題，結果在專案後期才暴露出來，導致專案長時間延誤。
對於乙個沒有內部專案經理的公司，產品經理或者技術人員作為專案負責人時，真的太難了，因為他們不具備專業的專案管理知識，更沒有評估專案風的經驗，所以專案很容易失敗。
總結： 平時需要多讀專業書籍。
正面管教php 我就這樣走進正面管教
我和 正面管教 還有一段淵源，2015年學校曾發給每個老師一本簡 尼爾森博士寫的 正面管教 我記得是王校長推薦的。那時，我們還組織了一次教師的學習會。因自己也是囫圇吞棗般讀完，印象最深的只有 和善與堅定 這五個字。後來和正面管教講師楊華京老師有了連線，就在今年5月邀請到楊老師團隊來學校給家長做正面管...
專案管理心得
做專案，和做其他任何事情一樣，對於我們面前的專案，在行業認知上我們多少都是無知的，不過我們可以根據經驗，用這世界乙個相同的東西 相似性 去分析它，細化它，抽象出來，一層一層，一塊一塊的實現出來。所以在我們的專案團隊中，我認為以下幾個原則非常重要 1，先慢後快。團隊的合作往往是磨合再磨合的合作在用，在...
心得 XHB專案
作為乙個android菜鳥，跟著老大做android專案，從立項到上線，從架構到實現，從懵懂到掌握，在這裡我總結一下在此專案中和收穫 遇到的問題和解決辦法 1 首先乙個專案最重要的兩個點就是需求和架構。需求搞不懂做的再多也是枉然，架構沒設計好，之後遇到問題想改會遇到很多問題會牽扯到很多東西。需求和架...