Re: [轉] 那些台灣軟體產業所缺少的–心有戚戚焉

看板Soft_Job作者rv180 (顯影)時間12年前 (2011/10/25 17:50)推噓3(3推 0噓 8→)

留言11則, 4人參與討論串1/1

-- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.136.52.127

推

rofellosx

10/24 12:18,

10/24 12:18

→

iincho

10/24 22:15,

10/24 22:15

推

littlethe

10/25 01:24,

10/25 01:24

→

Baternest

10/25 09:52,

10/25 09:52

→

Baternest

10/25 09:54,

10/25 09:54

這一系列看下來真是心有戚戚焉... 小弟第一間公司是間頗具規模的公司，但版本與Bug管控=>沒有！後來在客戶要求下，是用Excel...XD 個人是覺得版本控制有兩個目的： 1.功能區分 2.Bug管控老一派的工程師總覺得這些玩意礙手礙腳，覺得那是老闆或大頭拿來盯人的工具。 (事實上他們也這麼做了...) 在一間股票上市上櫃的高科技公司，推這個居然推不起來 XD 後來轉到一間小公司，在主管與老闆支持下，架了個簡單的BugZilla。我可以說，這種東西絕對對大家都有幫助！各部門都能在第一時間通報Bug，省去以往溝通上的問題。例如以前：FW發現有EE的問題，要從三樓跑到四樓找EE，找到後要花30分鐘吵架，EE才會承認這個問題是屬於他們的。有時候還要把ME拉進來，大家再吵個30分鐘，確定這個狗屁Bug到底是誰家的，這時候你花了一個小時，才能從這個根本與你無關的Bug 脫身。現在：Bug上系統，一開始雖然我們認為這是EE的問題，但其實ME與EE都收到信，EE發現問題不屬於他們的，他們會轉給ME。當然，ME可能在第一時間就意識到這問題其實是他們的，在EE通知他們前，他們可能已經處理好了！還有，絕大多數老闆、主管與工程師，都視Bug為財狼虎豹；但是其實Bug是很重要的！一個系統好不好、穩不穩定，就是看測試期間測出的Bug數量與內容來決定！比如說我做一台汽車，從開發到量產有1000個Bug，你說你做一台飛機，只有10個Bug，那你會敢買那架飛機嗎? 一個產品越複雜，Bug就一定越多。因此當我們要做一個產品時，我們就能預估它應該要有多少個Bug，也因此我們能夠過以往修正Bug的速度，來推測產品完成的時間表。也能透過Bug的數量，來推測產品的成熟度。此外做軟體的最吃虧的就是績效難以評比，此時Bug就可以拿來量化了，我們可以透過解決了多少Bug，來評估個人或是Team的績效。解決Bug的方法甚至可以申請專利，替公司或是個人取得額外的利益。無奈的是絕大多數公司(尤其傳產)，見到Bug都像鬼一樣，只要有人跟我說，我們的產品不能有Bug或沒有Bug，我就知道這個人沒Sense... 這世界上沒有沒Bug的產品，多或少而已。這種口號留給消費者吧... 事實上如果是代工性質的產業，對客戶來說有版本控制或是Bug回報也是很重要的。因為客戶只知道我給你錢，你把我要的東西做出來就對了！當案子Delay時，他們會覺得你欺騙他們，因為你跟他們說一切順利，沒有問題，但是時間到了，東西卻出不來？！(尤其是美國客戶) 現在很多大廠，你要幫他代工，可以，但是他們會看你的公司，如果沒有一個完善的管理系統，他們便會很慎重的考慮合作的問題(尤其是日本客戶...毛很多) 最好的情況是，你的系統客戶也能上，這樣客戶能隨時追蹤專案的情況，客戶會覺得他們什麼都知道，自然也不會來煩你。 (你才不需要三不五時接待從日本飛來的超級工作狂，或是從美國飛來不知道是出差還是觀光的觀光團) 同時客戶也會知道案子難易程度，一旦發生Delay，他們也能夠接受，因為他們能從系統上知道，這個案子比他們想像中難，有的時候甚至他們還會覺得賺到了(還好這案子是外包，不是自家花時間做...)。善用管理系統優勢： 1.提升部門間協調 2.客戶交流窗口 3.掌握專案進度 4.工程師自我時間安排 5.部門/工程師績效依據不過話說回來，這種東西應該是PM在建立的，怎麼好像都是SW工程師在搞...= =" -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 125.231.209.12

推

kkc0828

10/25 18:44, , 1^F

10/25 18:44, 1^F

→

kkc0828

10/25 18:44, , 2^F

10/25 18:44, 2^F

推

b6byc

10/25 18:50, , 3^F

10/25 18:50, 3^F