在面向B端的產品中，部分軟件公司對於產品的研發，是想要建立一套行業解決方案。因爲是想解決行業的問題，軟件的研發週期，需求收集都耗時較長。尤其是在產品研發後，一些需求的傳遞就沒有ToC迅捷，某項產品功能在初始研發時是滿足市場需求的，但經過一定週期再來分析時，這個需求可能就“淘汰”了。
此時，爲了做好產品功能優化，更好地服務於客戶就要在產品部分功能落地後進行調整，而我們提出『產品改進』這一產品，用於對B端產品改進需求、實際開發調整的管理。
產品改進業務
產品改進是什麼
產品改進是指在產品上線後，用戶反饋的一些改進建議，或是灰度測試暴露的“小問題”，需要單獨拎出時間來進行討論、研究以來對產品進行改進調整優化的產品使用需求，其中部分改進需求甚至會延展爲一個新的獨立項目。將這些需求進行評判、開發、以及後期的上線版本控制。
需求管理是什麼
整個需求的管理是非常廣泛的，其中包括原始需求、分析需求、必要需求等等，劃分的類別根據不同的標準劃分五花八門，具體的不再贅述，在《人人都是產品經理》上有各種大牛解答。但是，在這些劃分的背後都圍繞一個目的：
產品的開發方向，產品要實現哪些功能。
二者異同點
產品改進是整個後期產品線調整的總概，需求管理僅是其中之一。二者都是對實際產品業務需求的管理，只是產品改進更偏向於產品投入線下後的使用改進，而需求管理則是產品落地前後都具備的。
爲什麼要有產品改進
在敏捷開發的模式下，產品的開發工作也是存在“蜜月期”的：
在產品開發完成的前一週，直到產品落地的後一週，在這期間項目組成員方便跟進產品調整，“改得及，改得快"。
但是過了這個“蜜月期”，若是開發成員手頭又開展了其他工作，就可能產生兩個問題：
- 之前業務代碼會看起來“生疏“——消耗一定時間成本去熟悉
- 一些業務概念也不如初始開發時那麼清晰——盲目地直接更改可能產生新業務缺陷
額外一點，在公司層面，覈算人工成本時，難以界定其ROI。而且某些需求是零散的。例如：部分客戶提出來A業務要增加一個功能，B功能模塊希望整合到C裏。而『產品改進』主要功能就是，將零散的需求收集在一起，進行統一查看，將這些產品業務方面的調整單獨羅列出來，作爲一定工作時間內的開發工作，既是某次『產品迭代』的內容，也是個人待辦的列表。
落地方法
瞭解了產品改進的業務以及來源情況，下面就是『產品改進』的相關落地方法。
整個『產品改進』業務分三個部分進行考慮：
- 事前討論
- 事中監督
- 事後反饋
遵循如下流程：
涉及到角色：需求提出者、產品人員、開發人員、測試人員。
事前討論
可以具有一個需求池，一些用戶反饋的需求，或產品經理“拍腦袋”想到的內容，統統丟在這個池子裏，這一部分可以叫做『需求管理』。然後，定期定員召開需求評審會，也就是所謂“事前討論”，在實際動手前，大家坐在一起商討評審三方面信息：
- 哪些需求可以滿足 (What)
- 這些需求交由誰處理 (Who)
- 初步地規劃怎樣處理 (How)
所謂定期，可以是每月或每段週期內的某個固定時間點，例如每月的1號，也可以是每次版本迭代後。
定員：一般是相關產品線的負責人，需求的提出者，相關技術人員。
事中監督
產品改進這個模塊，最終落地到工作上其實是對產品功能的新開發或是調整。所以，產品改進落實下來就是功能改進的管理。
當一個需求被判定爲需要滿足後，就要對這個實際需求進行細分化地處理。一個需求在經過分析設計後，可能拆分爲N種實際落地的功能，這一點我在《服務於敏捷開發的項目文檔》中提到過。
爲了更好地瞭解某個開發的進度，可以用『功能管理』將其管理起來。注意這裏的管理的基本都是單一的功能點，若是一個需求可以作爲一個模塊或項目，那應該是進入到一個新項目中。
功能管理：用於管理某次產品迭代時要增加或修改的功能。其主要作用就是監控相關需求實際執行的完成進度。主要三類角色參與：產品人員、開發人員、測試人員。可以利用看板的形式來進行管理，各個狀態和相關人員的工作。
其中一個功能的狀態變化情況如下：
事後反饋
當一個需求被滿足後，需要將其反饋出去。主要是兩種：
- 信息通知需求提出者
- 版本公告
在『功能管理』的【產品確認】時就可以通過通訊類工具通知原始需求提出者，以來達到正向反饋。然後在『產品迭代』進行【確認發佈】操作時，可以和公告進行關聯，以此來告知公司內部其他成員此次版本的內容，以及明確的真正的上線時間。
正向的整體流程大致爲下：
正向裏『產品迭代』是最後建立的，對於要迭代的內容，是手動從『功能管理』中挑揀的。
而要是想用『敏捷』的方式管理，操作流程是反向的：
首先確立好某次『產品迭代』時限，然後拉出需求池判定需求，將相關需求分派下去，創建『功能』工作項時和『產品迭代』進行關聯（相當於把這些工作項歸併到某個衝刺裏），然後再在『產品迭代』的確認發佈時，將未完成的『功能』工作項進行移動到下一『產品迭代』。
總結
產品改進實際運用的也是敏捷開發的模式，定時定量，將一次『產品迭代』作爲一個衝刺，監督其過程，明確其結果。
不同公司的具體開發流程會有差異，以上愚論僅作參考。任何東西都有個性化的一面，就像加勒比海盜裏說的那樣
法典只不過是一些指導，它並不是必須遵守的規定。
