2009年5月19日 星期二

烏龍綠

Standard
人生難免被親近的人搞大烏龍,雖痛苦難耐,但卻可以讓現實強迫自己看清一些事。近來,某個好友,希望我能助他完成一些緊急的 Project,因為可能需要我長時間工作且讓我無暇接案,所以,他極為誠意的『盡量』開出高價碼,並請我到公司工作每周 40 小時,為期三個月,且因為有限於我的 Schedule ,他也同意可以是晚上半夜去,只要達到工作時數。

基於朋友立場,價碼多一點少一點不是問題,只要能讓我夠承擔家中的經濟壓力即可,當然,無論是就現實狀況可否容許來看或是基於朋友立場,經考慮過後,我也願意接受這樣的短期委託。所以,便開始將現有近行中的案子一一轉包他人接手,反正朋友本來就是該互相挺一下的,就沒想太多的做下去了。

一切溝通過程原本是很順利的,但是,等到了確定要開始 Go 的時候,一個事後補上的附加條款,令人當場心灰意冷,冷眼以待。這條件主要是一個確認考績的機制,大致上如下:
  1. 以考績決定可拿到之酬勞百分比,其分為四個等級:A(100%)、B(50%)、C(25%)、D(0%)
  2. 評定時程和依據為 Weekly Review,被 Review 的任務清單由開發者(我)和專案負責人經討論而定。
  3. 一旦有一項工作任務項目完成不合要求,即為 B 等,依嚴重情形則可能為 C 等甚至 D 等。
一切看似合理,但前提是:
  1. 我要保證三個月案子必需完成。
  2. 有至少三個以上之 Project 會同時進行,另外還包括突發狀況的任務,列屬雜事類。
  3. 每周至少40小時在有人監督之公司內工作。
  4. 所有的 Project 酬勞之『總和』,才是他『極為誠意』所開出的高價碼。
沒錯,光是這幾項條件,其實裡面就暗藏種種玄機,令人大為不快。

矛盾

其中看似最合理的部份『被 Review 的任務清單由開發者和專案負責人經討論而定。』,實為最不合理之處,因為連專案負責人都沒有權力和開發者決定每周任務的數量。矛盾的重點在於,三個月內案子就必定要完成,每周應有的工作量從一開始就決定好了,根本其實就沒有討論商議的空間,一但有空間,最後案子一定完成不了。

難以客觀公正的評分

因為案子不只有一個,所以可能會互相影響甚至占用其他 Project 的時間,所以評定分數可能會被其他 Project 的工作給拖累,一旦有其中一個 Project 出狀況而占用多點時間,其他 Project 極可能因此被影響到只有 B 等,立即減薪一半。況且,就算開發人員能力再強,也有可能就算一周 40 小時以上都砸進去拼命做,也做不完的情形發生,這樣並不是開發者產能不好,而是人力不足,責任其實並不在開發者身上,那為何開發者依然不能拿到 A?

從這項制度看來,打從一開始,就沒任何機會得到全部酬勞,更別談還有一個有隨機任務的雜事項目,讓整個工作內容的複雜度更深了一個等級。但理論上來說,該制度應用在 PM 身上是合理的,因為 PM 管的 Project 很單一,當人力不足時也有權力外求,但套用在開發人員上,就並不是這麼一回事了,只能看做變相的壓榨員工。

雖然能夠理解為何定出這評分制度,和感覺到該好友的心急,但如此不合理的制度,會令全天下人都無法接受,當然我也當場拒絕了該工作模式,只是頓時沒有收入和案子,令人陷入困境。這烏龍雖然不是他所願意,但的的確確是他所捅出來的。俗話說『親兄弟明算帳』,一開始就不該因為朋友一場,什麼都不想的茂然相挺,該先簽訂好契約,以免事後的烏龍,造成難以承受的損失。

曾幾何時,也步上的無盡的接案之路,接案的優點在於賺的錢多,但缺點也不在話下,壓力大肝也爆得大,更重要的是,案子數量的不穩定,也會造成有一頓沒一頓的窘境,有鑑於此,有案子就全都接,變成一個自然的反應,哪怕收到過量,最後淪落到轉包也一樣照單全收。

接案最令人嚮往的是,每個 Project 都是一個新挑戰,你可能碰到的是從未著墨的領域,又或者是半生不熟的世界,每次都可以學習新技術、研究新事物,處處充滿無限驚奇。做到最後,總都會突然發 現自己彷彿『十八般武藝樣樣精通』,不過仔細想想,其實『梧鼠五技而窮』的道理,體認最深的應該是自己才對。

話說,這次整個事件,也證明了我急於想脫離亂七八糟到處接案的心理,而希望能有穩定些的案子或工作,讓自己不用這麼累和精神分裂,一直賣技術和時間,真的和賣屁股沒兩樣。此外,大家都明瞭,真正能賺錢的不是超高竿的技術而是 idea,可悲的是一直以來都沒空去落實,這也是為什麼想脫離目前狀況的原因之一。如果可以,未來希望能相約數個好友、同好,成立公司、工作室,有比較穩定的事業呀!

後記

現在落得兩手空空,無論大小懇請有案或合作計畫就找我討論,感謝各位!