標籤:cap font 線上的 -- strong 任務 自測 出現 等等
一、前言
1、結對者:2015034643032 孔潭活、2015034643023 周宏傑
2、需求分析模型:NABCD 模型
3、原型設計工具:Axure RP 8、墨刀、FSCapture
二、結對過程
三、需求分析1、N(Need,需求):
- 對於高校學生來講,這個問答系統能夠使得新生得到老生和教師的指導,瞭解企業的就業實習資訊、學習大量的經驗,因此可以使得他們成長的高度會遠遠高於原先的成長高度
2、A(Approach,做法):
這個基於移動端的問答平台在校園中能有一個針對大學生高品質垂直交流的知識共用平台,將學生、教師以及企業統一聯絡起來,讓學生能在課堂以外,能夠得到老生和教師的指導,瞭解企業的就業實習資訊、學習大量的經驗,成長的高度會遠遠高於原先的成長高度。當這群新產生長起來,他們又會去給新一屆的新生解惑,新的新生得指導會比之前的新生得到的還要好,新的新產生長起來的高度再一次提高,如此良性迴圈下去,該校會形成自己內部的專屬學習交流圈,協助新生快速適應大學的學習生活,同時也為企業輸送人才鋪下技術基礎和提供了招聘渠道,可以說是開闢了大學課堂以外的學習輔導途徑。
學生註冊登入平台,即可發布校園日常問題和學術問題,查看校園最新資訊。日常問題可以查問校園學習攻略、周邊攻略、比賽詳情、心理調節、人生規劃、就業實習、社團活動等;學術問題可以讓學生探討專業問題,解決學習上的困惑,我們會與校方合作,邀請老師和優秀的師兄師姐進行解答;校園資訊包括最新的比賽通知、校內企業實訓課、校內舉辦的活動等,比賽資源來自於網路上的網站搜尋和校內官網的發布,涵蓋各專業。
3、B(Benefit,好處):
當在讀的高校學生會遇到各種問題,僅僅向網上的百度求助和向身邊的人請教是遠遠不夠的。而這樣一個專門針對高校師生面對的各種問題的問答平台,供高校師生使用,在這個平台上在讀的高校學生可以發表一些日常遇到的問題或者難以獨自解決的問題,平台回答者都是有經驗的師兄或者是老師,能夠及時給提問者帶來優秀的答案。在“校答人”平台上,學生可以掌握一手校園資訊。“校答人”平台上涉及學習、競賽、社團、心理、職業方向與人生規劃以及就業實習等方面,使用者可以通過提問擷取回覆,自己也可以依據自己的能力,充當回答者為他人排憂解難。
4、C(Competitors,競爭):
現在的問答平台正逐漸打破以往免費分享知識的慣性思維,正在轉向提供高品質回答的知識付費,向共用經濟領域進發,知識付費問答平台越來越受人們關注,目前比較有影響力的付費平台有大弓、知乎、分答等等。016年,有知識付費意願的使用者暴漲了3倍,知識付費使用者達到近5000萬人,截止到2017年3月,使用者知識付費可估算的總體經濟規模為100-150億左右。由於各行各業的人數增多,自身身份和職業常見問題的知識需求增加,當前問答平台正在向專業化與行業化過渡發展,比如有餐飲版的“餐答”,職場版的“業問”,醫學版的“來問醫生”,體育版的“映答”,知識分享平台的內容生態還在不斷豐富創新,但目前卻沒有針對大學生高品質垂直交流的知識共用平台。眾所周知,如今大學生是一個非常龐大的群體。
如所示,截止2016年,大學生數量已由15年前的114萬人狂飆至765萬人,該群體之大,讓我們不得不思考著為這個群體定製一些屬於他們青春活力的產品,因此這款基於移動端的問答平台就是在免費與付費的梯度上展開競爭,當然,也可以使用先免費,積累到一定使用者後再考慮收費問題,關鍵在於有付費必定存在免費。
5、D(Delivery,推廣):
原型設計完成後,即可進行開發,並通過相應的廣告平台做相應宣傳與推廣,當然,起步階段為了推廣,可做相應的優惠政策。
四、原型設計
註冊頁面原型
登入頁面原型
首頁原型
校園頁面原型
提問頁面原型
訊息頁面原型
我的頁面原型
五、總結
兵馬未動,糧草先行,或許開發中也可以應用這個道理吧,在時間充足的情況下,多寫這種需求分析與原型設計是很有必要的,然而現實骨感,很多事情是不會以一個人的意志為轉移的,我們現在的目標也不是成為全棧工程師,而是先往一個方向深入學習,而不是這樣所謂的走一個完整項目流程,一個完整的開發流程應該走,但不是這樣走,言盡於此,畢竟已經寫完了......我不是個麻瓜,但在所有的事情過程中,我最大的感受只有合作,我也一直堅信我們應該學會合作,但我們最缺乏的就是合作......
一言難盡,說來話長,想聽的關注公眾號 compassblog ,直接後台聯絡我吧。
六、PSP 表格
|
|
預計耗時(分鐘) |
實際耗時(分鐘) |
Planning |
計劃 |
30 |
30 |
Estimate |
估計這個任務需要多少時間 |
60 |
60 |
Development |
開發 |
120 |
120 |
Analysis |
需求分析 |
20 |
20 |
Design Spec |
產生設計文檔 |
0 |
0 |
Design Review |
設計複審(和同事審核設計文檔) |
0 |
0 |
Coding Standerd |
代碼規範(為目前的開發制定合適的規範) |
0 |
0 |
Design |
具體設計 |
30 |
50 |
Coding |
具體編碼 |
0 |
0 |
Code Review |
代碼複審 |
0 |
0 |
Text |
測試(自測,修改代碼,提交修改) |
0 |
0 |
Reporting |
報告 |
30 |
50 |
Text Report |
測試報告 |
20 |
30 |
Size Measurement |
計算工作量 |
2 |
1 |
Postmortem & Process Improvement Plan |
事後總結,並提出流程改善計劃 |
0 |
0 |
Sum |
合計 |
312 |
361 |
掃描二維碼關注公眾號,瞭解更多
基於移動端的問答系統--需求分析與原型設計