最近和好友们一起谈到项目开发的体会。听到了一个队友很值得思考的观点。
领导安排队友做一个略有难度的程序模块(注意是略有)，规定时间是8天。于是到了第七天,领导便按惯例惶恐不安弱弱的来问队友是否差不多了，第八天是否能准时完成。
据悉 队友当时给领导的回复差点让领导昏厥了过去,队友回复领导该模块还没做，原因是花了7天时间做了思考并且设计思路和架构，打算明天花1天时间来完成。
以下省略 领导和队友激烈的争执细节，结果是事已至此，只能按队友的思路做。
上述一个小故事看似很平常，却体现了两个不同角度的观点。
对于队友：
1.已经厌烦了提前完成程序后，随后几天噩梦般的修改与返工.
2.队友更注重了开发前的设计和思考
3.深入的领会了“磨刀不误砍柴工”的精髓
4.既然工期是8天，那就不折不扣的利用工期，保证量的同时还应该保证质。
对于领导：
1.队友的行为有消极怠工的嫌疑。
2.原来8天的工期如果3天做完，后面5天可以用来测试和完善。领导认为这这种方式是最好的方式。
3.万一前7天做的思路是有问题的或者根本就是错的，那么第八天将会功亏一篑。
4.认为IT行业，尤其是应用级项目的开发，同时还是国内的一些中小型企业，“磨刀误砍柴工”，领导认为根据实际情况来安排1+7 还是7+1才是对的，往往我们需要边砍柴边磨刀。
上述两方其实各有道理，确实从中小型企业来讲 领导的观点更为稳妥，特殊大型企业或产品化成熟度较高的企业，队友的观点更为有效。
1+7还是7+1 还是要根据企业、团队、产品化程度来定，不过呢，写到这很多网友肯定要喷，既然要按实际情况来定那么还写这个文章干吗。
为了满足有些喷友的需要，其实从我个人不成熟的角度来讲 我更倾向于领导观点的改良版。
往往一个项目的上线或者一个产品的推出，边砍柴边磨刀的例子实在太多（想想微软吧）,作为项目化的开发团队7+1是不符合实际情况的，产品化的团队1+7是不负责任的。
因此结合整体情况，很可能我们更需要的是7个1 ，而不是任何的1+7还是2+5或3+ 4.
也就是说作为项目经理， 制定大时间计划是对的。但是作为具体实施的项目组长或开发人员应该把工期切分为以天为单位的进度计划（同时每天要有一个下述关系的成果关联性）:第二天
用来验证第一天的成果，第三天验证第一和第二天的成果，第四天验证第二和第三天的成功(此时第一天的成果一定要保证无需验证)。用数列可以显示 1,1,2,3,5,8,13,聪明的你一定会看出这
个规律，这是个斐波那契数列。
当我们使用这种方法来安排8天的计划时，会确保每天安排计划所产生成果的连贯性和健壮性，如果中间某个环节出现问题不会影响到所有环节，只会影响相邻的3个环节而已。
最后要说明的是，无论1+7 还是7+1或者 上述的数列理论，都有失效的时候，世界本是就是不完美的，完美只能 “力求”而不能强取，希望本文对各位项目管理者有启发和帮助。