ibegyourpardon
2018-05-27 11:36:54 +08:00
严格来说是项目经理的事，时间节点应该项目经理把控。
即便是因为测试部门的原因造成了延误，那么项目经理也应该考虑到可能存在的延误，并及时协调各方沟通并知会，换句话说，理论上，即便测试部门人员有问题造成延误，项目经理也不是可以随意甩掉锅的。
但是，这些都是理论上的，实际上——有时候开发自己还就是测试呢，你怎么办？
现实中一般有两种解决思路。
一个是讨价还价法，就是自己预估了 1 天完成的测试，直接报 3 天，然后通常砍价还价下，也就变 1 天了。记得在相关软件里要有明文存档留证。不然也白砍了。
有的时候会变本加厉，3 天砍 1 天，中途跑过来再砍，说要半天。那这种时候就要注意，砍价要有底线。
还有个注意的点，其实也是本来应该做到的内容，测试是有项目的，不可能就用测试两个字涵盖所有内容。功能列表列个 1-10，写全了，每个分别多久时间，压测要多久，等等等等写明。
然后就变成了讨价还价的时候，你 12345 列出来，总共要多久，告诉对方。比方说往死了压都要 3 天了，对方说不行，那我们只有 2 天，必须上线。
ok，可以，那从中做一些取舍吧，比如说某某功能我们就不测了，能省下时间，但不测可能带来的风险是什么，万一出了风险是否能承受？ 你都要一五一十告诉对方，让对方做取舍，同时做书面留存。
这样除了能按时完成任务，还有个好处，体现出你和对方是站在一起的，是为了结果考虑的，你只是个执行，根据对方要求来执行的，但同时你充分为他着想了。
十有八九对方不敢自己完全做主，毕竟是风险哪，出了问题他那里敢背。但有了你的轻重缓急的列表，他也会和你站在一起，根据你给的建议，继续去向别的人或者领导阐述和解释，不管最后谁定夺，反正一直到有个人愿意为此承担责任才罢休。
所以我上面多次说了，书面留存，书面留存。
但这些套路别以为是职场生存技巧之类的，甩锅指南什么的，说到底，这确实是一种负责人的态度。把轻重缓急相关利弊都列出来，也确实能给别人做更好的决策。
有的时候我看大家都在说，领导根本不懂一个某某小功能有多复杂，领导一句话，下面要做三天，领导只给一天，还不满意，说一天怎么只做了这么个东西出来。
领导不理解是正常，术业有专攻，但我们不翻译下给他听，告诉他某某功能背后可能涉及的逻辑和可能性是什么，那领导怎么知道呢？如何把技术术语翻译成听得懂的人话，这真的是个技术活。尤其是，还要体现出你不是甩锅推卸责任，而是真的为了结果着想。
这些东西学会了也确实不能提高你的专业技能，但学会了这些，大多数情况下你能更有效率更专心的来在工作中提高你的专业技能，还是不亏的，值得一试。