編輯導語：對產品而言，獨立負責模塊是很重要的事，但如何做得更好，是值得思考的問題。本文就將圍繞需求背景和搜集信息兩個方面展開，推薦對此感興趣的朋友繼續閱讀，希望對你有所幫助，一起來看看吧。

還記得你頭一次獨立負責新模塊的興奮嗎？

對于很多產品來說，獨立負責模塊是職業生涯中的一個小里程碑，代表著你可以成體系的為模塊的產出的價值負責，可以肩負起思考它的過去、現在和未來的責任。

很多人也會認為，從0開始做一個模塊，沒有歷史負擔，不受過去牽累，是很簡單的事情。

但從0開始，也是在為這個模塊做打地基的工作，考慮得不夠周到，大概率會為自己和開發埋坑，導致未來迭代難度增加。問題再嚴重一點，甚至有可能演繹無法迭代、需要重構的悲劇。

希望以這次的需求為例子，一起探討：

• 如何盡可能全面地搜集信息，在下筆前做到胸有丘壑。2套方法，幫助捕捉業務描述不出來的需求細節，以及幫助產品短時間成為負責模塊的半個專家。
• 如何在拿到需求后進行全面的分析。這里提供一個在B端業務中非常好用的框架。
• 如何進行功能分析和設計實戰。這里話不多說，直接放上成果，供做這塊的童鞋參考，當然由于保密原因省略了一些細節，如果有需要，咱們可以私信溝通～

一、搜集信息

1. 確立目標

搜集信息是設計模塊的首要工作。

在績效考核這個具體需求的場景里，搜集信息的目的有二：

第一，全面了解績效管理的信息，達成對該事項的初步認識。

效果評定：未來業務部門對其他項目進行績效考核，自己能夠知道是如何操作的，甚至可以給業務提出一些考核流程的意見。

第二，通過全面的了解，設計出未來可擴展的產品方案。

效果評定：了解企業內部現有所有的場景，后續如何支持其他場景可以做到心中有數，可以在現有方案上平穩迭代和支持調研到的這些場景。

2. 5個搜集信息的渠道

通常而言，我們拿到需求，更常見的是直接向業務發起人詢問，但可能你會發現這樣的情況：

• 天馬行空地提出他的解決方案，言之這是他的經驗之談，你沒有足夠的知識和閱歷，聽之任之，結果上線后三天兩頭的修改，甚至發現管理邏輯上都走不通。
• 功能上線后馬上發現之前沒有聊到細節和特殊情況，沒能滿足上線目標，只有反復修改，每天疲于打補丁，搞得整個團隊都像熱鍋上的螞蟻。
• 功能上線后一切平穩，但過了段時間，遇到了類似的場景，之前大家沒有考慮到兼容性，導致需求迭代緩慢。

所以下文提供五個搜集信息的渠道，希望在信息搜集的階段能把基礎打牢，也更有和業務溝通的底氣，不至于一開始就被帶偏。

1）從通用資料中搜集

產品經理不可能面面俱到，事事知曉，我們需要信息來建立認知，并以此為基礎設計出有可擴展的方案。無論未來這個模塊產生什么樣的需求，都脫離不出現實的訴求，脫離不開企業和組織目的和發展規律，這些很難改變的東西，也就是所謂的【元認知】。

有句話說，這世界變化太快，是的，每天的新聞都在以爆炸的速度去增長，我們不眠不休的學習也是無法窮盡的，總得有點不變的東西作為心里的底氣去應對這些表現的變化。

以績效考核模塊為例。

它的元認知是是什么？不會改變和很難改變的是什么呢？容易改變的又是什么呢？

結合【WYH框架】我們可以得到如下信息。

不太會改變的

一般集中在事物的本質以及事務為何會存在。正常來說，來說差別不大，可以用于和業務達成共識。

績效考核是什么（what）

一種評估工作工作表現的方法。

在工作中，制定需要關注的指標，觀察指標并周期性地對指標評分，用以評估員工或業務的工作質量。

在組織中，這項工作往往是薪酬管理的前置部分，得出的數據可能成為薪酬考核的計算參數。

績效考核為什么會存在（why）

首先可以可以拆解組織目標到個人，在過程中可以自上而下地拆分目標，落實目標，保證大家朝一個方向前進。同時也會有甲方考核內部的情況，這種是用于甲方更好的管理多家供應商，用績效約束供應商進行更好的服務。

其次可以把好的標注明確地給到考核人?？冃且砸粭l一條的形式來呈現，每個條目有對應的目標和分值，應用smart原則來量化工作中的要求，讓員工有可以努力和改善的方向。

改變較小的

一般公司在做法和流程上會有所差別，但也是在大的方法論和原則上進行優化，總的來說，不會差異非常大，是需要和業務整體溝通的部分。

如何實現績效考核（how）

公司內部的績效管理步驟：經過設置指標——設置公式/參數——填寫目標——生成考核結果——查看數據/加工數據。

甲方給公司內部的績效管理步驟：告知關注指標和標準——系統或者人工對接指標考核數據——查看考核數據并采取新的行動。

這部分需要向公司確認內部是否是這樣的流程，差別在哪里，為何會有差別。

容易改變的

一般公司在實際的執行上會差距非常大，而且隔行如隔山，各個行業可能有更具體通用的方法論，甚至對于不同職能部門也會不同。這是需要和業務重點確認的部分。

某個崗位或者業務，如果需要績效考核應該這么做（how的細節）

不同崗位，不同公司設置的指標，對應的公示/參數，考核周期等等流程必然不同

這部分需要具體向需求方確認，明確需求范圍和特殊做法

梳理完成以上內容有沒有覺得自己更加自信，對于這項工作在組織中的意義，以及工作如何開展都有了基礎的認識呢？

既然成為了這個模塊的負責人，是有必要自主驅動，縱深地往模塊的基礎知識看看的。以上權當一個例子，你可以更加深入的去學習。

只要做到這一點，以下令人頭大場景你幾乎都能搞定。

• 業務不愿意說——你能通過一些專業的問題，在溝通中和業務建立起“你很懂哦”的心領神會，讓業務高看一眼，愿意傾吐。
• 業務經常跑偏，用一些你似懂非懂的詞匯有意無意岔開話題——你能及時在業務跑偏的時候提出問題，及時糾偏。
• 業務陳述信息顛倒矛盾，該說的不說，不該說的說一堆——用你的專業知識和框架思維結合在一起，一針見血的問出你要的問題，避免遺漏。

2）從需求發起人口中搜集信息

可以采用5w1h模版，搜集一下相關信息。

• Who：現在會考核那些人？是哪些項目上的？是哪些角色？
• what：現在會考核哪些指標？這些指標會變動么？表格上的各種規則，會變動么？會如何變動？郵件中有些信息，并非是績效管理模塊的，例如指標數據，例如員工總結，需要考慮展示么？
• where：是通過哪里呈現這些指標？
• when：這些指標什么時候會更新呢？一般考核周期是什么呢？未來大概會多久看一次數據？
• Why：考核數據會影響什么？如果數據不好，我們會采用什么措施？
• how：我們現在的填寫周期是什么呢？

注意：你的詢問對象，至少要涵蓋流程中的各項角色。例如這個場景中，會有查數據和看數據兩種角色，如果角色負責的業務，會影響到角色的行為，那么還需要詢問不同業務下同一個角色的工作流程。

注意：需要特別注意詢問數據變更的邏輯。是否會變，變得多與少，為何會變，變了以后會影響什么，這些都會和后期設計產品方案直接相關。

3） 從執行過程中的產出物中搜集信息

建立好了認知，就可以去做需求澄清了，在這個步驟中，不光要聽需求方講述，更要拿到需求方現在會產出的文檔。

為什么要重點強調產出物呢？

首先，它是階段性工作結果的體現，是溝通過程的中間產物，是現行的大家都認可的解決方案。產品的工作是把線下解決方案搬到線上，所以一切拆分工作都要圍繞產出物上進行分解。

其次，產出物是落在紙面上的表達，口頭表達信息會缺失，會有歧義，紙面上的文字可以很好的規避這些問題。往往口頭溝通中沒有體現到的問題，在產出物上都會得到澄清。

在績效考核這個需求中，我們就可以要到【績效要求表格】以及現在的替代法案【郵件】。

甲方考核的表和下圖類似，所以我需要拆分表格，明確表格中每項數據的來源和作用。

根據表格我們能大致分為兩個部分的信息。

一部分是甲方制定的績效規則，一部分是我們的實際表現，是績效結果。兩個部分的作用不一致，對應的操作人也不一致，是需要著重考慮系統如何去支持的。

考核指標/規則

• 日期：與考核周期相關
• 考核類型：考核指標分類
• 考核指標：甲方認為重要的事項
• 目標值：甲方認為應該達到的目標值
• 挑戰值：甲方認為應該嘗試的挑戰值
• 權重：甲方認為該項的重要性，是最后計算總分的參數

考核結果

• 實際值：每項考核的實際分數
• 得分： 根據實際值按照一定規則折算出來的分數
• 總分：根據權重算出來的分數
• 排名：所有供應商對比的排名

整理完表格信息，工作并沒有完。記得我們還有一個【郵件】的產出物么？

打開郵件，意外發生了?？梢钥吹洁]件中不僅僅是每日的考核數據，還有一些其他數據和工作人員的總結。

這時可以進一步回來思考：我們績效考核的范圍是什么呢？業務現在搜集的信息，和績效考核有什么關系呢？有了答案后，接著再思考這這部分多出的信息，是否要和業務做溝通，以及以什么立場和態度做溝通。

4）從組織內部其他業務線搜集信息

對模塊負責，當然要為它未來的價值負責。

所以你需要跨越當前需求方，去思考誰或者哪個部門可能還有類似的需求。模塊的終局，應該是可以支持到所有角色和部門的需求的。所以了解其企業內部其他人的需要，這一步需要主動跨越的步驟，對設計的的可擴展性非常重要，但也是很容易被忽略的。

在績效考核的例子中，我們就進一步去搜集了HR部門的績效考核數據，從而發現了績效規則的多樣性，充實了案例庫，也了解了這部分和薪酬管理的關聯。

5）從外部搜集信息

以上信息，搜集的都是企業內部的信息，可能會帶有強烈的企業個性化風格。

為了避免陷入定制化的困局，需要再看看外部信息，這時有兩種方向是我們可以去嘗試的。

一是提供類似模塊的通用產品，他們的流程和業務是如何做的。比如飛書有OKR績效，泛微有績效考核，CRM系統有對銷售的目標劃定。這些產品都可以成為考察的范圍，他們的通用化設計思路可以給后續工作帶來一些靈感。

二是其他企業是怎么樣做績效管理的?？梢詮陌俣任膸煺业娇己宋臋n，可以從人人查看其他產品的設計方案。在之前的搜索這部分信息的時候，自己很明顯的感受到，手頭在做的績效管理和大家的方案并不太一樣。大家的績效管理系統，更多的是體現員工自主定下績效，進行層層審批的這一過程。所以也才萌生了寫一篇文章的想法。

二、整理信息

以設計需求為目的，來整理搜集到的信息。

這一步可以著重對比：常規管理辦法VS自己公司的異同，這樣可以進一步追蹤造成不同的原因，也是為了可擴展性做進一步的思考。

推薦【人 時 物 權】框架進行分析。

• 人——有幾個角色會參與到這項工作中，每個角色會承擔的責任和義務是什么；
• 時——該項工作和時間的關系；
• 物——績效管理的信息共分為哪些類型，那些是不變的，哪些是可變的，哪些是可配置的；
• 權——不同角色在系統中的權限是怎么樣的。

按照這個框架，本需求整理出的結果如圖。

可以看到，在人/物方面，我司和常規做法存在著大量不同。

進一步把人單拎出來，單獨分析。

常規績效考核的四步包括：

1. 企業設定績效規則，包括要考核哪些指標，以及計算結果（完成率或加權總分）；
2. 員工/管理者設置期望達到的目標；
3. 員工設置目標值后逐級審批；
4. 領導周期性檢查績效達成情況。

而我司現狀要求的步驟不同，由三步構成：

1. 設定考核。項目考核主要由甲方驅動和設置，內部有針對崗位和業務部的考核。
2. 績效填寫。無法從甲方取數時，績效結果依賴于考核人自己填寫。
3. 領導周期性檢查績效達成情況&員工上報的績效分析。

除了最后查看的步驟大體一致，績效模版生成到產生數據的邏輯都不太一樣，所以基本判定為我們現在要求的是一種比較特殊的流程。

再進一步把事（績效）拎出來。

首先窮舉不同績效模版的模式，然后歸納總結成一張績效考核的字段全表。接著對表格的各個部分進行分類，明白每個類別的作用，進而考慮到每個類別在配置頁面中是否需要體現。

關于績效管理的信息分析，到此為止告一段落。

到現在你應該了解了績效管理對于企業經營的意義，線下實施績效管理的一般方案，以及我們服務的企業和常規方案的不同在哪里。

三、設計方案

信息的整理完成后，接下來我們需要進入方案設計了。

1. 功能分期

先不要著急畫UE，我們還有更重要的事情，即需要就現有資源，設計整個模塊的產品演化路徑。這樣能給到業務部門清晰的規劃，我們計劃分多少期完成什么樣的需求，未來計劃可以支持的類型有哪些。

從本次的案例來說，我們可以用四分法拆分現有需要支持的所有績效考核事項。

分期以后，指向的工作進一步清晰了。

首先會支持客戶制定績效，客戶處查看績效的模塊，未來這類需求都用定制模版的方法來實施，即業務說明需要統計哪些內容，以及對應的目標值等數據是多少，開發針對該種情況單獨定制一個模版。

未來會擴展支持通過后臺字段組合，配置生成對應的考核模版，這樣意味著我們對于模版后期還要做更多的投入，且要建立對應的模版指標庫，才能實現系統自動生成考核結果數據。

2. 功能設計

就一期功能而言，操作SOP如下：

1）線下確認好對應模板

• 模版需要填寫哪些內容；
• 哪些內容是已經填寫好數值的；
• 哪些內容是需要被考核人填寫的。

2） 配置好考核模板后，模版展示在列表中

• 有查看/編輯權限的人，可見該考核模版；
• 如果指標等數據有修改，產研團隊人工協助修改。

3）可以通過編輯功能，調整相關信息

4）對應用戶，可進入查看/編輯數據

所有人可查看的數據范圍受數據權限約束。

對應SOP設計完成后，記得盡量和業務同事核對一次。避免偏差。

四、尾聲

這個需求的最后呈現，說真的并不大復雜?？紤]到業務對績效模塊的價值認可度比較有限，時間又緊張，設計了簡單的但未來可擴展的方案。

但是由于經過了大量的信息搜集和分析，至少能從幾個方面得到收益。

第一，基本已經對這個模塊未來會如何發展了然于胸，腦中已經至少有了一二三期規劃。業務再提類似的需求，都能做到胸有丘壑心里不慌。

第二，通過搜集數據，也能發現這個模塊和薪酬模塊，BI模塊有著千絲萬縷的關系，那未來這些模塊需要開發和迭代的時候，可以成為當仁不讓的人選。

第三，可以把自己對這個模塊的未來規劃，在一開始就和開發溝通好，盡量結構化一些數據，雖然界面上還沒有支持自定義配置，但未來是需要往這個方向擴展的。產品是產研團隊的上游，不能只敢眼前的活兒，不然整個產研團隊也會經常被突入其來的事情困在眼前。

以上就是關于這個模塊的設計心得。下次再見～

本文由 @假裝是運營 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議