三個多月過去了，我們軟件開發經歷了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 ，我就要站出來，為我們的努力說話，為我們的軟件上線做出更多努力，更多推廣，要讓隊員們看到即使前面的路有些艱難，我們仍會堅定地走下去。

轉載于:https://www.cnblogs.com/OMG-Team/archive/2011/12/14/2288097.html

總結

以上是生活随笔為你收集整理的沉思录---Windows Phone软件开发Beta版回首的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。