自今年带领ETP团队敏捷转型后自己和团队的做事和思考的方式有了很大转变，也意识到很多习以为常中的不正常。
传统需求交接下经常出现这样的场景（以ETP产品真实故事举例）:
图一:谁对谁错?
以前的我会认为BA没有把需求文档写清楚产生了歧义，认为开发没有主动思考和BA确认，会让BA尽可能把文档写清楚。这样真的能解决问题吗?那么BA写到什么程度才是OK呢?其实我们都陷进了文档的陷阱，一个把文档作为软件交付达成一致信物的巨大陷阱，我们拿着这个信物让业务owner签字确认，让开发照着做，结果用户想要个小龙女我们却做成了小笼包，开发和BA都认为自己没有问题，用户也很无奈，"我虽然签了字，但几百页的需求文档我不可能一字字读吧"。产生这样尴尬局面的根因是我们用错了文档这个工具。
没有不好用的工具，只有使用不当的工具。文档是供人学习，阅读和备忘的，如果作为软件交付的凭证，缺少对需求的沟通，讨论和理解就会造成我们上面图片中情况。不论你在团队中是什么角色，如果发现了团队正身处文档陷阱都有义务提出，和团队一起持续改进是非常棒的事情！
那么敏捷团队在弱化文档之后如何帮助团队对需求理解达成一致呢?下期一起探讨用户故事地图，先抛个砖
文档陷阱——你中过招吗?
网友评论