你需要的是一个承诺
工作了四年以后，我升职为高级软件工程师。这里的升职不是管理上的提升，其实我现在只需要管好我自己，而是对一个软件工程师成熟度的认可。一个高级工程师，较之一个刚毕业的新手而言，他应该能够独立的推进一个项目，从技术，到和其他组的交流协作，都能够独当一面。我最近遇到的一个难题，就是如何和产品经理有效的协作来保证项目的进度。后来学习到一个秘诀，就是要别人的承诺。
具体的故事，是这样发生的。我和项目经理，一起制定使用者剧本(user story)，会议结束的时候，我们分了工。我的项目经理，要先在这些剧本里，加入验收测试，然后，我再预估它们的复杂度。换句话说，我的任务依赖着他的，他做不完，我就起不了步。
当天下午，大家很高心的散会了。第二天，我问他测试写明白了吗。他说他明天给我，我说好吧。可第三天，依旧没写好。我问他，他又说再等一天。三天过去了，剧本没写好，没测试，我没开工。
后来我的上司看到了，略有不爽，他说，怎么都第四天了，还没有开工。我当时想辩解，说不是我的错，因为我得等别人的活完了才能开始自己的，我是被别人耽误了。后来想辩解也没有意义，特别是这种推卸责任的辩解更没有意义。我的产品经理，当时也意识到自己确实没做好，在第四天，他写了测试。
后来，我找到了老板，高级高级工程师，问他我在这种情况下，应该怎么办？他给我讲了一下他作为新手时犯的错误，也给我说了一个解决办法。
在他是新手的时候，如果他依赖的人太慢，我老板就自己替他人把活做了。这样进度会有，但不是长久之计。首先，替他人把活做了，僭越了不说，到时候万一你做的并不是人家的本意，之后还得重头再来，特别是这种产品经理写验收测试的活，程序员一定要让他们从产品，从用户的角度来写测试，不能以程序员对产品的理解去写。其次，即便替人做的好，可自己的精力毕竟有限，不能作为长久的打算。
所以不可取，那么什么可取呢？回到我的经历中来，第一天，大家高兴散会的时候，不能就那么散了，而要问清楚，你什么时候能给我一个满意的答复，我们需要对方的一个承诺。承诺的远近并不是问题。远了，说明他有优先级更高的事情要做，要么，我不能干等，要么，我们把问题上传给决策者来重新讨论优先级。近了，更好。承诺的重要性在于明确各方的责任点和责任段，是为了更有效的交流，不至于把时间用在等待里。