我從事傳統專案管理已經超過10年了，在數位化時代的背景下，我有很深的體會：
從個人能力和長遠發展的角度來看，專案經理需要具備產品能力。
甚至在未來，也不再有獨立的專案和產品，專案經理擁有產品能力是必然趨勢。
因此，在進行專項專案管理的同時，我也在思考和探索，將產品思維融入到專案管理中。
筆者從專項的經驗和不足之處總結了以下幾個方面，供大家思考：
做主人的責任，積極推動
在傳統的專案管理下，專案的時間受到限制，專案的目標被設定，很多時候被動地被使用者的需求所接受。
每個部門使用者的需求都不能從自己的部門和想法中跳出來，不能從公司產品管理的高度來規劃，需求的緊迫性和重要性往往由各部門從自身利益出發來評估。
更何況，使用者的需求不是很清楚，有的說，“你幫我想想。 有人說，“讓我們嘗試乙個月，看看效果如何。 ”
起初，我也無語了：業務部門沒有想清楚目的和價值要達到什麼目的，提出什麼要求，做什麼專案。
越來越多的這種情況在以後發生我重新審視了自己的思維方式，發現我的思維侷限於專案管理的框架，所以我總是認為：
1）首先要明確使用者的要求，要求由使用者決定，越清楚越好。
2）弄清楚需求後，考慮如何實現它們。
3）根據我們現有的工作計畫確定需求的優先次序。
4）這件事情還需要其他組和部門的配合，等其他組和部門辦完後再說。
在思考了使用產品思維之後，我意識到我需要成為產品和專案的“主人”，在任何環節遇到問題時，我都有責任和義務積極推動和解決問題，而這種熱情來自於對需求和專案的主人翁意識
1）主動思考，挖掘需求
詢問使用者真正的痛點是什麼，目標是什麼。
現狀與目的之間的差距是**。 同時，也要考慮使用者的炫點，以及哪些方面和功能得到了改進，才能讓使用者感覺特別“爽”。
2）深入思考目標，而不僅僅是執行：
優先考慮你為什麼要這樣做，這正是使用者想要實現的目標。
在組織架構調整專項中，對組織戰略進行詳細分析，提前在前端系統中預測“網格式組織架構”內容所涉及的配置調整，以承擔建設方業務，提前完成相關配置; 識別建築業務人員交接業務需求與現有職能的差距，提出對接改造方案。
3）根據目標確定合理的優先順序
在以前的專案中，接手專案時首先要做的就是拆分與自己相關的任務，確定相應的負責人，並根據手頭的工作安排開發。
在後期產品整合需求中，結合實際業務，我們認為使用者的迫切需求是支援成本渠道中待銷產品的設計、收入確認和公司間結算，因此我們配合營銷服務數位化部門確定快速、最優的解決方案，並優先進行訂單轉型， 企業急需的發票和公司間結算流程;
預測資料維護的等效水平，提前完成所有資料維護。
4）主動推動並積極負責專案的進展
對於工作不明確，主動找其他部門**討論清晰明了，而不是被動地等待指示。
在票務系統的專用全電動票證中，雖然需求來源是票務系統對接的全電子發票。
但是，從專案一開始，我們就跳出了被動等待，從系統的公升級點主動解讀對接系統的需求，作為票務系統和前端系統之間的橋梁，提前列出了業務中可能發生的各種場景，並推導了每個系統中業務流程的步驟和資料需求， 從而主動演繹出各前端系統需要配合改造的內容，對各前端系統的改造進行公開和快速迭代改造。
特別是由於缺乏成熟的經驗，我們主動要求票務系統嘗試反向場景，並在已經開過全電發票的客戶之間分享推論，以便提前做好我們的反向場景流程。
同時，在專案實施過程中，積極監控和推進票務系統及各類前端系統進度，確保專案進度和質量。 在較短的時間內，我們協調各方聯合測試，快速發現問題，高效解決問題，監控轉化回歸測試進度，實現高效高質量完成聯合除錯測試，並預估、挖掘和解決問題。
附件：使用者測試問題跟蹤。
總結：跳出你預設角色的侷限，將傳統的執行者、合作者、響應者的角色轉變為創造者、領導者、推動者，從各個方面考慮，努力推動專案的完成，從而成為產品和專案的所有者。
擁抱變化，專注於資料分析
繼續思考優化
傳統的專案管理是分階段的，對時間敏感，但隨著時間的流逝，使用者的需求在不斷變化，所以我們也需要在“滿足使用者需求”中做乙個持續的過程。 即使客戶沒有提出要求，我們也在不斷思考優化和迭代，以提高產品質量，從而不斷滿足使用者的潛在需求。 同時，通過對資料的分析，根據資料帶給我們的反饋，我們進行不斷的優化迭代，敢於堅持對錯。
在組織架構調整專項中，根據年初客戶群銷售的產品劃分，原系統方案是通過前端系統1的LTC流程採購解決方案產品，採購后級工具產品遵循自研前端系統2的LTC流程。
但是，我很快發現，實際業務無法將產品劃分得如此清晰，解決方案產品在銷售時可能與工具產品一起銷售，在銷售位置級產品時也可能進行推廣，以擴大市場。
因此，我們的系統方案也應該更加靈活，在與營銷服務數位化部門協商後，盡快優化方案，取消原方案中對產品發放的限制，並在前端系統中增加產品資訊不健全的預警功能，以便快速支援原方案的迭代，適應業務可變性的需求。
同時，我們分析了重複的手動操作，並試圖統一和自動化流程。
以單據轉賬為例，我發現基本上從2月底到3月乙個半月的時間裡，我都厭倦了處理可能每天上報的客戶分配和歷史單據轉賬的需求，在系統中手動分配，資料統計手動分配的單據數量超過1個檔案數量的5w;
此外，一些文件分配是直接從前端發起的，沒有通知給後端系統，導致資料不一致、介面錯誤等問題。
我總結了ERP單據轉移涉及的單據範圍和對應的調整字段，可以使用標準功能進行操作，需要在後台執行，以及如何儲存日誌，並主動與解決方案系統部門討論自動轉賬的可行性，優化了現有的人員交接功能和介面。
並將優化體驗延伸到倉位級LTC流程，優化效能拆分功能。 最後，後端系統可以支援跨客戶群、跨客戶群內跨分支、跨分支機構內部的文件自動分配。
附件：手動文件傳輸到自動傳輸。
總結：擁抱變化並應對變化，而不是遵循計畫; 利用資料對結果進行觀察和分析，思考如何在原有函式上以最小的成本完成求解，實現快速迭代。
尊重多個系統的複雜性
與外圍系統高效對接
在現代企業應用中，多個系統往往是組合在一起的，多個系統之間的協同工作組成為乙個真正的業務系統，每個產品系統都不是孤立存在的，而是整個業務流中的乙個環節。 因此，我們需要在專案過程中進行全域性思維，而不是基於功能點的工具思維。
1）從產品和系統整合的角度思考技術方案，避免碎片化
負責解決方案的實施和交付通常會導致我過多地關注技術細節而忽視整體。
要思考需求給使用者帶來什麼樣的價值，幫助使用者解決在什麼場景中遇到的問題，同時保證多系統對接的穩定性和最低的改造成本。
比如我踩過這樣的坑，只考慮集團產品層面的標準化和統一化，為業務分析的標準化提供產品資料依據，認為ERP的材料是所有前端系統的產品源頭，前端系統應該按照ERP的梳理進行統一和標準化， 忽略了前端系統在產品層面也會有自己的邏輯控制，導致前端系統的產品選型、統計分析等問題。
2）合理**，保留擴充套件性：
在制定需求的過程中，最難受的就是需求的不確定性和靈活性，既要有規則，又要允許在特殊場景下跳過規則，所以在設計系統解決方案、業務模型和資料模型時，要適當考慮未來業務是否有變化的可能，提前預留方便後期變化的部分。
例如，ERP套件軟體在靈活性方面不強，通過配置表或配置項可能發生變化的內容，用於減少辛苦工作，實現功能切換; 連線外圍系統時預留擴充套件欄位和方法，將一些驗證規則或計算規則放入更靈活、可配置的中介軟體或前端系統中進行處理。
總結：從多系統的全域性視角出發，協調各系統之間的約束和關聯，實現1+1>2的有機結合。
更廣闊的設計思維和產品視角
將解決方案的標準版本商業化
資源總是有限的，但使用者的需求是無限的，所以在堅持迭代路徑和產品目標的同時，要考慮系統方案是否可以進一步標準化，從而以最少的時間和精力達到最大的效果。
例如，在ERP系統中，通用函式作為不同模組呼叫的功能組; 在整合方面，將單個功能點整合到乙個統一的介面中，用於外圍系統呼叫。
此外，還需要充分挖掘需求的共性，平衡“需求”和“成本”，提供場景特定的標準化能力，並將其抽象為最小可用的產品模組。
例如，在不破壞業務閉環的情況下，盡可能刪除業務流程的路徑; 通過合併同類專案來合併場景。
在此基礎上，“通用需求解耦，通用能力平台化”將通用部件與主產品解耦，通過平台搭建塊，實現業務靈活選型。
結論：
在數字時代，產品和專案的交集只會增加。
一切都是產品，一切都可以通過專案管理進行管理。
在傳統的專案管理中，引入產品思維，運用使用者思維和資料思維，主動分析問題，思考和挖掘使用者的真正目的和價值; 充分發揮解決問題的主人翁意識，不斷迭代優化，通過標準化的方法將解決方案產品化，解決問題。