軟體開發討論

作者: 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

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *