題記：最近重讀《最后期限》，有了不少的感觸，上次讀這本書還是大學的時候呢，看來有些東西只有當實際做過了用過了，才會明白起來，做多了用多了，才會真的明白。好多東西還是無法一時接受，所以寫個筆記吧，三五行，亦或三五十行，呵呵，反正我很少有耐心看完五十行的博客，所以我會盡量控制長度，再者，我可能也沒有那么多話說。

昨天被領導拉去開會，事情起因是前些天的一個項目，項目比較急，但時間卻無多，所以沒有走正規的流程，由我和另一同事－－兩個程序員－－直接出了需求文檔，然后發給相關的人征求意見。這樣做，一是因為策劃、市場的人不一定有時間來做這個，二是策劃相對電子商務行業還算個新人，不一定能夠很好理解這個與業務相關性極大的項目，三是如果策劃、市場他們來做需求，那么需求一定會變得很龐大，這個項目的完工日期將會被拖延太久，但項目的最后期限卻是在看得到的將來。

會議上，一些人發表了自己的看法，我們的文檔已經被改的面目全非了，有人在里面添加了很多東西，領導也談了不少自己的想法，說實話，那些想法的確是非常非常好的想法，不得不承認每個人都有自己的優勢，我一直坐在那里沒怎么說話，因為我在思考一個問題：現在能夠做什么？誠然他們有很多好的主意，但是并不比我提出這個項目時所想的多，我甚至比他們想的還要多得多，然而最終出來的卻是一份所有人都認為極其簡單，簡單到簡陋的需求。

現在能做什么？是的，什么也做不了，照現在這樣子，什么都做不了！所以我直接告訴領導說：我們沒有時間。我必須去很好的協調另一些同事，并且大家都很努力的去工作，才“有可能”完成早已分配好的任務，這個項目是臨時加進來的，因為真的很需要，然而我們卻沒有人有時間去做，唯一的辦法就是放棄，放棄所有可以放棄的功能，這樣做肯定會有人有意見，但好處卻遠大于壞處：

壞處：

• 那些人修改需求的時間基本算是浪費了
• 一些功能將不會被實現，而且短期內沒有被添加進去的可能

好處：

• 只需要完成程序員自己提出的需求，不會因為需求理解上的偏差導致項目延期
• 項目可以在一個可以忍受的期限內交付使用
• 程序員會比較樂意去做這件事，生產效率可能會有很大的提升
• 不會為了趕進度而寫出爛的代碼（關于進度與壓力的問題，下一篇會說一說）
• 程序員的成就感，來自需求和項目的雙重成就

結論：

• 如果項目想不延期，必須分配合理的人員和時間，并且必須放棄一些功能
• 程序員的想法不比別人少，但總做不好一些事，原因是沒有時間，而非其他借口

回頭看看剛才寫的，真的很爛，肯定是沒表達清我的意思，看來太久不寫些東西，也是為退化滴

轉載于:https://www.cnblogs.com/dingxue/archive/2007/09/05/The_Deadline_1.html

總結

以上是生活随笔為你收集整理的项目中的加减法－－《最后期限》读书笔记（1）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。