第一部分 調研，評測
評測：
軟體的bug，功能評測，黑箱測試
- 下載下傳并使用，描述最簡單直覺的個人第一次上手體驗。
下載下傳華為軟體開發雲APP(ios端)，打開華為軟體開發雲APP後，個人感覺登入界面的風格是簡約範的。先進行注冊，注冊好之後登陸，輸入賬号密碼，卻提示"請輸入有效的使用者名和密碼"...難道是一大早還沒睡醒?輸錯了？再來一次，還是不行..原來所謂的賬号并不是手機号碼...而是賬戶名，有點尬（個人感覺這裡應該提示輸入的賬号是使用者名）。來到主界面，界面風格依舊簡單清晰，點選了底部的導航欄按鈕，大緻可以了解了這款APP的主要功能。話不多說，先建一個項目體驗一把，點選建立的工程項目，可建立需求工作項，任務工作項，缺陷工作項。對于一個新人團隊開發一個項目，從需求分析到具體實作，都可在APP列出工作項，可用性還是挺強的。可将團隊成員都加入項目，但是得先掃二維碼，後輸入使用者名進行添加。用着用着，發現了這款軟體的一些bug（下文會提到）。第一次上手體驗這款APP，滿意度可以打75分吧（百分制）。
- bug定義
軟體的Bug，狹義概念是指軟體程式的漏洞或缺陷，廣義概念除此之外還包括測試工程師或使用者所發現和提出的軟體可改進的細節、或與需求文檔存在差異的功能實作等。（摘自百度百科）
- APP bug
- 點選待辦事項的分享功能，軟體無端閃退，停止運作，直接退回到桌面
軟體産品案例分析 - 對于工作項詳情的評論，一旦發送将無法修改，删除和撤回，而删除隻能将整個工作項删除。
軟體産品案例分析 - 當多個項目有同名的工作項時，在待辦功能中關鍵字搜尋同名工作項，搜尋結果隻會顯示包含關鍵字工作項的标題，并不會顯示該工作項所屬項目。使用者隻能通過逐個點選工作項去找到目标項目下的工作項。
軟體産品案例分析 - 在我的功能裡有一個區域功能，可選擇（東北區1/華北區1/華東區2），在添加項目成員時，若區域不相同則無法添加，修改更換成相同區域之後，才能添加。但區域使用者可随意修改，而不是靠定位功能，該功能實用性比較差。
軟體産品案例分析 - 在工作項詳情裡，有一個可配置設定子產品的功能， 點選子產品，顯示"目前項目下沒有子產品"。但是該APP并沒有将工程分成多子產品的功能。
軟體産品案例分析 軟體産品案例分析
- 你覺得為什麼這個産品組的人沒有發現這些bug?
- 可能是産品組人員對于軟體功能還未開發完全，比如區域選擇功能，應該是功能還未做完全
- 測試人員測試不夠完全
- 開發人員考慮不周
- 假設你們團隊需要開發這套系統，需要注意哪些方面(架構、部署運維、微服務等)。
- 可采用微服務架構，将原本單一的應用按照功能邊界分解成一系列獨立、專注的微服務。每個微服務對應傳統應用中的一個元件，但是可以獨立編譯、部署和擴充。
- 部署：部署程式包，功能開關，配置管理 運維：集中化日志，集中化監控
- 微服務開發:每個服務都該有自己的代碼庫。這樣可確定簽出規模盡可能小，源代碼控制日志更簡潔，并能對通路進行更細化的控制。
采訪：
- 介紹采訪對象的背景和需求（他們有沒有用過這個APP或類似的APP，除了現有的功能還有别的需求麼）
采訪對象：大三計算機專業學生 需求：開發一個小項目，用APP記錄需求分析和具體實作的任務卡，團隊成員之間可直接通過APP進行溝通交流
采訪對象在項目開發算是萌新一枚，之前并未使用過類似APP
- 讓采訪對象使用華為軟體開發雲（請上傳照片證明使用者的确正在使用，遠端采訪的同學請讓别人幫忙照相）
軟體産品案例分析 - 描述使用者使用這個産品的過程, 使用者的問題解決了麼？軟體在資料量/界面/功能/準确度上各有什麼優缺點？使用者體驗方面有問題麼？
使用者的需求為：用APP記錄需求分析和具體實作的任務卡，團隊成員之間可直接通過APP進行溝通交流。在記錄項目需求和任務的功能上，APP基本可滿足使用者的需求。但在溝通交流的需求上，使用者的體驗不是很好，團隊成員間隻能通過在工作項詳情下評論進行交流，交流起來不友善。
| 軟體方面 | 優點 | 缺點 |
| ------------- |:-------------:| :-----:|
| 資料量 | 可顯示的資料量可滿足需求量 | 工作項詳情加載速度不是很快(需要5-6秒) |
| 界面 | 簡約清晰 | 界面可以美化加工一下 |
| 功能 | 功能點命名可做到見其名知其用，簡單易上手 | 有些功能未實作完全(如項目可子產品化)，部分功能存在bug（點選閃退） |
| 準确度 | 資料顯示準确 | --- |
- 使用者對産品有什麼改進意見？
- 工作項詳情加載速度可以提速
- 将未實作完全的功能實作完全(如項目可子產品化)
- 修複bug（運作閃退）
- 結論：經過這麼多工作，你一定有充分的理由給這個軟體下一個評價,請選擇一個結論:
非常不推薦
不推薦
一般(★)
推薦
非常推薦
第二部分 分析
- 使用此軟體的大部分功能，聯系第二部分的分析，估計這個項目做到這個程度大約需要多少時間（團隊人數6人左右，計算機大學畢業生，并有專業UI 支援）。
4周時間。1人負責前端界面設計，1人負責後端伺服器維護，3人負責前後端資料互動，1人進行軟體測試。
- 分析這個軟體目前的優劣（和類似軟體相比），
- 優勢：簡單可用，容易上手，界面簡約清晰
- 劣勢：部分功能未實作完全，部分功能bug比較大
- 推理出團隊在軟體工程方面可以提高的一個重要部分（具體建議）。
軟體功能的完善性是至關重要的，半成品的功能隻會讓使用者體驗變差，對于半成品的功能，甯可沒有
- 功能邏輯框圖
軟體産品案例分析 - 子產品分析
軟體産品案例分析 - 多元度評分
| 次元 | 分數（百分制） | | ------------- |:-------------:| | 使用者體驗 | 80 | | UI界面美觀度 | 75 | | 核心功能 | 77 |
第三部分 建議和規劃
- 如果你是項目經理，如何提高進而在競争中勝出？
- UI界面美化，使用者對于軟體的最初的直覺感受就是界面的美觀程度
- 功能的完善性，對于半成品的功能，甯可沒有
- 主打功能要近乎完美，可能的話去實作創新功能
- 加大宣傳推廣力度
-
目前市場上有什麼樣的産品了？
teambition
軟體産品案例分析 -
你要設計什麼樣的功能？
項目群聊功能
- 為何要做這個功能，而不是其他功能？
項目成員之間溝通交流，可通過群聊功能進行。
選擇這個功能原因是：項目開發過程，成員間溝通交流是無可或缺的。而這款APP目前已完成的功能：成員隻能在某一工作項詳情下評論來進行溝通交流。這樣的溝通交流不順暢，不便利，有必要在這方面進行内容的增加。
- 為什麼使用者會用你的産品/功能？
實用性是使用者選擇産品的關鍵因素。将主打功能項目子產品和待辦工作項子產品做到極緻，積攢口碑，加以适當的宣傳，以此來增加使用者量。
- 你的創新在哪裡？可以用 NABCD 分析。
- N（Need，需求） 使用者使用軟體開發雲APP，團隊成員間想直接使用APP進行項目進度回報，項目問題回報，進行項目溝通交流
- A（Approach，做法）在APP目前已完成的功能增加群聊功能，項目成員間可加入群聊，進行項目溝通交流。群聊功能不僅僅隻有聊天功能，還支援檔案上傳共享。檔案格式多樣化（支援doc，pdf，xlsx，mp4,，jpg等多種常用檔案）
- B（Benefit，好處） 若團隊成員無法進行面對面交流會議，使用者可使用群聊功能進行溝通聯系。檔案可直接上傳群内，團隊成員可共享。
- C（Competition，競争）群聊功能不僅僅隻有聊天功能，還支援檔案上傳共享。檔案格式多樣化可在競争中更具有優勢。
- D（Delivery，推廣） 廣告投放，微信朋友圈宣傳等等。
- 如果你來上司這個團隊，會有什麼不一樣？
- 站在使用者的角度考慮問題，深入挖掘使用者需求
- 協調好各個成員間的任務權重，提高工作效率
- 管理好軟體的具體功能的生命周期
- 深入了解每個成員開發進度，確定項目保持功能/時間/資源的合理平衡
-
如果你的團隊有5個人, 4個月的時間，你作為項目經理，應該如何配置角色（開發，測試，美工等等）？
描述你的團隊在16 周期間每周都要做什麼，才能在第16周如期釋出軟體，大小裡程碑績點設定。
1人負責前端界面設計界面美化，1人負責後端伺服器維護和測試，3人負責前後端資料互動
|周數 | 任務 |
| ------------- |:-------------:|
| 1 | 需求擷取，市場調研，使用者調研|
| 2 | 需求分析，撰寫規格說明書 |
| 3-11 | 具體編碼，UI和資料庫同步設計，前後端互動|
| 12 | 測試人員進行測試形成測試報告，修複bug |
| 13 | 市場部分投放，接收記錄使用者回報 |
| 14-15 | 整理使用者回報，改進功能，修複bug |
| 16 | 正式釋出 |
- 項目釋出後，有沒有考慮過項目該怎麼部署才能滿足需求。依據下圖（某校教務處系統的部署）作為參考，分析16周後你所完成的項目上線需要哪些配套裝置(伺服器、帶寬、資料庫需求數量與配置) 。
例子中校教務處系統的部署，校教務處通路量最多的時候應該是學期選課和期末成績查詢。後端伺服器得負載起最大通路量。某校的教務處的使用者量大約在幾萬量級左右。
華為軟體開發雲伺服器的通路量應該不會出現通路量波動範圍大的情況，每天的通路量應該比較平均。估計使用者量的最大可能為萬量級。
- 後端伺服器配置 8核16G*2
- 應用伺服器 4核8G*2
- 關系型資料庫：SqlServer/MySQL/Oracle 數量3（讀寫分離2，備份*1）
- 緩存資料庫：Redis 數量 ： 2
- 網站安全性 : WAF