项目中的加减法－－《最后期限》读书笔记（1）
题记：最近重读《最后期限》，有了不少的感触，上次读这本书还是大学的时候呢，看来有些东西只有当实际做过了用过了，才会明白起来，做多了用多了，才会真的明白。好多东西还是无法一时接受，所以写个笔记吧，三五行，亦或三五十行，呵呵，反正我很少有耐心看完五十行的博客，所以我会尽量控制长度，再者，我可能也没有那么多话说。
昨天被领导拉去开会，事情起因是前些天的一个项目，项目比较急，但时间却无多，所以没有走正规的流程，由我和另一同事－－两个程序员－－直接出了需求文档，然后发给相关的人征求意见。这样做，一是因为策划、市场的人不一定有时间来做这个，二是策划相对电子商务行业还算个新人，不一定能够很好理解这个与业务相关性极大的项目，三是如果策划、市场他们来做需求，那么需求一定会变得很庞大，这个项目的完工日期将会被拖延太久，但项目的最后期限却是在看得到的将来。
会议上，一些人发表了自己的看法，我们的文档已经被改的面目全非了，有人在里面添加了很多东西，领导也谈了不少自己的想法，说实话，那些想法的确是非常非常好的想法，不得不承认每个人都有自己的优势，我一直坐在那里没怎么说话，因为我在思考一个问题：现在能够做什么？诚然他们有很多好的主意，但是并不比我提出这个项目时所想的多，我甚至比他们想的还要多得多，然而最终出来的却是一份所有人都认为极其简单，简单到简陋的需求。
现在能做什么？是的，什么也做不了，照现在这样子，什么都做不了！所以我直接告诉领导说：我们没有时间。我必须去很好的协调另一些同事，并且大家都很努力的去工作，才“有可能”完成早已分配好的任务，这个项目是临时加进来的，因为真的很需要，然而我们却没有人有时间去做，唯一的办法就是放弃，放弃所有可以放弃的功能，这样做肯定会有人有意见，但好处却远大于坏处：
坏处：- 那些人修改需求的时间基本算是浪费了
- 一些功能将不会被实现，而且短期内没有被添加进去的可能
- 只需要完成程序员自己提出的需求，不会因为需求理解上的偏差导致项目延期
- 项目可以在一个可以忍受的期限内交付使用
- 程序员会比较乐意去做这件事，生产效率可能会有很大的提升
- 不会为了赶进度而写出烂的代码（关于进度与压力的问题，下一篇会说一说）
- 程序员的成就感，来自需求和项目的双重成就
- 如果项目想不延期，必须分配合理的人员和时间，并且必须放弃一些功能
- 程序员的想法不比别人少，但总做不好一些事，原因是没有时间，而非其他借口
回头看看刚才写的，真的很烂，肯定是没表达清我的意思，看来太久不写些东西，也是为退化滴
