Re: [閒聊] 最後一根稻草... 嗎?

看板Soft_Job (軟體人)作者 (..)時間17年前 (2008/03/24 19:34), 編輯推噓0(000)
留言0則, 0人參與, 最新討論串9/15 (看更多)
※ 引述《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) ※ 編輯: iincho 來自: 211.76.240.242 (03/24 23:46)
文章代碼(AID): #17vv6jqh (Soft_Job)
討論串 (同標題文章)
文章代碼(AID): #17vv6jqh (Soft_Job)