正确认识：
前两个定律可以统一称为不完美定律。正因为各种不完美的存在，人不完美，环境不完美，所以项目进度一定会被各种因为干扰，时间不够是大概率的事件，是常规现象，时间够用才是特殊情况。接受时间和资源的矛盾，从项目已开始就要有充分的准备，赶早不敢晚，为后续各种不完美预留好缓冲空间。
常用应对策略：
1. 一定要有一个截止时间
任何项目都需要先确定交付时间，同事给出明确的各阶段时间。如果没有时间限制，项目就不可能自己结束。由于缺陷总是会有的，所以没有确定的结束时间，就不会有测试完成的时候。只要加测，总是会在测试过程中发现新的问题。
2. 明确项目目标和范围
只有范围明确，时间才能可控
要确定范围，需要先确定好项目目标。根据目标确定需要纳入的功能范。当遇到需求变更的时候，根据项目目标来判断是否需要接受这个变更。精益中讲的是明确需求的价值和意义，和这里的项目目标是类似的。
3. 从项目组的角度评估工作量和时间
开发人员最容有犯的错误是只从大妈修改的角度来评估工作量和时间。很多时候代码改起来简单，但真正投产除了写代码外，还要联调，测试，关联影响分析等等环节，实际需要的工作量和时间会成倍增加。
4. 提前知会关联系统
不再自己责任范围内的，都应该归属于不可控的范围，是未知的，是变量。我们需要尽快把不可控的变量想办法变成可控的已知的常量。尽量提前和关联方沟通，明确清楚项目组的要求，明确清楚关联方的态度和意见，把未知变成已知。
很多时候我们会喜欢先做自己负责的事情，而对涉及到其他人配合的事情会不自觉的往后推。
可能是因为责任心，比如觉得自己的事情还没搞清楚就去找其他人好像有点不妥；
也可能是有一定的社交恐惧，不被逼到最后不愿意跟其他人交流；
也可能是根据历史经验，觉得找了某人也没什么用，还不如自己研究，等等等等。
这样的结果，经常是自己搞了好几天，为了应对各种可能做了好几个方案，最后跟对方一沟通才发现完全不是那么一回事，浪费了好几天时间，当然时间就不够用了。
事实上，一旦发现可能涉及其他系统，其他人的时候，及时知会对方，和对方沟通清楚状况，是对工作也是对对方最负责的方式，也是最高效的方式。关联系统需要从技术角度，业务角度等不同角度来考虑是否有关联，有影响。
即使根据当前方案判断对关联系统没有影响，不需要对方改动，最好也要能知会到对方。
5. 不要替别人下结论
对于常年一起配合的关联系统来说，很多人对上下游系统的情况都比较熟悉，甚至对关联系统的各种处理逻辑和自己负责的系统一样熟悉。于是在项目讨论需求和方案设计的时，会出现关联系统人员不在场，就直接提对方做了决定。
由于不在自己负责范围内的系统，肯跟很熟悉某些处理逻辑，但你并不一定了解全部情况，也不一定了解历史变革，更不对系统的发展演变负责，因此无论你自己以为有多熟悉，都不应该踢对方下结论。即使某些决定是没有选择的，即使之前已经跟对方了解过的，当需要最终最决定的时候，还是由对方系统的负责人自己确定并给出结论。可以出主意，给建议，讨论方案等等，甚至可以协助对方写代码，做测试，但不应该替对方下结论。
6. 不要在本项目内改动项目外的缺陷
项目外的缺陷，是指不在本项目产生，且对本项目没有影响的缺陷。这类缺陷如果纳入本项目解决，相当于改变了项目的需求，需要重新评估影响范围，都需要登记并认真分析。项目外的缺陷一般需要转登记到产品缺陷中，并分析对产品运行是否有影响。并据此决定是马上立项解决，还是可以稍后处理
7. 不要轻易在本项目内改动非本项目范围内的代码。
这种情况最常见的是开发人员在项目开发过程中，发现了某段代码看起来是有问题的，比如写的不简练，逻辑有点混乱等，甚至看起来很明显的赋值错误。这一条和上一条项目外缺陷的类似，差别在于这个问题仅仅是开发人员从代码中推测出的问题，还没确定是否有缺陷，因为仅仅是看代码并不足以证明真的有问题。如果觉得某段代码不妥，可以根据代码找出受影响的业务场景，然后通过测试环境进行验证，通过检查生产数据确认该场景确实存在问题。实际验证过问题以后，还需要和业务一起讨论对业务的实际影响，再说应该采取什么样的解决方案。如果确定要解决，一般也不建议在本项目内解决，而是另外立项处理。
8. 小版本迭代开发
一般情况下，事物的规模越大，我们的硅酸误差也会越大。比如我们估算一栋楼的高度，误差一般在米级，而如果我们估算一台电脑的高度，误差可能会在分米级，肯定不会到米级，在校一点的估算手机的长度，误差可能连分米都不到，会精确到厘米级。所以，项目的规模越大，我们对项目完成时间的估算误差也会越大，因此时间往往不准确。而如果我们采用小版本迭代开发，控制项目规模的大小，则对项目时间和资源的估算会准确得多，从而对项目计划的管理也会更合理
扫一扫
907
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
