在《為什麼我們總是說不清「需求是什麼」》中,我們介紹了「需求的本質」,并大緻介紹了三個描述需求的「結構化語言工具」。這篇文章,希望進一步跟大家分享其中兩個工具:
工具一:任務規格書 Job Spec
「任務規格書」是比較完整又複雜的語言工具,實務中較少用到。呼應前面「産生需求的過程」,《創新者的窘境》一書的作者Clay Christensen 将任務界定為「用戶在特定場景下想獲得的提升」,任務一定和特定的情境脈絡有關,他進一步說:
任務「使得」用戶在特定「場景」中,能獲得「提升」。
A job enables the progress that an individual seeks in a given situation.
如果要記錄一個任務,他提出了「任務規格書」這個語言結構,其實也是個「文件結構」:
如果我們做完需求探索、用戶研究,可以按照以上五個問題,做成一份 1–3 頁的 A4 文件。因為這個結構相對完整、複雜、不夠簡潔,所以更适合以下情境:
工具二:任務故事 Job Story
「任務故事」是目前最被廣泛使用的工具,但也遭受很多用途理論研究者的批評,因為它過度簡化,容易被誤用。同時,提出者 Alan Klement 是個充滿争議的人物,因此得罪了很多用途理論的開創者。不過,Job Story 仍然是個實用的語言工具。
下面這張圖,簡潔地說明了 Job Story 任務故事的結構:
任務故事的格式,用任務故事代替用戶故事。
這個方法進一步被 Intercom 發揚,他們進一步解釋 Job Story 任務故事:
(1) When (Situation):引發需求的場景
(2) I Want to (Motivation):用戶在場景中的選擇動機
(3) So I can (Expected Outcome):在場景中的期待提升
然後,他們會用 1–2 頁 A4,提交一個名為 “Intermission” 的文件,當作一份産品/功能提案。在這份文件中,其中一段就是 Job Story,要能在幾百字内講完用戶需求。推測 Intercom 之後就用這幾百字的 Job Story 代表此産品/功能,在内部快速解釋用戶需求、溝通開發目的。
然而,實際上找出 Intercom 的 Job Story 案例,會發現幾個問題:
如果有以上問題,那 Job Story 就喪失了意義。若能避開上述問題,任務故事就适合用在以下場景:
這篇文章,介紹了二個「結構化語言工具」:
但這兩個工具都有明顯的缺點,如何彌補這兩個工具的缺點呢?有沒有更簡潔明了的語言工具?
下一篇文章,小編将繼續跟大家介紹最後一個語言工具「期望成果 Desired Outcome」,并且還會跟大家說明該如何串連這三個工具,以及如何和原有的工具一起相輔相成。
本文作者: Jason HOU
文章來源: Medium
了解更多敏捷開發、項目管理、行業動态等消息,關注我們LigaAI 或點擊LigaAI- 智能研發協作平台|智能項目協作,在線申請體驗我們的産品。
,更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!