Re: [閒聊] 深度討論:如何有效促進員工績效

看板toberich (創業)作者saja (莎亞)時間15年前 (2010/07/25 01:00)推噓1(1推 0噓 1→)

留言2則, 1人參與討論串3/3 (看更多)

A大很可愛的在水球回答了我的問題～～不過我有點希望a大可以發文一起討論！創業本來很多老闆一開始都認為只要有一台電腦一顆腦袋就開始軟體業的創業之路我在SALARY板上看到一個大大說因為FB跟微軟的崛起加上無名小站的成功很容易就讓創業主有一種錯覺認為軟體業的成功很容易也許推出一個概念性的產品是很容易的一件事但是我想凸顯的重點是【管理軟體公司】這件事遠遠難過於傳產或其他製造業等行業「我們應該要用只用好人才」約耳說。軟體業與其他知識集中的行業一樣，績效難以衡量的程度跟政治人物差不多只能在事後補救或是嘉賞一個工程師的行為、決策可以埋下相當大的炸彈或是成為關鍵競爭優勢許多老闆都很天真的連UML都不願意做~我真的覺得很可怕或是一個不謹慎/天真的決策方針長遠影響產品未來的發展我想所有的知識集中產業都是一樣的容易成功也容易失敗完了以上好廢話請A大補充吧!!! ※ 引述《kuoyu (^_^)》之銘言： : ※ 引述《saja (莎亞)》之銘言： : : 在製造業達成KPI並且給予績效獎勵是很有用的呢!!軟體業卻非如此 WHY? : 製造業的績效很容易衡量產出數量良率等等 : 軟體業就不好衡量了不同工程師寫出功能一樣的軟體 : 兩人各寫各的怎麼知道好壞?如何給分? : 學校裡面老師可能會看程式碼誰寫的好分數給高 : 但是學生人數一多老師時間不夠就用結果論 : 程式執行結果正確的就pass 不對的就重寫 : 很公平很公正簡單明瞭反正對學生的要求已經不多了 : 據說某些老師只要學生能寫出九九乘法表就過關不稀奇了 : 但是業界就不一樣了哪個主管會看程式碼給分的啊? : 執行起來ok就好了嗎? 不！還有很多要考慮的 : 有沒有哪個地方也瑕疵會出現bug?光這點就不是三兩下可以看到的 : 當一個系統越龐大自己越不容易看到bug 越怕被別人抓到bug : 一個系統的產生往往從需求分析開始做起 : 需求分析做的好資料流程就好弄清楚 : 才好規劃架構切割不同的模組 : 慢慢分割分割切成比較小的單位 : 然後才是寫程式寫好個別測試組起來測試 : 測試有問題再檢討問題在哪裡 : (嚴格說起來需求分析之前還要徹底的客戶訪談) : 如果前面做的不好後面就很難收尾 : 一般人會看到的只有「寫程式」那已經是中後段的部分了 : 當然也有人什麼前置作業都沒有直接寫程式 : 但是那只能應付小程式規模大一點很容易就科科了 : 想想看這些要怎麼去看績效好吧！路遙知馬力 : 給他實際上線看看不過有些bug可能要上線一兩個月才會被發現 : 好吧！那就一兩個月之後看看但是也可能半年甚至更久慘了 : bug先不談好了這案子張三八個星期完成李四要十週才生出來 : 這樣看起來張三的團隊能力比較強一些 : 一年之後客戶想要一個新的功能看看各生產線的即時績效表 : 張三跟各組長研究一下兩個星期可以加進來 : 加上測試預計一個月內結案 : 李四二話不說打開.ini檔改個設定一半的功能出來了 : 剩下的兩天可以新增完成因為李四一開始就預料到客戶會有此需求 : 由於不更動到原始程式流程只要產線停機時更新程式就行 : 加上測試預計兩個星期完成這樣一來李四比較強了 : 這時強者王五發現一個關鍵馬上寫個小程式 : 直接進DATABASE撈資料因為是獨立的小程式 : 就算on th fly都不用怕 : 這績效怎麼打啊? -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 118.231.168.108