zoukankan      html  css  js  c++  java
  • # 团队选题报告

    组长博客地址:点击这里

    选题报告内容

    本组评审表设计

    pingshen_preview




    NABCD 分析引用



    NEED 需求

    用户群体

    • 主要针对人群:福州大学的广大师生群体以及食堂各个店铺

    • 用户数量:根据130人的初步调查有8成受访者有此需求,则师生用户量大致在万人级别,而福大食堂商铺符合产品要求的大致有50-60家

    需求分类:

    用户群体 需求
    师生群体 - 面对琳琅满目的食堂菜品需要更低的决策成本来快速决定“这顿吃什么”的选择恐惧症
    - 需要一个准确的福大美食地图了解食堂热门店铺
    食堂店铺 需要一个有效的渠道获取食客的口味分布、以及饮食流行趋势



    APPROACH 途径

    • 基于安卓平台开发应用,当用户需要决策帮助时,应用会请用户做3-4道简单的布尔选择题,之后将结果发送到后端服务器,进行结果预测

    • 后端服务器基于php laravel框架进行开发,项目组中成员咨询过一些学长也是使用同款框架进行开发,在后期开发过程如果遇到问题,可以获得更直接的帮助与指导

    • 根据用户数据分析出针对性的用户口味分析报告帮助各个店铺改善菜品口味,提升客流量

    • 我们立足于本校进行项目开发,可以非常方便的与用户和商铺进行沟通,进而快速迭代产品



    BENIFIT 好处

    收益群体 好处
    学生/老师等一般用户: - 减少每天去食堂时犹豫吃什么的决策时间与机会成本
    - 轻松获悉福大食堂的热门店铺与菜式
    商铺: - 根据由我们提供的用户分析报告,商家可以针对报告内容进行菜品改良,使得出品更加符合大众口味,借此提升客流量并提高应收水平



    COMPETITORS 竞争



    • 主要竞争对手对比:
    比较 大众点评 这顿吃啥(微信小程序)
    应用截图



    优势 - 搜罗的餐饮信息丰富多样;
    - 有多样的筛选方式;
    - 有较多的用户创作内容。
    - 交互逻辑简单;
    - 只提供一个随机建议,减少用户决策成本。
    劣势 - 界面有效信息太多,分散用户注意力;
    - 用户需要继续操作才能进一步决策。
    - 只是推荐出一个菜名,没有更具深度的使用场景;
    - 用户完全无法对推荐结果进行干预,能否符合口味全凭运气。



    • 我们的优势在于:
      • 定位精准:定位清晰:我们的产品在一开始的定位就将目标人群设置为在校大学生,将使用场景设定在大学食堂的范围,这让我们目标清晰,需求明确。在软件开发的初始阶段将始终围绕我们的定位快速迭代产品

      • 先发优势:通过初期调查,市场上还没有出现具有统治力的同类产品,这使我们能领先一步抢占市场,为后续长远发展积累用户数据和推广运营经验。

      • 本地化优势:我们的 APP 立足于福大作为项目的发起点,开发团队成员都是
        福大在校生,对学校食堂的情况有切身体会,可以比其他竞争对手更好的进
        行本地化,吸引用户使用。



    DELIVERY 交付&推广

    新媒体推广

    • 宣传视频的制作与传播:通过简明的 MG 动画制作,使得潜在用户迅速了解产品理念与基本使用逻辑,积极与校知名社交平台沟通(如:青春福大),争取使得推广视频获得更多曝光度。

    • H5 页面的制作与传播: 通过制作有趣生动的 H5 页面,使得潜在用户迅速了解产品理念与基本使用逻辑,通过社交网站、社交工具等进行广泛传播

    线下推广

    • 设立官微、官博、官方公众号,周期性进行联动宣传,并与影响力较大的微博号、公众号、新闻站点合作,扩大影响范围。

    • 与校内创新创业平台合作,争取专业的支持和专业的推广渠道。

    • 通过设置“邀请有礼”活动,促使已有用户分享邀请码、分享本产品, 利用用户的人脉关系有效扩大用户群体的规模。

    试用版轻应用

    • 为了解决用户可能不愿意花费过多时间和精力下载陌生的app的推广困境,设计简洁迅速的试用版网页或者微信小程序,通过一个二维码就可以试用产品的主要功能,从而
      降低用户的学习成本,并向我们的 APP 引流。




    个人贡献分衡量准则

    绩效管理主要部分在于团队成员的团队任务贡献度。

    • 当团队成员接受了PM分配的一个团队任务之后,有责任按时按质量交付,否则需要受到一定的绩效上的处罚。
    • PM有能够给予最终评判的权力(超额完成加分、正常完成、未完成或未按质量完成),折算为乘以比例150%,100%,50%。
    • 在团队成员的相互交流时,确定团队的共同目标,鼓励积极的氛围,构建信任和谐的团队。所以,对消极的成员(例如开会迟到、交流时全程划水)的也会有所处罚。
    • 对于有积极为团队做出自己额外贡献(做了很多为未来/团队/他人考虑的贡献,而不仅仅是为当下/自己)的同学,也会有额外的绩效加分。




    团队中个人的贡献比例

    姓名 比例(%)
    王彬 20
    赵畅 15
    李恒达 11
    胡展瑞 16
    王源 11
    佘岳昕 11
    陈志炜 8
    陈文垚 8
    林煌炜 8




    小组现场答辩评分

    • 去掉一个最高分,去掉一个最低分,小组最终得分为80.17分
    组号 组名 打分
    2 拖鞋旅游队 81
    3 彳艮彳亍队 84
    4 火箭少男100 80
    5 起床一起肝活队 73
    6 404 Note Found队 86
    7 第三视角 74
    8 小白吃 76
    9 我头发呢队 86




    现场答辩记录:

    - 沙茶面,麻辣香锅这类自选菜考虑推荐吗?
    - 不考虑自选类商家。
    
    - 把自选商家排除在外的做法会不会损害到了自选商家的利益?
    - 项目初期暂不考虑。(谢谢这位同学的提问,我们需要仔细考虑这一问题)
    
    - 分析报告的内容大概是怎么生成的?
    - 决策模式,后端提示反馈。
    
    - 分析报告对于店家有什么好处?
    - 有助于店家了解福州大学师生的口味分布,帮助他们更好地经营,使得菜品口味更贴合大众需求。
    
    - 是否考虑添加学生评论的功能?
    - 我们希望我们的软件实现我们的最小功能集。而且我们的理念希望我们做出简洁易用的软件,所以初期不考虑添加。
    
    - 店铺拥挤的程度的数据如何采集?
    - 客观观察添加权重。GPS的定位也可以提供辅助。
    
    - 请问像京元这样自选的快餐如何做推荐?
    - 自选商家我们是不考虑的,因为很难维护一个流动的菜单。
    
    - 收集口味反馈,如何代表用户自身的需求?
    - 非随机推荐。
    
    - 柯老师:是否提供食堂平面图?地图、商家高亮、店铺大概的位置、路径是否可以作为后期加入的功能?
    - 考虑整合在福大美食地图里面。
    




    团队提问回答环节




    第二组的提问:

    • 问题1:推荐店家的算法是什么,倘若一个新用户注册后如何了解他的口味?

    • 答:在软件开发初期,我们会积极尝试可能的算法来达到我们对推荐精确度的要求,初步调查后,随机森林、kNN等线性回归算法在我们的考虑范围内, 我们在项目计划书中,以及现场PPT展示中都明确阐述了我们的软件是基于用户使用时对3-4道布尔选择题的选择来衡量用户的口味。

    • 问题2:以商家会员制为盈利模式,通过对商家了解,好像挺多商家对100/月挺不买账的,而且分析报告若是一开始就收费的话,怎样确保购买者对报告的信任,从而去购买你们的报告

    • 答:在产品的初期我们会给商家提供免费试用,来使得商家能对我们所提供的服务有一个可感的认识。

    • 问题3:假使项目在前期取得不错的开展,那后期有想过怎么将扩展产品功能

    • 答:我们的产品的立足点是福州大学,倘若项目后期取得可观的成果,会考虑进一步向大学城范围内各个高校推广。



    第三组的提问:

    • 问题1:请问盈利方式是什么?

    • 答:

      1、商家会员制:食堂的店铺可以通过成为我们的会员,每周获得我们对其菜品的口味提升建议,以及食堂用户口味偏好分析报告并以此提高客流量。

      2、 分析报告购买:我们会定期对后台就餐数据进行分析处理,生成按月、季度、年的不同时间跨度的用户口味分析报告,店铺经营者通过该报告可以客观获悉福州大学各食堂店铺的热度变化,并对接下去的经营策略做出及时调整。

    • 问题2:如果要扩大受众范围的难度大吗?

    • 答:目前未知,但未来是值得期待的。

    • 问题3:怎么保证推荐算法在推荐上保证满足用户需求?

    • 答:我们力求让用户做出简单的选择就可以得出最终的推荐,因此我们会在设计题目、对菜品进行合理分类上下功夫,力求推荐算法实现尽可能高的客观准确性。



    第四组的提问:

    • 问题1:演讲时时间把握问题

    • 答:感谢您的建议,以后会多多注意。

    • 问题2:推荐算法稳定性

    • 答:我们力求让用户做出简单的选择就可以得出最终的推荐,因此我们会在设计题目、对菜品进行合理分类上下功夫,力求推荐算法实现尽可能高的客观准确性。

    • 问题3:模块分割不明显

    • 答:鉴于问题阐述模糊,基于我们目前对自身产品的理解,我们的产品的两个功能相辅相成,且功能的核心思想紧紧围绕产品定位与用户需求,我们对模块划分的清晰程度有相称的自信



    第五组的提问:

    • 问题1:你们的产品应该对菜品的口味很了解,你们打算如何确保正确掌握了菜品的口味呢?

    • 答:感谢您的建议,这个问题在我们的项目初期也进行过深入的讨论,口味易受主观因素影响,每个人的口味都不尽相同,我们在进行菜品量化时将着重于口味衡量的客观性。另一方面,我们的算法并不仅仅基于用户的口味,还会根据用户使用时的时间和所处地点进行综合权衡。

    • 问题2:即食不会推荐自选窗口,那么是不是福大美食地图里面会缺少了自选这一类商家?

    • 答:自选窗口存在每日菜单变动的问题,这一客观局限在未有很好的解决方案前只得战略性放弃。

    • 问题3:套餐的本质无非是各种菜品的组合,那么你们是否有考虑过可以推荐自选窗口的某些菜品的组合呢?

    • 答:自选窗口存在每日菜单变动的问题。举例来说,若推荐了红烧茄子,但自选窗口今天没有做这道菜,这次推荐就是无用的了。



    第六组的提问:

    • 问题1:如何解决大众点评等平台的用户服务条例问题

    • 答:同学你提问的对象提错了,我们不会爬取大众点评的数据。

    • 问题2:如何推荐类似自选搭配的麻辣烫的菜品

    • 答:目前暂未考虑自选搭配的店铺,由用户参与自选搭配的菜品(如:麻辣烫),商家所提供的菜品并不固定,这一客观局限会影响我们推荐算法的稳定性,所以为了更良好的用户体验我们不得不战略放弃部分自选形式的店铺

    • 问题3:如何突显产品竞争优势吸引用户

    • 答:我们的产品在一开始的定位就将目标人群设置为FZU在校大学生,将使用场景设定在大学食堂的范围,目标清晰,需求明确。市面上存在一些类似菜品推荐的小程序或APP,但它们的核心都是随机推荐菜名而没有综合考虑用户需求,也没有结合所在地区的商铺进行本地化。此外现阶段的类大众点评软件的应用理念和操作逻辑基本大同小异,都是根据用户的地理位置给出附近区域的餐厅推荐,但却没有进一步深入达到某一菜品级别的推荐。以上就是我们的软件的竞争优势。



    第七组的提问:

    • 问题1:推荐菜品时是否有给出详细的推荐理由,这部分理由怎么获取?

    • 答:我们的软件是基于用户使用时对3-4道布尔选择题的选择来衡量用户的口味,并以此作为推荐算法的输入,根据用户对于我们给出的问题做出的选择来推荐。

    • 问题2:对于刚注册的新用户,你们要怎么给他们推荐?

    • 答:我们在项目计划书中,以及现场PPT展示中都明确阐述了我们的软件是基于用户使用时对3-4道布尔选择题的选择来衡量用户的口味。

    • 问题3:如果软件给用户推荐的菜品用户不满意是否有备选推荐,怎么保证推荐会在用户的接受范围之内

    • 答:首先,用户可以反馈他对于推荐结果的满意与否,并且我们给出最终的结果会是在一个符合用户选择的前提下进行多方面的权衡,我们会积极调整我们的算法准确性,提高用户的满意程度。



    第八组的提问:

    • 问题1:随机推荐如何反映全校学生的口味偏好?

    • 答:并不是随机推荐。我们的软件是基于用户使用时对3-4道布尔选择题的选择来衡量用户的口味。

    • 问题2:通过何种方式得到用户个人的喜好并进行推荐?

    • 答:我们在项目计划书中,以及现场PPT展示中都明确阐述了我们的软件是基于用户使用时对3-4道布尔选择题的选择来衡量用户的口味。

    • 问题3:推荐的菜品是否会在今日出现?程序推荐和食堂方面的准备如何协调?

    • 答:我们的app针对的是有固定菜单的商家,这在一定程度上避免了第一个问题。程序方面,我们负责收集各个食堂的菜单数据,将其整理归纳,结合推荐算法,完成我们APP的主要功能。



    第九组的提问(暂无):

    • 问题1:

    • 答:

    • 问题2:

    • 答:

    • 问题3:

    • 答:




    项目计划书修改处

    修改一

    before2

    corre2



    修改二

    before

    corre1

  • 相关阅读:
    软件体系架构复习要点
    Operating System on Raspberry Pi 3b
    2019-2020 ICPC North-Western Russia Regional Contest
    2019 ICPC ShenYang Regional Online Contest
    2019 ICPC XuZhou Regional Online Contest
    2019 ICPC NanChang Regional Online Contest
    2019 ICPC NanJing Regional Online Contest
    Codeforces Edu Round 72 (Rated for Div. 2)
    Codeforces Round #583 (Div.1+Div.2)
    AtCoder Beginning Contest 139
  • 原文地址:https://www.cnblogs.com/Huzr/p/9788157.html
Copyright © 2011-2022 走看看