故事的例子

先说明：今天加班到现在，所以先写一点点，後续再补上。

前天的文章有一位读者提问：

如果将团队在组织中的故事整理出来，却发现实在没有什麽特别的该怎麽办？

其实很多时候我们会对自己有过高的期待。故事其实一个载体，用力提醒我们要分享更完整的背景脉络 (context)、目标、愿景、与时程。如果你的公司、团队或是专案有个非常精彩动人的背景故事，那当然是最好。但不用特别担心自己的故事「没什麽特别」。

今天我希望透过几个例子，去更具体描述所谓的故事是什麽

案例一：任务交付

一个工程主管交付要开发新功能：

Version 1:

「我们需要开发 A & B 这三个功能，这次时间会比较赶，大概在两个月後需要完成测试，并上线。」

Version 2:

「我们从上次的使用者访谈中发现，有 40% 的使用者在使用时都有 OOO 的同样问题。在使用者测试中我们验证过 A & B 两个功能，确实提升了 70% 的使用互动率。所以我们希望在两个月後的 11.11 节前，能完成这两个功能，让他们有最大的 impact。」

说明：从 Verson 2 中，我们能充分了解开发功能 A & B 的背後的原因与脉络，例如：这个功能为谁而做的，为什麽要做、完成功能後公司期待的愿景/成果。同时也说明开发的时程，以及为何会有这个时程。

案例二：个人

一个工程主管说明如何跟他工作：

Version 1:

「这个决策我需要更长的时间去决定。」

Version 2:

「我认为技术的选择非常重要，因为每个选择後续会有很深远的影响。我喜欢透过小组讨论去帮助我思考，并试去透过不同的立场或观点去评估眼前的选择。优点是我认为这样产出的决策会会有比较全面的考量，但缺点是如果你没有提醒，你不会从我这里的到一个快速的决策——我需要时间去讨论它，甚至做一些研究。如果这次因为有某些时间压力你需要我快速做出决定，请提前让我知道。」

说明：我们从 Version 2 中更能理解这位主管的思考脉络。她不是只有告诉我们她的需求（需要更多时间去做决策），更厘清这个需求背後的原因，以及她重视的点是什麽。这样的沟通能让她的团队能更有效跟她讨论与协作。