2017年7月11日 星期二

經驗分享:從 OCF 官網改版看 PM 的工作流程(一)

之前 OCF 官網改版 完,想說既然 所有文件都放上網站 了,以後有人想做類似的案子又不知道從哪下手的話,可以直接丟連結。結果,上個月好友接到任務要改版公司官網,討論幾句後,才發現我想跟她說的事情,竟然都不在文件裡 o_O

OCF 官網的維護用交接文件

仔細想想,網站開發專案的生命週期中,有分析、規劃、實做、維護四個階段,而 OCF 官網的文件,是為了維護階段而設計的,主要用途是讓接手的人知道怎麼在現有的架構下做調整。但今天好友要做的事情,是從零開始推展專案,因此她要參考的就不是維護階段用的文件,而是前面的分析、規劃階段的文件。

為了避免重複作答,本文整理我們的會議內容,用 OCF 官網當例子說明身為網站改版專案的 PM 要做什麼、怎麼開始。這裡的 PM 指的是 product manager + project manager 總之就是萬屎歸宗的坑主,因為主要是講分析跟規劃階段的事情,所以底下提到的 PM 工作內容,會偏向 product manager 比較多。

Step 1 背景分析


釐清專案誕生的動力來源


之所以要做網站改版,最常見的導火線是被使用者抱怨網站難用、看不懂、沒重點、內容沒更新、手機上無法閱讀之類的,但也可能是其他跟使用者無關的因素,比方說,老闆覺得舊網站看膩了想要換張美美的皮,或者組織遇到其他問題,像是業績不佳,想要藉由網站改善 w (後面這兩種最好敬而遠之,你懂的)

總之,對 PM 來說,面對不同導火線來的網站改版,處理的手段也會不一樣。OCF 這邊的導火線是使用者的需求,好友的專案也是,所以下面說的就是以「由使用者需求所驅動的官網改版」為前提。

確認影響決策的危險因子


身為一個討厭做白工的懶人,做任何事前,先搞清楚誰有權力用一句話讓決策翻盤,是絕對必要的。基本上就是老闆 + 會影響老闆的人,會影響老闆的人可能是老闆的朋友啦,伴侶啦,或者高階主管啦。

這些人如果本身有網站開發相關的專業,那恭喜你,不僅憑空多出一批顧問,還會有人幫你坦掉奇怪的需求。相反地,如果決策者是資訊麻瓜,那就要相當注意他們的個人偏好。最理想的狀況,是只要能解決他遇到的實際問題其他都不會多管,在這種人底下,整個開發團隊的專業可以發揮到最大。其次則是有明確偏好的視覺風格,這也算容易解決。

會很賽的類型,一種是有很多要求但自己沒想清楚,改來改去沒有一貫的邏輯;另一種是對網站開發沒專業但有興趣,會積極參與且喜歡出意見。如果出現這兩種決策者,又沒有其他權力能制衡的話,那我通常會開始思考要怎麼落跑,無法落跑的話,至少在心裡先把專案的及格標準降個 50% 再說。

在這方面 OCF 官網改版算是罕見的爽案,畢竟是一群資訊宅搞出來的基金會,老闆們還可以當技術指導。好友的案子也蠻幸運,老闆是資訊麻瓜,但只要求解決痛點,不干涉過程。

盤點手上的人力資源


俗話說,網站組成的鐵三角有內容、設計、程式。

一、內容需要的人力資源

公司官網的內容,通常和業務、行銷單位瓜葛很深,生內容的過程需要花許多時間跟他們協作,要是人家不理你,就 GG 惹。所以如果平常有跟這些單位的人混熟,那是最方便,不然就要請老闆去喬人出來。我自己是因為長期當 OCF 志工,之前的案子就跟 Singing 培養出革命情感,所以她會罩我 XD 至於好友的案子,由於他們公司很大,不同部門彼此往往不認識,且組織內的分工比較沒彈性,所以就要請老闆去跟別的單位喬。

二、設計與程式需要的人力資源

傳統的網站開發,往往會等到規劃完成、要實做了,才找設計跟程式的人進來。這樣的時程切割,有可能讓人生出難以實做的企畫而不自知,結果變成要在執行階段回過頭來改企畫,浪費時程之外,還可能因為已經跟其他單位橋好了導致改不動,最後只好硬著頭皮照著怪怪藍圖實做下去。

我個人偏好的解法是讓 PM 本身略懂設計跟程式,這樣規劃時就可以納入實做上的考量,不然,至少知道討論到什麼的時候要去 cue 實做的人。但現實世界裡,PM 很可能不是來自網站開發團隊,而是因為對業務瞭解或者受到老闆信賴而被派來主導專案,網站開發不是 PM 的專長,自然不可能瞭解實做技術;這時候,最好可以拉著設計師、工程師,讓他們先以顧問的身份參加前期討論——這種情況下,專案啟動前就得先跟老闆要到人才行。

OCF 官網是由網站開發團隊主導,且剛開始規劃沒多久,設計跟程式就接二連三地自動湧入,在實做的領域擁有相當奢侈的顧問資源;好友的案子則否,得靠額外的政治力量去喬人。

勘查專案的限制與決策者的底線


時程不限、經費寬鬆、目標簡潔明確,到這種境界,大概就稱得上含著金湯匙出生的專案了吧!

一、時程限制

但現實總是殘酷的,如果官網改版是為了配合其他重大事件,那就會有不可妥協的時程限制,這種時候,要盡可能地收斂範疇、預留緩衝,因為做到後面,坑一定會變大,進度也一定會 delay,只是幅度大小的問題而已,天縱英才如我也難逃此劫,施主們萬萬不要鐵齒(被揍)還有,如果實做部分打算外包的話,那光是外包廠商的訪價、議約,往往就要花上一兩個月,且品質優良的外包廠商,通常手上專案是滿的,要發包給對方還得排隊……

總之,這方面 OCF 官網跟好友的案子都很好命,屬於有機成長型的改版,沒有非遷就不可的時程限制,可以按照理想的步調好好做。

二、經費限制

經費方面,在規格不明的前期想要粗估的話,常見的作法是找個看起來類似的專案打聽,藉此推測外包價格。

這方法可能的問題,一來是因為許多程式實做是瀏覽器看得見、但使用者看不見的,對技術不瞭解的人無法分辨不同網站間的實做差異多大,很可能會找錯範例;二來是這算法漏掉規劃期間的內部溝通成本以及顧問費用,雖然 in house 人力的鐘點費跟顧問費比起外包相對便宜,但好的規劃所需的大量溝通協作,所花費的時間絕對不是內部人員「抽空順便」能應付的;三來在分析跟規劃的成果浮現後,網站規格往往跟初期的猜想很不一樣,有能力實做的外包廠商也會跟著不一樣,且通常費用會比預期的貴很多,然而當初粗估的數字已經烙印在老闆心目中,要說服他接受新的價格恐怕得費上好一番力氣。

這方面 OCF 官網沒遇到什麼困擾,因為專案主要是志工在做,我們這些志工可是免錢又好用呢(撥瀏海)但好友的案子就不能這樣亂搞了,可行的作法大概是兵分二路,規劃期可能的經費等初步的 WBS 拉出來以後再來數人月,實做期可能的外包經費則可以粗略參考這類點餐網站 http://howmuchtomakeanapp.com/ 雖然這是估 app 用的,但除了最終呈現是在手機上以外,背後程式功能實做的原理跟網站是一樣的,雖然不同廠商的報價,會因為產出品質與供需狀況而有很大的變化,但透過這個點餐網站,至少可以先瞭解不同的功能規格會對整體報價造成多大比例的影響,這樣被老闆問到費用的時候,既不用把數字說死挖坑給自己跳,又可以給出個初步說法,讓對方有心理準備。

三、決策者的底線

至於決策者的底線也就是對成品的最低要求,一方面跟專案誕生的導火線有關,從「讓我不要再被罵」到「贏過競爭對手」甚至「拿到補助款」之類的都有可能;比方說,OCF 官網的低標是讓他們不用重複對外解釋 OCF 到底是什麼碗糕,而好友案子的低標,則是要在官網改版的同時建立一套內部制度,終結長期以來的混亂流程。

另一方面,決策者的底線也會跟組織自己的特性有關,例如 OCF 官網當然就是要開源碼、開放協作,好友的案子則可能要考慮額外的公關問題。

制訂自己的目標


身為一個沒愛心沒恆心又懶又宅的利己主義者,做任何需要持續超過一個禮拜的事,都一定得先替自己設計好長期的誘因才行。

如果是工作的話,誘因可以是很單純的拿時間換錢,只要準時發薪,什麼都好,就算老闆要大便,也可以快樂地給他大便沒問題。但如果對工作有愛、對客戶有情義、或者對自己的專業有所堅持,此時就會進入一個叫做「誰在乎誰痛苦」的賽局裡,對工作的堅持,可能反而成為挫折和怨懟的根源,進而縮短工作的壽命。此時,真正利己的誘因,就是走下去的重要支柱。如果是沒錢拿的社群專案參與者,或是 NPO 志工呢?那利己的誘因就需要更強烈,否則過程中任何的摩擦或不順遂,都可能演變成剝削感滋生的苗床。

在 OCF 官網的案子裡,我的主要誘因是自己原本就想找個專案練手,驗證新學的 UX 跟 service design 知識,而我手邊可以取得的、真槍實彈的、有接地氣的專案,也只有 OCF 官網而已。雖然之前在 g0v 開了一堆專案,但它們大多是狗食,且是一人專案,拿來練 UX 效果有限。換句話說,在看似為了 OCF 無私奉獻的行為背後,我其實是為了達成自己的目標而別無選擇;其他兩個志工 poga 跟 yaya 自然也是各懷鬼胎(?)不在話下。這些各自的誘因,是我們在六個月的開發過程中,持之以恆、穩定輸出的基礎。

每個人在不同人生階段有不同的目標,可以拿來當作專案中的利己誘因,除了錢以外,可以是為了累積作品,為了練功,為了升遷,為了建立人脈,為了滿足好奇心……等。這些目標,除了成為前進的動力以外,也是個人決策的重要依據,畢竟時間有限,理想無窮,世界上沒有完美的專案,但一定會有人許下你手上資源不足以達成的願望,此時,這些個人目標,就可以當作妥協跟取捨的基準。



沒想到把會議記錄改寫成部落格文要花這麼大力氣,寫了好幾天到這邊也才講完頭兩頁而已 orz 只好斷然處置,把文章拆開,先發表寫好的部分然後趕快回去寫 code,不然作品一直沒進度,投履歷的日子遙遙無期啊(抱頭



本文授權:CC BY-NC 4.0 / ETBlue