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