 |
| 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
沒有留言:
張貼留言