編輯導語:上次我們談了如何圍繞需求背景搜集信息,那麼當我們搜集完企業内外部信息後,要怎樣将搜集到的信息整理成績效管理方案呢?本文圍繞信息整理以及方案設計這兩個方面展開,對做績效考核模塊感興趣的童鞋快來看看吧!
搜集完企業内外部的信息,我們對績效管理有了新的認識。
搜集信息的步驟具體可見 《手把手學做B端需求:績效考核模塊(上)》
接下來需要進入到整理信息步驟,以及最後開啟設計方案。
一、整理信息以設計需求為目的,來整理搜集到的信息。
這一步可以着重對比:常規管理辦法VS自己公司的異同,這樣可以進一步追蹤造成不同的原因,也是為了可擴展性做進一步的思考。
推薦【人 時 物 權】框架進行分析。
- 人——有幾個角色會參與到這項工作中,每個角色會承擔的責任和義務是什麼;
- 時——該項工作和時間的關系;
- 物——績效管理的信息共分為哪些類型,那些是不變的,哪些是可變的,哪些是可配置的;
- 權——不同角色在系統中的權限是怎麼樣的。
按照這個框架,本需求整理出的結果如圖。
可以看到,在人/物方面,我司和常規做法存在着大量不同。
進一步把人單拎出來,單獨分析。
常規績效考核的四步包括:
- 企業設定績效規則,包括要考核哪些指标,以及計算結果(完成率或加權總分);
- 員工/管理者設置期望達到的目标;
- 員工設置目标值後逐級審批;
- 領導周期性檢查績效達成情況。
而我司現狀要求的步驟不同,由三步構成:
- 設定考核。項目考核主要由甲方驅動和設置,内部有針對崗位和業務部的考核。
- 績效填寫。無法從甲方取數時,績效結果依賴于考核人自己填寫。
- 領導周期性檢查績效達成情況&員工上報的績效分析。
除了最後查看的步驟大體一緻,績效模版生成到産生數據的邏輯都不太一樣,所以基本判定為我們現在要求的是一種比較特殊的流程。
再進一步把事(績效)拎出來。
首先窮舉不同績效模版的模式,然後歸納總結成一張績效考核的字段全表。接着對表格的各個部分進行分類,明白每個類别的作用,進而考慮到每個類别在配置頁面中是否需要體現。
關于績效管理的信息分析,到此為止告一段落。
到現在你應該了解了績效管理對于企業經營的意義,線下實施績效管理的一般方案,以及我們服務的企業和常規方案的不同在哪裡。
二、設計方案信息的整理完成後,接下來我們需要進入方案設計了。
1. 功能分期
先不要着急畫UE,我們還有更重要的事情,即需要就現有資源,設計整個模塊的産品演化路徑。這樣能給到業務部門清晰的規劃,我們計劃分多少期完成什麼樣的需求,未來計劃可以支持的類型有哪些。
從本次的案例來說,我們可以用四分法拆分現有需要支持的所有績效考核事項。
分期以後,指向的工作進一步清晰了。
首先會支持客戶制定績效,客戶處查看績效的模塊,未來這類需求都用定制模版的方法來實施,即業務說明需要統計哪些内容,以及對應的目标值等數據是多少,開發針對該種情況單獨定制一個模版。
未來會擴展支持通過後台字段組合,配置生成對應的考核模版,這樣意味着我們對于模版後期還要做更多的投入,且要建立對應的模版指标庫,才能實現系統自動生成考核結果數據。
2. 功能設計
就一期功能而言,操作SOP如下。
1)線下确認好對應模闆
- 模版需要填寫哪些内容;
- 哪些内容是已經填寫好數值的;
- 哪些内容是需要被考核人填寫的。
2) 配置好考核模闆後,模版展示在列表中
- 有查看/編輯權限的人,可見該考核模版;
- 如果指标等數據有修改,産研團隊人工協助修改。
3)可以通過編輯功能,調整相關信息
4)對應用戶,可進入查看/編輯數據
所有人可查看的數據範圍受數據權限約束。
對應SOP設計完成後,記得盡量和業務同事核對一次。避免偏差。
三、尾聲這個需求的最後呈現,說真的并不大複雜。考慮到業務對績效模塊的價值認可度比較有限,時間又緊張,設計了簡單的但未來可擴展的方案。
但是由于經過了大量的信息搜集和分析,至少能從幾個方面得到收益。
第一,基本已經對這個模塊未來會如何發展了然于胸,腦中已經至少有了一二三期規劃。業務再提類似的需求,都能做到胸有丘壑心裡不慌。
第二,通過搜集數據,也能發現這個模塊和薪酬模塊,BI模塊有着千絲萬縷的關系,那未來這些模塊需要開發和叠代的時候,可以成為當仁不讓的人選。
第三,可以把自己對這個模塊的未來規劃,在一開始就和開發溝通好,盡量結構化一些數據,雖然界面上還沒有支持自定義配置,但未來是需要往這個方向擴展的。産品是産研團隊的上遊,不能隻敢眼前的活兒,不然整個産研團隊也會經常被突入其來的事情困在眼前。
以上就是關于這個模塊的設計心得。下次再見~
本文由 @假裝是運營 原創發布于人人都是産品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
,更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!