l

2012年9月25日 星期二

鄉民的問題

Sept. 24 15:08~16:24

image

 

今天早上一起床就收到某位鄉民寄來的一封信:

***

Teddy你好:

(Q1)不好意思,這個問題不知道能不能請教你。
在部落格上面很多軟工方面的文章,
(Q2) 裡面有非常大的成份在開發流程、開發團隊上面,但是實際上,最小的個體還是一個人,
(Q3)所以像是「團體為重、個人為輕」的想法會不會太理想呢?
(Q4) 延伸問題像是:積效/考積/獎金的分配?
當以團體為單位工作,獎勵卻以個人為單位分派時,
很容易就出現問題了啊…
會有這些問題,是因為在工作上常常覺得現有流程不好,
(Q5) 想要改變的時候,發現最大的問題還是在「人」上面………

另一個問題,最新一篇《傻的願意相信(2)》最後提到
「培養多才藝的員工(生產線的工人要能夠具備組裝車輛任何部份的能力)」
這邊有個疑問,當程式設計也變成每個人都一樣的時候,
(Q6)這是不是就沒有專業可言了?
(Q7)延伸問題:當每個人都做一樣的事情的時候,如何培養更深的技術?
舉例來說,每個人都要會DB正規化、stored procedure、Web Server/Client、C++、C#、Flash…etc
(Q8)我不是很容易理解,因為以前的想法都叫「專業分工」,依各自的專業來進行分工,
而專注在自已領域上的人,自然也容易在該領域深入研究。
另一個說法是:要廣或深,如果什麼都學一點的話,就等於什麼都不會的說法

***

以下是Teddy的答覆:

  • Q1:當然可以問啊,而且什麼問題都可以問,但是Teddy保留「不回答」的權利XD。
  • Q2:其實在「搞笑談軟工」裡面,除了「開發流程」以外,Teddy也談了很多關於軟體設計、軟體架構、模式、設計模式、持續整合、軟體測試、例外處理、好書推薦的文章啊。只是這一系列的文章好像都比較沒人欣賞啊…Orz(Teddy內心獨白:還有每週兩篇的大易輸入法遊記哩 挑眉質疑)。
  • Q3:ㄟ,如果你是看完Teddy的部落格而有了「團體為重、個人為輕」的想法,Teddy在此向你鞠躬道歉…Orz。Teddy應該沒有說過類似這樣的話吧?!Teddy要強調的是「個人能力和團隊合作一樣重要(或者說,個人能力和團隊合作之間要取得平衡)」。Teddy曾經說開發團隊成員要有「追求技術卓越」的精神,所以個人重不重要?當然重要。但是(通常這兩個字之後才是重點),何謂「厲害的個人」?是那種自己很厲害但不願意分享也不管別人死活的人,才叫做厲害。還是有能力能夠幫助別人,使得別人原本認為很困難的事情,在他的協助之下,變得比較簡單(這句話有點繞口 XD)。
  • Q4:講到打考績這件事,在台灣應該不容易做到只打「整個團隊的考績」,那怎麼辦?還是有一些折衷的方法,下次請Teddy吃飯再慢慢告訴你 XD。
  • Q5:絕對是人的問題大大大大大大大…於流程的問題啊。開發流程再怎麼搞來搞去,也就是那幾種,最後的問題都是出在「執行流程的那些人身上」。
  • Q6:「培養多才藝的員工(生產線的工人要能夠具備組裝車輛任何部份的能力)」這一點是「理想值」,絕對不代表員工就沒有專業可言。你可以想像,一個Scrum團隊的成員,如果具備所謂的「T型人」(最近學到的一個詞)特質,除了在某一個領域具備專業,對於其他週邊的相關知識也要有所涉獵。Teddy之前舉過一個例子,假設你的團隊中原本有一個資料庫很強人,他的能力用100分來計算。如果在認領工作的時候,有計畫地讓其他不懂資料庫的人和他合作,長久下來,就算其他人達不到100分的程度,但至少也有40、50、60…分。這比「完全不懂(0分)」,全部都要依靠這位資料庫高手,在調配工作的時候彈性就大了很多。另外還有其他的好處,像是日後的維護工作安排、人員請假比較自由、人員流動對專案影響較少等等。
  • Q7:不是每個人都做一樣的事情,而是每個人有自己專精的幾樣(舉例,有些人可能architecture design與multiple-threading programming很強,資料庫設計中等,UI設計只懂概念。而有些人則是HTML/CSS/JavaScrip很熟,資料庫中等,但是軟體架構設計能力很弱)。重點是,團隊中大部分的事情,儘可能培養一人以上可以處理的能力,這樣團隊成員會有一種可以依靠,而不是所有事情都要單兵作戰的孤獨感。
  • Q8:專業分工本身有好處也有缺點,箇中奧妙很難一下子講清楚。我很能理解你對於「專業分工」的疑惑,為什麼以前大家都說要「專業分工」,但是現在Teddy卻說要「多才多藝」。Teddy建議你可以去看一下《決定未來的十種人》這本書。另外,套句Teddy在《Force是什麼?》所引用《POSA5》這本書裡面的一句話:「Force告訴我們為什麼模式所要解決的問題是一個真正的問題;為什麼這個問題很難,為什麼這個問題需要一個聰明的,甚至是違反直覺的解決方案。Force也是了解為何會採用此種解決方案(而非其他方案)的關鍵。」你現在會認為培養「多才多藝」是一種「違反直覺
  • (也就是專業分工)」的解決方案,是因為你對這個問題的force還沒有觀察的非常清楚,所以自然對於solution會有所懷疑。

***

扯了這麼多,結論就是:「這位鄉民病的不輕 XD」,請速 服用 報名「Scrum敏捷方法實作班:第四梯次」。另外,下次如果還有開「模式入門第一堂課:30 分鐘寫出一個模式」也要來報名參加啊 XD(學會pattern方法對於分析問題真的很有用啊)。

***

友藏內心獨白:腦袋中又冒出Quality Without A Name這句話啊。

沒有留言:

張貼留言