标签：
场景一：某研发需要确认需求，找了A，A让找B，B让找C，C不在，研发的工作中断
场景二：某测试发现问题，研发要求借用环境，测试认为影响其测试工作，两者白扯不清。
第一个问题是沟通距离太长，容易导致工作暂停。我个人对此深恶痛绝，当我像被踢皮球似的，从A到B再到C，而且C还不在，我心情之差可想而知，更别说高效工作了。我组件团队时，对自己的要求是让团队都能开心的工作（其实效率高很容易让人工作开心，毕竟不用加班~）。为了达到这个目的，我需要快速的响应团员的需求，其实这就是统一团队中PO的作用，在很多情况下，要做到这点并不容易，但是要是能做到，则效果是惊人的。基于前面的描述，整个系统的重构都是我设计的，我在需求方面的权威是绝对的，因此基本上所有需求我都能确认，无需找其他人。这也反过来让团员心无旁骛，工作惯性一直持续。迭代回顾统一认可好的方面是“分工明确，沟通氛围好”
第二个问题是不同角色间的沟通的问题，测试同事也需要高效工作，自然不希望被打断。解决这个问题，我的做法是安排一个沟通、组织型研发人员（最好具有影响力）与测试同事一起完成测试例，这个研发人员能够快速帮助测试同事解决一些小问题，测试同事无需纠结在这些小问题上，工作效率得以提升。另一方面，如果是重要问题，该研发人员也能够协助一起定位分析，避免影响到研发团队。再者如果需要协调更多人来定位，该研发人员也能够保证快速协调到人员来定位。最大程度保证测试同事的工作不被打断，高效工作。（对该研发人员的手段要求很高，不过这个方法也是当初IBM的人教的，当时我作为该角色与测试同事一起，能够明显感觉到整个测试部门对该角色的需求，20多号人轮流问我，累的不行）
鉴于上述的分享，谈一下我对“统一团队的目的”的看法：打通沟通的障碍，让彼此间的沟通距离为1。这些都有很多小案例，例如PO需要承担非常多的外部沟通责任，避免影响团队内成员。还有当PO无法把握的事情，需要亲自和团员一起确认，无需团员来组织沟通。
还有一个分享就是当团队比较大时，像我所描述的团队人员有13人，这时PO的工作会非常累。我的做法是发现有影响力的人，并将其树立为Team Leader，由其分担一部分工作。事实上我的运气比较好，团队里有两个这样的人员，我顺势分成两个小组，这两个人员的积极性很高，而且也有意愿帮助组内的同事，同时我也确保组员有疑问时，组长也要清楚，从而达到极好的沟通效果。（例如我可能）
标签：
原文地址：http://blog.csdn.net/jamesf1982/article/details/45286955
