由 Jeff 看世界

原文：拿軟體品質來評員工績效，沒搞錯吧?

小弟前兩週也被主管考核 KPI 了
對於我目前的工作並非如軟體工程師或業務
小弟的職稱是系統分析師，KPI衡量指標如下
(自我評量及主管評量以1~5 分評分)
1.對 X 平台系統的熟悉掌握度?
2.文件是否如期交付?
3.文件製作是否符合客戶需求?

專案開發過程是一個團隊合作完成
上由 PM 下至 SA/SD 到 PG/QA
軟體品質控管套用最常說的 V Model
各階段的產出與執行透過驗證與確認達到軟體品質
先不討論現實面是否可以達成或如何執行
軟體品質的好壞似乎等同於專案的成敗
因此軟體品質也被拿來當做考核的指標

回歸正提筆者是新進員工
因此第一項指標的衡量是必定需要的

但第二三項筆者認為是個KPI大陷阱如何說呢?

2.文件的交付是否準時?
老實說起來應該與第三項合併或是在細分
準時交付並不代表文件品質達到客戶滿意!!
準時交付並不代表符合專案需求完成!!
準時交付並不代表能被專案成員正確執行!!
可能上述的幾點可以被說成是SA/SD 的個人素養與專業道德
但考核的目的不就是為了分別出個人對於工作上的績效表現嗎?

3.文件製作是否符合客戶需求?
符合客戶需求這六個字看在每個專案成員的眼中
永遠都是很沉重與不可能的任務
需求不斷的變更理論上都該不斷的更新PMP WBS SA/SD 文件等
但專案通常都是趕..趕....趕
聽起來好多藉口~但事實就是如此 至少筆者目前為止Run 過的專案都沒做到過
相信做過軟體專案的同業會有一樣的感觸吧!!
文件的品質或產出固然是對客戶最直接的回饋
但是無形的服務及態度也是提升客戶滿意度與專案順利的無名英雄

光這兩點筆者就發呆了十分鐘才勉強填出個數字~填多少呢秘密:p

其實筆者不是否定 KPI 的衡量持反對或抗拒想法
只是想提出KPI 所衡量的項目與衡量的方法
不論是使用360 度考核或是一般自評主管評的考核
最根本考核項目該更Match 各職稱/職位的工作價值
或許是比較好的解決方案
但老實說筆者也暫時想不出該如何考核自己的工作價值
或許要等待更多先進們的討論與研究~~

XPlanner is a project planning and tracking tool for eXtreme Programming (XP) teams.

The customers pick the features to be added (user stories) to each development iteration.

The developers estimate the effort to complete the stories either at the story level or by decomposing the story into tasks and estimating those.

Information about team development velocity from the previous iteration is used to estimate if the team can complete the stories proposed by the customer.

The XPlanner tool was created to support this process and address issues experienced in a long-term real-life XP project.

XPlanner Install Guide

XPlanner Overview

專案管理知識體系，越來越重視專案管理風險結構分析
－專案管理知識體系2004版中，針對風險管理新增風險分解結構（Risk Breakdown Structure；俗稱RBS），讓專案經理可以由範疇、成本、時間與品質目標中，分析各構面的風險值與衝擊程度。

－專案計畫下的工作分解結構讓專案經理可將工作細分後，再逐一指派成員執行。高度完整性的WBS可讓專案經理控管與追蹤專案進度。

－風險分解結構也基於相同的精神，基於完整的RBS所擬定的管理計畫可提升規避風險的機率。

摘錄自ITHome Online
你的專案管理管對關鍵嗎? 一文