沉思錄—Windows Phone軟體開發Beta版回首

三個多月過去了，我們軟體開發經曆了Alpha版本、Beta版本、Beta2 版本，最終做出來了，在該月末就會發布，alpha版本過後組員一起開了會，然後在beta版本，beta2版本我們軟體設計和alpha版本UI設計基本完全不一樣， 工作量也比alpha版本大很多，隊員們的熱情也此起彼伏，設計草案也換了很多……回首起來，確實值得很多反思

…………

…………

…………

如果我們重新來過，那麼我會做的比現在更好嗎？ 如果我們繼續改進，那麼我們會有什麼其他突破？如果？

下面我將從這幾個方面來一起回首我們的軟體開發以及改進流程

我們軟體具體實現和設想已經在上一篇部落格裡寫的很清楚，這裡我就不在此闡述

http://www.cnblogs.com/OMG-Team/archive/2011/11/26/2264704.html

1. 軟體的設想和計劃

可以說任何事情都要有個大綱，大綱可以保證我們正確無誤的沿著計劃前進，我們在Beta版本繼續明確了我們會議助手的核心：協助那些參加會議的人高效而又便捷的參加會議，聽talk，記錄自己喜歡的論文和會議。 為了更快地展示會議的議程，我們設想分兩個層次，第一個層次是session和下面的talk，第二個層次是talk detail 介面， 然後支援session , talk 添加按鈕並鬧鐘提醒功能。然後為了實現我們強大的功能，我們選擇添加作者以首字母為索引的作者列表，然後點擊作者列表可以到作者的詳細介面，添加地圖，添加記事本，添加關鍵字搜尋，添加會議設定，添加主辦方提供的其他資訊。其實我們只是為了完成這個設想而假設了很多結果，這個肯定會有用，那個肯定也會有用，想著feature越多，肯定越好

Feature越多，功能越強大？ 這樣是對的嗎？

雖說我們做過了使用者調查，但是我們調查的結果並沒有很滿意，我們並沒有很好的手段去瞭解使用者的痛苦，去聆聽他們的心聲，因為真實的使用者都是我們的導師，我們害怕耽誤他們的時間，所以使用者調查做的不是很好，使用者在開會的痛苦除了如何高效地展示agenda之外我們的定位也不是很准。 通過現在的使用者反饋，除了展示agenda和展示使用者提供的其他資訊（賓館，會場等） 我們發現其他feature並不是很突出，或者說對使用者來說要不要都是差不多。

而且還有一點是： 我們的設計缺少使用者粘性，有可能這個軟體使用者用了一次，就不用了，因為這個軟體不是social的，都是individual，沒有一個使用者交流的情境。

根據真實使用者反饋，其實開會時候，很多參會人員都會推薦這個會議，那個會議，都會講述自己看了寫什麼論文，或者感覺什麼論文不錯，也會交流自己的心得，甚至會交流自己的連絡方式

因此如果我們重做的話，除了展示agenda以外，我們想可以有多個標籤，如果感覺喜歡或者有意思的或者已經讀過的，或者將要讀，或者推薦給其他人的都可以進行分類，一旦標好之後，我們就可以通過這些標好的論文或者會議進行交流了。 可以實現近距離無線通訊，或者和周圍的伺服器進行通訊，這樣我們既可以滿足使用者的多樣化需求，也可以滿足使用者快速交流的需要，甚至有這樣一個情境，使用者兩個手機像握手一樣搖一搖，就可以通訊了。

2. 人員管理分配以及具體實現

我們軟體工程有5+1，其中一個是臨時調配過來的，對以前的代碼也不是很熟悉，所以我選擇分配給他比較獨立的任務，而其他五個代碼能力相差很大，可以這樣說其中有一個人代碼能力很強，代碼風格也很不錯，但是此人很有自己的特點，對任何事物慾望不是很強烈，而且比較獨立，所以很難改變他的想法或者激勵他幹什麼事情，平常開會時候精神狀態也不是很好，從此看出，他對這個任務不是很喜愛。 其他四人代碼能力平平， 對c#也是剛剛入門，在alpha版本出現了一個很不好的現象就是那個人能力超強，基本上把所有代碼都寫了。 其他人的代碼貢獻率很低。為了排除這個現象，同時保證確保整體的代碼品質，我決定前期把所有人的任務分配的差不多，那個代碼能力很強人的負責底層代碼的構建，其他人負責沒有涉及構架代碼的其他模組，而且也保證了每個人的代碼分配，最後一旦其他人的程式碼完成了，可以把重心都轉移到整合和架構的擴充上面。

事實證明這個方法挺好的，確實保證了整體的良好代碼風格和品質，但是問題也相繼出現，我們沒有分很詳細的task，沒有很詳細的時間，是一個模組一個模組的分給他們每個人，因此每個人的進度不好確保，不好量化，因此不好估計他們的工作。

我們又想了想，發現如果我們繼續走一步，把每個人的模組化工作也量化好，尤其是底層架構那個大骨頭也能量化好，這樣的效率應該更高一點。

作為PM我又考慮到我們隊員的整體代碼能力不強，所以我把時間節點調的非常密集，共有兩周的任務，我基本上都放在了第一周完成，雖說當時我們的一周沒完成，但是至少保證了兩周之內完成了。給我們很多預留了時間保證了我們的工作進度。

這一點挺不錯的。所以趁著大家的熱情，把主要任務放在前面，把時間壓縮，能有效保證我們開發進度。

3. 代碼品質

雖說我們團隊有一個人代碼品質很好，但是他始終替代不了我們所有人，在異常處理方面是最明顯的，我們很多人都沒有意識，如果代碼出現異常怎麼辦？如果解析不成功怎麼辦？ 但是經過後期的bug 修複，以及test 整體的代碼還是挺強健。

代碼品質其實是需要tester來進行監督的，可能是前期我們的tester充當dev的緣故，後期的tester 做的並不是很到位，很多情況下都是PM催著他們，有時是一遍遍催。可能我並沒有很大調動他們的積極性，或者項目到了後期，大家的熱情降低導致戰鬥力下降。

這方面，PM要加強tester的作戰能力，調動他們的熱情，比如聊天，或者物質獎勵之外， 還應該監督tester有一個規範和嚴格的檢測標準。

4. 團隊的合作和效率

經過alpha版本的團隊合作訓練，我們總體的合作還是挺好的，有什麼問題確實做到了即時報告PM，但是效率這方面還是有點欠缺，最主要因素是我們的代碼實現能力還是有所欠缺，很多情況下是我們有一些想法，但是限於代碼的實現有時候不得不折中或者妥協。但凡是都有第一次，相信我們的代碼能力會越來越強，以後效率會越來越高。

5. PM協調

此次軟體工程，說實話PM乾的活挺多，既充當傳統的PM角色，還攬有一個dev的活，這樣的PM好麼?

其實這樣的PM不好

因為PM其實不是每天寫些部落格，監督下隊員的進度就行了的，也不是認為你PM寫代碼就牛逼了，牛更加調動隊員的積極性了的。

其實PM的核心在於想法，在於溝通，在於防微杜漸，在於保證進度，在於確保團隊的方向，在於協調領導和使用者需求。在於決策下一步該怎麼走？走的好不好？在於觀察隊員們的戰鬥力，時不時給他們打打氣，給他們聊聊天，看看他們的問題，看看他們的需求，第一時間解決。

而這次的PM充其量就是苦力，就是苦力鼓勵機，PM用自己的時間和熱情想鼓勵大家，其實這樣的鼓勵是不持久的，是短暫的。

而事實證明也是這樣的，即時現在我再苦力，在用心，他們的激情並沒有很好的被調動，甚至現在的隊員有時一動不動。

如果重新開始，PM會選擇做好使用者調查，提供更多簡潔的設計，果斷做些決策，加強PM的影響力和感染力。

分析每個隊員的特點，並針對每個隊員進行疏通，進行交流。

6. 總結

其實我們的軟體不是一個完整的軟體，是一個在學術搜尋平台上搭建的一個新的應用，沒有獨立性， 很多想法受束，這也可能是我們隊員後期激情不是很高漲的原因，另一個方面是我們的軟體使用者使用人群雖說很明確，但挺少，而且還面臨著這樣一個問題，要得到Host的支援和推廣。

雖說路途有些糾結，但是既然是PM ，我就要站出來，為我們的努力說話，為我們的軟體上線做出更多努力，更多推廣，要讓隊員們看到即使前面的路有些艱難，我們仍會堅定地走下去。