作者: iincho (..) 看板: Soft_Job
標題: Re: [閒聊] 最後一根稻草… 嗎?
時間: Mon Mar 24 19:34:04 2008
※ 引述《zanyking (遙遠的旅人)》之銘言：
: : 分享一些個人看法:
: : 建立一個這種團隊, 並不應該仰賴各成員的工作互相overlap來達成, 因為這是
: : 十分不經濟的作法(不只就人力運用而言, 抑或是溝通協調而言)
: : 要達成這個目標, 個人認為關鍵在將各成員的輸入、產出進行標準化、規格化,
: : 這樣子要抽換任一個成員的成本將會相對降低, 一旦完成這個工作, 溝通協調的
: : 問題自然也不會產生, 因為不管是誰來接, 都能很快上手。簡單地說, 就是將各
: : 成員當成一個模組來使用。
: 一個有出息Developer坐在電腦前，他深刻的了解到自己是顆標準規格的螺絲釘，於是
: 他可以快樂希望的寫程式而不會擔心自己的未來？
: 我比較相信他會努力的鑽研技術，努力的建立自己的『不可取代性』，然後趕快離開
: 這個『模組化』的鬼地方。
這裡講的標準話我想並非指程式是怎麼寫, 而是你寫程式的一些基本規格 ,以及必須
產出的東西。例如，變數命名的規則，註解的格式，應該要產出的文件等。
很多RD會想建立己的不可取代性，目的無非是希望別人不要爬到自己頭上，實務上來說
這是可能的，但並不是最好的辦法。這樣做只會讓整個team的風險承受力降低，以管理
的角度來看是不能接受的，試想，今天你不可取代，那天派你出國飛機掉下來公司要
怎麼辦?
不過我個人的看法是沒什麼東西是不能取代的，又不是做什麼尖端科技，真的做困難
如演算法研究的反而不怕規格化，因為他的經驗不是這種機制可以複製。
: 我想，軟體工程指的不是把人當成模組看待，而是把軟體設計成可模組化的，或把工作
: 內容、項目依軟體開發的特質合理定義清楚的一門學問。會把人當成模組的是某種在人
: 員管理上的過時態度。而這種態度或假設，忽略了人的個體差異性，以及人具有很多無
: 法預期的非線性動態變動特質。
: 人只有在被當成人來看待、接受以人的本質為基礎發展出來的管理技巧，才能發揮出最
: 大的腦力資本效益。
: 簡單的說，比起研究工業工程、流程管理、要徑之類的，多多吸收認知心理學、腦神經
: 科學、社會學，說不定還對專案成功更有幫助。
: 當一個工作有越高的可取代性，就會有越高的人員流動率，你看櫃台小姐、行政助理
: 這類工作的平均流動率就知道了。
你覺得路上隨便找個人可以當RD嗎?
上面提到的可抽換性，指的不是隨便抽個路人甲乙丙來，而是指可以交給夠能力的人，
比如說，這個職位需要會C語言就能做，就不應該把工作弄成非得熟C熟C++熟ASM才能做，
更不應該是接手的人非得要找你來問，這樣才能降低專案開發的成本，做了一陣子以後，
能力有成長了，就找個菜鳥來頂，原來個人就調去做更複雜的工作。
會恐懼被取代的原因有幾個：
1.那個位子實際上沒有成長性或是成長緩慢。
2.公司沒有辦法提供更複雜工作的機會。
RD會一面工作一面成長，對管理者來說，幫RD找到更適合他們的工作是管理者的責任，
很可惜台灣有意識到這方面的管理者不多，所以RD也以建立技術上不可取代性為樂。
: 就算不考慮人性好了，討論實務上的工作內容。
: 對於機械工程模組，完美的按照設計的規格輸出入是最好的。
: 對於軟體開發者…標準的輸出入？你指的是中文聽說能力嗎？
: 定義清楚的工作內容通常並不可行。
: 機械通常按照既有已知規範、欲解決某個明確的已知問題而設計，那麼當某個問題是通
: 用的，例如將兩個鐵片栓緊的一種利用螺旋紋路間巨大摩擦力的解決方案，這種解決方案
: 的具體產品(螺絲釘與螺帽)就能稱作模組。
: 人究竟是要符合哪個具體規範，去解決哪個『已知』問題好來讓自己可以被稱作模組呢？
: 更多的時候，軟體開發者的工作是要去挖掘更多團隊還未知卻重要的問題，並且提供解決
: 方案吧？
未知? 常態是一開始不去搞清楚當然是未知。沒規範的大部分的RD都是直接坐下來寫，
會先想清楚再寫的通常會被當作笨蛋。 對大型專案來說，一開始定義清楚要做什麼是
必須的，中間或可提供一些修正的機會，但是什麼都不規畫只靠靈感，終究會失敗。
過程應該是規畫=>執行=>修正=>再執行=>再修正….
每個階段必須評估，這個階段預計要有的產出。對於對於執行面，可以用一些方法來
估計RD的執行程度。
: 軟體開發就我所知有一大部分的領域要求開發者在不確定的需求、模糊的限制條件、
: 有未知風險的技術領域下去做開發，而這些軟體的需求與限制條件比起機械，離終端的
: 人類使用需求更近。況且，幾乎無可否認的，軟體的『製造』就是設計，而設計就是得
: 靠人來做。一個不論是『需求』還是『供給』都離人的價值判斷這麼近的產業，以生產、
: 製造領域的想法來規範、評量是不合理且也不效率的。
: 我並不否認方法論、品質管理的重要，也不會認為CMMI、RUP或者其他有名的軟體開發
: 流程不好，但是他們都是對專案『事務』的管理，而不是對『人』。
: 所以，我也不意外常常有人覺得它們沒用，或是麻煩，因為這些人的公司可能連最基本
: 的人的管理都沒有做好。
: 我相信，人的管理，特別其中Undocumented的部份只會越來越重要。
這點我持反對的看法，現在軟體已經不是五個人十個人可以搞得出來，一個一百人的team
要用這種方式管，垮掉的風險太高。
※ 編輯: iincho 來自: 211.76.240.242 (03/24 23:38)
作者: Lapha (lapha) 看板: Soft_Job
標題: Re: [閒聊] 最後一根稻草… 嗎?
時間: Mon Mar 24 23:25:26 2008
※ 引述《zanyking (遙遠的旅人)》之銘言：
: 一個有出息Developer坐在電腦前，他深刻的了解到自己是顆標準規格的螺絲釘，於是
: 他可以快樂希望的寫程式而不會擔心自己的未來？
: 我比較相信他會努力的鑽研技術，努力的建立自己的『不可取代性』，然後趕快離開
: 這個『模組化』的鬼地方。
這邊得說明一下:
標準化、模組化, 指的是”工作的模式、介面”, 而不是指對待每個成員的方式。
如果只把RD當螺絲使用, 後面就不用去強調”培養”這個動作了。另外, 除了”培養”,
前文中也提到了”鑑別”成員的能力, 為什麼要”鑑別”??
每個成員都有其差異性, 要培養一個RD, 不能僅僅是組個讀書會, 大家一起聽聽課,
離開教室, 全部又打回原型。”鑑別”的用意, 就在於了解各別RD的需求, 為之後的
“培養”做準備。
至於會不會想趕快離開這個問題, 我是不曉得自己算不算有出息 :p 不過我曾經待
過一個類似的環境, 在那邊的工作經驗是十分令人懷念的 🙂
怎麼說呢? 今天我被assign了一個工作, 有明確的介面和功能需求, 我可以自己去
發揮創意完成它, 反正只要符合介面, 我不用擔心有人會跳腳; 而過程中留下的
文件, 讓我即使請假, 別的成員也能了解我的規劃, 不致於一頭霧水; 當我在實作
中有些新的修正想要feedback給原始架構時, 大家會知道那些東西被影響, 而不是
開會時各憑印象在”喊價”..XD
至於處理”未知的問題”, 我想文件、紀錄應該更重要才是, 嘗試過那些東西, 得到
怎樣的結果, 分析的過程, 做出決策的理由, 這些都是該累積下來的東西, 如果以
一句 undocument 帶過, 我想這滿可惜的。
如果能了解”規格化”的意思, 那麼就可以來說明下一個重要的東西: “紀律”
我想這個詞不會出現在許多軟體工程師的字典裡, 因為一個廣為接受的觀念是:
“軟體是創意產業”(至少電影裡面的駭客那個不是一手可樂一手比薩, 一個人熬幾晚,
就搞出超炫的玩意兒, 讓主角去出生入死一下)
軟體當然是創意的產業, 但如果真要把它當”產業”來看, 那麼比較完整的說法, 應該
將軟體視為”創意和紀律的結合”。這在別的行業中並不算陌生: 建築需要創意吧?
但沒人會想住在大樑沒上正的屋子裡; 服裝設計需要創意吧? 但如果連車縫都不正,
大概沒人會想買; 音樂需要創意吧? 但沒人會欣賞交響樂中放砲的那神來一筆..
當我們將軟體視為一個產業, 一個需要眾人合作的專案時, 除了個人的能力, 我們必
需更從團體的角度去看事情。在設計時, 讓大家盡可能發揮創意; 到了執行時, 反而
應該嚴格的遵守初始的規劃精神。
RD總是擔心自己會被別人取代, 所以非得留一手以彰顯自己的價值, 但是你也留, 他
也留, 每個同事間各自建立不可逾越的城牆, 躲在自己的小天地裡當然很安全, 但是一
個常見的怪現象是: 一群高手組成的團隊, 卻常做出失敗的專案。這似乎不是個很理想
的狀況。
我的想法或許有點怪異, 不過我個人的看法是覺得一個RD的價值,在於能創造出多大
的價值, 而不在收藏了多少技術。畢竟, 技術本身是工具, 利用工具去完成工作, 才是
我們的目標, 一個履歷上寫滿各式技術的資深RD, 卻發現他沒完成過幾個成功的專案,
這不會很奇怪嗎?
—
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 123.193.24.15
[1;37m推 [33miincho [m [33m:你是碰到難得一見的好主管吧… [m 03/24 23:37
作者: leicheong (睡魔) 看板: Soft_Job
標題: Re: [閒聊] 最後一根稻草… 嗎?
時間: Mon Mar 24 23:56:50 2008
※ 引述《iincho (..)》之銘言：
: 這裡講的標準話我想並非指程式是怎麼寫, 而是你寫程式的一些基本規格 ,以及必須
: 產出的東西。例如，變數命名的規則，註解的格式，應該要產出的文件等。
: 很多RD會想建立己的不可取代性，目的無非是希望別人不要爬到自己頭上，實務上來說
: 這是可能的，但並不是最好的辦法。這樣做只會讓整個team的風險承受力降低，以管理
: 的角度來看是不能接受的，試想，今天你不可取代那那天派你出國飛機掉下來公司要
: 怎麼辦?
:
: 不過我個人的看法是沒什麼東西是不能取代的，又不是做什麼尖端科技，真的做困難
: 如演算法研究的反而不怕規格化，因為他的經驗不是這種機制可以複製。
確實, 沒甚麼技巧是不能取代的. 不能取代的只有經驗而已.
這經驗除了包括從過往中獲得, 知道那些pattern的東西最容易出錯,那些
pattern用起來效果比較好這些老生常談的東西以外, 更包括由過往成功
經驗中獲得的, 對自己能力的認知.
當要接下一個包含不確定因素的project時, 通常只有剛出校園的會躍躍
欲試. 然後多半因為能力不足而發現無法突破. 比較有經驗的會先考慮一下,
如果自己在相關層面已經有足夠的累積, 即使自己不直接知道是不是能夠
解決那不確定因素, 成功的機會也就大多了. 如果自己累積不夠, 也能
明確地說出自己不確定能否解決, 而請求更多時間先做調查, 甚至直接
說明自己無法勝那工作. 能夠提供這些資訊, 對管理層來說無疑是很重要的.
: 你覺得路上隨便找個人可以當RD嗎?
: 上面提到的可抽換性，指的不是隨便抽個路人甲乙丙來，而是指可以交給夠能力的人，
: 比如說，這個職位需要會C語言就能做，就不應該把工作弄成非得熟C熟C++熟ASM才能做，
: 這樣才能降低專案開發的成本，做了一陣子以後，這個人有成長了，就找個菜鳥來頂，
: 原來個人就調去做更複雜的工作。
: 會恐懼被取代的原因有幾個：
: 1.那個位子實際上沒有成長性/或是成長緩慢。
: 2.公司沒有辦法提供更複雜工作的機會。
: RD會一面工作一面成長，對管理者來說，幫RD找到更適合他們的工作是管理者的責任，
: 很可惜台灣有意識到這方面的管理者不多，所以RD也以建立技術上不可取代性為樂。
雖然不排除有這樣「卡位」的RD存在, 但我更願意相信因對電腦的喜好
而加入這行業的人來說, 寫程式的工作和音樂家寫新樂曲的心態沒有差別.
(留意這裡說的是RD, 是指在能充分發揮自己探索能力那些人, 而不是天天
在寫POS那樣枯燥的東西的)
我們沒有故意讓寫出來的程式必須被熟悉那語言的人看才看得懂, 但很多時候
只有某種作法才能獲得需要的效能. (舉個例子, Synchornious I/O functions
多容易用啊, 但很多時候在多執行緒環境, 只有用Asynchorious I/O才可以得到
理想的responsiveness.)
: 未知? 常態是一開始不去搞清楚當然是未知。沒規範的大部分的RD都馬直接坐下來寫，
: 會先想清楚再寫的通常會被當作笨蛋。 對大型專案來說，一開始定一清楚要做什麼是
: 必須的，中間或可提供一些修正的機會，但是什麼都不規畫只靠靈感，終究會失敗。
: 過程應該是規畫=>執行=>修正=>再執行=>
正常情況下的確如此. 但你可知道「在編寫過程中強行插入新功能」在業界
是多普遍? 當「規劃」在建造過程中被迫修改, 你就面臨在不停的「再規劃」
中打轉的危險. 當時限迫近的時候, 有時就要從各種「非必要」的流程中
省略了.
不幸地, 可能是「省略規劃的失敗率太低」 (他們往往會把有shipment
的專案就算成成功的了, 不管其實是如何「爛尾」… =.=), 「規劃」
本身往往成為最先「開刀」的對象…
當相同的事一再發生, 不可避免地就會演變成「一開始就直接省略
規劃」的情況… 這些專案將有一部份「成功」而算在上段的成功數
裡…….
我就親身經歷過一間公司對流程要求的崩壞 (雖然進去時已經是
頗後期的了)
: 每個階段必須評估，這個階段預計要有的產出。對於對於執行面，可以用一些方法來
: 估計RD的執行程度。
關於這個… 我想由過往對於「評估」的討論串中, 我沒看到對評估
RD執行程度的有效方法?
: 這點我持反對的看法，現在軟體已經不是五個人十個人可以搞得出來，一個一百人的team
: 要用這種方式管，垮掉的風險太高。
難到你不認為對組員整體的情緒管理, 是從團隊能否有效率的關鍵?
要知道, 壞情緒導致的no work mood是會傳染的. 但要隔離也不行,
因為高效率的團隊在運作過程中必然會發展出若干程度的, 互相
依賴的關係. 只抽掉某個目前工作效率低下的成員對團隊的整體
運作只怕在做成反效果…
要規避這些關於「人」的東西, 只怕只能用印度那種強行把人
「堆」成團隊的方式吧…
在現代管理學上, 越來越多的焦點被放在和「人」相關的東西了.
(好像我是念數學的, 卻也必須念Organizational Behavior等學科.
這些過往是Undocumented的東西, 現在也逐漸被人描述出來, 更成為
一門正式的學科了.) 也證明了他們也認同這些是不可忽略的.
「要用這種方式管，垮掉的風險太高。」? 不管的話, 我看垮掉的風險
會更高啦… 😛
—
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 219.73.76.111