close
就職場工作來說，產出的評估是很重要的
本篇論點是：「系統分析的不受重視與胡搞，跟產出的評估有關」
本篇論點是：「系統分析的不受重視與胡搞，跟產出的評估有關」
對管理者而言，要不要同意做一件事情，多少都會做些評估，通常會看：
1.做了有甚麼好處(不做會怎樣)
2.做了有甚麼壞處(EX:增加成本)
3.可能產生甚麼樣的風險
1.做了有甚麼好處(不做會怎樣)
2.做了有甚麼壞處(EX:增加成本)
3.可能產生甚麼樣的風險
以系統分析來說：
1.做了有甚麼好處
一般論點是:釐清需求，避免做白工，讓使用者滿意
但換個角度來說，做了系統分析能減少多少成本，能透過獲利增加多少利益呢？
這些好處並無法用數字化表示，要做了才知道有甚麼好處。
2.做了有甚麼壞處呢
這個很明顯，增加時間，這甚至可以透過薪資計算出更詳細的成本數字。
而且有些需求提出者其實並不想花費時間在這種事情在上面
最提出需求的人而言，最輕鬆的做法就是他們隨便說說，剩下開發人員自己想辦法實現
3.可能風險
系統分析不是做了就能有成果
有時得看是誰做，以及有沒有克服一些系統分析的阻礙
有時做系統分析只是為了交差，可能是給不懂開發的人做做樣子，假裝很專業
也可能是工程師怨念檔不住，所以隨便找個人做系統分析交差一下
(最常見的是直接要求工程師自己做，但時程不變...)
1.做了有甚麼好處
一般論點是:釐清需求，避免做白工，讓使用者滿意
但換個角度來說，做了系統分析能減少多少成本，能透過獲利增加多少利益呢？
這些好處並無法用數字化表示，要做了才知道有甚麼好處。
2.做了有甚麼壞處呢
這個很明顯，增加時間，這甚至可以透過薪資計算出更詳細的成本數字。
而且有些需求提出者其實並不想花費時間在這種事情在上面
最提出需求的人而言，最輕鬆的做法就是他們隨便說說，剩下開發人員自己想辦法實現
3.可能風險
系統分析不是做了就能有成果
有時得看是誰做，以及有沒有克服一些系統分析的阻礙
有時做系統分析只是為了交差，可能是給不懂開發的人做做樣子，假裝很專業
也可能是工程師怨念檔不住，所以隨便找個人做系統分析交差一下
(最常見的是直接要求工程師自己做，但時程不變...)
簡而言之
做系統分析的好處並無法很具體表示
產生的代價卻可以很具體的表示
做了還不保證值得
做系統分析的好處並無法很具體表示
產生的代價卻可以很具體的表示
做了還不保證值得
我認為做系統分析是個信仰(相信做系統分析是有助於開發)
而對不懂技術的管理者而言，並不具有這種信仰，只看數字
就算同意做了，做的過程中也可能會做各種影響成果的事情
(「時間可不可以花得更短點」、「這個我沒空討論，你先做，好了我再看是否OK」、一直拖時間不為自己提的需求畫押...等等)
而對不懂技術的管理者而言，並不具有這種信仰，只看數字
就算同意做了，做的過程中也可能會做各種影響成果的事情
(「時間可不可以花得更短點」、「這個我沒空討論，你先做，好了我再看是否OK」、一直拖時間不為自己提的需求畫押...等等)
最後結果常常就是...
系統能跑就很了不起，然後邊用邊罵開發者做太爛．．．
系統能跑就很了不起，然後邊用邊罵開發者做太爛．．．
全站熱搜
留言列表
