想跟大家唠唠“雅各布森”这个名字。这名字我估摸着不少人听着耳熟，可能在书里见过，也可能在某些谈话里蹦出来过。对我来说，这可不是个陌生的词儿，因为它实实在在地影响过我一段时间的工作方法。
那得从几年前说起了。那时候我在一个小团队，负责一个新产品的用户需求沟通和文档整理。我们就是老一套，开会、访谈、写文档，但总觉得效率不高，需求传达老是出偏差，开发那边拿到东西，做出来的跟我们想的有时候能差个十万八千里。
痛定思痛，我就开始琢磨了。 遇到问题就喜欢瞎琢磨，上网看看，翻翻书。偶然间，就接触到了“雅各布森”的一些理论，具体是哪个雅各布森，当时我也没太深究，反正看到他提到一些关于沟通、语言、符号啥的，我就觉得，这里面好像有点门道，能用到我们工作里。
我的实践过程大概是这样的：
- 第一步，硬啃理论（虽然没啃明白多少）。 我找了些相关的资料，什么《语言学和诗学》之类的，老实说，看得我头大。那些术语太绕了，什么能指所指，组合聚合，简直跟天书一样。当时我就想，这玩意儿能落地吗？
- 第二步，尝试简化和转化。 我发现直接套用那些高深理论肯定不行，团队里其他人也接受不了。我就想，能不能把核心思想提炼出来，用大白话讲，再结合我们具体的工作场景。比如，雅各布森不是强调语言的几个功能嘛我就琢磨，我们写需求文档，是不是也得考虑这些？比如信息功能（把需求说明白）、情感功能（让用户觉得这产品懂他）、指令功能（告诉开发怎么做）等等。
- 第三步，小范围试验。 我没敢大张旗鼓地搞，就先从自己负责的那一小块开始。我开始尝试用一种更结构化的方式来描述用户故事和需求点。比如，我会特别强调“谁（用户角色）”在“什么情境下（场景）”想要“做什么（目标）”以及“为什么（价值）”。这听起来简单？但以前我们写文档，经常就忽略了“为什么”，或者“情境”描述不清。
- 第四步，引入视觉化和模型。 我还从雅各布森那里受到启发，觉得单纯的文字有时候还是不够。我就开始尝试用一些简单的流程图、原型草图，甚至是一些状态转换图来辅助表达。想着这些图表就像一种“符号”，能更直观地传递信息，减少误解。我还记得当时画了个简单的用户旅程地图，把用户从接触产品到完成核心目标的每一步都标出来，附上对应的需求点和情感曲线。
- 第五步，收集反馈，迭代调整。 我把这些新的文档格式和沟通方式用起来之后，就主动去找开发和测试的同事聊天，问他们感觉怎么样，是不是比以前清楚多了，还有哪些地方不明白。根据他们的反馈，我又不断调整我的方法。比如，一开始我搞得太细，开发觉得啰嗦，后来我就学着把握颗粒度。
实现的效果嘛还真挺明显的。
虽然我没敢说完全吃透了“雅各布森”的理论，甚至可能理解得有些偏差，但通过这么一番折腾，我们团队的需求沟通效率确实提高了不少。需求文档的歧义减少了，开发返工的次数也下来了。最重要的是，团队成员之间对于“如何清晰表达需求”这件事，有了一个更统一的认识。
所以你看，有时候一些看似高大上的理论，不一定非要原封不动地照搬。咱们做实践的，关键是能不能从中受到启发，找到一两个点，哪怕是最浅显的一两个点，结合自己的实际情况，把它用起来，解决实际问题。对我来说，那段琢磨“雅各布森”并尝试应用的经历，就是这么个过程。它让我明白，很多时候，答案可能就藏在那些你初看时觉得“这有啥用”的地方，关键看你愿不愿意去钻研，去转化，去尝试。
这就是我关于“雅各布森”的一点实践记录，不一定对，就是跟大家分享一下我的经历和感受。希望能给大家一点小小的启发！
还没有评论，来说两句吧...