個人作業——軟件評測

這個作業屬於哪個課程	軟件工程
這個作業要求在哪里	個人作業——軟件測評
這個作業的目標	評測分析騰訊即時通信IM，采訪潛在用戶，對於即時通信SDK的建議和規划
作業正文	....
其他參考文獻	....

---

一、調研評測

1.1 評測

針對本次作業我使用了ios端、web端還有微信小程序版本的Demo，同時為了測試的完整性和全面性，我邀請了一位朋友安裝了Android端的Demo，這樣可以在我們的對話使用上發現一些Bug並且可以得到安卓端Demo的一些功能問題。

1. 使用中

• ios端Demo

  

• web端Demo

  

  

• 微信小程序Demo

  

• Android端Demo

  

---

2. 功能性bug

（1）通訊錄好友單向延遲

用戶A添加用戶B的時候若請求通過，正常情況下這樣的雙向好友申請個人信息是會出現在彼此的通訊錄中，而在測試過程中發現，添加好友成功以后被添加的好友的通訊錄中是不會存在發起添加好友請求的好友信息。當用戶B重新搜索用戶A添加的時候出現A的信息界面，與已經成為好友的情況的界面一樣，只有音頻通話按鈕和發送消息按鈕，並無添加按鈕，證明A與B已成為好友。但是B的通訊錄里卻無A。

如下圖，我在17:16分的時候添加了使用安卓Demo的朋友，在我的iosDemo通訊錄中有顯示我的朋友（越），而在安卓Demo上包括微信小程序和App端在通訊錄里都不存在用戶A（我）。

而在十分鍾之后17:26，安卓的Demo通訊錄里才出現了十分鍾前加的好友（用戶A）。證明被添加的好友消息同步延遲。

（2）群消息滯后

當安卓Demo用戶注冊后就被拉入雲通信IM技術交流群3，在我的iosDemo中可以看到安卓用戶的進群通知，而在安卓端卻沒有進群的提示，即消息欄並未出現該群的消息。直到五分鍾才顯示了進群的消息。因為當時沒有反應過來做截圖的證據，所以這里無截圖。

（3）消息已讀延遲

app端的Demo都具有消息已讀和未讀的功能，正常情況下在用戶A給用戶B成功發送消息后，在消息的角標顯示“未讀”，當用戶B點開對話框后“未讀”變成“已讀”，所以若用戶B回復消息，則用戶A消息旁的”未讀“一定變成“已讀”。但是在測試的過程中發現，當我發消息給我的朋友（越）時且得到了回復，“未讀”仍未改變。在過了一段時間之后，“未讀”才變成“已讀”。

（4）不同平台功能不同步

• app端不支持視頻通話

正常情況下同一用戶的聊天工具在微信小程序或是App端都是同步的，即消息同步、通訊錄同步等。並且之間可以相互通信。在測試過程中發現視頻通話只可以是小程序對小程序，在app端的話會顯示[不支持的自定義消息]。同一軟件不同平台功能不匹配的問題是比較嚴重的，無法保證對話雙方的軟件使用途徑，所以很容易錯失一些重要的信息，而且在發生不支持自定義消息的情況下，對話雙方的設備上都沒有顯示具體的原因，撥打視頻的一方仍可以通話等待，只是會一直沒有應答。

• 小程序端不支持修改備注和添加好友

如圖所示，SMG_YUE是原用戶ID，“越”是我在app端設置的備注。備注是標識分辨一個人的重要依據，小程序不支持修改備注的話會導致聊天的盲目性，難以確定聊天對象。這個添加好友作為必備功能，如果小程序不支持的話就會基本阻隔用戶的選擇。

（5）ios端app消息不提醒（安卓端app隨機提醒）

安卓端經過測試，提醒隨機，即有的時候會提醒，有的時候不會。開啟了聲音提醒之后，在接受到消息之后並無聲音提醒和消息欄通知。只有在點開app消息列表之后才可以看到消息未讀的小紅點。而通過對安卓app端的測試發現，在安卓系統中是有提示的。這個功能性bug也是比較嚴重的一個，沒有消息提醒大大降低了平時的溝通效率，也就基本喪失了即時通信軟件的意義。即時通信要求實時的接收發送消息，不提醒就會導致信息的忽略和慢反饋，對於一些緊急的消息來說，這個bug影響較大。

（6）好友信息延遲

用戶換頭像后，其好友不能在通訊錄或聊天界面發現該用戶頭像發生改變。

15:13用戶SMG_YUE更換頭像，在我這端是看不見的。可能過了十幾分鍾在我的界面才看到其頭像改變。

---

3.預測原因

其中添加好友通訊錄單向延遲、群消息延遲和已讀消息延遲的原因可能都是網絡延遲的原因，也有可能是系統內部的運算機制效率比較低的原因。當使用的用戶數量巨大的時候，系統為了同步對話雙方的消息和狀態都需要大量的數據緩存機制，然后經過對比和不斷的更新，實時顯示消息的已讀未讀狀況。假設該Demo的用戶有10萬人，如果做一張中間表保存用戶是否對這些消息已讀未讀的話，就會變成每人只要接收到一條信息中間表立馬產生10萬條記錄。發送的消息越多中間表記錄成倍數增長。所以未讀已讀情況反饋到系統時就已經浪費了較長時間，所以產生延遲現象。

至於ios端的消息不提示bug，可能是ios系統迭代更新太快的原因？好吧我不知道。

1.2 采訪

一、產品

​ 我想做一款具有模擬對話和資源匯總功能的即時聊天app。

以下所說的目標用戶“追星族”指的不是狂熱不顧一切的無腦粉絲形象，而是一群希望與偶像共同進步，產生靈魂上的共鳴，由此被激勵的粉絲，是正能量的影響作用。

（1）主要功能

1. 具有即時聊天的所有基本功能

   可以添加好友，與現實中或者網絡上的真人進行對話。支持群聊、視頻語音通話、收發紅包、個人賬戶錢包等功能。

2. 模擬對話

   可以設定你希望的對話對象。在產品中存有大部分的藝人的資料和圖片，當用戶選擇已有藝人的信息時，可以變成一對一的模擬聊天。系統會根據藝人的愛好習慣來模擬與用戶的對話，在聊天框中的功能選取還有此藝人的語音包，例如點擊“唱歌”，系統則會隨機搜索該藝人的主唱歌曲並發布對話，用戶可點擊收聽。若藝人並無演唱歌曲則對話框中不具備該選項。當系統搜索到已被用戶添加的藝人有新歌發布或者活動行程就會自動向用戶發起對話通知用戶。也可以設置成自己生活中認識的人，或者是已經離自己遠去的家人朋友，這種情況需要填寫這些人的信息（不是身份證號這類的重要保密信息），比如愛好習慣和口頭禪，系統會進行分析從而盡量的進行模仿對話。

3. 資源動態

   該產品具有匯集被添加藝人資源的功能。將一個資源廣場分為五個部分：單曲專區、影視劇專區、版權專區、綜藝專區、動態專區。除了版權專區和動態專區每個專區都匯總了該藝人的大部分作品，匯集在一起方便“追星族”的閱覽。版權專區存放一些我們平台所獲取不到版權的藝人的作品的鏈接合集，通過鏈接用戶可以很快速的進入另一個平台進行觀看。動態專區匯集了藝人各個平台所發布的動態，例如微博、綠洲、instagram等。多數平台搞的用戶手忙腳亂，匯總在一起就更加方便查看。

（二）面向用戶

• who

  追星一族、有想要對話的離自己遠去的想念的家人朋友的人、普通用戶（只進行與朋友的即時聊天的人）

• when

  1. 對於追星一族來說，每天基本都是要登錄該產品進行瀏覽的，除了吃飯睡覺可以說是無時無刻。

  2. 對於有“遺憾想念”的人來說，在夜深人靜的時候，思緒最煩擾傷心的時候就是使用該產品最頻繁時間。

  3. 普通用戶在空閑的時候都有可能使用，也可以在工作學習中向同事同學發起討論對話。

• where

  用戶可以在任何地方使用該產品，只要想發起聊天的時候都可以。

• what

  我的產品是具有模擬對話和資源匯總功能的即時聊天app。

  用戶的期待就是方便自己的追星之旅、得到對於人為遺憾的慰藉、簡潔專注的即時聊天體驗。

• why

  我的產品在市面上還並未發現類似的競品。

  1. 對於追星族來說，在最快的時間內獲取偶像的資源是比較重要的，而藝人的所有資源作品都是分散在不同平台的，這樣的集體整合大大節約了時間提高了效率。並且模擬與自己的偶像聊天可以讓自己獲得從偶像那里來的正能量，拉近了彼此之間的距離，得到對於追星族來說最大的愉悅。
  2. 對於抱有遺憾的人來說，這里就是撫平傷口的療愈基地，可能是有一句話曾經沒有說出口，是離開才懂得珍惜的苦，還有可能是對於已逝之人的留戀，在這里可以得到心理上的慰藉。
  3. 對於不怎么喜歡看朋友圈也不喜歡發動態的人來說，該產品就是世外桃源，簡潔的界面功能方便操作也不會被那些逼着你給他們點贊的人所“脅迫”，更不用為了完成老板發布的任務去發布違心的宣傳動態。

• how

  用戶就是正常注冊登錄使用，支持手機號驗證碼登錄和郵箱登錄。之后可以選擇添加好友或者模擬對象，然后展開聊天。資源廣場也是一鍵直達，容易上手。

（三）NABCD分析

1. Need

一、對產品功能性的需求

1. 即時聊天的基本功能（直接沿用騰訊SDK）
2. 一個智能的對話系統，可以大數據分析被模仿者的說話方式性格習慣
3. 資源整合功能，可以將不同平台的同種資源放在一起
4. 自動搜索同步推送功能，針對某位藝人的實時活動進行更新，推送給訂閱用戶

二、對產品開發過程的需求

1. 與網絡信息接軌，例如使用爬蟲等程序
2. 大數據分析
3. 人工智能話的對話系統（適當考慮語音交互和語音合成）
4. 數據庫的用戶信息存儲和藝人的相關信息存儲，也可再有添加新模擬對象的信息的數據表

三、非功能性需求（服務質量需求）

1. 實時更新資源保證用戶的信息獲取速度
2. 界面的通用性，容易操作
3. 避免即時聊天的發送接收延遲
4. 模擬聊天內容的合理性

四、綜合需求

1. 聊天版塊
2. 資源板塊
3. 個人信息版塊

五、利益相關者的需求

​ 用戶：

1. 資源更新的實時性
2. 產品使用起來快捷方便容易上手
3. 界面美觀簡潔
4. 模擬聊天的真實感

2. Approach

一、微博等資源較多的平台的使用體驗

二、身邊追星族的需求整合

三、對生活中潛在用戶的發現和調研

3. Benefit

一、模擬聊天的新鮮感和愉悅感

二、不用擔心人際關系的緊張感（發不自願的動態或者進行不自願的投票點贊）

三、資源大雜燴的方便性

4. Competitors

一、相對於競品的優勢

1. 模擬聊天智能化
2. 可以由模擬偶像一對一推送自己的作品
3. 不存在動態點贊歡迎程度的虛榮對比感
4. 沒有已讀未讀功能，以免使得不愛回信息之人尷尬，聊天就更自如
5. 被添加藝人的各類資源條理整齊歸類，節省了來回切換各種app的時間
6. 心靈上的安慰是別的產品給不了的

二、界面特點

1. 大眾化的界面，即導航欄加內容框加底部切換按鈕，更容易操作，功能位置剛開始上手也能大致了解
2. 白黑兩種主體顏色可選，主打簡約小清新風格
3. 內容框中可由底部切換按鈕切換為資源廣場、聊天、通訊錄和我的信息。
4. 通訊錄中在頂部會顯示“我的偶像”、“我的XX“按鈕，點擊即可進入模擬好友列表，群聊和黑名單也在頂部顯示。通訊錄中部就是正常的按照好友備注首字母順序排列的好友列表。

5. Delivery

​ 采用網站推廣的形式，多在類似微博、instagram、網易雲音樂等匯集了目標用戶的地方購買廣告位。也可以采用身邊人推薦的方法，試用推廣。

---

二、采訪

此次采訪使用深入面談的用戶調研方法，因為是疫情期間，所以將面談改成了電話的詳談。

Q: 介紹采訪對象的背景和需求

姓名	性別	學歷	年齡	目標用戶種類	需求
趙某	女	現大學第三年在讀	21	有喜歡藝人的普通用戶	匯集各大平台的藝人資源的App

Q: 讓采訪對象使用10-30分鍾體驗騰訊即時通信的demo

Q: 描述用戶使用這個demo的過程, 用戶的問題解決了么？

用戶根據我提供的二維碼下載了安卓app端的Demo和微信小程序端的Demo，並注冊登錄，加我為好友，與我進行平日的聊天測試。這個Demo還是普通的即時聊天軟件，對於這樣的功能，用戶是不存在什么問題的。因為平日里的QQ、微信就已經足夠滿足用戶的聊天需求了。

Q: 軟件在數據量/界面/功能/准確度上各有什么優缺點？用戶體驗方面有問題么？

	優點	缺點
數據量	暫無	暫無
界面	簡約	缺少基本功能的設置界面
功能	沒有朋友圈的功能，可以專注聊天，比較高效；通訊錄設置界面一目了然	app和微信小程序端消息不同步，容易耽誤較緊急的事；缺少消息提醒的不同模式（震動和響鈴）；沒有群聊的介紹和單獨消息提醒設置
准確度	暫無	暫無

用戶體驗方面的問題：微信小程序端每次重新進入都需要登錄，導致時間的浪費，比較繁瑣。聊天內容消息提醒不及時，影響溝通效率。

Q: 介紹你想用這個SDK開發怎樣的產品？

在之前的產品分析中我已經做了描述，並將此口述給了我的用戶。

Q: 用戶對騰訊即時通信的功能有什么改進意見？

1. 安卓端的“我”設置增加消息提示、個人資料設置等和ios端一樣的功能

   在采訪之前我一直都是使用的ios端的Demo，所以不清楚安卓端的功能不一樣的問題。如圖：

   ios端的“我”設置界面：點擊“我”——>“用戶A”——>“個人信息”界面可以有這些功能：

   

   Android端的“我”界面

   安卓端只有這一個設置界面，並不能像ios一樣設置自己的生日、性別、所在地。並且沒有消息提醒的設置方法。

   

2. 增加群聊和好友信息的消息提示的分類

3. 頭像換成可自定義的

4. 聊天增加添加保存表情的功能

5. 去掉已讀未讀功能

6. 解決微信小程序和App端信息、語音、視頻不同步的問題

Q: 用戶對你想開發的產品有哪些意見？

1. 增加投票打榜的專區，可以集合所有藝人有關作品的投票的鏈接。
2. 在藝人的作品下面增加該作品創作時不為人知的部分例如音樂的背后小故事，或者是初衷和原因。
3. 增加“時間點滴”版塊，里面主要放置藝人所說過的一些富有哲理正能量可以激勵到別人的話還有一些做過的暖心事件。
4. 在后期可以以偶像名義在軟件上發起響應號召粉絲們加入公益活動，為社會做出貢獻。

---

三、 結論

對於騰訊即時通信我的評價是一般。有好有壞吧。主要就是以上提到的bug都改完應該會好很多。

---

二、分析

1.工作估計

Q: 使用騰訊即時通信的所有功能，聯系第二部分的分析，估計這個SDK做到這個程度大約需要多少時間？（團隊人數大約6人左右，計算機大學畢業生）

​ 估計要三個月的時間。（參考后面的題目：五個人四個月）

2.分析優劣

和騰訊IM大致功能相似的還有騰訊，網易，環信，容能雲等。

(1) 容能雲

容能雲是廈門容能科技有限公司開發的一款雲通訊Paas服務平台。容能雲即時通訊雲服務SDK有通話服務、短信、流量、紅包、IM服務、音視頻、直播、用戶托管、反垃圾、數據統計這些功能，直接接入一鍵解決問題。容能雲的IM即時通信具有豐富的消息類型、完善的群組管理、資料關系鏈管理、優質的消息推送服務、信息托管服務、音視頻紅包集成，讓APP快速擁有各種即時通訊能力。

對比：下載了容能雲的Demo想為對比做試用，但是在手機號注冊的時候出現了一些問題，如圖：

所以我進入官網瀏覽了一下已有賬號的界面顯示，如圖：

• 騰訊缺點

  相對於容能雲而言，騰訊IM的即時通訊功能就較為精簡。只看界面的話，騰訊雲的界面就稍有遜色，容能雲的排版布局和顏色都比較清新簡潔，使用者的第一印象就比較好。在音視頻方面容能雲支持點對點視頻/一對多視頻/多方視頻會議，對平台跨終端支持，而騰訊IM在app端並不支持視頻通話，這點與騰訊IM相比更加完善健全。騰訊IM沒有紅包即沒有用戶賬戶的錢包功能，需要靠后期編程接入再去實現。騰訊IM在消息推送在ios端並無提示，這也就是之前的bug展示。容能雲比騰訊雲多了一個能力中心板塊，可以支持視頻會議和直播等熱門功能，而騰訊雲的功能較少，只專注於消息的互通。

• 騰訊優勢

  如果這么一對比的話可能騰訊確實處於下風，不過對於黑名單這個功能，騰訊雲是有涉及到的，並且放在了通訊錄的位置，用戶體驗感較好，可以隨時查看黑名單部分。因為有的時候拉黑一個人往往找不到查看的位置，想要再把他“放出來”就有些困難。如果說對比SDK代碼部分的健壯性，那可能有的一比，只不過我這里只測試了現有的Demo部分，所以只從這個直觀呈現上來對比。

(2) 網易雲信

我去官網上找了一下Demo ios版，但是得到了客服拒絕的消息：

退一步，我就去使用了小程序版本的，還好可以免費使用。網易雲信功能也比騰訊要多，是我對比了這三種Demo用戶體驗感最好的一個。

• 騰訊缺點

  網易雲信有討論組和高級群的划分，並且也具備前面騰訊與容能雲對比的黑名單優勢，界面也很好看簡約鮮明。並且還具備我的電腦功能，這對於上班上學的人來說是非常重要的功能，從手機傳輸數據到電腦是很方便的。騰訊的小程序並沒有添加好友的功能，更不用說創建群組的功能和搜索群的功能。網易雲信可以顯示通訊錄的好友狀態，是錦上添花的功能，而騰訊並不能查看好友狀態。最值得誇贊的是網易雲信的隨心所欲更換頭像的功能，騰訊是不能更換自定義的頭像的，而小程序連換頭像都不行。網易雲信的個人信息也有很多項，在查看好友信息的時候也會很明確。

• 騰訊優勢

  網易雲信的小程序端是沒有消息未讀已讀功能的，消息的旁邊不會顯示接收信息。騰訊有已讀未讀顯示，但這個功能還是處於爭議的部分，因為總有大部分人不太希望別人知道自己已讀不回的壞習慣。

3. 提高部分

1. 界面優化

界面決定了用戶對於該軟件的第一印象，相當於整個軟件的門面。可能界面總是被程序員們忽視，覺得界面只是一些技術不行的人所做的邊角料，頂多作為錦上添花而不是雪中送炭。但是我認為，界面雖然不如后端邏輯設計一樣重要但也是不可或缺的。如果有一個軟件的界面做的不好，大多數人往往會選擇另一個功能相似的產品，而這時候后端的處理功能再怎么強大也不重要了。好的用戶體驗感就來自於清新整潔的界面，讓人有舒適的感覺，從而延長對於軟件的使用時間。就好比很多人總喜歡買一些好看而沒有實際作用的東西來實現心里的愉悅。

在前面我對比了兩個與騰訊即時通信相似的Demo，體驗感都勝過騰訊。而導致我更喜歡更願意把測試的時間花在另外兩個“配角”的身上。不怎么吸引人的界面加上略有些卡頓延遲的bug那真的算是事故現場了。

具體建議：除非有着過人的設計天賦，界面還是設計成用戶都熟悉的排版布局比較好。一是用戶熟知容易上手，二是避免五花八門喧賓奪主。常見的app布局即為導航欄+內容框+底部選卡。在規則的布局中加一點獨特的“小巧思”，例如導航欄選卡的圖標，可以根據不同的軟件風格來設計。顏色方面切忌跳色和多色，最好帶有主題顏色，像騰訊這樣的默認顏色白灰是不可取的。界面上的按鈕可以設計成動畫的形式，即按照用戶的實際操作手勢來制定相應的圖標變化，是最簡單的智能化。

2. 功能種類

功能的實現是不必過多強調的部分，因為每個項目的開發過程已經被突出慣了。所以功能的種類選取是需要提高的部分。功能不是越多越好，一個軟件的功能都是依附於這個軟件。而不常使用到的功能往往浪費了很多的資源和時間。例如之前測試的容能雲Demo，其中有一個直播的功能，但是對於主打即時通信招牌的軟件，直播就不太合適。即時通信主要針對辦公和擁有具體事宜的情況，是多人之間的信息交流，是有來有往的，是可以實時得到反饋的。而直播大多用於娛樂消遣的情況，是一對多的情況，基本不能得到有效的實時反饋，這與即時通信的理念背道而馳。雖說功能多比較方便全面，總有一部分人願意去使用一些額外的功能，但這畢竟是少數，軟件當然是要將自己的主打功能煉精，接着由主打功能做延伸，延伸添加功能的時候受眾是不會變的，使用該軟件的目的也是不改變的，所以要避免過分拓展，造成丟了西瓜撿芝麻的悲劇。

具體建議：勿忘初心，時刻提醒團隊這個軟件開發的本來目的是什么，做好主要的功能之后再考慮研發新功能，開始就是要把一兩種功能做精，做到獨樹一幟金雞獨立，在同類產品中有優勢的時候，有一定忠實用戶的時候再可以根據用戶調研收集用戶想要拓展的功能，再錦上添花，開發同類產品中沒有的功能，吸引更多用戶。每次添加的功能種類不能貪多，一次一兩種就可以了。如果在用戶調研中發現某拓展功能的使用率較低的時候，即可以考慮刪除，減少后期維護的經濟人力時間壓力。

---

三、建議和規划

Q: 如果你是項目經理，如何提高從而在競爭中勝出？

• 提高自己介紹產品的語言表達能力
• 加大推廣力度（必要時可以加大宣傳投資）
• 保證產品的美觀
• 多用戶測評產品不卡頓無bug
• 開發亮點功能

Q: 目前市場上有什么樣的產品了？

• 愛豆聊天器

  根據功能介紹與我們產品的模擬聊天功能基本符合，但是並沒有其余的拓展功能，並且已經下架。

• 叨叨記賬

  叨叨記賬是上海自古紅藍人工智能科技有限公司一款記賬軟件。主打聊天記賬，根據角色設置及記賬場景，觸發不同的對話內容。但是不具有真人即時聊天的功能。

Q: 你要設計什么樣的功能？

• 模擬聊天
• 紅包收發以及賬戶錢包
• 資源整合

Q: 為何要做這個功能，而不是其他功能？

這些功能是市面上的即時聊天產品所不具有的。如果要結合即時聊天的功能的話，擴展模擬聊天功能是比較合適的，並且針對現在市場上對於偶像追尋的需求增多，我想做一個關於整合藝人作品的功能，還可以通過一對一私聊的方式讓需求用戶盡快得知有關新消息。這個追星族的需求是通過我身邊的朋友總結出來的。模擬自己的朋友/親人也是為了緩解目標用戶的悲傷心理。在現今生活節奏越來越快，身體健康都難以保證的情況下人們的心理健康就更容易被忽視，這些積攢的情緒需要一個發泄口，而模擬會話就是一個不打擾身邊人的最優“垃圾桶”和“避風港”。

賬戶錢包的功能我打算是用在給藝人打榜、購買專輯的方向，但是這作為還在考慮中的拓展功能。

Q: 為什么用戶會用你的產品/功能？

1. 界面美觀
2. 市面上沒有存在的競品
3. 案例調研，集成了目標用戶希望的多數功能
4. 得到快樂和安慰和清凈
5. 功能關聯度較高，使用方便，”一頂多“

剩下的在之前已經說的很清楚了，可以去看之前我的競品優勢分析。

Q: 你的創新在哪里？可以用 NABCD 分析。

創新：

• Need

  1. 模擬對話
  2. 資源整合

• Approach

  1. 現有多個功能完備的軟件可以結合參考
  2. 身邊真實案例分析

• Benefit

  可以查看上文產品分析，創新點在多個地方重復了好幾遍。

• Competitors

  可以查看上文產品分析，優勢在多個地方重復了好幾遍。

• Delivery

  目標用戶聚集地做廣告位推廣

Q: 如果你來領導這個團隊，會有什么不一樣？

​ 我作為項目經理會較少參與到實際的編碼中，所以我來說說平時的統籌工作。除了項目有關的正式工作，其余方面都是比較靈活隨意的。我們團隊是可以暢所欲言的，不論是誰對誰或者誰對什么事情方面有一些不滿和問題都可以來找我反饋解決。我們每天的任務安排計划是明確的，只要在規定時間內完成進度就可以放飛自己了。在做完某一個主要功能的時候可以一起出去聚餐（最好可以申請到公費報銷），參不參與都可以。會議不會常開，就算是開會也是類似於討論會的輕松氛圍。會議的召開模式依據於事件的重要緊急程度，當是緊急且重要的事情時，項目中的每個參與者都必須到位，而其余情況不強求事件無關人員必須參與。提案類的活動會給提出建議並被采納的人加以獎勵（獎金或是小禮品），從而提高參與度和積極性。如果發生項目進度拖沓，隊員懶散的情況，嚴懲不貸。該嚴肅的時候嚴肅，其余時間嬉笑打鬧都可以。

Q: 如果你的團隊有5個人, 4個月的時間，你作為項目經理，應該如何配置角色（開發，測試，美工等等）？

​ 需求分析和軟件開發准備階段需要所有人都參與進來，將用時最小化。在正式開發階段，一個人負責Android前端，一個人負責Android后端，一個人負責ios前端，一個人負責ios后端，一個人負責美工UI。在測試階段，可以讓負責Android和ios的人員互換，互相測試彼此的功能，負責美工的人員可以兩種系統兼顧，分別測試使用。后期主要開發的四人可以對於美工的界面設計提出建議和意見，完成最后的修改完善。（如果可以的話，我們只專注於一種系統的開發，就將Android和ios同端負責人合並，即兩個人負責前端，兩個人負責后端。）

Q: 描述你的團隊在周期為16周，每周都要做什么，才能保證在第16周如期發布軟件。

第一周：用戶調查

第二周：產品需求分析

第三周：原型設計

第四到五周：系統結構設計、數據庫設計、接口設計

第六到十二周：前后端同步開發

第十三到十五周：測試

第十六周：發布

Q: 項目發布后，有沒有考慮過項目該怎么部署才能滿足需求？

應用服務器配置：4核8G x 2
后端服務器配置：8核16G x 3
關系型數據庫：MySql數量：3(讀寫分離、備份 x 1）
緩存數據庫：Redis數量 ：2（主備）
網站安全性：WAF,DDOS