3 石頭湯與煮青蛙
兩個方面,一還是'軟件的熵'當中的含義,喜歡書里面的這段話:'大多數的項目的拖
延都是一天一天發生的,系統一個特性一個特性的偏離其規范.一個又一個的補丁被打
到某段代碼上,直到最初的代碼一點沒有留下'. 二是團隊的協同合作,這樣石頭湯也很
鮮美.

4足夠好的軟件
就是俗話說的一鳥在手勝于二鳥在林.
首先得確保軟件可用性,至于亮點,特色,在可用以后才需要考慮.而且還得明確用戶需
求(雖然這點始終被強調).大家都知道系統不可能做的完美,但是自己著手開發的時候
總是朝著盡可能完美的方向發展,欺騙自己說,這個功能多么偉大,一定要加上去,那個
功能多么驚天動地,最后反而成為四不像,使項目延期.
在第一次企圖做那個todo list的時候,想著把calendar和task兩項功能完整的結合,
同時還想著把contact功能也加入,甚至還有ms porject的管理功能,但是一切都太多,
以致于設計了少數幾個界面以后就陷入了無止境的功能權衡中,因為太多東西又想完美
.所以第一次最終結果是除了最后那個簡陋的復雜的界面,什么東西都沒有,當然如今代
碼也已經不知道是不是被自己刪除,能夠留在自己硬盤上并且使用的還是那個簡簡單單
的GeeTask,功能不多,但是的確對我來說,足夠好了,如果還有新的功能,添加就是了,不
用一次就做一個大而全的玩意出來.
也想起在上一個公司參與的第一個項目,房地產的預警系統,先前同事通過研究,不知
道從哪里搞到一些其他人做的預警系統,動用高深的所謂經濟學景氣循環算法來計算,
艱難的實現這些公式.當然我們自己也不知道這個是不是準.后來我負責去給客戶實施,
在客戶處,得知了驚人的消息:客戶需要的足夠好的軟件其實就是一個新聞發布功能的
東西,因為他們也不懂,是領導的要求---領導當然也是被上層領導要求.這個例子雖然
特殊,但是也說明了一定要及早知道客戶心中的足夠好的軟件是什么.