2022-BUAA-SE 第二次作业-CSDN动态微社区及app分析

2022-BUAA-SE 第二次作业-CSDN动态微社区及app分析

项目 内容
这个作业属于哪个课程 2022春季软件工程（罗杰 任健）
这个作业属于哪个课程 个人作业-软件案例分析
我在这个课程的目标是 了解并提高自己对软件工程的认识和实践能力
这个作业在哪个具体方面帮助我实现目标 通过分析现有的成熟软件，能够看到其闪光点，然后找出不足并结合软工知识进行分析和剖析，锻炼自己对于软件工程项目的管理能力。

目录

作为一个开发新手以及计算机系同学，我在学习生活常常会遇到这样那样的技术问题，由于问题的复杂性，常常出现自己无法handle的问题，此时就要依靠强大的互联网来解决我的问题。在刚开始网上求解的过程中，我最常用的方法无疑是复制粘贴报错信息，输入网址栏，使用浏览器的默认搜索引擎进行搜索。在中文互联网的语境下，大多数报错经验讨论还是出现在CSDN上。CSDN作为体量交大的中文技术交流平台，它取得的成就令人敬佩，但它本身也存在相当多的弊端，为人诟病。同时，随着自媒体时代的到来，微信公众号已经成为人们日常生活中各种信息的来源，其中也不乏各种科技咨询以及学术讨论。谁会成为未来的趋势呢？答案并不明了。所以我选择选取CSDNapp社区以及微信公众号进行分析。

课程作业要求聚焦分析csdn app动态部分，但是那一部分其实像只是一个带陌生人的朋友圈，本身没什么东西，你只能漫无目的的刷新，然后获取别人的想法，我觉得和知乎的想法功能很像，是一个思维碰撞发碎碎念的地方。所以我就只能把整个app一起分析了。

调研评测

使用截图

使用截图看下方截图就好啦，绝对超过3天）

软件bug

(以下bug结果均在iphone13 IOS15.3.1版本环境下测试得到)

其中issue#1~#7都为CSDN app非动态功能的bug，issue#7~#9为动态功能的bug

issue#1 部分页面刷新数据黑屏延迟bug

  • 可复现性：必然发生
  • 复现步骤：
    • 1.打开csdn app
    • 2.导航栏中选择首页
    • 3.选择首页中的”问答“栏
    • 4.上拉刷新，黑屏加载，无法操作1秒左右
    • 5.数据加载完毕可以操作
    • ps:以上情形完全适用于导航栏中”商城“选项的内容加载。
  • Bug具体情况描述
    • 如题，不再赘述
    • csdn -refresh
  • Bug分析
    • 可能成因
      • 数据库查询优化冗余，导致查询速度太慢，同时没有做好过渡动画填充。
    • 严重性
      • 系统功能和安全性上，其实无。
      • 用户体验上，用户表示每次刷新一下需要被黑屏一下真受不了。。。
    • 预期以及改进建议
      • 学习知乎/leetcode如下
      • zhihu-refresh

issue#2 商城搜索UI bug

  • 可复现性：必然发生
  • 复现步骤:
    • 1.打开商城
    • 2.点击搜索
    • 3.点击搜索栏
    • 4.欣赏bug
  • Bug具体情况描述
    • 如下图，搜索栏会出现莫名ui重复bug
    • csdn-serach-ui
  • Bug分析
    • 可能成因
      • 没啥分析的，就是UI设计的锅...没有测试吗？
    • 严重性
      • 一个只有用户受伤的世界达成啦！用户表示这商城不太想用。
    • 预期以及改进建议
      • 不求花里胡哨，但求不要出丑。

issue#3 商城购物车UI bug

  • 可复现性：必然发生
  • 复现步骤:
    • 1.前往CSDN商城
    • 2.选择一件商品
    • 3.将它加入购物车
    • 4.打开购物车
    • 5.先体验第一个bug
      • 当商品数量为1时，左边减号是灰色，代表不可用
      • 右边加号是黑色，我们可以添加购物数量
      • 最大数量限制为100
      • 当数量为100时加号仍显示黑色，但点击无效
    • 6.再体验第二个bug
      • 点击右上角编辑
      • 选择删除商品
      • 无论删除后是否还剩余商品，此时你都会发现左上角的后退按钮无了
  • Bug具体情况描述
    • 见上，下配动图
    • csdn-cart
  • Bug分析
    • 可能成因
      • UI design's pot
    • 严重性
      • 用户体验继续--
    • 预期以及改进建议
      • 简单修复上述问题就行了。

issue#4 csdn指数压力测试

  • 可复现性：偶尔发生 （2/500）
  • 复现步骤
  • Bug具体情况描述
    • 在查询csdn指数时，偶尔会出现关键词正确，以前也能查到，但本次查询失败的现象。
    • csdn-index-pressure-test
  • Bug分析
    • 可能成因
      • 可能是查询实现的效率问题，因为csdn指数这个地方实现有点坑爹，见issue#6
    • 严重性
      • 系统功能上，结果并不严重，但是反映出的系统设计问题应该得到重视。到底是开发时埋下的雷还是系统设计时的tradeoff，需要团队决定。
      • 安全性上个人不太了解，我认为与安全性无关。
      • 用户体验上，其实还行，因为没人会这么疯狂的切换，除了测试开发工程师）
    • 预期以及改进建议
      • 见issue#6

issue#5 csdn指数第五个关键字可以为空

  • 可复现性：必然发生
  • 复现步骤：
    • 1.不断添加csdn指数的关键字
    • 2.当添加4个以后，第五个关键字在选择时展开备选栏，但是不选，直接点确定。
  • Bug具体情况描述
    • 会出现”空查询“
    • csdn-index-5para
  • Bug分析
    • 可能成因
      • 这个确定键设计的有问题，应该是选择完关键词后再出现
    • 严重性
      • 系统功能上，无所谓，因为所谓关键词都是预设好的，不支持模糊搜索，所以根本搜不到为空的结果
      • 安全性上，查询空可能会导致系统崩溃，看后端实现细节了。
      • 用户体验上，只会进一步降低用户对于csdn app的印象。
    • 预期以及改进建议
      • 预期：把确定键设置到展开后再出现，因为提前出现的确定键其实也点不了。

issue#6 csdn指数 回退

  • 可复现性：必然发生
  • 复现步骤：
    • 1.查询csdn指数。
    • 2.查询一定次数后，使用返回键返回。
  • Bug具体情况描述
    • 为了退出csdn指数部分而做出的返回操作，是用户查询csdn指数前后两次关键词不同的次数。
    • 当然，如果左滑或者点回退操作右侧的”ד都是可以直接返回的。
    • csdn-index-backward
  • Bug分析
    • 可能成因
      • 每次查询可能都新开了一个新的事件，导致回退的时候需要一个一个事件的回退。
    • 严重性
      • 系统功能上，因为系统提供了右滑退出，开发者也提供了点”ד推出，所以影响不大，可以正常使用。
      • 安全性上，由于上述对于其实现的猜想，如果用户由于好奇在该页面查询过多次而没有退出，会不会造成用户设备的过量内存消耗；同时，如果大规模用户都在使用这个功能，会不会导致系统负载过大。
      • 用户体验上，使用起来可以，能用，但是会感觉软件设计不是很优雅，尤其是第一次用会感到很奇怪。
    • 预期以及改进建议
      • 因为前后两次不同的查询之间并没有逻辑上的关系，为什么不设计的使得用户点一下就可以成功回退呢？每次查询显然不是”新开了一个页面“这样子。

issue#7 删除动态后，显示动态数未改变

  • 可复现性：必然发生
  • 复现步骤
    • 1.点击动态中自己的头像
    • 2.查看自己的动态个数
    • 3.从动态中任意选择一个进行删除
    • 4.删除后可以发现，动态个数并没有改变
    • 5.等待半小时以上，仍没有改变
  • Bug具体情况描述
    • 如Bug名所言，在删除个人的动态后，个人信息界面的动态个数并没有改变。
    • 显示有9个，实际上我已经删的只剩2个了，而且超过半小时以上没有改变
  • Bug分析
    • Bug可能成因
      • 不懂，我们显示这些个数字都是直接调后端api传过来的。也许是为了性能考虑，这边搞成了定时更新吧。也不排除是系统有其他严重bug导致了。
    • Bug严重性
      • 系统功能
        • 如果开发者就是按"成因"所述那样考虑了性能，那么其实功能算完善。
      • 安全性
        • 如果开发者就是按"成因"所述那样考虑了性能，那么安全性也算完善。
      • 用户体验
        • 用户体验--，没有即时更新，以为你这软件没人维护呢...
        • 用户会问这么些个问题：为什么其他平台有即使更新的数字？为什么平台没有捏？是技术水平的问题吗？那么他们提供的其他服务质量是否与这个平台的质量相关呢？
    • Bug预期以及改进建议
      • 建议排查然后改成即时更新的。

issue#8 社区点赞通知重复出现

  • 可复现性：必然发生
  • 复现步骤：
    • 1.选择一条你曾发出的动态
    • 2.对该动态点赞
    • 3.退回个人消息界面
    • 4.点击“赞与评论”
    • 5.发现接收到自己的点赞/评论消息
    • 6.再次返回该动态
    • 7.取消该动态的赞
    • 8.再次点击赞
    • 9.退回“赞与评论”
    • 10.发现在原消息历史保存的情况下，又新增了一条自己的点赞/评论消息
  • Bug具体情况描述
    • 如issue名所言，在收到点赞消息时，新增消息未区分别人的点赞和自己的点赞，同时对于反复取消和点赞的情形没有做处理，导致用户消息栈可能存在大量冗余，占用空间的同时可能导致意外错误。
    • 找到点赞的动态image-20220314160849073
    • 取消赞image-20220314160856869
    • 恢复赞image-20220314160922269
    • 查看收到的消息image-20220314160930441
  • Bug分析
    • 成因分析
      • 个人认为是开发人员没有在点赞消息通知中对点赞的取消做相应处理。同时没有区分自己的点赞评论与他人的点赞评论。
        • 当用户点击取消点赞时，后台应当依据用户id和其操作的动态的id去指定的数据库中删除这个点赞记录。
        • 点赞消息通知应该是引用的点赞记录中的数据，并根据点赞时间字段进行排序，而后展示在app端。
        • 但是也许点赞消息被缓存在了服务器数据库的另一张表中（不在用户端的缓存，笔者尝试过清楚客户端内存，但消息并未消失）。故对点赞记录的删除并没有删除历史记录。
        • 实际上，可以理解开发者的想法：在点赞消息中记录所有的点赞历史。但是这种呈现方式是否过于凌乱？只显示了点赞记录，让使用者看起来很迷惑。我的预期和建议请看下方。
    • 严重性分析
      • 系统功能上，由于系统是一定要记录用户的操作过程的，即使删除了数据，删除记录也会以一定形式存在系统日志中。这部分历史记录消耗的数据库空间总体来说影响不大。
      • 安全性上讲，其实也没啥大问题，我的理解是开了一个新存储空间存储操作记录。不过不排除意外存下了这么些东西的可能，造成不必要的安全隐患。
      • 用户体验上，反正我打开时是感觉挺震撼的，反复点赞的通知居然成了自己一直为自己点赞...要么也显示取消（有点冗余？取消还通知一下，是不是有点尴尬）。累积的消息多了，就很难分辨谁的点赞是有效的，谁的又是无效的了。
    • 预期以及改进建议
      • 我认为新浪微博的做法就很讨喜。
      • 新浪微博处理点赞评论通知就是在他人点赞后为你更新这个消息，同时当他人取消后就移除这个消息，就当什么也没发生。
      • 其实作为社交技术交流平台...没必要给用户那么详细的操作记录。除非是像飞书一样的办公平台，会记录详细的“已读”“未读”等消息用于提高工作效率。

issue#9 发表动态后，动态进行审核前会先短暂出现在广场

  • 可复现性：必然发生

  • 复现步骤：

    • 1.动态右上角点击加号，发布动态
    • 2.随意输入内容，随意选择标签（随意是指不影响结果）
    • 3.发布动态
    • 4.发布动态后页面会返回到广场，此时你可以看到自己刚发表的动态
    • 5.但刷新一下后，动态消失
    • 6.点击“我的”，可以看到动态处于“审核中”

  • Bug具体情况描述

    • 如题，不再赘述

    • 发布瞬间，未审核的动态会出现在广场

    • image-20220314170302143

    • 刷新后，未审核动态出现在“我的“中

    image-20220314170308882

  • Bug分析

    • Bug可能成因
      • 因为这种列表都是从数据库中请求以后然后展示在前端的，所以只能说是发布后未审核的数据满足了广场的”筛选要求“并出现在了用户界面，再次刷新后，也许服务器才对表中的未审查数据进行处理，然后得到了被审查后的结果。
    • Bug的严重性
      • 系统功能和安全性上都不确定，因为不知道他们具体怎么实现的。所以不知道这种未审查的动态是否可以被他人看到（因为广场是随机展示的，而且整个微社区中没有动态检索功能，所以无法验证猜想）
      • 用户体验上，也许会让用户感到很迷惑吧。细节处处有问题，让人不太舒服。
    • Bug的预期以及改进建议
      • 建议更改数据库查询方式/新动态加入数据库表方式，保证未审查的动态的安全性。

  • 功能评测

    • 系统功能主要有博客、热榜、消息系统、动态系统以及个人信息系统。

    • app整体内容粗糙

      app导航栏把app分为了首页、商城、动态、消息、我的这五部分。

      首页的内容还挺不错的，有热榜、讨论、学习等。但是商城就很粗糙，看起来像是赶工出来的，和大学三学生的大作业一个风格，UI设计频频出现bug。动态类似一个低配版的朋友圈，只能刷着看看玩，不能指望它解决问题。消息就是正常的消息列表。我的里面除了个人信息，还塞了很多内容，我基本上每个都体验了，觉得功能多而粗糙。技能树限定在C JAVA PYTHON这仨语言左右，csdn指数搜索也有bug，而且是关键词完全匹配，错一个字搜索结果都是0。整体给人的感觉是背弃了博客的本身，在app中塞了大量奇怪的成分。

    • 内容容量大

      要说你去百度搜任何一个关于计算机科学的问题，那么csdn大概率会给你一个像样的答案。如果连csdn都没有相关的话题，那么只能说是中国这个方面就不太领先，比如硬件设计、芯片等话题。这为许多急于解决问题的同学带来了很方便的使用体验。

    • 内容水平较为日常

      如果CSDN app要作为IT学生的学习工作社交平台的话，他需要具有一定的优质内容创作者。但是从目前来看其实很吸引人的优质内容创作者相较于知乎、博客园来说并不是特别多。在动态中能看到的是每个像我一样的普通人在分享和记录自己的学习生活。相较于知乎很常见的论文解读、b站的跟李沐学ai以及国外大学网课视频、博客园的技术文档来讲还是显得有些青涩稚嫩。除此以外，微信公众号的许多创作者、咨询分享者如量子位、机器之心、差评以及各种CS期刊解读都以其持续的更新以及专题的讲解获得了更多的创作者以及读者。

    • 目标不明确

      如果课程要求调研的是csdn的动态功能的话，那么这个功能完全不具有解决问题的能力。因为这个动态并不支持搜索功能。只有关注一栏的博文和动态可以至少说是”范围索引“，如果你想解决某个迫在眉睫的问题，那么我建议你直接去首页搜，这个社区只是一个发发感想，分享生活和观点的”朋友圈“。

    • 代码阅读不便

      作为一个技术交流平台，代码交流是必要且频繁的，但是CSDN app对于代码块阅读的支持做的并不是很好，既没有单独的移动端阅读代码模式，也不适应手机横屏。那么请问用户如何手机app上阅读代码呢？竖屏那么窄，实际上看起来很难受。

      csdn-blog

      我把leetcode以及微信公众号对于代码块的支持放上来，对比一下就知道了。

      • 微信

        wechat-blog

      • leetcode：

        leetcode-blog

结论

  • 定性：不推荐

  • 定量:

    • 类别 描述 评分 （满分 10 分, 良好 6 分, 及格 4 分，聊胜于无 1 分, 很差 -3 分）
      功能 核心功能 博客，基数大，历史久，实用但同质化严重、内容质量层次不齐 6
      细节 有什么为用户考虑的细节? 有热搜、博文等功能，动态可以转发，看到更多人的动态。 4
      用户体验 当用户完成功能时，不干扰用户 (例如: 是否不断弹出不相关广告)。 有时候会把你需要的内容加上vip，诱导你充钱&充vip，但是其实那些资源在别的地方是免费的，知识付费当然合理，只是资源的质量和水平用户都无法提前了解，有很多付费下载下来是垃圾文件的例子 -3
      辅助功能 一些辅助功能如皮肤等 可以设置字体等 4
      差异化功能 这个软件独特的功能. 它对用户的吸引力有多大? 唯一独特功能：遇到技术问题时，可以快速大致了解问题（但不一定可以完全解决） 浅度解决问题能力强 10
      软件的效能 占用内存, 启动速度, 内存泄漏情况 不够流畅，根据分析应该有内存泄露 4
      体验 软件的适应性 在联网/断网, 大小屏幕, 没有鼠标的情况下都可以顺畅操作. 和不同平台的软件能流畅协作 4
      成长性 记住用户的选择, 适应用户的特点，用户越用越方便 我不做评价，因为我把所有应用的超范围的隐私权限全关了... 6
      用户有控制权 系统状态有反馈，等待时间要合适。关键操作有确认提示，有明确的错误信息。 让用户方便地从错误中恢复工作, 快捷操作键可调整。 博客功能倒还好，倒是新开发的动态、各种答题、技能书、csdn指数之类的，完全没有确认选项，甚至删除动态都是一个标，点击也不会高亮，只是删掉。 -3
      自选 商业模式 国际著名的技术交流平台StackOverflow的商业模式是为群组开辟具有隐私性的问题群组，但所有问题交流都是免费，我觉得是良性发展。CSDN目前火急火燎的要用户从网页端向app端迁移，用户端则把商城、”精品课程“等放在显眼位置，开发的细节也不太好，很难说是中文互联网的环境决定了商业模式还是csdn主动拥抱了这种互联网模式，但是我还是不太喜欢这种浮躁的商业模式。 -3

分析

使用此服务的所有功能，估计这个软件/网站/服务做到这个程度大约需要多少时间(团队人数6人左右，计算机大学毕业生，并有专业UI支持)。

  • 我们假定csdn已经有了雏形和模式，我们只用开发app。
  • 这个app的ui模板可以找到，6人分工的话，根据我安卓开发的水平，三天可以完成app的设计。再过四天并前后端的实现。后续三四天开始对接，测试相关功能，功能补全，发布一个较完整的产品总流程大概两周到三周左右。、
  • 当然，如果要在用户体量很大的情况下，根据用户反馈的bug持续维护优化以及扩大服务器的处理量的话，就需要经年累月的技术实践，这样就不好说了，我自己没有相关体验。但我估计要持续好几个月甚至一年。

分析这个软件目前的优劣(和类似软件相比)，这个产品的质量在同类产品中估计名列第几？

csdn app主要包含的标签：问答、博客、资源、课程、刷题。下面以这五类分别排名

  • 问答
    • 1.知乎：优质创作者多，学术前沿大牛多，高校学生和程序员多。
    • 2.牛客：程序员就业网站第一。咨询以及帖子多。
    • 3.csdn：博客内容基数大，搜索能获得的结果较多，也可以看作问答）
  • 博客
    • 1.博客园：内容丰富，积累深厚，质量稍微比csdn高一点
    • 2.csdn：内容范围广，但同质化严重，同时用户基数大
    • 3.简书：教程多，但用户相对较少，影响了内容
  • 资源
    • 1.百度网盘：还是除了小众网站以外的资源宝库
    • 2.csdn：资源很多，但不乏垃圾文件，资源收费
    • 3.百度文库等圈钱一众文库
  • 课程
    • 1.github：github上有最原汁原味的世界一流大学的课程以及作业
    • 2.bilibili：有不那么丰富的中英文课程资源以及视频教程
    • 3.中国大学慕课：有国内较为官方的课程资源以及学习班
  • 刷题
    • 1.leetcode：程序员求职必备最火网站，题库经典，社区建设良好（比赛、问答、交流、学习规划）
    • 2.csdn：配套很多博客资源讲解题目，近水楼台先得月，可以系统学习
    • 3.牛客：面向求职，高频面试题，但是有点八股

从各方面的问题，推理出这个软件团队在软件工程方面可以提高的一个重要方面(具体建议)

  • 做好测试和alpha阶段测试，不然一个release的版本怎么会有这么多不合理的地方。

你在第一部分发现的bug，为何软件团队不能在发布前修复？他们是不知道，还是有意不修复？你觉得是什么原因？

  • 我认为是项目经理往往是催着上线新功能新项目，过于急促导致没有做好测试。因为你可以看到眼花缭乱的功能，但是每一项都没有自己的特色，而且很多地方都能找出那么一点点小瑕疵，应该不至于对于ui界面也有意不修复吧。

建议和规划

市场概况

  • 首先市场有多大？
    • 根据国家统计局的数据，2018年我国企业总数量为1278.9万台，假定一台电脑对应0.8个程序员（科学研究、信息技术大概占了总计算机数的80%）。每年的应届毕业生又在千万级别，其中最终转码的学生我们给一个系数大概在20%吧（计算机相关专业一般占15%人数，但还有一些同学最终也会从事信息技术行业）。我们根据平均的研究生升学率 35%再划分一下本科生和研究生，认为本科生学制4年，研究生2.5年。假定每年毕业学生人数不变，这些年来互联网公司的计算机数量900万台，忽略其他群体，那么总的受众人数在(1000×0.2×4 + 1000×0.35×0.2×2.5 + 1300×0.8) = 2015万人。
  • 其次直接的用户有多少？潜在的用户又有多少？
    • 技术交流平台最直接的用户应该是学生，因为职业程序员会有公司内网的论坛以及同事，这些技术论坛大概率不是其解决问题的首选。而高级的研究生、博士生参与技术交流平台搜索的时间少，大部分应该是进行期刊论文的阅读，只有牵扯到技术实现时才可能到论坛搜索具体的低级技术。直接用户应该是大部分的学生（0.8）以及相当一部分(0.6)的程序员，即1560万人。
    • 潜在的用户包括很多非计算机系专业同时可能毕业了才萌生转码想法的同学、一些其他行业想了解信息产业发展咨询的人、一些想使用计算机技术先进生产力的技术、管理人员。这部分可以按1%计算吧，因为主要是调研人员，保守估计100万左右。

市场现状

  • 目前市场上有什么样的产品了？

    • 知乎、微信公众号、思否、掘金社区、牛客、力扣等

  • 上述产品的定位、优势与劣势在哪里？

    • 定位有求职类（力扣、牛客），技术解决类（死否、掘金、csdn）以及技术研讨科普类（知乎、微信公众号、bilibili）。
    • 求职类的主要和一线大厂合作，提供面试笔试指导，为求职做准备，但其实不是提升自己的最好办法。
    • 技术解决类都focus on具体的问题，同时更新blog记录问题，能促进人的习惯养成以及发展，但内容水平层次不齐。
    • 技术研讨类要么注重科普，将具体的问题和资讯以通俗易懂的形式传播，要么以文章的形式研读文论、讨论关于一个学术热点的看法，两者受众都有限。

  • 上述产品之间呈现什么样的关系，哪些为竞品关系？以及竞争中的各方态势如何？

    • 主要呈现竞争、共赢的关系
    • 除了csdn 思否以及掘金社区属于竞品关系以外，其他的产品要么是表面竞争实际共赢（牛客、力扣），要么是很随性包容。
    • 掘金社区和思否异军突起，但是大部分份额还是在csdn手中。

  • 市场与产品生态

    • 这个产品的核心用户群是什么样的人？典型用户是什么样的？学历，年龄，专业，爱好，收入，表面需求，潜在需求都是什么？
      • 核心用户群：学生，程序员、开发者、低级学术研究者、学历高、年龄较年前、计算机专业、爱好写代码、收入高、表面需求是解决问题，实际需求是寻求个人技能的提高，谋求更好的发展。
    • 产品的用户群体之间是否存在一定的关系？是否有利用其相互作用二次构成特定用户生态的可能性？
      • 用户群体可以简单分为内容创造者以及受众。类似于明星与粉丝，但这种关系并不确定，因为大家都是有想法的人，今天你的想法吸引了他，明天说不定你也提出一个巧妙的解决问题的思路，大家相互学习，将优质的内容留在平台，这样就有了用户粘性。没错，我说的就是知乎和bilibili。
    • 产品的子产品，以及其他相关产品之间是否存在一定的关系？是否有利用各个产品特性之间的相互关系二次构成产品生态的可能性？
      • 有关系啦，csdn就利用博客资源，在练习题的答疑上使用了博客资源，很方便，形成了一定的生态，博客系统也为用户的动态和消息提供了基石。大家需要想法的碰撞，那么动态也就应运而生。但是，但是我觉得还是不要无序扩张，搞很多功能，又做得同质、不理想让用户觉得很难受。

产品规划

  • 你要在当前软件的基础上设计什么样的新功能？为何要做这个功能，而不是其他功能？为什么用户会用你的产品/功能？你的创新在哪里？可以用NABCD分析。

    • 不要有新功能了，我会先把现在的用户体验差的地方都修了再谈大规模的新功能。
    • 如果已经修好了bug。我可能会更新技能树，并且把技能树的更新权限开放给有资质的开发者、创作者，而不是指望着平台本身的开发者去开发这些技能树。看到现有的技能树很局限固化只能等着平台来搞其实挺离谱的。为什么用户会用我的产品？因为它免费、开源，由创作者更新经验教训，由读者来评判好坏，它会是有用的。我的创新就是尝试给用户以修改技能树的权限，打造出一个良性循环的技能树机制。
    • NABCD
      • Need
        • 针对当前市面上技能树没有活力，比如csdn的，虽然叶子节点都是由相关blog组成，但是其根节点往往都是固定的，缺乏活力。
        • 我们想要建立一个能够保障技能树及时更新的管理系统，方便用户提交技能树的新建、增加节点等的请求，从而对技能树做一个更新操作，配以优美的ui，适应技术的发展和广大开发者需要。
        • 上面提到目前学生群体的人数很大，对于技能树的需求也相当可观。
      • Approach
        • 将用户从app端接口发送的指定格式的请求先发送到平台人工审查合理性。
        • 审批后发送到后台检测技能树是否有冲突（相似节点、同名节点、同名根）。
        • 如果没有冲突，则新建一个索引结构，将它连接到父节点，根据用户建议以及系统建议将一定标签下的blog经检测分配到叶子节点。
      • Benefit
        • 实现了用户与平台的协同合作，更好的满足了用户的需求，同时实现了技能树的更新
      • Competitors
        • 市面上没有见到平台有做技能树的（除了csdn），其他的技能树大多是帖子里创作者根据自己见解和经验总结而成，不如csdn这样集成资源。
      • Delivery
        • 技能树的构建是基于csdn已有的模式(具体技能->叶子节点->csdn上的典型博客)推广而来的，不是白手起家做的。

  • 如果你是项目经理，可以招聘6个人，并且有4个月的时间，你认为应该如何配置角色(开发，测试，美工等等) 才能在第16周如期发布软件的改进版本，并取得预想中的成绩。

    • 技能树的话，难点就是开发范式的构建。遵循什么样的规则集才能让这棵树完整的生长？所以我会放两个学术性的人才去研究这些理论性的问题，给出一些规则性的需求。选择一位美工去设计这颗树的外观。另外三人都负责开发，最后测试时由提出规则的人带着开发者一起测试。因为4个月挺短的，所以可能就是在现有版本上开发，现有技能树也使用了博客资源作为树的节点，故我们只是想把这个树的生长做一个及时审批更新&安全性检查的管理系统。

  • 请为你的团队设计16个周期每周的详细规划。

    周数 任务
    1 需求分析
    2 业务逻辑确定
    3 相关知识学习
    4 确定第一版页面设计、后端设计
    5 alpha阶段开发（侧重搭建系统的架构）
    6 alpha阶段开发（侧重实现系统的具体功能）
    7 alpha阶段进度汇总、提出新的想法和改进、单元测试、开始内部使用
    8 beta阶段开发（侧重实现新提出的功能）
    9 beta阶段开发（侧重稳定版本，舍弃不必要的功能确保稳定性）
    10 beta阶段进度汇总、ab阶段对比分析变动、邀请目标群体使用
    11 用户使用反馈收集与回复
    12 将反馈以重要程度分类，首先维护重要的功能
    13 将反馈以重要程度分类，首先维护重要的功能
    14 集成测试、维护
    15 压力测试、维护
    16 正式上线
posted @ 2022-03-14 23:47  WuhuAirforce  阅读(247)  评论(2)    收藏  举报