Re: [URL] 軟體公司該這樣做：領導你的員工、而非管

[derekhsu (華麗的天下無雙)]

※ 引述《cc1plus (cc1plus)》之銘言：
: ※ 引述《TonyQ (自立而後立人。)》之銘言：
: : 很多人總是把管理認為就是有一個人在旁邊給你下指令，要你一動一動地去做，像是個班
: : 長一樣，這就叫管理。然後只要畫大餅，就是叫領導。事實上絕非如此吧。
: :                                                                         」
: :         而我想 mmdays 的文章，正是在批判大家普遍認為這種"管理"，
: :         只是他並沒有針對管理這個定義多加著墨，所以兩邊看起來會對不起來。:P
: :         無論如何，我覺得重要的事情是不要找多餘的麻煩，盡量讓時間花在刀口上。
: :         然後認知到工時並不太能當作量化指標，同樣四小時，
: :         有時候就是效能超高有時候就是效能超低，端看很多背景條件，
: :         並不會因為一個人一樣都花了四小時，產出就一樣。
: HR/Admin :
:      公司的開銷太大, 要縮減人事支出, 就弄好核薪表給 RD, RD 強不強我又不知道
:      還是要照年資給薪水, 台清椒起薪 34000 其他 -2000, 私校 -4000, 碩士 42000,
:      每一年資加 1000~1500 , 再加 3% 主管權利, 這樣就 OK 了
:      老闆交待要看工時, 那就全面執行打卡制.... ===> 軟體崩壞的開始...
在台灣，我可以舉出十個，甚至一百個造成軟體崩壞的原因，但裡面不會有打卡制。
怎麼會有人認為打卡制是造成軟體崩壞的原因？你是資方嗎？
但若是責任制，我會把他造成軟體崩壞的前五名，甚至是前三名。

: 如果你是 GM, 你要從那一個環節開始改善?
比如說mmdays的那篇文章，老實說，有些觀點我並不贊同，除了用詞不正確以外，
還有另外的問題，或者說，他並沒有把適用的範圍定得正確。

裡面的內容只適用於Startup、天才型員工以及扁平型組織。

他會寫出這樣的文章，跟該名作者本身的經歷有關，出自於Google，剛好是最多天才
型員工，而且是扁平式的組織，之後，他出來創業，成立的iKala不是上百人的大型軟
體公司，而是一間Startup。

為什麼天才型員工不需要被設限？（我不用管理這個詞，因為該文誤解了管理的意義）

在此之前我們必須瞭解什麼叫做天才型員工，自己有一套做事的方法，能夠自我學習主
動學會任何技術，具備溝通、協調技巧，雖獨樹一格卻不偏離主流，所以能跟他人合作
。簡單來說，天才型員工自己就可以成為一人公司，自己一個人就能研發產品，既然不
用告訴他怎麼做，他就能做得很好，那何必去指導、設限他該做些什麼呢？讓他自我發
展，就能讓產能最大化，放任式管理也是一種管理。

Google裡面這種人，想必不少，我想沒有這種水準也進不了Google。既然他看到的都是
天才型員工，會有這樣的想法也是必然的。

然而，原文說到，軟體開發是創意工作，是真的如此嗎？

在台灣有很多軟體公司，將規格開好之後直接交給大陸、甚至是印度的外包公司進行，
，許多公司有著固定的流程，固定的作法，只要給定標準的規格，他就能用標準的寫法
產生標準的產品。

甚至當你的框架做好以後，寫程式就像填空題一樣，把東西填起來就好，不是所有的軟
體都是「這麼的有創意」。

「碼農」雖然指從事沒有前景的IT行業人員，但也有像農夫一般，重複做固定的Coding
工作的意義。

有些（或者說大部分）軟體從業人員，不是天才型員工。

不是天才型員工也就罷了，起碼能本本分份的照著規矩做事，最可怕的是不是天才型員工
的人卻自認自己是天才型員工。然後，上級放任他「自我管理」，於是寫出來的Code
支離破碎，如果是只有他自己能看得懂，那也就罷了，最可怕的是不是他自己事後也看
不懂，而是天才式地自我發明一些自以為很好的輪子，甚至寫出「部分可用」的程式碼
（比如說，小樣本10個以內做得到，大樣本100個以上就掛了）

如果，管理者知道自己的部屬不是天才型員工，請不要放任他們自我管理，要讓他們
認清楚，其實他們不是天才型員工，放任自認為是天才型員工的普通員工亂來，是軟體
崩壞的其中一個重要原因，請讓他們認清現實，並想辦法協助他們提昇自己的程度到
天才型員工的能力。

所以我們要Code Review，所以我們要Pair Programming、所以我們要QA、所以我們要
Coding Style，所以我們要Spec Document，所以我們要甘特圖，Agile、
這是讓普通員工發揮生產力的方式，而不是只告訴他目的地，不是領導。

而是「有一個人在旁邊給他下指令，要他一動一動地去做。」

每個公司、人員，程度不同，限制程度的拿捏，就是「管理的藝術」。
也就是技術管理者最需要學習的東西。

至於為什麼Startup也適用？
  因為Startup的目標明確，為了達成目標，可以透過「任何手段」，所有會阻礙這個
  目標的，都是必須捨棄的。為了趕產品上市搶先行者優勢，底層可以先呼嚨再改，程
  式碼可以寫到人家看不懂，你帶自己的電腦來可以做得更快，好，帶你的電腦。你
  半夜上班更有效率，好，你半夜來。你有自己的框架但是別人不會用，好，你先上再說
  。如果不限制自己員工，可以讓目標更早完成。在達成目標之前，所有對於管理投入
  資源，都可能成為達成目標的阻礙。

  有些軟體公司產品都還沒上市就把公司組織規劃得像是股票上市公司一樣，通常失敗居
  多。

而大型軟體公司，利害關係人越多，於是管理制度的重要性就會顯現，避免多頭馬車或是
拖疆野馬的出現，協調、合作變得更為複雜，資源的競爭、績效的評估、激勵的方式，
會需要越來越多的管理規章來讓事情變得順暢。

於是，管理規章與限制，這時反倒可以讓軟體工程師專注在軟體本身的開發上，而不是
吵架

至於組織型態的影響，足以用另外一個篇幅來說明。

另外就是「打卡制」跟「責任制」，似乎把責任制想得太美好了。
大部分的血汗工廠，血汗軟體公司，都把責任制掛在嘴上。
「上下班不用打卡」或者「上班打卡制，下班責任制」都是責任制。

造成RD做到一半辭職，工作無法收尾的，不是打卡制，而是責任制。

真正的責任制，應該要依照責任輕重、工作量多寡，生產力高下決定報酬。

如果是固定工時責任制，那麼技術管理者應該要交付該員工工時範圍內能夠處理的工作。
如果是固定產出責任制，那員工把責任範圍做完之後，應該就不用繼續工作了。
如果是績效導向責任制，那產生越多的員工（比如說他願意一天工作16個小時）應該可以
或得較高的報酬。

然而，軟體生產力的評估，卻是一項非常大的難題。

每個人能力不同，每個需求難度不同，即使極有經驗的管理者，也不見得能做得很好。

不過，該文作者是高手，有在Google的工作經驗，他要Run責任制，當然有他的道理，
而且是Startup，更需要對公司的認同感，而且我相信這個責任制會比打卡制好。

但台灣大部分實際的責任制狀況會是：

1.早做完的人，被塞了更多的工作。
2.被塞了許多的工作，早就超過原本預計的固定工時。
3.大家差不多時間做完，難度不同績效卻相同。


因為責任制背後隱藏一個恐怖的事實：
「軟體工程師的智慧有價，時間無價。」

我說，「軟體工程師的智慧有價，時間也有價」。

即使我花時間思考解決難題、不斷測試找出原因，這段期間都「有價」。

純粹的打卡制（有加班費的那種）能讓資方知道。「員工的時間是有成本的」

於是他們才會去思考，那些員工工作效率好，怎樣合理分配工作減少加班費，
哪些人做得快不用加班。每個員工的效率如何，即使管理者再笨再沒經驗，不
懂軟體，他也會想到這一層。

因為讓員工加班，要錢啊。

因為我們的時間，是要錢的；思考，是要錢的；測試，是要錢的。我們回家後
放著老婆小孩女友情婦父母不管VPN回去工作、放假的時候去海邊玩還帶著手
機On Call，是要錢的。

真正的責任制是不錯，但是實施責任制需要很多的經驗還有條件配合。

一個真正的打卡工時制，會比莫名其妙的責任制拯救更多的軟體專案。
「上下班打卡制 + 工作責任制」，工時有價。

我從事過好幾份工作，全部都要On Call。

現在的工作，
從接到電話起算。出發到公司可以搭小黃報公帳，自己開車則照里程算油錢。
進公司刷卡起到離開為止算加班費，不要錢可以報補休。
不到公司用VPN處理，從連線起算，到終止連線為止，全部都可以報加班或補修。

我覺得打卡制，還不錯。

--
所有我的作品，請到.....
～四十八個德瑞克～http://blog.derekhsu.homeip.net
馬皇本紀：http://blog.derekhsu.homeip.net/2009/08/821
上官先生傳：http://blog.derekhsu.homeip.net/2009/08/825

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 175.181.114.9
※ 編輯: derekhsu        來自: 175.181.114.9        (06/13 23:45)
※ 編輯: derekhsu        來自: 175.181.114.9        (06/13 23:46)
推 thinkniht:我認為責任制本身是不錯 但問題是...通常都是被濫用
※ 編輯: derekhsu        來自: 175.181.114.9        (06/13 23:48)
→ thinkniht:一旦變成 加班無限+免加班費 ，那就很有問題了=.=|||
推 landlord:good!
→ cc1plus:我先回軟體崩壞的開始是從打卡制開始這件事.
→ cc1plus:其實是想諷剌, 接下來就是上班打卡制, 下班責任制.
→ cc1plus:不過我想就算是"軟體", 還是有著程度上的差別
→ derekhsu:是，沒錯，所以，我認為該文不能照單全收
→ derekhsu:台大畢業進Google然後創業，看到的視野想必跟我這種普通
→ derekhsu:員工不同
→ superpai:推
推 dendrobium:推!
→ andymai:其實c大講的很明顯就是上班打卡下班責任~否則正常打卡的話
→ andymai:~其餘因素不考慮~又怎會有崩壞的可能?
→ andymai:@@原來c大已經說明了XD 話說回來~要是軟體公司都有這篇文
→ andymai:章的思維~應該能減少流動率...
→ gpmm:真的只能推了…
推 ppaass:我得了一種不推這篇會死得病！
推 chang0721::) 我得了一種不推這篇會死得病！
推 leav:責任制ok, 問題是加班費還是要照給啊啊啊!!!
推 twk:大推~
推 ledia:他也不過是想連人才招募也一起複製同樣的模式
→ ledia:畢竟如果玩 startup 有錢燒, 是可以無限創意的啊 :p
推 viper9709:推~~很中肯的心得文