編輯導語：上次我們談了如何圍繞需求背景搜集信息，那麼當我們搜集完企業内外部信息後，要怎樣将搜集到的信息整理成績效管理方案呢？本文圍繞信息整理以及方案設計這兩個方面展開，對做績效考核模塊感興趣的童鞋快來看看吧！

搜集完企業内外部的信息，我們對績效管理有了新的認識。

搜集信息的步驟具體可見 《手把手學做B端需求：績效考核模塊（上）》

接下來需要進入到整理信息步驟，以及最後開啟設計方案。

一、整理信息

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

二、設計方案

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

1. 功能分期

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

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

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

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

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

2. 功能設計

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

1）線下确認好對應模闆

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

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

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

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

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

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

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

三、尾聲

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

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

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

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

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

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

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

題圖來自Unsplash，基于CC0協議

,