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