大徐

我现在用双系统，主要是ubuntu，记录和写作使用自搭的本地wordpress。偶尔切换到windows下，写东西就喜欢用google doc，跨平台、跨机器。今天上google doc第一感觉速度快了，以前多少都有点延迟，打开、修改、保存这些操作不那么顺畅。之后就在右上角看到了一个暗红色的链接，New features! ，打开一看，傻了，竟然加了这么多功能！从编辑器到语言扩展，从导出、打印到搜索分类，功能强大了不少。

之前我写过一篇细节思考：给用户什么样的帮助？，里面写的多好啊，可惜一直做的不好。我发现我现在做的项目，版本更新很快，页面和功能经常改动，唯一不变的就应该是帮助文档了。产品没有稳定下来，经常大篇幅的写帮助文档，甚至图文并茂确实有点不值。因此经过几个月，多个版本的迭代以后，我发现帮助文档已经和线上的产品对不上了。有的产品已经修改了升级了，帮助文档里还是老的说明，新上线的东西帮助里面又没有体现。更要命的是，在页面上、在操作中几乎看不到适宜的帮助提示，帮助文档的链接只放在网站顶部的导航右侧的固定为之内，内容一成不变，一潭死水。更甭说给客服人员培训了，更甭说是充当一线客服去和用户沟通了。

我这么难受是因为，一方面我确实是肩负客服方面支撑的产品经理，另一方面我也确实挺重视这部分内容。不过，事实上我自己也做的不好，今天新上线的一个东西，我就没有写帮助文档，客服当然也没有写帮助文档，客服甚至都不知道阴天要上线的这些具体功能的详细描述。有啥变化客服可能比任何人知道的都晚，甚至客服是从用户哪里得知的网站变化。太被动了，太不正确了，太需要改进了。我希望在现在的流程中加入客服的环节，毕竟产品上线后客服是必须的，而且是很重要的。

解决问题之前，先分析分析为什么会出现这个问题。现在团队尽量在做敏捷开发，一周一个版本，快速改进，快速上线。但很明显很多产品经理并不能胜任项目经理的角色，不能很好的带领团队、安排工作。结果是产品经理跟着用户转、跟着领导转、跟着开发工程师转、跟着测试工程师转，就是不跟着自己转。产品经理忙！每天要开会过需求安排实施配合测试，抽不出时间来更新文档，相对于其他的事情来说，更新帮助文档这件事情就变的不紧急也不重要了，因此排不上优先级也属正常。及时有专职的项目经理这个角色，也并不一定能够缓解这个问题，产品经理一样会更多的事情缠身。要知道这些倒霉鬼还有更多的事情没有做呢！比如很多产品经理没有时间做数据分析，没有时间做用户调研，没有时间和运营、市场、销售的同学沟通交流。另外，就是产品经理可能自己不重视，或者没有意识。

可能最合理的解决方案是，在整个上线流程中加入客服的参与，比如产品开发前的评审就有客服参加，测试也有客服参与，客服帮助完善帮助文档，甚至可以做的图文并茂。但是很明显，不太适合以周为单位，以小团队为单位，以快速相应为目标的开发方式。虽然整个团队并没有做到多么的优化多么的敏捷，但每周的版本已经再给所有的人压力，如果过程中有人请假都会收到影响，可以说项目进度是很脆弱的。加入客服流程，有可能会对流程造成影响，而且让倒霉的产品经理去推动更多一种角色，更加艰巨。如果加入客服流程，最好的方式是有富有经验的客服经理全程、主动的参与项目开发中，并协调客服资源进行必要的相应。我认为只能靠人，不能靠流程和制度来改进。

还有什么办法？比如能不能容忍不更新帮助文档？我想如果数据分析做的足够好的话，也许能够这么做。但数据分析做的好可能比及时更新一份帮助文档更难，能够从数据上找到问题可不是件容易的事情，也不是初创公司擅长的事情，很多团队甚至没有数据分析角色的参与。我想不更新帮助文档是不能容忍的，产品永远不是完美的，不同的用户的体验永远是不同的，我们面对的是那么复杂的用户群体。而我们提供的是产品、是服务，这就更决定了我们一定要有客户服务。

还有什么方法？逼迫倒霉的产品经理在百忙之中抽时间来修正老的内容、撰写新的内容、去推动更新、去推动整个客服团队跟进每周的项目进化。实话说，很多产品经理真的很难有精力去做这件事，或者不重视这件事，或者没考虑到这件事。这件事的优先级也不高，相比之下每天都有那么多的会要开，有那么多的文档要写，有那么多人那么多事情要去沟通，有那么多的bug要去确认和验收。但是，无论如何倒霉的产品经理都要抽时间花精力做这件事，为什么？只有产品经理最熟悉产品，只有产品经理最了解产品做了什么创新，做了什么修改，对用户有什么挑战，用户可能会有什么疑问，用户需要什么样的解答……。所有这一切只有产品经理是最清楚的，你说，产品经理不写谁写？而且产品经理写文档那是小儿科，那是必杀技，把事情写的深入浅出那是必须的。

还有什么方法？让用户帮助用户？比如开放用户反馈区，比如建设用户论坛、用户QQ群。总的来说不太可行，第一，用户提问的时候最需要的是得到一个官方的，正确的答案。第二，用户需要及时的得到答复。第三，没事儿老帮助别人的雷锋并不多，他们帮助其他人需要物质或者精神上的收获。第四，我们应该鼓励用户在我们的产品里面热火朝天，而不是在我们的客服环节热火朝天。虽然这么说，但其实还是有很多产品都设置了诸如官方讨论区这样的论坛板块或者QQ群，允许用户之间互相交流和讨论。实话说，这样的服务方式适合企业用户，不适合个人用户。比如用友的一套财务软件，主要卖给那些企业客户使用，让那些公司的IT人员、财务人员一起沟通可能是个好事儿。但是如果提供的是针对个人的服务，比如招商银行的网上银行，让那些个人用户聚在一起讨论，有什么好处吗？

怎么办？怎么办？怎么办？我所能想到的最浪漫的事就还是靠人，不能靠制度和流程。负责任的产品经理和积极的客服经理通力合作，主动推送＋被动追踪，一起达成目标。客服经理充当半个产品助理，主动寻找产品经理沟通产品的更新点，自己整理文字，更新文档，培训一线客服人员。产品经理充当半个客服助理，主动和客服经理沟通产品变更，可能是电话，可能是邮件，可能是面对面的聊聊，可能一顿午饭就完成了沟通。双方一帮一，一对红，比学赶帮超，争取把客服工作做好。产品计划、项目计划有变更随时周知客服经理，产品提交测试后可以第一时间邀请客服经理参与测试，最起码可以看一看变化，具体的上线修改内容，具体的上线时间点，可能的投诉点，提前周知。还是挺理想的一个方式，事实上客服的压力是很大的，尤其是产品不稳定的时候，当客服的同学心情不好的时候，当用户反应的问题不能及时解决，甚至不能解释给反馈的时候，谁陪着你沟通？

所以说，互相关心、互相支持，互相鼓励，才是正道儿。另外，得赶紧催着工程师给写个帮助更新的工具，要不更新起来也确实麻烦。