iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 25
2
Modern Web

菜鳥工程師必修的 30 堂溝通課系列 第 25

【前期準備篇】我們用溝通協作,打造出 400,000+ 瀏覽數平台

在繼續談 The F2E 之前,我想要分享一下自己做專案的歷程。在以前我在前公司上班時,絕大部分的流程就是會先出系統分析書(SA)、系統設計書(SD)。都做好後,就會開始請工程師、設計需依序加入開發。

這種又會稱作瀑布式開發,也就是前面流程做好,後面就依序步驟繼續做下去。

但在以前跑專案時,都常會有以下問題:

  • 需求時常變更,搞得大家人仰馬翻。
  • 最後準備要結案時,規劃的項目不符合業主需求,Loading 全都壓在最後面的時間,加班變成常態

你要說當初 SA、SD 人員沒規劃好嗎?但在系統開發上,自然會遇到一些開發時才出現的預期外的問題,所以可能在開發中期才提早發現。此時的文件又可能得再衡量是否要修改,或者是系統是否需要大幅度調整。

所以當我自己當 PM 後,也是看了很多專案管理論,最後我的結論是依照團隊與專案性質不同,來導入適合的方法。硬是代入管理方法,有時反而不進則退。這觀念就很像寫程式一樣,你用了很多設計模式,以為自己很高大上,但最後維護管理時,發現其實根本不需要用到這些東西,反而造成自己維護上的困難,是共同的道理。

這裡我就來分享一下,我自己在規劃專案時用到的兩個心法。

重要里程碑

所謂的重要里程碑,就是一個專案執行過程中,有哪些是重要的完成項目,若完成就表示你有完成一個小里程碑,最終大里程碑可能就是結案收款。

這樣團隊成員在推動專案時,也可以依照這些小里程碑的執行項目,知道自己得先朝向目標前進。

所以在這個專案上,我就設置了兩個里程碑,也就是以下兩個

  • 第一階段 (6/10發佈活動)
    • 挑戰者可以註冊平台,並報名第二屆活動
    • 第一屆舊資料倒入平台,並可以觀察歷史資料
  • 第二階段 user story(7/8正式開賽 - 以投稿流程與分享進行優化)

user story (使用者故事)

使用者故事是我很愛用來討論「需求訪談」的方法,

他可以分析出此服務有哪些「角色」,他們可以在這個服務上做哪些事情。

我們用人力銀行來說好了,分成廠商求職者的角色,我們就來看看這兩個角色可以在平台上做哪些事。

廠商

  • 可以在平台上刊登職缺
  • 可以管理有應徵的人才們,並透過平台邀請他們來面試
  • 可以觀看履歷系統,主動尋找人才

求職者

  • 可以在平台上撰寫履歷
  • 可以在平台上尋找職缺
  • 可以投遞履歷給廠商

而針對以上的角色能做到的是,你就可以思考要開發哪些功能,以符合角色能夠在平台上能順利操作功能。

像是這次的 The F2E 依照里程碑的規劃 user story 則是:

  • 第一階段 user story (6/10發佈活動)
    • 挑戰者可以註冊平台,並報名第二屆活動,並可以選擇要參加的類別(前端、UI 組)
  • 第二階段 user story
    • 我已報名,針對關卡進行投稿 (7/8正式開賽 - 以投稿流程與分享進行優化)
      • UI 設計師
        • 關卡
        • 線上標示文件網址
        • og:image(1200*628)
      • 前端工程師
        • 關卡
        • codepen網址
    • 我可以對 UI 設計師的作品
      • 按愛心
      • 採用
    • 我可以對前端工程師的作品
      • 按愛心

小結

有很多人看到這裡,或許會疑惑說,「為什麼不一次到位就好?」,通常來說一次到位會有個風險存在於說,你開了越多功能給使用者時,往往也會有很多潛在 BUG 問題會被挖出來。

與其如此,不如先上一個版本讓挑戰者先 run ,確保系統穩定度與動線都沒問題後,之後依序上新服務來說,也不會有太多問題。

所以和共同創辦人討論過後,就決定先讓大家報名順便熟悉系統,之後大家投稿自己的作品也不會有操作上的問題。

這其實也有個開發弊病在於說,老闆都會希望所有功能一次到位,但真正上線才發現問題一堆,花了很多大錢最後都打水漂。與其如此,不如思考先做個最小可行性 MVP,確保有其市場再繼續迭代開發,風險控管也較好。

下個章節我們就將開始進入到「產品漸進開發」的章節勒 :D


上一篇
【尋找 TA 篇】我們用溝通協作,打造出 400,000+ 瀏覽數平台
下一篇
【設計 wireframe 篇】我們用溝通協作,打造出 400,000+ 瀏覽數平台
系列文
菜鳥工程師必修的 30 堂溝通課30

尚未有邦友留言

立即登入留言