一個月前我們啟動了一個看起來像是“閃電計劃”的專案，用兩週的時間完成系統的改版，內容包括原型設計、介面設計、開發、測試、上線。時間緊任務重，看起來有點像不可完成的任務。最終通過整個團隊的密切配合，和包括週末在內的加班加點按時完成了任務。但僅僅是完成，並未出彩。這是我第一次和整個團隊一起參與較為完整的一次專案開發，從上線前到上線後，整個過程中似乎總是不那麼平坦，有許多細節值得思考。但是時間緊急來不及追究，現在有必要靜下來回顧思考，有哪些好的地方是可以繼續沿用的，有哪些差的地方是需要改進的。
我們現在的團隊和小的創業團隊沒什麼差別：
- 成員之間沒有一起開發過完整的專案，缺少磨合
- 我們的工作流程、溝通方式、開發流程沒有嚴格規範，大部分是通過即時溝通來達成意見一致，說好聽了是敏捷，說難聽了就是原始。
- 需求的修改、程式碼的聯調沒有明確的流程，沒有形成規範的文件，以後想要翻看之前的記錄將比較困難
- 為了追求快速完成專案，犧牲了程式碼設計架構的時間。沒有良好的架構，以後需求改動或擴充套件會比較費力
這些特徵決定了我們必然會以現在的流程來進行開發，但由此產生的問題我們有沒有方法來改善呢？答案肯定是有的，現在需要回顧一下整個流程，慢慢來尋找答案。
在確定需求的時候，我們全部的人員開了一次會，5個小時左右，把所有要做的東西過了一遍，有疑惑的地方當場拍板應該怎麼做。應該說是解決了所有的疑惑，因為我們明白這樣的會議不會再來一次的，接下來就要進行開發了。我覺得做的比較好的是，我們在討論過後總會得出一個結論，這一塊該怎麼做，那一塊改怎麼做。可以說我們的會是“有結果的”，這相當重要。如果僅僅是停留在發現問題、提出問題的層面，那這個會也就和沒開一樣了。這是值得沿用的一點。
但是我們的會就沒有缺陷嗎？顯然不是。我們這次改版涉及到的功能點太多，因為是改版而不是重新做一個東西，所以有很多是我們沒看到的。所謂沒看到的就是一些隱藏的業務邏輯，需要在特定的場景下才會發生。我們的舊系統邏輯比較複雜，我們的人員從產品到開發都是新的，對老系統缺乏整體全面的瞭解。我們整理出了新的需求，但有一個致命的缺陷：我們沒有全面的考慮新的需求與舊的邏輯有哪些衝突，我們沒有考慮舊邏輯之所以那樣做的原因，功能點之間存在的關聯或是前置條件，這些都沒有清楚的瞭解。
這個致命的缺陷直接導致我們在開發的過程中不斷髮現有遺漏的地方，以至於不得不先完善遺漏的東西，最終的開發量粗略估計有需求文件上面的1.5倍。
其實過來人都有這樣的經歷，甚至覺得這是喜聞樂見的，專案開發大都如此嘛，沒有不會變的需求。但這樣的情況並非是什麼好事，那我們該如何改善呢？我們開了5個小時的需求討論會，難道還不夠嗎？當然不夠，因為我們只開了一次。因為我們是在改版，是在重構，在開發的過程中必然會發現第一次討論沒考慮到的東西，在積累了一定的問題後，我們是不是需要重新拿起需求文件，重新審視一遍，再來一次簡短的討論會，該添哪些東西，或者是時間不夠了該砍哪些東西。
我們的開發流程還是比較順利的，因為明白時間有限，所以採取了簡單處理、重複迭代、快速成形的方案，有一些新的設計想法都沒有采用，而是沿用了原來的較為穩妥的做法。比如我們計劃想減少請求數，把一些頁面內容做成非同步獲取的，但最終考慮到改動的東西會比較多，就放棄了，還是複製貼上了不少程式碼，每個頁面還像原來那樣單獨請求。頁面載入速度沒有提升，但保證了穩妥不出問題。再談優雅什麼的，那更是沒有了。
我們每天早晨開一個15分鐘左右碰頭會，通報一下昨天的進度，核對一下今天的任務。讓每個人都心裡有數，這一點還是做的不錯的。
現在需要反問一句了，開發的過程中有什麼問題嗎？有。因為我們還是發生過返工的。除去需求變化的原因，由於考慮欠缺，沒有明確方案就急於寫程式碼，導致寫了一大半的時候發現方案有誤，最終更改方案重新開發，這一點還是很傷的。現在需要告訴自己一句了：就算時間再緊急，也要想清楚了再動手。事實上，有明確且正確的方案後，編碼是佔用不了多少時間的，這一點一直會給人造成誤區，認為做專案主要就是寫程式碼。
開發完後就是緊張的測試了。我們沒有專門的測試組，創業團隊的風格嘛。於是從別的組拉來兩個實習生，外加產品經理、開發人員、客服妹子，組成了一支測試隊伍。利用週六週日的兩天時間，完成了產品的測試。測試的方式是最原始的功能測試，說白了就是以使用者的身份，在頁面上點來點去，把各個功能塊都跑一遍，看看哪裡走不通了。我們也沒有bug庫之類的輔助工具，測試人員測完一輪就群發郵件通知一下，或者直接通過IM來交流，然後開發根據郵件和討論組中的bug來修改。
這樣的測試流程很明顯是有問題的。對比一下，如果我們建立bug庫，我們規範了的流程大概是這個樣子：測試人員提交bug到庫=>開發經理/組長分配bug給組員=>開發修改bug=>開發提交給測試返測=>測試人員標記bug通過/bug仍存在再次提交到庫。
上面的流程看似冗雜，但少了其中任一環都不能保證一個bug能被最終解決，並且讓大家知道這個bug已經處理了。這個是很重要的，大家能對每一個問題都有一個清晰的掌控，否則當使用者來我們我們的時候，我們的回答只能含糊不清，因為我們自己都不清楚這個問題到底是解決了還是沒有。就從我們實際情況來看，我們也確實遇到了以下問題：
- 對照郵件來處理bug很容易會有遺漏，因為沒法標記這個bug是已處理還是未處理，或者是測試有誤不處理。全憑人腦記憶。在討論組裡提bug則更容易遺漏，因為可能開發人員壓根就沒看到這條資訊。
- bug的認領問題。有些bug需要前端來改，有些需要後端來改，沒有一個人來統一分配，分工不明確。組員自己認領自己的bug，或者相互溝通協調，時間成本都太大
- 開發修改完bug後，沒有給測試回覆郵件來說明bug的處理情況。bug最終的處理結果只有開發清楚，沒有一份可以保持的文件來記錄，測試並沒有百分百的返測他所提的bug，只是提完就算結束了。這樣缺乏互動溝通，大家最終對結果的瞭解都是含糊的。
這樣看來我們的測試流程確實是有很多問題的，這也直接導致了我們的產品上線後，不斷接到使用者反饋，其中大多數都是bug。那我們當初為什麼要這麼做呢？答案只有一個字：快。在有限的時間內，一個創業團隊，根本無法建立起來這麼完善的測試流程，這也是客觀事實。看來這問題是無解了，真的嗎？或許這個時候我們需要回歸到問題的根本上，思考這樣一個問題：花一定的時間建立一個完善的工作流程，最終下來是會浪費時間，還是節省時間？我們想答案並不是那麼絕對的。
通過原始的溝通方式，使用原始的工作流程，我們終於把產品折騰上線了。產品上線後的穩定期持續了兩週之久，不斷有使用者反饋發現了bug，客服那邊都忙壞了。開發這頭也是手忙腳亂，我們建立了一個討論組，大家都在裡面反饋發現的問題，bug像炸彈一樣向開發狂轟濫炸，場面可想而知。
在這個階段，我們陷入了像測試階段一樣的困境。太亂了。這個時候發現的問題都是零零散散的，甚至都沒有郵件來彙總，所以都在討論組裡面提。開發人員一變修改程式碼，一邊留意討論組裡又提了什麼問題。有時候一個bug修改的時間長，討論組了已經攢了n個bug，有時候大家發言太多就把一些問題遺漏了。而且這個時候都是靠人腦在記憶，很容易就忘記了到底有多少bug存在，這個時候就會出現有人在討論組反映了一個問題，卻沒人迴應的狀況。與此同時，由於遺漏了反饋來的問題，客服、運營又會感覺這邊響應不及時，無法向使用者交代。總而言之，就是一個字：亂。
問題在哪裡其實是顯而易見的，我們缺少一個人來統籌工作，應該是專案經理的角色。但是像這樣的創業團隊，無論是產品還是開發，每個人都會奮鬥在第一線，沒有一個人能抽出身來統籌一下專案，或者說把所有反饋的問題整理一下，做成一個列表來挨個對過。如果我們沒辦法專門有一個人來統籌進度，那麼就必須抽一個人出來做這件事了，我想最合適的還是產品經理，同時擔當QA的角色。這個時候對產品經理的要求就比較高了，必須快速的與開發進行有效溝通，所謂有效溝通就是一定要得出一個結論來，這個問題該如何改，現在就動手。由產品經理來驅動整個過程。
有時候會感慨，專案節奏太快，都沒有時間思考了。其實這是一件可怕的事情，像這樣“閃電計劃”似的專案開發，是非常寶貴的經歷，如果不能從中學習到一些東西，真的是太可惜了。現在有時間靜下來進行思考了，我們的不足暴漏的很明顯，在今後的工作中必須針對性的進行調整，只有這樣才有提升的可能，否則永遠只是重複勞動的機器。
好久沒有碼字了，感覺整個行文都有點生硬了，最近看了阮一峰老師寫的為什麼要堅持寫部落格，非常贊同裡面的觀點，因為寫作能促使你不斷的思考，而思考對於人的提升至關重要。