大家對於軟體人力派遣的接受程度如何？

yihan1028 2013-09-17 17:51:13 ‧ 10465 瀏覽

分享至

您的見解是？歡迎大家討論

登入發表討論

直播研討會

{{ item.channelVendor }} {{ item.webinarstarted }} |

直播中

6 個回答

sula3065408

iT邦研究生 1 級 ‧ 2013-09-17 20:00:31

最佳解答

軟體人力的派遣應該用啥單位計價？
時間？
專案？
按件計酬？
字數？
今天派遣的人手真的能力完成專案嗎？
如果混時間呢？

軟體開發不是人力壓進去就一定有成果的，案主真的這樣搞出個東西出來，應該也算是個妖怪系統了，不然就是個畸形跟怪胎，軟體也不是開發出來就沒事了，系統上線測試、使用，衍生出問題之後的修正也是個麻煩，派遣人力在專案結束之後，應該要理會業主嗎？

維護是業主的責任。

整個派遣制度基本上是設計來壓榨工人的系統，讓案主免去社會責任跟往後的成本，軟體開發可以用寫100行垃圾碼混過時間，實際上只有10行效果，更糟的是他還會吃掉你系統的效率，而且這些人要是打著，你要他們寫什麼就寫什麼的心態，系統有缺陷也是照寫，反正你團隊在空轉那是你家的事情，況且你空轉就需要更多的時間，那專案收不了山，鬼打牆走不停的情況下，派遣人力的收入才會穩定，軟體開發這些人要賣的不純然是時間，有很大一部份是腦力。

合約能綁什麼效率出來？

如果計價的單位是時間的話，根本不可能，如果是專案的話，那不如就切割出來乾脆外包一整個更省事，會用到派遣人力就是上頭出錢的人不會切，可能是顧問在建議，用傳統的瀑布式的專案搞法在走，不然幹嘛用派遣？

軟工可以派遣，當然PM可以派遣、SD可以派遣、SA可以派遣，整個團隊大多數是派遣進來的都有可能，你覺得這種團隊的成品，能動就算是OK了，以後要維護喔，哈，誰接誰倒楣，而且這些人沒必要幫你省成本，架構好的架構、好的設計方法，一切以交差沒被驗出來為最高原則。

態度不積極不見得表現在外，有時候是藏在字裡行間，或是架構設計上，同樣的寫程式，好的架構維護起來很輕鬆，壞的習慣寫出來的程式，改起來就痛苦萬分，光一個不用定義用常數給你到處copy-paste這點小事，差距就很大了，反正code愈亂，麻煩的又不是一開始寫的人，業主付的是鐘點費而已，怎麼寫你咬我，看業主驗到什麼程度，就出幾分力就好了，多了都是種浪費，時間太多還可以寫個工具把原先整齊的東西打亂交差，其實還蠻有趣的。

既然福利比不上正職，那薪水應該是多少？

理論上應該約是原先市場行情的兩倍左右，仲介又抽掉多少比例？

軟體派遣是很詭異的系統，不如發包工程找個頭承接。

回應 5
分享
檢舉

看更多先前的回應...收起先前的回應...

yesyesok iT邦研究生 4 級 ‧ 2013-09-17 21:39:04 檢舉

大大講得比較正確= W =
我也大多從事派遣的~ 基本上即便真的有心想做好
但受限於不穩定，做白工，跟派遣的工作一般都爛缺
所以到最後就是如大大所說東西有做出來就好
因為案子結束就是拍拍屁股走人，講白點就是
拿完錢走人，以後出問題誰理你們，要用派遣就要有那個疸承擔風險
要省錢用派遣又要對方負責，人也是要生活，不然你來做看看

Ken(Bigcandy) iT邦大師 1 級 ‧ 2013-09-18 11:14:50 檢舉

你的質疑/問題當然存在，沒錯
但那是ooxx的案主
要是我，會接著簽維護合約，同時間，另有顧問確認程式碼的內容、寫法、交接狀況

所以我才說，只有『溝通』上不方便而已，品質？我不怕。

yihan1028 iT邦新手 3 級 ‧ 2013-09-18 14:55:43 檢舉

謝謝諸位。很好的分享

sula3065408 iT邦研究生 1 級 ‧ 2013-09-18 20:30:45 檢舉

只拿出條香蕉，基本上也只請的起猴子。

當你拿出維護合約的時候，有一定要簽嗎？
前面一段收了錢，下工，後面那一段，基本上已經是你家的事情了，不簽有違約嗎？
那一開始在僱用的時候，給的合約就包含維護，那應該給多少費用呢？
一般行情的兩倍、三倍，還是更多？

光溝通上不方便，有人在推、拖、拉，反正時間成本也是算業主的，應該也不痛不癢吧。

光心態上產生的消極抵抗，可以搞的花樣可多的勒，這些工程師不是一般搬運工，腦袋跟邏輯根本上不差，把環境這樣搞，只會造成這群人會額外花腦筋跟你作對，光是這些耗下去的效率折損，可能要再精算一下。

顧問的確可以確認程式碼的內容、寫法跟交接情況，這些東西也的確可以做出某種程度的水準，寫code五分鐘，看code要不要一分鐘，你確定顧問全看完、讀通、理解？

code有問題，薪水就不發嗎？
再模糊一點，可以動作的code，顧問看不懂怎麼寫出來的，這樣薪水要止付嗎？

按照我的經驗，不可能規劃細到程式碼內部作法，頂多就是介面、行為開完就了不起了，驗證也按照規格走，這已經是很好的設計了，區塊內的作法還是得讓工程師自己搞，可能某人寫出來的code，不見得每個人都能相互理解。

頂多開到黑箱驗完就很精實，要到搞白箱進去函式、流程一個一個的檢查，時間成本也不低阿，專案後期時程壓迫感大的時候，能不能保證品質，我想大家都有經驗的。

照這樣算會同意這種條件的工作，在某種比例上能力可能不是很理想，就算顧問把技術風險搞掉了，這些人寫程式的手法粗糙的搞，copy-paste應該是很常見的東西，尤其是你也沒多少時間驗收的時候，反過來說，為了讓品質安定下來，業主得要承受一直滑掉時程的成本，顧問及管理階層可以猜想，後面草草了事的機率會很大喔。

修改

sula3065408 iT邦研究生 1 級 ‧ 2013-09-18 20:51:36 檢舉

倒過來說，當你僱用的工程師使用了比顧問技巧還高的語法的時候，會發生什麼事情？
顧問看不懂之後呢？

都要限制在顧問的能力之下，當然就是顧問說啥做啥，沒說就不做也可以，亂做也可以，只要功能對就行了。

登入發表回應