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

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

一、產(chǎn)生的背景

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

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

二、自研產(chǎn)品的演變思路

于是，若形成公司內(nèi)部自研產(chǎn)品，就大抵會經(jīng)過這樣的演變模式：

如上圖示意：

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

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

當然，走到這已經(jīng)是與以往完全不同的兩種商業(yè)模式了，在這里僅作為一種產(chǎn)品發(fā)展思路的設(shè)想，具體視情況而定；

三、建設(shè)意義

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

對于公司，打磨戰(zhàn)略級標準應(yīng)用產(chǎn)品，提高產(chǎn)品擴展性和兼容性。降低定制率提高產(chǎn)品的復(fù)用率，易于擴大市場。

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

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

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

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

四、落地自研產(chǎn)品的思路

1、溝通公司高層和戰(zhàn)略層的想法、規(guī)劃、了解落地形成自研產(chǎn)品的目標要求

2、作為產(chǎn)品經(jīng)理，需要著重考慮產(chǎn)品架構(gòu)和范圍界定（這塊從兩大方向來考慮）

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

主要包含：

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

綜上，綜合考慮需求的覆蓋面，市場的反饋，需求在技術(shù)側(cè)實現(xiàn)方案的平衡等多方面進行需求池錄入和優(yōu)先級排序，形成產(chǎn)品版本和架構(gòu)劃分。

2. 拉通產(chǎn)品資源，拉通各關(guān)鍵部門，形成自研產(chǎn)品實施立項和計劃

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

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

在形成成熟的自研產(chǎn)品過程里，是一個不斷在實戰(zhàn)項目里驗證和完善的過程，需要整個公司、產(chǎn)研團隊的協(xié)同發(fā)力。

（1）技術(shù)側(cè)的考量

關(guān)于技術(shù)側(cè)，在架構(gòu)和代碼結(jié)構(gòu)的開發(fā)側(cè)，要側(cè)重于微服務(wù)架構(gòu)，低耦合，高內(nèi)聚的目標需求，增加代碼的復(fù)用性和易維護、可拓展性需求。

（2）產(chǎn)研協(xié)作側(cè)考量

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

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

（3）架構(gòu)設(shè)計的角度

產(chǎn)品架構(gòu)邊界和技術(shù)架構(gòu)，需要在一定的范圍內(nèi)可靈活調(diào)整，以便于滿足市場快速多元的需求。

這樣，當項目側(cè)和自研側(cè)可以互相推動，形成良性循環(huán)時，自研產(chǎn)品的建設(shè)或許會走的相對容易一些。