日期: 2007 年 11 月 14 日

發佈於

我在奇摩Yahoo!的日子 – 開發知識+

在跟老闆簡報知識+ 要怎麼做之前，我已經直接開工偷跑了，因為大主管壓的時間，實在是不合理，反應也無濟於事，只會被認為是負面思考，就硬著頭皮搞吧！

在簡報之後，確定了幾個重點，廢掉了服務串接，簡化了階段功能。雖然有些東西我很想做，但主管勸我要做取捨，否則不是我陣亡，就是團隊一起跳海。我接受了，也得以更快馬加鞭進行開發。

■ 服務製作

有鑑於交友之前人力不足的狀況，主管怕我過勞死，知識+ 變她要做，所以特地跟人力資源部門（HR）爭取到一個工作名額，但找人卻又是一件苦差事，加上我得一邊製作、一邊看履歷、一邊面試，只能用焦頭爛額來形容。

最後，找到了 K 同事來一同協助知識+ 的開發，由她負責規劃分類、擬定規範、撰寫服務說明、編寫 Flash 教學...。說真的，如果沒有她的加入，我...無法想像會發生什麼慘絕人寰的後果。

2004/07/13 日記

工作瓶頸有兩種：

一種是知道怎麼做，但就是沒時間做。
一種是時間很足夠，但就是不知道怎麼做。

專案前段，是第一種。
專案中段，是第二種。
專案後段，我想，將會是第一、二種混雜...。

雖然搞專案，是我比較見長的部份，但是總不能天天搞、急急搞。

■ 視覺設計

由於交友開發時遇到一些不愉快的事，這回主管直接指定視覺設計人員，以避免溝通不良的狀況再度發生。

雖然我這回還是自己用 HTML 做出頁面草稿 (wireframe)，但我從不認為視覺設計人員會因此被侷限住。如果把前一棒的努力當作是沒地方發揮的藉口，那你這一棒的價值在哪裡？

感謝主！我和這位視覺設計有一定的默契，合作得很愉快，雖然有時候她脾氣也滿硬的。

2004/09/25 日記

凌晨，為了專案上市的時間，在線上跟主管「溝通」。
說溝通是好聽，說爭執才是事實。

原本期望每個環節都加分，現在卻是每個環節都誤點。
產品的上市時間還有可能被迫提早，怎麼會變成這樣呢？

一個延後，一個提前，那麼誰要被迫壓縮時間？誰要被迫棄守城池？

企劃，是現實與理想之間的線性規劃，我還在試圖找尋那個均衡點...

■ 使用者體驗

當時，公司正推動所謂的 User Experience Design （使用者體驗設計），更強調易用性及網友的使用經驗。在互動設計師 C 同事的協助下，釐清了一些模糊的規劃及不當的用詞。

這也讓我瞭解到，原來我在規劃交友、知識+ 時，花許多心神在思考琢磨的操作、動線、流程...等，就是跟互動設計相關。

2004/10/04 日記

之前，看過一部漫畫，叫「教頭當家 Rookies」，裡面有一句經典的話「One for All」，強調團隊的重要。今天下午，把這一張群像圖做出來時，我想到了這一句，但也有另一句延伸...

One for All, All for One.

我為人人．人人為我，是這樣翻的嗎？我不知道。每個人都為了協同一致的目標在努力，當團隊共識凝聚，彼此的心也就合而為一了。

繼續努力吧！

■ 程式開發

原本指派之前跟我合作交友的工程師來負責程式開發，但他突然被調去做更重要的工作，最後變成三位新工程師來接替知識+ 的開發工作。

能進來Yahoo!奇摩的工程師，雖然都是程式開發的箇中高手，但合作默契的培養，卻必須一點一滴從零開始。對於突然的陣前換將，我一開始無法接受，也厭煩重新培養默契。不過，如果什麼事都能順心如意，那也太好幹了。

換個角度來看，新來的三位工程師也滿可憐的，一來公司報到，新人的蜜月期都還沒爽到，就被丟入如火如荼的知識+ 開發火坑中。專案又大又重，時間又少又急，再加上身為新人，只能捏著 LP 悶著做，苦水往肚裡吞。

2004/10/24 日記

專案所規劃的新產品，已經要進入測試的階段。

製作有些許的延誤，導致上市時間也必須順勢往後延。要做一個好產品，品質控管(QC)是一定要的。

匆匆上市固然可以先搶市場，但是如果產品有暇疪，辛苦攻佔的市場是會迅速地淪陷，競爭對手也將會立即抄襲，然後進行超車。

原本以為產品會照著我的規劃製作，但哪有如此順心如意的事呢？產品交到我手上，開始進行測試，發現問題還真的不少。

工程師也可憐，在那麼短的時間內，製作出這麼複雜的產品，雖然看到樣品有問題，我還是得耐著性子與工程師溝通討論。

自從上一個專案後，我已經很少加班，不是工作變少，而是不願意再加班。眼看上市時間一天天逼近，而我又不想給它爛的狀況之下，我又開始加班了...

七點多下班、八點多下班、提早上班，狀況多到測不完，只好這兩天週末也給它加下去，啊～搞專案真的要這麼累嗎？

工作累是天經地義的，但是加班會加出問題，我的身體也無法負荷。

專案寫了，不搞不行。
產品做了，不測不行。
褲子脫了，不拉不行。

■ 測試

知識+ 是一個複雜度極高的網路服務，問答流程、點數增減、等級升降，都是互相交錯牽引。

在規劃時，已經有意識到這個狀況，但進入測試這一關，才親身感受到知識+ 的背後運作真是他 x 的複雜。除了要測試前端（網友使用的部分），還要測試後端（編輯、客服使用的部分），不僅規則要一致，還要資料即時同步。

在測試的過程中，發現有不少地方和當初的規劃相左，或許我寫得不夠明確，或許工程師做到發瘋。雖然又肚爛又痛苦，但還是得沉住氣，耐著性子溝通找出解套的方法。

由於要測的東西實在很多，發生的狀況實在不少，上線的時間實在太趕，內部還沒測完...知識+ 就上線了。身為製作人的我，無力，也無奈...

上線再繼續測吧~

■ 系列文章