文/花花
一直都在说团队沟通，可如何做好沟通，只有参考，没有绝对。
互联网公司一个产品的团队，规模一般有10人左右，其中PM 1-2人，RD 5-6人，QA、UI 1人这样。
这种情况下，如何打造一个沟通不畅的团队呢？
1.需求口头说，无原型，无需求说明；
没有原型或需求说明书，一般要不就是项目紧急，要不PM菜到家。
正常情况下，项目紧急，可以简单记录需求，不一定要详细需求说明，但需求变更，需要及时更改并通知。
2.项目的信息，不考虑全面就开始做事了，无确认和反馈机制。
经常个人主义以为了解了，其实只看到冰山一角。这种沟通问题，双方都有责任，到最后却都在背后黑对方。
如：
PM：我要做登录功能；
RD：好。于是做了一个包含用户名和密码的登录框；
PM：额...其实我设计的是绑定手机的用户名，不是随便命名的的用户，还有登录页面怎么没有忘记密码啊......
RD os：脑残PM......
PM os：这 RD 好low......
3.沟通后不做记录。
周会无记录，项目进度情况无记录，沟通的需求无记录，接口无记录......一切凭最强大脑做事，事后发现不对，已懵。
“我记得是这样的啊?!!”
“晕，我跟你说的是这样的，什么脑子！！”
沟通的过程一般遵循漏斗原理，发表人想传达的信息，由A传到B，再到C、D、E后，E能接收的有10%就不错了。
真是十万八千里，好脑子不如烂笔头，做记录是非常必要的。
虽说口头是最快的沟通方式，但也要预警说完就忘哦！
4.沟通工具任性，想怎样就怎样。
无文件收发、共享、在线添加编辑功能，新成员无法通过最全的文档记录快速了解工作，更多通过口头沟通。
一个常见场景：
PM：我把这个需求文档传给你啊
RD A：好啊。于是收到了qq发来的word 文档。
过一段时间后，PM更改了文档，一些地方做了变动。
RD B问A：唉，你这文档在哪里的？
RD A：必须是PM啊。
于是，B拿到手的文档，大体和A相同，但细节却不一致。
可怕的是，PM 却一直觉得自己工作做得好，把自己的产出给了有需要的人员。
目前比较流行的团队在线编辑、共享文档等协同工具有很多，可他们一般都不会采用。
（协同工具：不管是成员的聊天信息，还是来自于外部的服务信息，或者是团队中共享的文件、评论等，所有这些信息都可以随时在平台上进行搜索并呈现。）
5.“最好”的代码管理，就是没有管理。
上线无发布记录，发布的版本也许漏掉已测试好的某个功能点，发现后就撤回再发布。
不同RD 有不同开发风格，不遵循同一个规范，在一个产品里就是一坨粥。
6.信息截断，信息不同步。
场景一：
评审会，PM 说，就按照这个原型做吧。
一段时间后，UI 修改了一些需求，PM 和 RD A 说，你按照这个修改下需求吧。
开发几天后，和A 一起开发一个产品不同模块的RD B，发现接口变了，怎么回事？
了解后，“我晕，有需求变动为嘛不一起说？“
PM：“哦，现在说也不迟啊，来，咱们俩去会议室讨论下～”
RD B：......
场景二：
需求评审阶段，QA 吭哧吭哧按照原型写了好多详细用例，艾玛，太有成就感了。
开始测试，发现，咿？需求怎么变了，了解后，果真是中间临时决定修改的，最后发现用例可复用率不到一半。
QA：你改需求，口头和我说了么？你做记录修改了么？你更新文档了么？你有通知到其他所有团队的人了么？最不济你群里有说这个事例么？白白浪费我的时间！
7.非相关的人员就参与少。
QA 只负责测试，需求讨论 NO！这种情况很常见，咨询很多QA，都反馈说感觉自己的参与感少！觉得产品某处更合理之处，提出来基本没人鸟。
团队成员可以做的远非本职工作，调动所有人的积极性，百利无一害。
......
点很多，欢迎补充和吐槽～～
网友评论