咬文嚼字的必要性（一）：用句型輔助思考

前同事 Peter Su 提出他在荷蘭工作的觀察：

貼文短短，卻已提到幾則重點：

• 準則
• 思考框架
• 句型
• 參考範例

儘管自己還沒有在國外工作過，但成天浸潤在外文書籍，也感同身受。

關於「思考框架」這一點，我在〈思考框架的刻意練習〉一文提過自己的看法。現在這篇文章，我想繼續談談「句型」這一點。

用句型輔助思考

歐美系的思考框架或準則，很喜歡用「句型」式的步驟來引導思考。

譬如說，在軟體研發領域常用的 user story，本身就有一個經典句型：

As a <type of user>, I want <some goal> so that <some reason>.

另一個似乎開始引人注目的 JTBD (jobs to be done) 也有一個經典的 job story 句型：

When <situation>, I want <motivation> so I can <expected outcome>.

在 Impact Mapping 書中，Gojko Adzic 建議使用以下句型來開展 actor 及 behavior impact 的關係：

<The actor> can help us to achieve <some goal> by <behave> faster/better.

<The actor> can obstruct us from achieving <some goal> by <behave> slower/worse.

在 Specification by Example 書中，Gojko Adzic 建議使用以下 Gherkin 句型來制定實例化需求：

Given <a precondition> when <an action happens> then <the following post-conditions should be satisfied>.

在限制理論的衝突圖（疑雲圖）中，針對 B→A、C→A、D→B、D′→C 四個邏輯關聯及假設，Jelena Fedurko 提出一些邏輯檢驗句型，甚至還主張要「大聲唸出來」呢：

In order to <left clause> we must <right clause> because <assumption>.

前面示範的都是短句，但句型也可能很長。像大師 Geoffrey Moore 就提過很長的 value proposition 句型：

For <bulls-eye customer> who <key purchase motivation insight> our product is a <in customer language> that <key benefit>. Unlike <key competitors> ours <key differentiators> at a price <than competitors>.

   

句型，讓初學者容易依循上手，但蜜月期總有結束之日。若只追求表面句型的合式，而不進一步認真雕琢句子內容，輕則無法發揮此思考框架的威力，重則誤用。

因此，有志之士，對於這些句型背後的填空之處，尤其是命名，會吹毛求疵到咬文嚼字的地步。

不明就裡的人會納悶：「真的有必要這樣嗎？」

來看幾個例子吧。

團隊共創法

團隊共創法 (consensus workshop method) 當中，第四步驟是命名。

命名，也是有箇中眉角的。

Yves 在〈找出組織無法變敏捷的阻礙 – 團隊共創法實做〉一文提到「移除『缺乏』，讓命名更貼近核心」的訣竅：

在 ICA 的課程中學到，如果阻礙是含有『缺乏』的字眼，如不夠、太少等，代表這只是表象或症狀，需要花些時間去挖掘更深層的造成原因。所以我嘗試以我的觀點再往深入去發掘，讓字面上沒有『缺乏』的字眼。

你覺得，這是吹毛求疵咬文嚼字嗎？

專案管理

在專案管理領域，WBS 及 activity（或稱 task）兩者，很常被人混為一談。

以 PMI 的 PMBOK 體系而言，WBS 是屬於 scope management 知識領域，activity 則是屬於 schedule management 知識領域。一靜，一動。

本質不同，表述形式自然不應相同。

關於 WBS，在 PMBOK Guide 4th 如是說：

Work Breakdown Structure (WBS) [Output/Input]. A deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project.

雖然到了 PMBOK Guide 5th 及 6th，此定義都略作調整，刪掉 “deliverable-oriented” 字眼：

Work Breakdown Structure (WBS). A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.

但大體上，WBS 的表述形式，仍是以「名詞」或「名詞片語」為主。

至於 activity，在 PMBOK Guide 6th 如是說：

Define Activities is the process of identifying and documenting the specific actions to be performed to produce the project deliverables. […] Activities represent the effort needed to complete a work package. The Define Activities process defines the final outputs as activities rather than deliverables, as done in the Create WBS process.

很明顯的，activity 的表述形式，是以「動詞字句」為主。

實例化需求

實例化需求 (specification by example; SBE) 也是個易學難精的技藝。所幸新書 Writing Great Specifications: Using Specification by Example and Gherkin 適時出現，站在巨人的肩膀上，擔起 “Gherkin Manual of Style” 的責任。

先摘錄整體風格的建議：

• Don’t write scenarios about the UI. Write about business outcomes. Nobody cares about the UI; they care if they can get their job done.
• Keep your scenarios at an abstraction level that allows you to aim for as few Givens, Whens, and Thens as possible without sacrificing readability.

再摘錄針對「Given/When/Then」的個別建議。某些建議，甚至咬文嚼字到「語態」及「時態」等文法層次：

• Don’t phrase Givens as actions. Use passive voice in past tense, or phrase each Given as a list of things that need to happen before the actors can move the action forward.
• Aim for one When keyword per scenario.
• User tasks take place in the present and should be phrased in active voice to differentiate them from contexts and outcomes.
• User tasks should allow actors to proceed to Thens. If a When needs additional clarification, it’s merely a user action.
• To facilitate outside-in development, use the following template to phrase most of your Thens: should be able to .

這些風格建議，對於實際帶過 SBE workshop 的人，可說心有戚戚焉。

限制理論

限制理論對於清晰思考的要求非常高，thinking processes (TP) 更是如此。

就拿只有五個框框、五個箭頭的 evaporating cloud（衝突圖、疑雲圖）來說吧。如果單論表面形式，可能已經是最簡單最簡潔的了——但也沒那麼單純。

Jelena Fedurko 在《撥雲見日》一書如是說：

絕大多數的疑雲圖之所以無效，原因是寫圖的人不理解正確、精確地遣詞用字的重要性。

摘錄幾則「正確精準的遣詞用字」建議：

• 每個框內的陳述，應該是一個簡單的句子，沒有任何因果字眼，如「因為、因此、由於、為了」等。
• 目標 A、需求 B、需求 C 是正面陳述。不要使用「不、非、否」之類的文字。
• 每個框內的陳述，都應該包含一個動詞。
• B 和 C 的內容，是需求而不是行動（描述因為重複發生的動作，如：確保、維持、提供、支持、預防或避免等，而形成的持續狀態）。

書中還有更多嚴謹的建構及檢驗步驟，值得認真練習。

系統思考

系統思考／系統動力學領域常用工具有二：CLD (causal loop diagram) 及 SFD (stock and flow diagram)。其中，SFD 涉及兩種量化元素的類型：存量 (stock) 及流量 (flow)，門檻較高 ¹ ，因此多數人會改由較簡單的 CLD 入門。但這也意味著，這些人不一定具備該有的「變量」敏銳度。

對「變量」不敏銳，會反映在錯誤命名上。難怪 Seeing the Forest for the Trees 一書特別提醒，在 CLD 中請堅持以「名詞」形式來表述：

RULE 5: USE NOUNS, NOT VERBS

If you look at all the causal loop diagrams in this book, you will find that every item is a noun or a noun phrase, rather than a verb or a verb phrase.

There is often a tendency to express the appropriate action as a verb (hire or fire) rather than as a noun equivalent (hiring or firing). If you can keep to nouns, even here, so emphasizing the action itself, you will find that your causal loop diagrams are clearer.

書中也提醒，不要將「增加」或「減少」之類的字眼偷渡進來，那等於是越俎代庖：

RULE 6: DON’T USE TERMS SUCH AS “INCREASE IN” OR “DECREASE IN”

When drawing causal loop diagrams you will inevitably be tempted to include these two phrases in your descriptions.

However strong the temptation, resist it. That’s what the arrows are for, especially the Ss and the Os.

此書的「CLD 十二條黃金法則」，值得仔細體會：

結語

予豈咬文嚼字哉？予不得已也。

為了充分發揮思考框架的威力，請暫時不要當差不多先生吧。

畢竟，嘗試深度掌握某些知識體系，先蹲後跳，後發先至，是划算的投資。