快速開發後的思考

 

　　一個月前咱們啓動了一個看起來像是「閃電計劃」的項目，用兩週的時間完成系統的改版，內容包括原型設計、界面設計、開發、測試、上線。時間緊任務重，看起來有點像不可完成的任務。最終經過整個團隊的密切配合，和包括週末在內的加班加點按時完成了任務。但僅僅是完成，並未出彩。這是我第一次和整個團隊一塊兒參與較爲完整的一次項目開發，從上線前到上線後，整個過程當中彷佛老是不那麼平坦，有許多細節值得思考。可是時間緊急來不及追究，如今有必要靜下來回顧思考，有哪些好的地方是能夠繼續沿用的，有哪些差的地方是須要改進的。

　　咱們如今的團隊和小的創業團隊沒什麼差異：

1. 成員之間沒有一塊兒開發過完整的項目，缺乏磨合
2. 咱們的工做流程、溝通方式、開發流程沒有嚴格規範，大部分是經過即時溝通來達成意見一致，說好聽了是敏捷，說難聽了就是原始。
3. 需求的修改、代碼的聯調沒有明確的流程，沒有造成規範的文檔，之後想要翻看以前的記錄將比較困難
4. 爲了追求快速完成項目，犧牲了代碼設計架構的時間。沒有良好的架構，之後需求改動或擴展會比較費力

 

　　這些特徵決定了咱們必然會以如今的流程來進行開發，但由此產生的問題咱們有沒有方法來改善呢？答案確定是有的，如今須要回顧一下整個流程，慢慢來尋找答案。

 

　　在肯定需求的時候，咱們所有的人員開了一次會，5個小時左右，把全部要作的東西過了一遍，有疑惑的地方當場拍板應該怎麼作。應該說是解決了全部的疑惑，由於咱們明白這樣的會議不會再來一次的，接下來就要進行開發了。我以爲作的比較好的是，咱們在討論事後總會得出一個結論，這一塊該怎麼作，那一塊改怎麼作。能夠說咱們的會是「有結果的」，這至關重要。若是僅僅是停留在發現問題、提出問題的層面，那這個會也就和沒開同樣了。這是值得沿用的一點。

　　可是咱們的會就沒有缺陷嗎？顯然不是。咱們此次改版涉及到的功能點太多，由於是改版而不是從新作一個東西，因此有不少是咱們沒看到的。所謂沒看到的就是一些隱藏的業務邏輯，須要在特定的場景下才會發生。咱們的舊系統邏輯比較複雜，咱們的人員從產品到開發都是新的，對老系統缺少總體全面的瞭解。咱們整理出了新的需求，但有一個致命的缺陷：咱們沒有全面的考慮新的需求與舊的邏輯有哪些衝突，咱們沒有考慮舊邏輯之因此那樣作的緣由，功能點之間存在的關聯或是前置條件，這些都沒有清楚的瞭解。

　　這個致命的缺陷直接致使咱們在開發的過程當中不斷髮現有遺漏的地方，以致於不得不先完善遺漏的東西，最終的開發量粗略估計有需求文檔上面的1.5倍。

　　其實過來人都有這樣的經歷，甚至以爲這是喜聞樂見的，項目開發大都如此嘛，沒有不會變的需求。但這樣的狀況並不是是什麼好事，那咱們該如何改善呢？咱們開了5個小時的需求討論會，難道還不夠嗎？固然不夠，由於咱們只開了一次。由於咱們是在改版，是在重構，在開發的過程當中必然會發現第一次討論沒考慮到的東西，在積累了必定的問題後，咱們是否是須要從新拿起需求文檔，從新審視一遍，再來一次簡短的討論會，該添哪些東西，或者是時間不夠了該砍哪些東西。

 

　　咱們的開發流程仍是比較順利的，由於明白時間有限，因此採起了簡單處理、重複迭代、快速成形的方案，有一些新的設計想法都沒有采用，而是沿用了原來的較爲穩妥的作法。好比咱們計劃想減小請求數，把一些頁面內容作成異步獲取的，但最終考慮到改動的東西會比較多，就放棄了，仍是複製粘貼了很多代碼，每一個頁面還像原來那樣單獨請求。頁面加載速度沒有提高，但保證了穩妥不出問題。再談優雅什麼的，那更是沒有了。

　　咱們天天早晨開一個15分鐘左右碰頭會，通報一下昨天的進度，覈對一下今天的任務。讓每一個人都內心有數，這一點仍是作的不錯的。

　　如今須要反問一句了，開發的過程當中有什麼問題嗎？有。由於咱們仍是發生過返工的。除去需求變化的緣由，因爲考慮欠缺，沒有明確方案就急於寫代碼，致使寫了一大半的時候發現方案有誤，最終更改方案從新開發，這一點仍是很傷的。如今須要告訴本身一句了：就算時間再緊急，也要想清楚了再動手。事實上，有明確且正確的方案後，編碼是佔用不了多少時間的，這一點一直會給人形成誤區，認爲作項目主要就是寫代碼。

 

　　開發完後就是緊張的測試了。咱們沒有專門的測試組，創業團隊的風格嘛。因而從別的組拉來兩個實習生，外加產品經理、開發人員、客服妹子，組成了一支測試隊伍。利用週六週日的兩天時間，完成了產品的測試。測試的方式是最原始的功能測試，說白了就是以用戶的身份，在頁面上點來點去，把各個功能塊都跑一遍，看看哪裏走不通了。咱們也沒有bug庫之類的輔助工具，測試人員測完一輪就羣發郵件通知一下，或者直接經過IM來交流，而後開發根據郵件和討論組中的bug來修改。

　　這樣的測試流程很明顯是有問題的。對比一下，若是咱們創建bug庫，咱們規範了的流程大概是這個樣子：測試人員提交bug到庫=>開發經理/組長分配bug給組員=>開發修改bug=>開發提交給測試返測=>測試人員標記bug經過/bug仍存在再次提交到庫。

　　上面的流程看似冗雜，但少了其中任一環都不能保證一個bug能被最終解決，而且讓你們知道這個bug已經處理了。這個是很重要的，你們能對每個問題都有一個清晰的掌控，不然當用戶來咱們咱們的時候，咱們的回答只能含糊不清，由於咱們本身都不清楚這個問題究竟是解決了仍是沒有。就從咱們實際狀況來看，咱們也確實遇到了如下問題：

1. 對照郵件來處理bug很容易會有遺漏，由於無法標記這個bug是已處理仍是未處理，或者是測試有誤不處理。全憑人腦記憶。在討論組裏提bug則更容易遺漏，由於可能開發人員壓根就沒看到這條信息。
2. bug的認領問題。有些bug須要前端來改，有些須要後端來改，沒有一我的來統一分配，分工不明確。組員本身認領本身的bug，或者相互溝通協調，時間成本都太大
3. 開發修改完bug後，沒有給測試回覆郵件來講明bug的處理狀況。bug最終的處理結果只有開發清楚，沒有一份能夠保持的文檔來記錄，測試並無百分百的返測他所提的bug，只是提完就算結束了。這樣缺少互動溝通，你們最終對結果的瞭解都是含糊的。

　　這樣看來咱們的測試流程確實是有不少問題的，這也直接致使了咱們的產品上線後，不斷接到用戶反饋，其中大多數都是bug。那咱們當初爲何要這麼作呢？答案只有一個字：快。在有限的時間內，一個創業團隊，根本沒法創建起來這麼完善的測試流程，這也是客觀事實。看來這問題是無解了，真的嗎？或許這個時候咱們須要迴歸到問題的根本上，思考這樣一個問題：花必定的時間創建一個完善的工做流程，最終下來是會浪費時間，仍是節省時間？咱們想答案並非那麼絕對的。

 

　　經過原始的溝通方式，使用原始的工做流程，咱們終於把產品折騰上線了。產品上線後的穩按期持續了兩週之久，不斷有用戶反饋發現了bug，客服那邊都忙壞了。開發這頭也是手忙腳亂，咱們創建了一個討論組，你們都在裏面反饋發現的問題，bug像炸彈同樣向開發狂轟濫炸，場面可想而知。

　　在這個階段，咱們陷入了像測試階段同樣的困境。太亂了。這個時候發現的問題都是零零散散的，甚至都沒有郵件來彙總，因此都在討論組裏面提。開發人員一變修改代碼，一邊留意討論組裏又提了什麼問題。有時候一個bug修改的時間長，討論組了已經攢了n個bug，有時候你們發言太多就把一些問題遺漏了。並且這個時候都是靠人腦在記憶，很容易就忘記了到底有多少bug存在，這個時候就會出現有人在討論組反映了一個問題，卻沒人迴應的情況。與此同時，因爲遺漏了反饋來的問題，客服、運營又會感受這邊響應不及時，沒法向用戶交代。總而言之，就是一個字：亂。

　　問題在哪裏實際上是顯而易見的，咱們缺乏一我的來統籌工做，應該是項目經理的角色。可是像這樣的創業團隊，不管是產品仍是開發，每一個人都會奮鬥在第一線，沒有一我的能抽出身來統籌一下項目，或者說把全部反饋的問題整理一下，作成一個列表來挨個對過。若是咱們沒辦法專門有一我的來統籌進度，那麼就必須抽一我的出來作這件事了，我想最合適的仍是產品經理，同時擔當QA的角色。這個時候對產品經理的要求就比較高了，必須快速的與開發進行有效溝通，所謂有效溝通就是必定要得出一個結論來，這個問題該如何改，如今就動手。由產品經理來驅動整個過程。

 

　　有時候會感慨，項目節奏太快，都沒有時間思考了。其實這是一件可怕的事情，像這樣「閃電計劃」似的項目開發，是很是寶貴的經歷，若是不能從中學習到一些東西，真的是太惋惜了。如今有時間靜下來進行思考了，咱們的不足暴漏的很明顯，在從此的工做中必須針對性的進行調整，只有這樣纔有提高的可能，不然永遠只是重複勞動的機器。

 

　　很久沒有碼字了，感受整個行文都有點生硬了，最近看了阮一峯老師寫的 爲何要堅持寫博客，很是贊同裏面的觀點，由於寫做能促使你不斷的思考，而思考對於人的提高相當重要。