iT邦幫忙

第 12 屆 iT 邦幫忙鐵人賽

DAY 2
8
自我挑戰組

從 RD 到 PM 的奇妙旅程 - 陪伴我成長的心法與工具整理集系列 第 2

[Day02] 淺說需求 - 上集

需求從哪裡來?

說到需求,這半年來我觀察到了很有意思的現象。需求分成兩種:

  1. 使用者大約知道自己想要什麼功能,即使描述得很零散,但大致上能簡約寫出一個列點式的需求。
  2. 需要我們去挖掘出他心裡面真正在想什麼,大部分談的是感覺,談的是願景,如何彌平願景與現實中的巨大鴻溝,對我而言充滿挑戰性。

先來說說前者,通常我會列出幾個大項:

  1. 需求描述
  2. 解決方案
  3. 技術評估
  4. 最終結論

需求描述

這部分如果能盡量了解使用者的背景知識,會對於列出解決方案十分有幫助。因為部分使用者會直接提出他認爲最佳的解決方案,但或許是天生好奇心旺盛,當我把我自己帶入使用者的實際生活場景時,如果我自己並不認為對「身為那個使用者的我」的工作流程有改善,我就會去深入了解為什麼使用者會認為這是最佳解。

情境說明:改善某個在流程上保有彈性,又可以隨意選擇流程的 App,因為最初並沒有設定「必須完成」的步驟有哪些,以至於流程管理較為混亂。

第一線使用者的主管:我希望可以在每個步驟都放上簽名流程!

我:為什麼會希望都放上簽名流程呢?這樣對於第一線工程人員並不友善呀。他如果原本只要請客戶簽一次名,變成一張訂單要簽很多次,他會覺得很惱人吧。

第一線使用者的主管:我想確保他每一步都有做到啊!有些人我也不知道他們是不是在摸魚,該做的推銷也不知道有沒有給客戶看,反正這幾個月的狀況都不太好。

我:那你跟我說這幾張類型單子一定要做的事情有哪些,有哪些是選填的,我來幫你想想怎麼改善。

從上述的故事中,我們可以知道,其實主管他並不是一定要工程人員簽名,而是希望知道他設定的日常交辦流程,有沒有正確地被工程人員執行,並讓他們的客戶知道。挖掘到更深入的意見,這時候,就可以來列解決方案了!

解決方案

這時候考慮的面向會是業務上的操作會怎麼執行,由於剛剛在需求描述有做點功課,在列解決方案時,除了可以考慮得更全面外,也可以讓方法更多元,但有時候牽涉的單位非常多,如果這時候有張清單能協助我們檢視利害關係人的話,會減少許多繞彎路的過程。

心中稍微順過了需求,就拉著我們家 UI/UX 來討論怎麼呈現才能讓使用者體驗上更順暢,列出了幾種解決方案後,帶著我們家設計畫給我的 wireframe,再去找客戶開會。

我:這邊我們有兩種建議

  1. 我們把這些一定要完成的流程做個設定,如果沒有完成,就沒有辦法進行下一步,畫面上同時也會在側選欄上顯示哪些是已完成,哪些是尚待完成。如果有完成,按鈕會變成可執行的顏色。除此之外,資料庫內也會紀錄工程人員實際完成的項目與時間
  2. 先顯示所有必要流程,並且不能隨意跳過這些流程,後面再放上附加的流程,這樣可以嗎?(簡報配圖說明)

第一線使用者的主管:我這邊沒什麼問題。兩種我回去想一下再回覆你。

事情到這裡我以為結束了,結果幾週後接到需要修改的電話,對方的稽核對於這個流程有疑義,於是我們又再次召開了會議,製作了流程影片,模擬了第一線工程人員與客戶互動的過程,才勉勉強強過關。

打到這裡發現有點過長,明天再繼續說明技術評估最終結論的部分~感謝看到這裡的你們!


上一篇
[Day01] 那些讓我打開電腦紀錄的 PM 生活
下一篇
[Day03] 淺說需求 - 下集
系列文
從 RD 到 PM 的奇妙旅程 - 陪伴我成長的心法與工具整理集30

尚未有邦友留言

立即登入留言