下面是在水木軟工上的對話。有興趣的可以看看，全文涉及工程與科學之間的差異，軟體工程的工程本身的分析，專案經理的行為和強弱勢專案經理的一些問題。

btw：裡面有著名的錢五哥的回覆，呵呵。

發信人: timshaw (去SofeEng(軟體工程)小侃吧), 信區: SoftEng
標  題: [合集] “軟體工程”中的“工程”大家是如何理解的？
發信站: 水木社群 (Wed Jan 20 12:50:05 2010), 站內

☆─────────────────────────────────────☆
   ihomd (ihomd) 於  (Thu Jan 14 18:05:31 2010)  提到:

別笑我弱大家討論討論，呵呵

我老聽說“要以工程的方法來開發軟體..."等等類似忠告。可以我怎麼也不能領會工程的真
正意義。
我能想到的就是"more pratical"和理性。因為在我的理解中傳統的工程(就是類似於建小區
)的產物都是實證的都必須是可行的都必須是經得起考驗的。與之相對的就是誇誇其談的藝
術的創意的只需要設計不重實現的，這些方向要的是縱橫捭闔天馬行空。
兩項相較：一邊是海水一邊是火焰，一邊是理性與冷靜，一邊則是感性與激情。一邊是控制
一邊是縱情。

而我們研發軟體，同建房子一樣，不僅要設計，更要能實現。最終的工件必須是經過客戶用
戶檢驗的，這個檢驗也是有標準的，不存在公說公有理婆說婆有理的情況。

軟體工程的提法反映了當時軟體開發屢遭失控打擊的形勢下，永不停止學習的軟體人向傳統
行業借鑑經驗的決心。自此之後，估算技術測量技術地位急劇高升?

各位是怎麼理解這個軟體工程中的“工程”的？有沒有人講講來龍去脈，freestyle。^_^

但是軟體工程中有方法論過程論，這算不算傳統工程理論的一部分？




☆─────────────────────────────────────☆
   qingrun (青潤) 於  (Thu Jan 14 21:10:42 2010)  提到:

不弱。能深入思考工程兩個字的含義是很有必要的。
不思考工程兩個字就來做軟體開發的人，容易形而上學，更容易僵化的處理新的概念和新的方法論，借用老毛同志的話就是，容易本本主義。呵呵
不過，你這個話題太大，bbs上做這樣的討論，需要大量的文字輸入，得不償失，呵呵。
辯論或者討論的時候，思辨過程和響應迴路過長，價值不大，這樣的問題應該考慮別的討論形式會比較好一些。

【 在 ihomd (ihomd) 的大作中提到: 】
: 別笑我弱大家討論討論，呵呵

: 我老聽說“要以工程的方法來開發軟體..."等等類似忠告。可以我怎麼也不能領會工程的真
: 正意義。
: ...................



☆─────────────────────────────────────☆
   blueslc (Thomas) 於  (Thu Jan 14 23:04:41 2010)  提到:

Engineering is a cooperative game of invention and communication.
from <Agile software development - the cooperative game>
這本書有一章講工程和軟體工程，說的很好，我試著重複一下看看了。
過程中有創新的才是工程，沒有的話就是生產而已，在傳統領域，很多工程其實只是生產而已，沒有什麼難度。比如造房子，造第一座房子是工程，如果造同樣的第二座，那就是生產。造第一座的難度，肯定比第二座要大很多
軟體由於其獨特性，每一個軟體都不一樣，所以軟體工程，要和你造第一房子作對比，而不是第二座。
【 在 ihomd (ihomd) 的大作中提到: 】
: 別笑我弱大家討論討論，呵呵
: 我老聽說“要以工程的方法來開發軟體..."等等類似忠告。可以我怎麼也不能領會工程的真
: 正意義。
: ...................



☆─────────────────────────────────────☆
   qingrun (青潤) 於  (Thu Jan 14 23:23:36 2010)  提到:

這個對比似乎應該是科學研究與工程對比，科學研究是造第一座房子，然後工程才是重複後面的房子過程，呵呵。
我個人認為，這本書裡面講的這個工程的解釋應該是完全錯誤的。它混淆了科研與工程之間的差異。

【 在 blueslc (Thomas) 的大作中提到: 】
: Engineering is a cooperative game of invention and communication.
: from <Agile software development - the cooperative game>
: 這本書有一章講工程和軟體工程，說的很好，我試著重複一下看看了。
: 過程中有創新的才是工程，沒有的話就是生產而已，在傳統領域，很多工程其實只是生產而已，沒有什麼難度。比如造房子，造第一座房子是工程，如果造同樣的第二座，那就是生產。造第一座的難度，肯定比第二座要大很多
: 軟體由於其獨特性，每一個軟體都不一樣，所以軟體工程，要和你造第一房子作對比，而不是第二座。


☆─────────────────────────────────────☆
   qingrun (青潤) 於  (Thu Jan 14 23:27:44 2010)  提到:

評論一下這句話：但是軟體工程中有方法論過程論，這算不算傳統工程理論的一部分？
我記得我的blog上有一片關於軟體工程重新定義的文字上（我對軟體工程領域劃分的認識之一，地址：http://blog.csdn.net/qingrun/archive/2006/12/21/1451598.aspx ），和一個在河南某大學的老師產生了爭論，通過評論和評論回覆的方式爭論了幾乎一整天，其實說的就是一兩個小時就可以說完的東西。
對這個話題以及這個話題中各方面包含的內容做了比較深入的討論。

【 在 ihomd (ihomd) 的大作中提到: 】
: 別笑我弱大家討論討論，呵呵
: 我老聽說“要以工程的方法來開發軟體..."等等類似忠告。可以我怎麼也不能領會工程的真
: 正意義。
: ...................



☆─────────────────────────────────────☆
   qlw (錢五哥) 於  (Thu Jan 14 23:43:55 2010)  提到:


工程和技巧相對應。工程的基礎是可以測量，曾經影印過一張施工隊的進度和報價
上面將投入、工時、成本算的清清楚楚。這和動輒可能延期的軟體開發有天壤之別

但是軟體工程也是很困難的，測量到現在似乎也沒有什麼人提出來與時俱進的方法
工程化最終導致了文件化和僵化。因此出現了敏捷過程 - 出發點是簡化傳統的工程
思路，從而回歸到產品化的正確道路上。但是在解決規模擴大的問題方面還是有
些問題。早一些的CASE、元件化、軟體工廠等概念，雖然盛極而衰，但是留下了
包括pattern、UML在內的遺產，對工程化有不小的幫助。

工程化首先要求可以重用，如果至今一直用主機+Cobol+DB2，則我堅信現在已經
工程化好久了，可惜目前是Linux+虛擬化+雲端計算的時代，原先搞的那套玩意早就
過時了，工程化還受到技術成熟性的制約！

可以看看Gartner的Hyper Cycle，現在M2M已經開始預熱了。看到這類玩意，不禁
心說，“工程化又遠了”

供討論

【 在 timshaw (寫啥呢？真矛盾) 的大作中提到: 】
: 多謝qingrun評價,我是啞巴,說不出子醜寅卯
: 呼喚canper,kabbesy,mike,SPQR,dicken等老版友
: 呼喚錢五哥
: ...................



☆─────────────────────────────────────☆
   timshaw (寫啥呢？真矛盾) 於  (Thu Jan 14 23:58:08 2010)  提到:


我再講些感想。

軟體工程是如此的複雜，風險是如此的高，搞到65%的軟體專案延期，30%的專案直接取消。
跟傳統工程的按時交付率差別如此之大。
原因有二：
第一是軟字，軟的就像女人的奶子客戶都想捏成自己想要的形狀。很多客戶都不知道達到隨便捏的程度需要吃多少木瓜，這種客戶和軟體提供商的溝通有點巴別塔。
其 二在原軟體工程固有的複雜性。傳統工程正如我開始所說，設計和實現相分離，勞斯萊斯的design和implementation是完全個裂開的。而軟體 專案中design和implementtation是如此的不可分家，每一個實現者都在自己的範圍內進行design。

和傳統工程比 較，軟體工程的軌跡必然是守破離。大亂時代，我們需要一個框架，是以學習傳統工程，但由於上面兩點，慢慢的，軟體工程變異出自己的特性，我認為這裡可以分 為三個層次：過程論/方法論/最佳實踐和反模式，這些都是那些重視測量估算的傳統工程所沒有的。慢慢的最終發展出自己的一套理論，和傳統軟體工程完全不同 的理論。在這裡，測量不是最重要的，最重要的是革新，是重構，是抽象，是溝通是融合而不是分而治之不是人為構築壁壘。



【 在 qlw (錢五哥) 的大作中提到: 】
: 工程和技巧相對應。工程的基礎是可以測量，曾經影印過一張施工隊的進度和報價
: 上面將投入、工時、成本算的清清楚楚。這和動輒可能延期的軟體開發有天壤之別
: 但是軟體工程也是很困難的，測量到現在似乎也沒有什麼人提出來與時俱進的方法
: ...................



☆─────────────────────────────────────☆
   timshaw (寫啥呢？真矛盾) 於  (Fri Jan 15 00:21:24 2010)  提到:

那肯定啊，但是主要指導思想還是IOC和分而治之。
說起這個就想起而二戰的通用，短時間內就是用IOC理念造就瞭如此多的飛機。。。。

【 在 canper (洗衣粉) 的大作中提到: 】
:  車盲，不瞭解，不過我想造車設計師也不是畫完圖紙就完事的吧，也要參與樣品車的組裝，除錯。




☆─────────────────────────────────────☆
   canper (洗衣粉) 於  (Fri Jan 15 00:26:47 2010)  提到:


 我覺得軟體中設計和編碼分開也是完全可以的，但並不表示這樣就可以降低編碼人員的水平，以及設計者可以不參與到編碼階段中。

  我想配合設計師一起組織樣品車的技術的工資也不是和普通工人一個檔次的。

【 在 timshaw (寫啥呢？真矛盾) 的大作中提到: 】
: 那肯定啊，但是主要指導思想還是IOC和分而治之。
: 說起這個就想起而二戰的通用，短時間內就是用IOC理念造就瞭如此多的飛機。。。。




☆─────────────────────────────────────☆
   timshaw (寫啥呢？真矛盾) 於  (Fri Jan 15 00:31:14 2010)  提到:

我覺得軟體行業革新的動力就是融合互相學習無法剝奪的學習，而傳統行業是分而治之，缺乏對流缺乏溝通。軟體行業如果沒融合沒溝通，基本上就夕陽了。
我們之所以如此熱愛這個行業，就在於我們喜歡溝通交流喜歡持續改進而不是得過且過。

【 在 canper (洗衣粉) 的大作中提到: 】
:  我覺得軟體中設計和編碼分開也是完全可以的，但並不表示這樣就可以降低編碼人員的水平，以及設計者可以不參與到編碼階段中。
:   我想配合設計師一起組織樣品車的技術的工資也不是和普通工人一個檔次的。




☆─────────────────────────────────────☆
   canper (洗衣粉) 於  (Fri Jan 15 00:32:05 2010)  提到:


 不過同樣的事情如果放到建築業就不是那麼回事了，設計師畫完圖紙就完了，沒有必要建一棟房子來驗證自己的設計。

  如果是服裝業呢，好像也要做出樣品來看看效果。


【 在 canper (洗衣粉) 的大作中提到: 】
:  我覺得軟體中設計和編碼分開也是完全可以的，但並不表示這樣就可以降低編碼人員的水平，以及設計者可以不參與到編碼階段中。
:   我想配合設計師一起組織樣品車的技術的工資也不是和普通工人一個檔次的。




☆─────────────────────────────────────☆
   canper (洗衣粉) 於  (Fri Jan 15 00:33:10 2010)  提到:


 這個，我還真說不上熱愛
【 在 timshaw (寫啥呢？真矛盾) 的大作中提到: 】
: 我覺得軟體行業革新的動力就是融合互相學習無法剝奪的學習，而傳統行業是分而治之，缺乏對流缺乏溝通。軟體行業如果沒融合沒溝通，基本上就夕陽了。
: 我們之所以如此熱愛這個行業，就在於我們喜歡溝通交流喜歡持續改進而不是得過且過。




☆─────────────────────────────────────☆
   canper (洗衣粉) 於  (Fri Jan 15 00:35:22 2010)  提到:


 在考慮一個問題，一個好的汽車工程師不需要擁有技師的技能。
 一個好的服裝設計師不一定是個好裁縫。


 但是一個好的軟體設計師不是一個好的程式設計人員就不靠譜了

【 在 canper (洗衣粉) 的大作中提到: 】
:  不過同樣的事情如果放到建築業就不是那麼回事了，設計師畫完圖紙就完了，沒有必要建一棟房子來驗證自己的設計。
:   如果是服裝業呢，好像也要做出樣品來看看效果。




☆─────────────────────────────────────☆
   timshaw (寫啥呢？真矛盾) 於  (Fri Jan 15 00:36:00 2010)  提到:

這就是軟體業的design和implementation不可分離的特點啊。

【 在 canper (洗衣粉) 的大作中提到: 】
:  在考慮一個問題，一個好的汽車工程師不需要擁有技師的技能。
:  一個好的服裝設計師不一定是個好裁縫。
:  但是一個好的軟體設計師不是一個好的程式設計人員就不靠譜了
: ...................



☆─────────────────────────────────────☆
   canper (洗衣粉) 於  (Fri Jan 15 00:38:02 2010)  提到:


 但是一個好的軟體工程師不需要是一個好美工，哈哈
【 在 timshaw (寫啥呢？真矛盾) 的大作中提到: 】
: 這就是軟體業的design和implementation不可分離的特點啊。




☆─────────────────────────────────────☆
   timshaw (寫啥呢？真矛盾) 於  (Fri Jan 15 00:39:49 2010)  提到:

這裡的design不是指UI design,而是指 architecture啊。
【 在 canper (洗衣粉) 的大作中提到: 】
:  但是一個好的軟體工程師不需要是一個好美工，哈哈




☆─────────────────────────────────────☆
   qingrun (青潤) 於  (Fri Jan 15 14:25:48 2010)  提到:

這 樣的實驗我做過，02年8月，南京地稅金力四期專案上，我從上海帶了5個人過去參加tp當年的團隊，後面給了我兩個星期做一個模組實用性原型，成都那邊給 了我一個美工，我這邊自己做模型開發，設計完成後，分給了一個做頁面，一個做資料庫，我做業務控制層，一個人做銀行介面的扣款，一共8天不到全部搞定，一 次性通過測試。
做介面和資料庫開發的人完全是在我給定的模型匯出的程式碼上進行的，我們做了一次設計變更，形成了一個獨立的直接物件資料的寫入類。
所以，我一直定義的編碼人員就是印度的那種編碼層次就足夠了。
不是說設計人員完全脫離編碼，而是對於一些創造性和創新性或者說有一定難度的編碼是需要設計人員寫好的，類似於過去傳統軟體工程中提出的微程式碼的開發階段所完成的內容。
這樣，就可以完整地實現程式碼設計的分離。實現我們的對印外包。

【 在 canper (洗衣粉) 的大作中提到: 】
:  我覺得軟體中設計和編碼分開也是完全可以的，但並不表示這樣就可以降低編碼人員的水平，以及設計者可以不參與到編碼階段中。
:   我想配合設計師一起組織樣品車的技術的工資也不是和普通工人一個檔次的。



☆─────────────────────────────────────☆
   qingrun (青潤) 於  (Fri Jan 15 14:28:53 2010)  提到:

一個好的汽車工程師也需要好的技師的配合，在做一些設計的時候，需要他們才實現設計，然後進行驗證，獲得驗證結果後，對設計進行調整和優化——我的本專業材料學就是幹這個的，現在大多數同學都在汽車行業，嘿嘿。

【 在 canper (洗衣粉) 的大作中提到: 】
:  在考慮一個問題，一個好的汽車工程師不需要擁有技師的技能。
:  一個好的服裝設計師不一定是個好裁縫。
:  但是一個好的軟體設計師不是一個好的程式設計人員就不靠譜了



☆─────────────────────────────────────☆
   blueslc (Thomas) 於  (Fri Jan 15 17:44:54 2010)  提到:

但對於軟體開發，對開發者來說，我們經常都是在造第一座房子，有時候還是在原來房子的基礎上加層，更加困難
【 在 qingrun (青潤) 的大作中提到: 】
: 這個對比似乎應該是科學研究與工程對比，科學研究是造第一座房子，然後工程才是重複後面的房子過程，呵呵。
: 我個人認為，這本書裡面講的這個工程的解釋應該是完全錯誤的。它混淆了科研與工程之間的差異。



☆─────────────────────────────────────☆
   qingrun (青潤) 於  (Fri Jan 15 18:10:17 2010)  提到:

不管我們做什麼軟體，這個軟體大部分都是此前已經有人做過的，或者有過類似的，或者至少是在原理上已經被證明過的，如果非要強調，應該說，科學是對原理的驗證，而工程是對原理的實現。
難度有可能實現比推理過程更難，所以，在科學領域的很多學科上都有大量至今還無法驗證的假設，這是客觀存在的，假設往往需要很多條件滿足後才可能被驗證，所以，那本書上說的工程的所謂概念是完全錯誤的！！！

【 在 blueslc (Thomas) 的大作中提到: 】
: 但對於軟體開發，對開發者來說，我們經常都是在造第一座房子，有時候還是在原來房子的基礎上加層，更加困難



☆─────────────────────────────────────☆
   ilovecpp (cpp) 於  (Fri Jan 15 23:48:23 2010)  提到:

【 在 timshaw (寫啥呢？真矛盾) 的大作中提到: 】
: 我再講些感想。
: 軟體工程是如此的複雜，風險是如此的高，搞到65%的軟體專案延期，30%的專案
: 直接取消。
: 跟傳統工程的按時交付率差別如此之大。

傳統工程真有這麼牛？

787的延期，Larabee的延期，業界巨頭數十億美元輕易打水漂。

一部美國軍機發展史，就看見三個詞：延期，超出預算，專案取消。

軟體工程喜歡拿蓋房子作比。蓋房子真是這個時代最接近軟體工程的傳統工程？

我父母是電子工程師。我的直觀印象是，電子產品的開發決不像蓋房子，倒是和
軟體開發的過程頗多相似之處。

和傳統工程比，我們做得真的更差嗎？

諸多疑問，難以釐清。



☆─────────────────────────────────────☆
   qingrun (青潤) 於  (Sat Jan 16 11:23:17 2010)  提到:

對 於國內來說，我們和國外的差距主要在管理意識上，而不是技術層面；由於管理意識的差異，引起的投資方對軟體系統的渴望和要求有了非常大的變化，國內的傳媒 方面對國外軟體專案的報道，也包括國外對自己的軟體工程實施的報道也都大多集中於成功的例子，加上隨著大家對科技進步的奢望，總認為軟體應該能做到什麼什 麼樣子，應該能解決什麼什麼問題，卻忽視了軟體本身最需要解決的根本問題：資料積累。
國外的軟體行業走過了超過我們三倍以上的時間，他們積累的資料基礎遠遠不是我們目前能夠比擬的。
對 美國來說，因為幾次世界大戰都沒有到他的本土，他的企業和經濟的延續性在全世界範圍內都可以算是最好的，其資料的保持也是最好的，而我國，大部分企業都是 80年以後重建的，更多的資料在二戰，文革中全面毀滅，沒有剩下什麼，我們所能研究到的資料積累能超過10年的都不多，而且大部分是未資訊化處理的原始數 據，但是同時，國內的宣傳為了獲得眼球的注意力，更多的關注在國外已成功地專案和目前的技術積累和產品狀態下，所以，附帶而來，傳統行業在資訊化的時候對 我們的期望就處於一個相對過高的水平線上，於是就帶來了意識與技術現實的直接衝突，加上可投入研發資金和積累的時間問題，於是這個矛盾就更為劇烈了。
所以，不是我們做得不夠努力，而是環境太過於苛刻了。
雖說解決這些問題不是不可能但是，需要多方面的配合和引導，涉足點太多，就超出了這個話題了。呵呵
【 在 ilovecpp (cpp) 的大作中提到: 】
: 傳統工程真有這麼牛？
: 787的延期，Larabee的延期，業界巨頭數十億美元輕易打水漂。
: 一部美國軍機發展史，就看見三個詞：延期，超出預算，專案取消。
: 軟體工程喜歡拿蓋房子作比。蓋房子真是這個時代最接近軟體工程的傳統工程？

: 我父母是電子工程師。我的直觀印象是，電子產品的開發決不像蓋房子，倒是和
軟體開發的過程頗多相似之處。

: 和傳統工程比，我們做得真的更差嗎？

: 諸多疑問，難以釐清。


☆─────────────────────────────────────☆
   blueslc (Thomas) 於  (Sat Jan 16 11:40:07 2010)  提到:

那軟體的開發算是科學？還是算是社會學？很多事情都沒有這麼絕對的。
【 在 qingrun (青潤) 的大作中提到: 】
: 不管我們做什麼軟體，這個軟體大部分都是此前已經有人做過的，或者有過類似的，或者至少是在原理上已經被證明過的，如果非要強調，應該說，科學是對原理的驗證，而工程是對原理的實現。
: 難度有可能實現比推理過程更難，所以，在科學領域的很多學科上都有大量至今還無法驗證的假設，這是客觀存在的，假設往往需要很多條件滿足後才可能被驗證，所以，那本書上說的工程的所謂概念是完全錯誤的！！！



☆─────────────────────────────────────☆
   canper (洗衣粉) 於  (Sat Jan 16 11:47:17 2010)  提到:


 這篇說的好，呼喚版主m之
【 在 qingrun (青潤) 的大作中提到: 】
: 對於國內來說，我們和國外的差距主要在管理意識上，而不是技術層面；由於管理意識的差異，引起的投資方對軟體系統的渴望和要求有了非常大的變化，國內的傳媒方面對國外軟體專案的報道，也包括國外對自己的軟體工程實施的報道也都大多集中於成功的例子，加上隨著大家對科
: 國外的軟體行業走過了超過我們三倍以上的時間，他們積累的資料基礎遠遠不是我們目前能夠比擬的。
: 對美國來說，因為幾次世界大戰都沒有到他的本土，他的企業和經濟的延續性在全世界範圍內都可以算是最好的，其資料的保持也是最好的，而我國，大部分企業都 是80年以後重建的，更多的資料在二戰，文革中全面毀滅，沒有剩下什麼，我們所能研究到的資料積累能超過10年的都不
: ...................



☆─────────────────────────────────────☆
   qingrun (青潤) 於  (Sat Jan 16 11:56:03 2010)  提到:

軟體開發是工程學的內容，絕對不是科學領域直接關聯的內容，當然，一切都是在科學理論的指導或者指引下完成的，這個事情，可以說是絕對的。
科學的概念和範疇是可以明確地東西。這個問題也是可以明確地，呵呵。

【 在 blueslc (Thomas) 的大作中提到: 】
: 那軟體的開發算是科學？還是算是社會學？很多事情都沒有這麼絕對的。



☆─────────────────────────────────────☆
   canper (洗衣粉) 於  (Sat Jan 16 12:02:23 2010)  提到:


 後面兩項我都不喜歡，每次同事去的時候我就躺一邊睡覺，讓他們很鬱悶
【 在 timshaw (寫啥呢？真矛盾) 的大作中提到: 】
: 在深圳啊，來的話請吃腸粉...^_^，晚上可以去吃糕點。no洗腳no按摩




☆─────────────────────────────────────☆
   canper (洗衣粉) 於  (Sat Jan 16 12:09:13 2010)  提到:


 我就一個寫程式碼兼做工程的，整天和客戶打交道
【 在 timshaw (寫啥呢？真矛盾) 的大作中提到: 】
: 莫非你是技術顧問/總監，老被銷售經理拉著壓陣�




☆─────────────────────────────────────☆
   timshaw (寫啥呢？真矛盾) 於  (Sat Jan 16 12:20:57 2010)  提到:

說起這個來，確實在管理意識上有些不匹配，舉個很弱的例子
我以前有個非it的老大，買了個2w的asp原始碼，後來幾個專案非要我用這個asp原始碼，一個專案下來用“不要改”阻擊了我起碼快20次提議。
他很難理解有現成的東西為啥不用，彷彿另起爐灶或者升級給就算是把他那小2w給浪費了會給他造成很多成本費用似的。雖然我解釋過很多次。
搞軟體有時候對成本對質量的貢獻，管理人員在管理層面上過程成層面上的運作不見得比技術人員關鍵。
此時，我想起一本書（應該是《軟體工程的事實與謬誤》）前言中提到作者說過的一句話，大意是說他喜歡搞技術，很享受這種技術人的意見壓倒管理者命令的狀況。當時我覺得很好笑，我心想在中國你有立錐之地嗎？


【 在 qingrun (青潤) 的大作中提到: 】
: 對於國內來說，我們和國外的差距主要在管理意識上，而不是技術層面；由於管理意識的差異，引起的投資方對軟體系統的渴望和要求有了非常大的變化，國內的傳媒方面對國外軟體專案的報道，也包括國外對自己的軟體工程實施的報道也都大多集中於成功的例子，加上隨著大家對科
: 國外的軟體行業走過了超過我們三倍以上的時間，他們積累的資料基礎遠遠不是我們目前能夠比擬的。
: 對美國來說，因為幾次世界大戰都沒有到他的本土，他的企業和經濟的延續性在全世界範圍內都可以算是最好的，其資料的保持也是最好的，而我國，大部分企業都 是80年以後重建的，更多的資料在二戰，文革中全面毀滅，沒有剩下什麼，我們所能研究到的資料積累能超過10年的都不
: ...................



☆─────────────────────────────────────☆
   timshaw (寫啥呢？真矛盾) 於  (Sat Jan 16 12:22:05 2010)  提到:

昨晚上看到一本用友人寫的書，說很多技術顧問不願意跟著銷售出去吃喝玩樂，而銷售經理又不好意思不叫，怕得罪啊。..
【 在 canper (洗衣粉) 的大作中提到: 】
:  我就一個寫程式碼兼做工程的，整天和客戶打交道




☆─────────────────────────────────────☆
   qingrun (青潤) 於  (Sat Jan 16 12:25:42 2010)  提到:

我去年年初就拍死了一個合作公司的市場，對技術人員太不尊重了，後來他們還過來找了我一次，希望我繼續提供諮詢和培訓，我沒理他，就沒有再找我了。

【 在 timshaw (寫啥呢？真矛盾) 的大作中提到: 】
: 昨晚上看到一本用友人寫的書，說很多技術顧問不願意跟著銷售出去吃喝玩樂，而銷售經理又不好意思不叫，怕得罪啊。..



☆─────────────────────────────────────☆
   qingrun (青潤) 於  (Sat Jan 16 12:26:50 2010)  提到:

所以，在中國，有技術基礎，又能謙虛做事的專案管理人員才可能把專案做的很好，單純的強勢或者弱勢專案經理都是不好當的。呵呵。

【 在 timshaw (寫啥呢？真矛盾) 的大作中提到: 】
: 說起這個來，確實在管理意識上有些不匹配，舉個很弱的例子
: 我以前有個非it的老大，買了個2w的asp原始碼，後來幾個專案非要我用這個asp原始碼，一個專案下來用“不要改”阻擊了我起碼快20次提議。
: 他很難理解有現成的東西為啥不用，彷彿另起爐灶或者升級給就算是把他那小2w給浪費了會給他造成很多成本費用似的。雖然我解釋過很多次。
: ...................



☆─────────────────────────────────────☆
   keygen (貧賤夫妻百事哀) 於  (Sat Jan 16 12:29:09 2010)  提到:

技術牛的專案管理人員強勢點，大家倒是很願意接受的。哈哈
【 在 qingrun (青潤) 的大作中提到: 】
: 所以，在中國，有技術基礎，又能謙虛做事的專案管理人員才可能把專案做的很好，單純的強勢或者弱勢專案經理都是不好當的。呵呵。




☆─────────────────────────────────────☆
   qingrun (青潤) 於  (Sat Jan 16 12:34:02 2010)  提到:

那樣會有一個問題出現，而且這個問題根本無法解決，那就是：
如果團隊內有一個差不多一樣牛的技術人員存在的話。

我曾經在自動化所跟隨過一個技術很牛的研究員，離開後，寫了一系列好像是五篇相關文字在我的blog上，就是談如何和一個純技術的老闆合作的話題。
和他的合作就存在一個很嚴重的問題，那就是：他情商太低，低到了公認的負值——有人說這還不夠。
一個例子08年底到09年中期，他發生了兩次學生集體叛逃的事件，第一次18個學生9個集體提出換導師，其中有兩個博士，是我在的時候的弟兄，人很老實，都已經博士第三或者第四年了，你想想，能把人家壓迫成什麼樣子才能逼人家做出這樣的選擇。呵呵。
技術上大家都服氣，都認為他很牛，我出來後，提到他也都說，他技術上的確很牛，別的，大都一帶而過，偶爾用類似上面的事件作證明來說明一些，呵呵。
【 在 keygen (貧賤夫妻百事哀) 的大作中提到: 】
: 技術牛的專案管理人員強勢點，大家倒是很願意接受的。哈哈



☆─────────────────────────────────────☆
   timshaw (寫啥呢？真矛盾) 於  (Sat Jan 16 12:50:26 2010)  提到:

你這麼一說我還真是眼界太窄了。。光盯著那些蓋房子的了
下次再打聽打聽別的行業
【 在 ilovecpp (cpp) 的大作中提到: 】
: 傳統工程真有這麼牛？
: 787的延期，Larabee的延期，業界巨頭數十億美元輕易打水漂。
: 一部美國軍機發展史，就看見三個詞：延期，超出預算，專案取消。
: ...................



☆─────────────────────────────────────☆
   canper (洗衣粉) 於  (Sat Jan 16 13:35:40 2010)  提到:


   其實每時每刻這種事情都在發生，基本上大家都把拍馬屁當做一種禮儀，可是並不是每個人都喜歡別人拍的，人家又覺得不拍不禮貌，拍了對方沒反應有覺得對方不禮貌。
【 在 timshaw (寫啥呢？真矛盾) 的大作中提到: 】
: 昨晚上看到一本用友人寫的書，說很多技術顧問不願意跟著銷售出去吃喝玩樂，而銷售經理又不好意思不叫，怕得罪啊。..




☆─────────────────────────────────────☆
   timshaw (寫啥呢？真矛盾) 於  (Sat Jan 16 13:38:57 2010)  提到:

所以你在洗腳房裡睡覺，他們估計在嘀咕:難道是要把妞送到他房裡去? @_@
開個玩笑。

【 在 canper (洗衣粉) 的大作中提到: 】
:    其實每時每刻這種事情都在發生，基本上大家都把拍馬屁當做一種禮儀，可是並不是每個人都喜歡別人拍的，人家又覺得不拍不禮貌，拍了對方沒反應有覺得對方不禮貌。




☆─────────────────────────────────────☆
   canper (洗衣粉) 於  (Sat Jan 16 13:41:40 2010)  提到:


 沒有，每次出來他們都使勁的和我說這是很健康的事情，不要想歪了等等。


 天地良心，我從來都認為這是很健康很健康的事情，但是健康的事情多了去了，又不見得一定要做。話說每星期打羽毛球我都沒去，怎麼就沒人來和我解釋：打羽毛球是很健康的事情。

【 在 timshaw (寫啥呢？真矛盾) 的大作中提到: 】
: 所以你在洗腳房裡睡覺，他們估計在嘀咕:難道是要把妞送到他房裡去? @_@
: 開個玩笑。




☆─────────────────────────────────────☆
   SPQR (蒼狼) 於  (Sat Jan 16 17:52:51 2010)  提到:

這是因為不會說話啊...
做銷售的, 何至於這麼不會溝通

【 在 timshaw (寫啥呢？真矛盾) 的大作中提到: 】
: 昨晚上看到一本用友人寫的書，說很多技術顧問不願意跟著銷售出去吃喝玩樂，而銷售經理又不好意思不叫，怕得罪啊。..




☆─────────────────────────────────────☆
   SPQR (蒼狼) 於  (Sat Jan 16 17:54:29 2010)  提到:

打羽毛球是很健康的事情

【 在 canper (洗衣粉) 的大作中提到: 】
:  沒有，每次出來他們都使勁的和我說這是很健康的事情，不要想歪了等等。
:  天地良心，我從來都認為這是很健康很健康的事情，但是健康的事情多了去了，又不見得一定要做。話說每星期打羽毛球我都沒去，怎麼就沒人來和我解釋：打羽毛球是很健康的事情。




☆─────────────────────────────────────☆
   timshaw (寫啥呢？真矛盾) 於  (Sat Jan 16 18:17:17 2010)  提到:


銷售來了，贊o(∩_∩)o...哈哈
【 在 SPQR (蒼狼) 的大作中提到: 】
: 這是因為不會說話啊...
: 做銷售的, 何至於這麼不會溝通




☆─────────────────────────────────────☆
   finely (finely) 於  (Sat Jan 16 20:55:03 2010)  提到:

你們都喜歡髮長文 啊

我說個簡短的，主要就是“工程”和“研究”之區別

工程就是幹活，理論和工具都是現成的，用就是了

研究是高難度的創新，是製造理論和新工具的

軟體從本質上講，是個工程，但是一個複雜度極高的工程，以至於很難控制，所以需要一些理論和方法來控制這個工程。

【 在 ihomd (ihomd) 的大作中提到: 】
: 別笑我弱大家討論討論，呵呵
: 我老聽說“要以工程的方法來開發軟體..."等等類似忠告。可以我怎麼也不能領會工程的真
: 正意義。
: ...................



☆─────────────────────────────────────☆
   SPQR (蒼狼) 於  (Sat Jan 16 22:43:39 2010)  提到:

有意思

所以工程大致是(關鍵字)
1) 應用/製造 (輸出是可以直接使用的實物)
2) 系統化的/方法論的

不是;
1) 研究 (輸出是研究報告)

但是其實工程這個概念是不需要嚴格界定的

【 在 finely (finely) 的大作中提到: 】
: 你們都喜歡髮長文 啊
: 我說個簡短的，主要就是“工程”和“研究”之區別
: 工程就是幹活，理論和工具都是現成的，用就是了
: ...................



☆─────────────────────────────────────☆
   zhangmike (秦月) 於  (Sun Jan 17 08:21:43 2010)  提到:

正確的短文的產生 是先有長文，再提煉,提煉完了後，短文就不完全對，一般95%的情況下是對的。還有5%的特殊情況下就不對。
然後就又有討論和爭論，焦點在5%的部分。
所以有時間也可以看看長文。


【 在 SPQR (蒼狼) 的大作中提到: 】
: 有意思
: 所以工程大致是(關鍵字)
: 1) 應用/製造 (輸出是可以直接使用的實物)
: ...................