Re: [閒聊] 最後一根稻草... 嗎?
※ 引述《Lapha (lapha)》之銘言：
: ※ 引述《comate ()》之銘言：
: : 最近常在思考一個問題:
: : 如果 programmer 寫出來的東西是可以輕易找人接手替換
: : 還有需要進入如此繁複的軟工流程嗎?
: 前一篇可能沒表達完整, 請見諒..
: "換人"這件事, 一直都不太可能"輕易", 簡單地說, 專案開始了以後, 我們
: 幾乎不可能只換一個人, 卻不用付出額外成本的。如果能讓原始成員一路
: 做下去, 對管理階層來說, 成本應該是最小的。
: 所以, 問題變成, 如何降低此成本? (即: 不得不換人的狀況發生時, 怎麼辦?)
: 關於所提"...專案本身需要高門檻, 制式文件能帶的助益..." 首先, 制式
: 文件是用來描述目前的工作現狀、規劃考量, 各部份該有的功能和介面等資訊,
: 而不是一本武功秘笈, 讓新人進來, 苦讀五天五夜就神功大成, 然後一腳把老人
: 踢開 XD
========
製造業喜歡講 "叢聚" 效應, 也就是同類型的零組件有不同的供
應來源. 印象中早期的電子產品業在設計電路時, 如果有個零組件是
只有一個單一來源, 這樣的設計是會盡量避免的, 但是在造產品時卻
又故意跟其他同類型產品盡量在大組件上不能互換, 這種情況在電視
音響業非常明顯.
PC 電腦業顯然不是如此, 這也是早期的家電大廠商都未加入PC
產業的一個主因. PC 產業是靠不停的換代發生產品快速替換的現象,
但零組件在相當大塊的範圍是可替換的, 當產業合併到變大時也就是
notebook PC 的時代, 此時的現象就跟家電業很像了.
印度的軟體公司其規模都號稱很大, 也就是聘用的人員都號稱上
萬人以上. 如果公司能掌控的技術人員夠多, 又能把人的專長分門別
類的做好, 而包的工作又夠多, 性質相近的一定會很多, 有個模組因
人或小團隊上不來時, 找另外一個團隊代替重做, 只要介面相符, 模
組自然能替換, 這就像換不同廠牌的軟碟機, 管他是那個廠用那個IC
零件做出來的.
在人員專長與團隊上, 這些相同專長的小團隊都是 overlap 的,
管理的重點就是這些小團隊的情報掌控. 人力委外與仲介如果大規模
的發生, 只要有足夠的連絡網路就會發生叢聚效應.
電腦程式師在某種程度上就是古代中國皇家統治系統的識字文官,
使用同一套八股公文在做情報溝通, 同時用公文在命令執行系統(如徵
伕徵稅納糧, 這裡就是電腦與網路)照著公文文件辦事.
寫文章本身就是不容易維護, 但就文旨另寫一紙是可以的, 要抄
抄改改, 同一個人或同類型的人還是容易辦到.
基本上, 台灣的軟體公司沒有委外仲介的大環境, 也沒有掌控大
兵團人力的習慣, 靠中小企業自動合成一條龍又因惡質的內需環境無
法合作, 也沒有 PC 硬體產業一上來就是外銷, 供不應求的環境, 當
然這跟單一軟體可以大量複製有關. 基本的差異就是不能大量取得各
種軟體需求.
小公司要有彈性, 除非能快速應用大量委外與仲介, 這些叢聚效
應的供應來源情報就不能少, 甚至還得間接的養才能掌控可靠的供應.
: 在前一篇中有提到, 不能把釘子塞進螺絲孔, 指的就是: 平時就要培養、鑑別成員
: 的能力。
: 如果某個位置的能力需求很常見, 例如:只要熟C語言,那就面試時仔細審核即可;
: 如果某位置需要的能力, 是該專案特有, 一般面試者幾乎不可能有, 那就可以考慮
: 之前版有友所提 Job Rotate 方式, 以培養各成員的能力。
: 這個是重要的前提, 就好像我們不能寄望一個美工人員能在看了某某文件後, 第二天
: 就開始去設計資料庫架構。文件寫出來的目的, 是讓能力ok 的接手成員趕快上手,
: 不是去讓一個新人打通任督二脈用的..
: 了解這一點, 就知道"換人"一點也不"輕易", 首先要去找到符合能力需求的人就
: 要時間, 再來得去驗證他的能力, 然後幫助他上手, 這些成本, 都算在專案進行的時
: 程之中, 對專案本身的破壞是很大的。
如果人力成本夠低, 雙線同時進行, 再相互比對並非不可以, 畢竟正確與
如期的交貨是最大的競爭力. 落後或失誤的團隊也是可以繼續投資培育的, 能
力總是被培養出來的. 至於天才, 那就是範例, 可以當樣本被學習, 能複製天
才的能力, 那又是一種競爭力.
: 如果某位成員, 是已經培養很久, 具有各式能力, 而且又有很好的工作默契和
: 共識的老班底, 那麼失去他, 可能會覺得欲哭無淚吧~ XD
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.115.6.234
討論串 (同標題文章)
完整討論串 (本文為第 7 之 15 篇)：
Soft_Job 近期熱門文章
PTT職涯區 即時熱門文章