任何一個項目制的公司遲早都會面臨這樣一個問題：項目需求如何落地到產品需求里？本文總結了相關思路，一起來看看吧。

最近有同行問我，項目需求如何落地到產品需求里？我想，這或許是一個不錯的選題，因為這是任何一個項目制公司遲早都要面臨的問題。

一、產生的背景

一般公司做的項目多了，就會發現疲于奔命，客戶需求多種多樣，定制化有利于客戶的需求，但對于甲方和乙方浪費了大量的時間和人力成本。

因此對于很多重復性較高且甲方都在用的行業方案，我們傾向于在內部形成自己的自研產品，提高項目實施的高效，滿足快速且輕成本交付的需要。

二、自研產品的演變思路

于是，若形成公司內部自研產品，就大抵會經過這樣的演變模式：

如上圖示意：

我們從大量的甲方項目經驗里，形成內部自研的產品版本，同時自研產品線可輔助用于交付項目，項目也可不斷通過實戰輔助迭代自研產品，這樣相輔相成，直到形成行業較為成熟的解決方案。

這時候，產品版本清晰，承載的業務和核心能力也趨于成熟，可以快速用于項目交付。同時，因為已經積攢了太多的實戰經驗，完全可以逐步抽離出一部分共性需求，至于個性化較強的部分可以用apaas來靈活、自定義地解決，這又進一步融合形成了行業內標準的產品方案，即saas，甚至還可以再細分為行業saas、場景saas、通用型saas。

當然，走到這已經是與以往完全不同的兩種商業模式了，在這里僅作為一種產品發展思路的設想，具體視情況而定；

三、建設意義

關于項目到落地自研產品的價值和意義，對公司和個人都同樣深遠。

對于公司，打磨戰略級標準應用產品，提高產品擴展性和兼容性。降低定制率提高產品的復用率，易于擴大市場。

并且基于尋求多元化的業務增長點考量，這是一個資源整合的過程，也是一條必走的路。

對我們產品個人，如果有幸能參與到這樣一次經歷，會有很大的提升?；蛟S能做一款接近市場客戶的真實有用的好產品。

那如果你接到這樣一個任務，又該如何著手開始呢？

以下是一個可以落地執行的思路，僅供參考！

四、落地自研產品的思路

1、溝通公司高層和戰略層的想法、規劃、了解落地形成自研產品的目標要求

2、作為產品經理，需要著重考慮產品架構和范圍界定（這塊從兩大方向來考慮）

1. 確定自研產品的定位、范圍界定，解決的場景和問題

主要包含：

• 梳理過往交付項目客戶關注率較高的需求和業務；
• 梳理統計過往交付項目支撐率和覆蓋率較高的需求；
• 參考市場上相對成熟的競品、做競品部分的調研；
• 可考慮收集招投標文件要求來進行需求梳理做一定參考；畢竟競品挖掘有限；
• 收集客戶使用側.市場側.售后運維側.開發側等需求反饋；

綜上，綜合考慮需求的覆蓋面，市場的反饋，需求在技術側實現方案的平衡等多方面進行需求池錄入和優先級排序，形成產品版本和架構劃分。

2. 拉通產品資源，拉通各關鍵部門，形成自研產品實施立項和計劃

• 拉通技術、解決方案、市場銷售等關鍵部門，進行立項計劃宣導、需求評審‘和問題確認。
• 溝通技術側的代碼復用情況，做資源整合，即是否可解耦直接打包生成MVP1.0自研產品版本；盡量拉取功能閉環更全面的項目需求；將這部分可用的需求做篩選，梳理納入1.0版本清單里。
• 后續根據立項計劃，演進路線，再逐步進行產品迭代管理和推動。

3. 此外，還需要有以下方面的考量

在形成成熟的自研產品過程里，是一個不斷在實戰項目里驗證和完善的過程，需要整個公司、產研團隊的協同發力。

（1）技術側的考量

關于技術側，在架構和代碼結構的開發側，要側重于微服務架構，低耦合，高內聚的目標需求，增加代碼的復用性和易維護、可拓展性需求。

（2）產研協作側考量

在團隊分工協作側，需要建立整個項目側與自研側的協作機制；需要一整套標準規范和要求制度，以便自研產品可以在項目側得到推動和有效驗證，并逐步提升項目需求的支撐率，同時可反向推動自研產品形成更加有核心競爭點的產品力，為后期占據市場做準備。

在這套機制里，項目側和自研側的干系人均有義務互相輔助和推動；并及時反饋，不能自成一派。

（3）架構設計的角度

產品架構邊界和技術架構，需要在一定的范圍內可靈活調整，以便于滿足市場快速多元的需求。

這樣，當項目側和自研側可以互相推動，形成良性循環時，自研產品的建設或許會走的相對容易一些。