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