一次失敗的Release
去年8月份加入一家創業公司，和原同僚做VR相關的産品開發，到18年正月初七，總共release過兩次，真正經理了一次從0到1的過程。第一次release産品初步成型，大概在10月份，在公司内部做了一次宣發，我們做的是ToC的産品，但這次release沒有真正意義上的C端客戶，倒是可以拿着這個雛形産品到處去找内容提供商；另外可以拿到市場上去"試點"了，找一些潛在的目标使用者，去收集回報；再有就是需要向投資人交答卷。
第二次release就是直接面向實在的客戶了，release時間點在正月初七。我認定這次Release是失敗的，是因為軟體品質出現了問題——産品拿到使用現場的時候發現諸多bug,系統根本跑不通，在現場調試了三天才将就着能用。想想自己曾經信誓旦旦的說這次釋出的目标是要保證軟體健壯性，出錯率保證在5%以内，臉不禁紅到了脖子跟，呵呵。
這篇文章隻從項目管理和軟體開發的角度來闡述這次release之前的諸多流程，用以分析項目失敗的原因。
一個好的軟體産品，軟體品質是基石，軟體品質指的是軟體的穩定性和流暢度，軟體品質過不了關，軟體再怎麼易用，業務功能再牛逼，也稱不上合格的産品。
研發團隊成員
研發團隊總共四個開發，我和原同僚做背景和VR終端開發，一個新員工做網頁前端開發，一個員工做Unity開發。做美工的就不算了。沒有測試，沒有項目經理（靈活教練）。我和原同僚是資曆比較深的，另外兩個員工經驗相對要淺。研發團隊是原同僚和老大組建的，不知道為什麼忽略掉這兩種成員角色。或許是因為支出吧。
為什麼會失敗
這次失敗，當然有客觀原因，譬如成員角色就是不完整的，譬如時間緊迫，但這些都不說，主要還是從自身找找原因，這樣在下次遇到相同情況的時候，我們不能保證做到完美，但至少能保證減少錯誤或者沒有大的錯誤，臻于完美。
因為團隊成員角色的缺失，是以我們自己要擔任起這些角色的功能，其實這都是後話，我們沒有意識到它的重要性。
先從自身問題說起，我以前的背景全部是在發展相當成熟的大公司裡任職開發工作，估計原同僚也是類似，沒有小公司創業經驗，缺乏大局觀。原先經曆的項目都号稱是靈活開發，眼睛看見了項目經理如何運作一個項目：如何進度跟蹤，如何協調資源，如何應對産品團隊提出的需求變化等等；看到了測試人員如何工作：寫測試計劃，寫自動化測試用例，和開發人員溝通測試結果等等。但這次經曆說明了，眼見為『虛』，這些其它角色都沒有親身經曆，過腦沒過心。從心裡知道這些程式是必要的，但沒有見過缺失這些角色會造成什麼後果，心裡自然而然的還是将自己定位成開發人員，按照開發的路子一直走。 沒有項目管理整個團隊就是一盤散沙，沒有目标，沒有計劃，沒有需求優先級，産品過來需求就去做，做到什麼時候沒有預估，最後，失敗是注定的。下面詳細說說我們這次項目運作過程中缺失的流程：
沒有時間節點
這是緻命的，老大把release時間确定了，研發團隊應該将研發測試的時間節點也定下來，什麼時候代碼寫完，什麼時候單元測試完，要留出來多長時間的系統聯調時間，什麼時候code freeze.時間确定下來後，各個階段的目标就明确了，寫代碼階段要保證代碼品質，自測階段要盡可能的發現新加代碼中的問題，聯調階段至少要保證沒有大的bug，小bug要盡量清理掉。code freeze出release版，坐等上線。
我們這次隻有一個release時間，其餘的都是瞬息自然，最後可想而知，運送裝置當天勉強把軟體裝到裝置裡，沒有測試完，發現的問題沒有解決完。
沒有進度跟蹤
靈活開發标準流程中的一環就是standup meeting，由項目經理了解每天項目進度，這其實是把寫代碼的時間節點分成了小目标，每個開發人員把需求的完成當做自己的一個目标，一個小目标又可以分成幾個小小目标，例如，一個子產品的完成就是完成了一個小小目标。項目跟蹤可以讓項目經理了解大緻的開發進度，和大的時間節點相關聯，如果過程中遇到問題，可以提前做出判斷，采取補救措施。項目成員也可以通過這種方式讓目标更加明确，遇到問題及時做出調整，并且也能了解其它項目成員的進度。
很可惜的是我們也沒有standup meeting,目标變得模糊起來，這會導緻問題，就像上學的期末考慮，把所有問題最終都堆積到臨考試的前兩周，結果可想而知，能及格就不錯了。
需求傳遞流程不規範
先說問題，我們的産品經理傳遞需求都是通過口頭來傳達的，有以下幾個缺點：
- 口頭傳達會有資訊損失，表達出來的東西和想法可能就會有出入，再傳遞到另外一個人的腦子裡，了解的可能和你表達的又不一樣，一次次傳遞，到最後的實施人員，最終可能面目全非。可能有點誇張，我們的團隊也很小，溝通成本也小，但終究還是有問題。你碰到過開發和産品打架麼？開發：你就是這麼說的，我做的完全是照你說的做的。産品：我沒這麼說過，你肯定是誤解我的意思了。呵呵。
- 人的想法是會變的，人是會遺忘的。今天以為東西這麼做好，頭腦裡有一套完整的功能流程，但明天可能覺得那裡不對，但卻想不起來具體是哪裡不對了。
- 有些東西不是一下就能了解的，實施人員得到需求後，可能一下就以為自己明白了，但設計和實作過程中才會發現産品需求有更深層次的用意。在反複揣摩産品需求，加深自己的了解時，記在腦子中的需求可能沒有原先那麼清晰明确了，好吧，又得去找産品團隊确認。
我說這麼多的目的隻有一個：需求需要書面形式的寫下來。産品團隊寫的過程中會多一個反複揣摩的過程，怎麼表達更準确無誤，自己的這種想法對不對？然後寫下來，寫下來就是寫下來了，産品可以在這個基礎上反複更改，直到無誤。實施人員可以反複的了解産品的需求，這回反複了解的需求每次都是清晰可見的。
我們這次也碰到了需求了解不到位的問題，開發人員的功能實作和需求傳遞者的想法出現了偏差。
最後說說測試的問題
最近研發團隊加入了Scrum Master新成員，有比較豐富的管理經驗，但他做出的決定是先不要招測試人員。功能自己做自己測試。我對測試人員的看法如下：
- 我覺得開發和測試是對立的，某種意義上來說，開發人員測試自己的代碼往往不客觀，尤其是單元測試覆寫不到的功能點，開發往往認為自己的功能是沒問題的，有一個比喻：程式員寫出的代碼就是自己的孩子，哪有老給自己孩子揭短的。呵呵。是以這兩個角色看問題的角度是不一樣的。是以我認為測試人員還是必要的。
Scrum Master可能覺得我們目前的功能還沒有那麼複雜。是以自測應該沒問題吧。在沒有測試人員的情況下，為了保證軟體品質，覆寫率高的單元測試就很有必要了。
希望我們以後能夠做的更好，加油！
作者：
HarlanC部落格位址：
http://www.cnblogs.com/harlanc/個人部落格：
http://www.harlancn.me/本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出,
原文連結如果覺的部落客寫的可以，收到您的贊會是很大的動力，如果您覺的不好，您可以投反對票，但麻煩您留言寫下問題在哪裡，這樣才能共同進步。謝謝！