手上的這個項目已經做了一年了，當然也到頭了，因爲工作崗位要調整不再繼續下去了。一年來的經歷滿多的，記下來吧～
記得一年前剛參加工作不久，老大突然找我談話，說讓我負責某項目，其實這個項目是滿大的，自己從數據庫設計到業務邏輯全部要負責，要命的是沒有經驗，技術 也需要現學，捉襟見肘不說，還要常常加班。但更要命的一個問題在於自己的個性，因爲我自己是那種比較內向的人，也是慢熱的人，對很多東西要慢慢才能理解。 你想一個不懂又不喜歡多問的人，會是什麼狀態。（當然也有個客觀條件，大家都很忙，沒人會給你那麼耐心的指導。但是以這個條件爲接口的人是好面子的人，我 就是那種人，是做不好事情的）
根據項目組的需要，我們人員集中到了一起，去另一個BU那裏辦公。吼吼，熱鬧了～
一、需求評審
開始的日子，天天開會，幹什麼呢？當然是需求評審。人員也是相當的豐富，從開發到產品經理一個不落。當然對於我來說一片空白，因爲沒有那些概念，反正你們怎麼說我們怎麼做就行了唄。但那些所謂有經驗的人呢？其實什麼都沒講出來，開會其實就是在浪費時間。
因爲後來的事實證明，當初的需求有根本性的錯誤和不足，這也是導致項目屢次出問題的原因之一。當然，可借鑑的經驗幾乎是沒有了，但是教訓也是有意義的，防止以後重犯。列舉如下：
1、目標過高，不切實際。
大凡對待一個新生事物，人們都難免會產生一種美好的憧憬，好大喜功的情緒開始蔓延。但不要忘了那句話：爲了面子和同情心做的事情是註定要失敗的。
爲什麼說目標過高了呢？因爲我們的定位是給Product Manager自助製作活動的平臺，這其實就沒有考慮到產品經理和開發人員之間的鴻溝，忽略了太多的細節性問題。如果從長遠看，PM來DIY當然是最好的，同時如果PM可以DIY的話，那所有的配置必須是“傻瓜”型的，因爲他們沒有那麼多時間和精力去做複雜的配置，更別提理解你那些後臺的邏輯。但要做到這種“傻瓜”型的配置，必須是十分成熟的，相對固定的業務邏輯纔可以。而現在的情況是我們在摸着石頭過河，想一步跨過去，只會跌在河裏。
2、用戶定位錯誤
當然這是由於1引起的，因爲他定位在PM那裏，所以很多東西做的似乎是很“易用”，但實際上PM還是覺得麻煩。最後只好安排專門的運維人員來做這項工作，呵呵，運維人員覺得這太麻煩了，因爲人家可以直接在後臺搞定。用戶定位錯了，很多功能也就跟着出問題了，因爲做的功能不一定是真正的用戶所需要的。
二、一期開發
在一團和氣的評審之後，終於進入了正題，開始開發了。一個項目的成敗與一個人很有關係，這個人當然就是PM。很不幸，開始的PM也是主程，當然這本身並不是不幸的最大根源，最大的根源在於他不會溝通…..
最近收到他的一封郵件，簽名很有意思：用心溝通，從PK走向Win/Win。呵呵，真的很滑稽，一個PM以一種PK的心態來和別人溝通，結果是什麼？Of Course，爭吵吧。我就記得那時很不愉快，因爲整個項目組都在爭吵，吵需求，吵前後臺的不一致……應吵盡吵。更有趣的在於，PM大哥就不站在整個項目的立場考慮問題，而是站在他主程的位置上考慮，更要命的是這個主程還是那種小家子氣，就知道守着自己的一畝三分地，生怕自己工作做多的人。常聽他說：這我不管，你給我怎樣怎樣就符合我的要求了。靠，大哥，你是PM兼主程呀！就這種格局！這是立場的問題，至於溝通的技巧就更別提了……
這就是當時項目組內的情況，你想產品的質量能好嗎？而且當時各方的需求來勢洶洶，他又擋不住，出現了趕工的情況，質量的隱患就這樣一個一個的埋了下來，等待爆發的一天。當然這天並不遙遠，而且是週期性的，一次接着一次。其實項目組開始時遇到這種困難也是可以理解的，畢竟在摸着石頭過河嘛。關鍵在於出了問題怎麼辦？一個又一個的昏招出現了，做流程，流程中的每一步都抄送領導……靠，現在回想起來真是覺得很滑稽，究竟在搞些什麼東西～
而且這GG的RP值實在不敢恭維，反映在一次重大的事故中的表現。那次事故比較大，驚動了老大們，這GG揹着我們去彙報，在沒有確定BUG的情況下就認定是我們前臺出問題了，把自己撇的乾乾淨淨。於是處罰通知下來了，連累一個運維的哥們也跟着挨罰，當然他被罰的更多，因爲他PM嘛。當老大們傾巢而出研究相關問題時，我纔有幸有機會闡述一下對這個問題的看法，你不重現BUG，怎麼保證下次不出現同樣的問題。於是老大下令必須定位出BUG來。當天，BUG定位出來了，他的程序有個漏洞……事後他笑嘻嘻的過來說：終於給你洗刷了冤屈了～
害我們被罰款，被全部門通告，莫須有的罪名給我們加過來，又輕描淡寫的對我們說他幫我們洗刷了冤屈……這件事對我的傷害特別大，連我自己都很奇怪當時爲什麼會忍下來，靠，老子不幹了還不行嗎，你愛找誰就找誰去。可能當時還是專注在技術層面吧，就因爲他一個又一個的昏招，給我造成了各種需求，讓我有機會用到大量的技術，成長還是很快的。只可惜項目變得聲名狼藉，讓我一點都高興不起來。
部門漸漸意識到這個問題的嚴重性，於是調來一個新的PM，那位GG專注做主程了。這下更不得了了，凡是別人的需求在他那裏都簡單，凡是他的需求推三阻四，困難重重。新的PM還是可以的，至少對項目組的凝聚力要強上N倍。但一艘偏了航向的大船，也不是一時可以轉過來的，何況他也沒找對正確的方向呢。
整個一起就像走在一個沼澤地裏，艱難的爬行，還要不時的受點傷～
三、二期開發
主程GG可能太具有戰鬥力了，總之是離開了項目組。這時中心的老大親自督導，記憶很深的一次務虛會議是討論我們的項目到底是做什麼的，要給出一個定義。很有意義，只有在這個時候我們的航向纔開始向正確的方向偏移。
之後，監控、配置各方面都加強起來，成績慢慢的出來了，事故頻率振盪衰減。經驗也要總結一下：
1、 堅定項目的目標
堅定了我們自己的目標，就可以站穩自己的立場，明確自己的優先級順序，於是基礎性的東西慢慢搭建起來，系統自然就穩定，同時對需求也可以滿足的很好。擺脫了那種被需求拖着跑，這搞一塊兒那搞一塊兒的窘境，終於有了一個框架性的東東。
2、 掌握節奏
堅定了目標之後，對需求就有了足夠的勇氣和理由拒絕，於是開發節奏慢了下來，開始重視質量，這樣大家做的還是比較開心的。
四、尾聲
今天又完成了一次改版，感覺用戶的易用性得到了一定的提升。呵呵，做了一年多到現在才真正明白什麼叫從用戶的角度看問題，而不是站在自己的立場上。也算是一個大的收穫吧。
同時今天項目組又重新進行了合併，吸收了其他兩個項目組。不過我要離開了，不再參與了，去做自己更喜歡的後臺。
老大給我們開了一個戰略分析會，讓我們列出我們項目用戶最關注的5－10條需求（縱座標，關注度越高座標值越大），並給將我們對這些需求的支撐情況進行打分，0－5分（橫座標，分越高座標值越大），連成曲線。用另一種顏色列出競爭對手的這條曲線。吼吼，最後的曲線奇形怪狀～但國際大公司的曲線是什麼？看下圖。
說明什麼？對用戶最關注的我們就實現的最好，後面的我們差不多就可以了。爲什麼？因爲任何公司它的資源都是有限的，你不可能把所有的事情都做好。怎麼辦？做最重要的事情，用戶關注的事情就是最重要的事情！
說到這裏，二期雖然有很多經驗，但是一個比較失敗的地方就是對客戶最關注的事情沒有做好，而是什麼都做，什麼都想做好，失去了重點。
離開之際，如果要總結一下的話，我覺得可以用一句廣告詞來表達：專注您所關注。“您”就是用戶，去掉華麗與包裝，最樸素的東西才最重要。
PS：文中對某位GG批評較多，難免會有失偏頗，我想寫這些不是爲了批評他，而是提醒自己是不是會犯同樣的錯誤，有沒有站在一個更高的角度看問題，跳出自己的小圈圈，同時也換位思考一下，想想別人的難處。