[客座] 網路創業天敵,收不完的尾巴,誰的錯?

Posted by Aug9

手上結束這不算小的專案後,又看到這幾天Mr.6的做網站的人,「收尾巴」為何重要?一文、xdite回覆的作網站不只是外包廠商的事,以及獨孤木收尾巴?!這應該還沒開始吧!。所以讓我也來參一腳,來分享一些心得。

不論網站製作或外包都算是專案,都需要進行專案控管。而小型網站或許只需要一個工程師就能獨自coding完成,但規模大的網站建置專案甚至跨部門動用到數個團隊數十人外加數十個月的人力。而這之中許多看似簡單的小問題,往往就因為跨部門溝通聯繫不量而讓小問題變成大問題。一個只需要程式設計師花5分鐘就能解決的小蟲子(Bugs),有時卻造成整個專案時程延後一星期。建置網站對於有過幾年程式設計經驗的programer來說不是難事,只需一根菸的時間在腦中思考一下,馬上就可以開資料庫然後開始coding。但當系統龐大到需要跨部門協同作業時,沒經過有經驗的人來做系統分析與時程規劃的前置作業。通常就已經可預見這個專案最終命運,delay、delay、再delay。

台灣大多數的程式人員都是從學生開始練習寫程式,一個人寫程式時都有著自己的「風格」。從學生時代到進入公司上班這數年時間,早已養成每個人寫程式特有的習慣。所以我以前常跟同事開玩笑說:「如何短時間內認識工程師的個性?最快的方法不是跟他交談,而是看他的程式碼。因為許多高手接觸電腦的時間比跟人相處的時間來的多,久了自然忘記如何與人交談,反而擅長與電腦對談。」當一人獨自開發時,可以盡情展現自我風格或展現高超的程式技巧。但當系統(網站)龐大到無法僅靠一人完成時,就需要透過團隊力量來分工合作。這時候的個人風格,就會影響整個專案的進行。

在此分享個真實故事。某個大型網站的專案分割為三個子系統,其中一個子系統將蒐集的資料傳回JAVA Server,然後存到資料庫中。讓另一個工程師建置的php站台來讀取資料庫資料。一切看似都如此的完美與簡單,但事情發展總出乎意料。某日因為負責php的同仁進度超前,所以打算先測試php站台功能是否能與資料庫正常運作。但其他同事正為了專案進度落後而焦頭爛額,沒時間裡會資料庫中還沒有任何資料。所以php工程師直接進資料庫修改資料表,打算直接丟幾筆測試資料。填完資料測完功能,也跟該部門的同事發現php系統上要改的地方。也就「順便」直接在資料庫中新增資料表與欄位,滿足了原先系統未滿足的需求。等要丟入正式資料到資料庫時,大家才發現晴天霹靂的恐怖事情。不知何時共用的資料庫中的所有資料表,竟然資料欄位全部變成小寫?而兩個各有數千行程式碼的子系統,一個全用小寫、另個全用大寫來命名。這時究竟要改哪個系統才好早已沒人知道,大家已陷入一片哀嚎與咒罵聲中。

從大家三篇的文章加上前面志威分享的小故事,可看出網站的成敗與否。問題不單單只是xdite心中所想的:「改一個功能並不是很難,只是我要花一些時間去看程式碼和重新改寫。」但對於老闆來說,他的專業不在於技術的研究。老闆甚至可以不懂任何一行程式,他該做的事情是要看的是比員工更高層次的「方向」與「未來」。也不僅只是Mr.6單純的認為:「你給我成品前,難道自己不會『撿撿』嗎?」。身為員工的程式撰寫員寫出來的程式,在自己眼中是看不到老闆眼中使用者真正需求(很多時候程式的修改不是功能問題,而是老闆的需求改變)。而擁有豐富專案管理實務經驗的獨孤木前輩,文中就提到網站建置或外包的重要問題。問題的癥結點是溝通!溝通與協調上會花去絕大部分的時間,而時間之於專案就如同汽車與汽油的關係。每多開一公里就多浪費一公里的油錢,專案多延宕一天沒結案,總成本就會持續超出預算。

其實大家都沒錯,只是看事情的眼界高低的差異與出發的觀點不同。幾位朋友分別從網站開發的程式設計者、網站外包的業主與專案管理者,這些不同的角度去看網站(專案)長尾巴這件事情。而我再進一步補充,究竟要如何找到讓專案順利並圓滿完成的解決方案呢?這個答案就是找到一個稱職、有能力的PM。一個良好的PM除要具備相當的domain knowhow與時程控管能力外,最重要的就是溝通協調能力。他必須將老闆時長過於遠大的夢想,找到執行與實做的方法,更要能溝通協調把像在各星球各自為政、不同部門的理性嚴謹工程師與行銷、美工等創意人員,通通揉合在一起朝相同目標前進。也能夠事前就規劃好整個專案的時程,並且設定適當的check point,隨時掌控進度與各部門狀況。這也是為何有些前輩會說,看一個網站建置(專案)的成敗,只要看看帶頭的PM是誰?就能明白這個專案未來的成敗。

喜歡這篇文章嗎? 分享出去給作者一點鼓勵吧!