DMA01
釐清專案/產品利害關係人

釐清專案/產品利害關係人

Understanding stakeholders of a project/ product

寓意科技

本文將說明公部門常見的系統開發思維與在執行專案前,需要先釐清目的、使用者與利害關係人

公部門並沒有PM這個職稱,但每個單位或多或少都會碰到「資訊採購」的需求,不管是架個網站、建個App,大至系統整合等軟體服務。只要你是承辦人,對內要收集與釐清需求,生出「需求說明書」,跑完招標、採購、開發、驗收流程,且過程中需要跟外包廠商溝通、聯繫,如果這一連串都擊不倒你,你還是想要做出能為人所用的產品,可以參考本篇,希望能對你有些幫助。

 

如果聽到老闆交辦:「想要架個網站來放自家單位藏品」,或許有些承辦人第一個浮現的念頭是要怎麼開規格?預算夠嗎?交期是什麼?但如果你期待這個網站可以長期營運,在忙著找人開規格、進入招標程序前,應該先考慮的是為什麼會有這個需求?要做給誰用?希望藉由釐清公部門使用者、利害關係人,說明公部門常見的開發思維,幫助產出真正有人使用的產品。

優先釐清專案發起人的目的為何?

開頭提到老闆某天交辦:「想要架個網站來放自家單位藏品」,你有想過老闆這個念頭是從哪冒出來的?持續探索老闆心中想要解決什麼問題,搞不好經過釐清後,就有其他更快速可以解決問題的方案了。

 

老闆可能在煩惱成果展要展示些什麼內容;或是去別的單位參訪後,想要交換資源,拉起合作案。以「想在成果展展示」為例,重點並不是該怎麼籌備成果展,而是老闆與單位想透過成果展得到什麼:是想要爭取更多經費嗎?還是想要拓展單位知名度?一層一層向下挖掘,經過釐清之後,如果仍決定需要建置網站,也可以幫助產品在開發的過程中不會走歪,能夠在完成之後,達到建置目的,真正解決問題。

你的使用者是誰?

確定需要架設網站後,下一步就得釐清使用者了。一般商業開發上,產品是為了解決用戶的需求,進而獲取收益。而公部門除了服務民眾滿足需求外;另一種常見目的則為資訊佈達,以求更順暢的推動政策,或期盼與民眾溝通。如果不理解使用者,在前者就會出現每用必罵的產品;後者則為建置後卻沒多少人知曉或使用。

 

你了解使用者使用的動機嗎?他是在什麼情境下使用?使用這個產品,可以幫助他滿足需求,完成什麼任務嗎?如果他不使用我們的產品,那有什麼替代方案?舉例來說,我們假設想要查詢單位藏品的是高中歷史老師,作為他上課補充教材。但他有機會知道我們的產品嗎?如果有,我們在呈現上要怎麼符合他的需求?另外,或是市面上是否有類似產品:像是維基百科、其他博物館網站等,是否已經能滿足他的需求了呢?

 

如果我們沒辦法找到真正的使用者(而非老闆、親友或同事)來釐清上述 4 個問題,或你在評估時,發現現況已有很好滿足使用者的方案,如果仍執意要開發,很可能就會推出不太有人用系統--但其實公部門有時會出現使用者是內外部少數特定人員的狀況,請各位釐清專案目的,按照自己的情境自行評估斟酌。

公部門中的利害關係人

除了一同執行專案的團隊成員,以及專案發起人之外,只要會被這個專案影響,或是能夠影響這個專案是否能順利推動者,均為專案的利害關係人。想要避免專案失敗,就必須管理利害關係人的需求。以架設網站為例,利害關係人包含採購、會計、之後負責營運的同事或團隊、跨單位的協作對象、顧問等。組織與長官間的人際關係,也會左右專案推展的狀態,請一併先納入評估。

寓意科技
寓意科技

寓意科技提供專業的及系統資訊科技管理顧問服務,協助企業規劃並完成軟體建置

fable寓意科技官方網站:https://www.fable.com.tw/

fable寓意科技 Medium:https://medium.com/@fableltd

產品管理的三個誤區與三個迷思 — PM下午茶#33
這三個誤區與三個迷思,都可以總結為產品經理一種「不自信」的展現,不知道自己產品的核心價值、不明白自己的用戶需要什麼,所以會抄競爭者、產品還沒完美不敢推出、想專注一個很大的市場,撿市占的碎屑就好。
追太緊很壓迫,追太鬆會掉球,PM該如何追蹤進度?
PM的工作就是,把遊戲規則訂清楚,幫團隊剷除阻礙(包含心理阻礙),然後觀察運作流程,發掘可能的問題,進一步優化流程,讓團隊協作得更順暢。
團隊的 GIT 分支管理策略 (4) : 發佈的分支模式
一個技術落差大的團隊還是需要從功能分支開始,搭配發佈分支,然後逐步縮減發佈間距提高頻率,經過這樣的過程讓團隊累積技術力,最終也許可以達到持續交付。