团队项目-选题和需求分析

罗杰 2023-02-23 20:09:06

任务

请各团队阅读教材有关需求规格说明书的部分和本指引，根据选题要求完成团队项目选题，并提交一篇博客分析本团队的选题。

博客要求

请在博客中包含如下内容：

根据 NABCD 模型，写出自己项目的 NABCD；
说明选题意义；
明确写出在哪里发布软件；
估计发布后一周的总用户量（精确到百）、每日活跃用户量等能够反映团队开发的软件被用户使用情况的指标。

选题要求

团队项目，是共同实现想法的过程。从这一点上来考虑，任何灵光一闪都自有其价值。

但是，作为一门课程——而且是侧重方法论的课程，课程组希望同学们能充分利用大约两个月的实践，体验课程内容所涉及的方方面面、最终实现真正可用的产品。因此，对团队选题有如下流程上的要求。同时，也为同学们提供了选题的简单指引。

选题来源

团队项目的选题原则上鼓励大家自行思考并确定，但需经过课程组的审核。

选题指引中将提及既往课程实践中的历史选题，也会虚设一些题目用以讨论。如若选择这些题目，请在迭代创新上有更多考虑，并提供更详细、清晰的实现方案。简单的“复刻”不被接受作为选题。

相同领域、相同目标需求的选题最多可以有两组选择，按照与课题组报备的顺序先到先得。

随时欢迎与助教、老师、同学们一起讨论选题。

时间节点

请团队尽量早地开始考虑选题，尽早决定题目有助于团队获得更多时间完成选题调研、开始下一阶段的任务。

课程第四周课上

提出初步的选题并参与课堂讨论收集反馈。

课程第五周课上

较为详细地介绍选题，需要包括如下内容：

选题
调研和背景
主要功能点和创新
产品分发
实现方法
预期规模
其他：请查阅选题指引，提前思考选题涉及的其他方面。

课程第六周

完成最终的选题确定，在课程博客提交需求分析文档。

选题指引

以下内容，涉及关于选题可以考虑的多个方面。这些方面不一定完全覆盖了选题将对开发实践带来的各种挑战，请大家尽可能地多考虑，为自己的选题负责。

作为一篇指引，让我们来一起设想一个在往年课程中常常被提出、又常常因为欠缺关键创新而被团队们否决的校园应用：校园论坛，探讨可以在哪些方面进行创新来使它满足课程实践的需要。

方便起见，为它取一个暂定的诨名：「Re：从零开始的弱弱校园Forum！」，简称 「Re: Forum」。「Re: Forum」 会经过以下几个方面模拟的思考，有些时候看上去未来广阔、有些时候又显得那么前景暗淡——放轻松！任何选题、或者说产品的构思都会经受各方面考虑的考验，一款优秀的产品来源于对资源的合理配置、对目标的理性预估、以及资源和目标的良性互动所最终达成的平衡。

发现需求和创新

需求的来源

既有需求

团队或许会选择一个已有多数实践的“母题”，选择这样的选题意味着有相当多能活用的经验和想法，但也同样意味着项目的创新空间会被大大限缩——领域内已有相当多优秀的先行者。

在选择这种类型的题目时，团队应该确保对相关行业的生态、已有的竞品有广泛的认知和把握。起源于校园小团队的软件项目如果有挑战既有业态的雄心，就要确保自己能在这场“不对称战争”中具备关键、逆转性的优势。对于团队的创新想法，不妨时时思考：“为什么市场上没有出现此类实践，是否是市场的固有属性或结构性问题从根本上限制了它们的发展？如果‘他们’——握着更多资源的既有团队之后选择了同一实践，我们有哪些资源保证先发的我们可以取得不对称优势？"

我们的 「Re: Forum」 显然是一个既有需求。

“新”的需求

有真正新的需求吗？ 当然有！要相信自己的洞见和创造力——前提是这份洞见足够牢固，即对探讨的需求领域有足够多的了解。

在从一个“新”需求出发时，也请不要选择直接“白手起家”。请相信即便具体需求不同，也一定有可以参照的“他山之石”。例如，选择开发一个音乐人的作品集网站，可以参照 Behance 等主要关注平面设计的社区来从“同为创作者”的角度考虑用户需求和功能点的设计。

创新点或竞争优势

可供创新的方面有很多。在选题时，可以从以下几个方面来组织团队的思考，举例来说明：

独有的技术

支持新想法最直接的做法是：（至少是率先）应用某种独有的技术。

例如，高德地图在22年夏季发布的“防晒导航”功能，基于独有的光影跟踪、阴影覆盖面积计算等技术。这一功能为其带来的声量效益可以参照这篇文章，独有的技术实现最终转化成了实实在在的产品竞争力。

考虑 「Re: Forum」，我们是否可以引入某种自然语言处理算法，实现话题的自动提取和维护？或者引入某种去中心化的计算形式，让我们的弱弱论坛不依靠中心服务器而在校园网内同学们的终端上自动维护、分散运行？又或者引入 VR/AR 技术，建构校园虚拟空间？

独占的资源

如果团队能获得某种独占的资源，那么可以将这种资源转化为竞争力。

例如，来自 2022 年软工课程的实践：「求职岛」，与学校职协合作，对接校内的科研实习资源，设计了基于校友身份验证的会员制的校园实习信息分享平台。平台的用户群体和信息资源均来自封闭的校园内部，从而可以作为产品对比类似求职平台所能具有的独有优势。

考虑 「Re: Forum」，我们是否可以集成更多校内信息，例如接入体育场馆预约信息、空教室信息、课程排课信息等，将这些信息活用来形成校园内部的线上生活社区？

新的形式或方法

对于已有的领域和既存的需求，创新同样可以源于一套为用户设计的新的呈现形式、方法或工作流。

例如，来自 2021 年软工课程的实践：「近取Key」，一款基于记忆宫殿理论的单词记忆应用。

“新”不仅可以来源于为用户做“加法”：提供某种新的方式；同样也可以来源于“减法”：基于某种功能上的限制给用户带来新的体验。

例如，日前在国外爆火的社交媒体应用「BeReal」，通过删除照片的美图功能、每次上传自拍都要求前后摄像头同时拍照、在一天内的随机时间指定两分钟要求用户必须上传一张自拍否则就为用户的个人信息做特殊标记，来达到“减少人们的社交媒体压力”的初衷。这些条条框框看似为用户带来了各种枷锁，实际上却成功地基于稳固自洽的价值观和功能实现达成了“新”方式的输出和病毒性传播。

有加有减、能促进产品的成功。例如，一款跨文化交流软件「Slowly」把用户之间的交流限定为笔谈，并为它加上犹如现实世界中信件的种种设定：一方面，双方的往来信息只能一封封“寄出”、每一次交流会按照双方的现实地理位置来计算一个介乎几小时到十数小时的“送达时间”——这种迟延是一种“减法”、是对数字时代沟通和交流形式的逆反，但能鼓励用户多思考表达方式、促成有效沟通；另一方面，每位用户都有基于自己地理位置来设计的一套“邮票”可以随信附赠、与笔友通过“信件”交换——这种形式上的丰富是“加法”，提升了社交的趣味性，为用户带来更多交流之外的“附加价值”。这一切形式的创新，为产品赢得了较高的用户粘性。

考虑 「Re: Forum」，是否可以基于位置，只在三餐时间、对定位信息在校内食堂的用户开放，打造一款交流信息的“云饭堂”（或者“云图书馆”、“云新主楼搬砖工地”）？

细分领域或需求

在细分领域分析用户痛点，也可以是产品的创新来源。

例如，一款名叫「奶牛快传」的网盘应用，针对网盘工具类用户中只利用网盘进行文件分享的部分需求进行针对性的优化，推出了不限速、但存储量较小而刚好满足多数用户需求的文件分享服务，并通过结合高质量的页面广告设计和优美、用户友好、一致的 UI 呈现形式，来实现用户体验和广告转化带来的盈利之间的平衡。

考虑 「Re: Forum」，是否可以考虑某一类特定的校内交流进行优化？例如瞄准校内竞赛、项目的组队场合等等。

信息差

在因为各类原因不具备某种服务的区域，提供已有的服务，针对这一区域进行特异性的优化、或获取某种资源来保持这种优势，也同样是一种竞争力。

考虑 「Re: Forum」，本校附近友校一直都有校内的前台匿名交流平台，是否可以在本校内提供类似的服务？

需求分析和调研

这部分，请参见《构建之法》第八章的内容。

推荐同学们通过具体的案例访谈形成调研文档，以问卷调查等方式形成数据支撑——无论如何，选题的背景介绍应该有触达对象用户的资料论证其合理性。

实现

团队结构和管理模式

不同团队、不同的选题和功能点的取舍，需求不同的团队结构和管理模式。以下举出几点考虑的方向：

团队决定，「Re: Forum」 应当是一款 WebApp。我们是否可以采用前后端分离的方式开发、又或是采用全栈框架？为了适应开发模式的选择，我们是否需要对已有的小团队再一次细分开发分组？如果考虑前后端分离，这种分组既可以仅仅分到“前端几个人、后端几个人”，也可以进一步细分，例如把前端按照 MVVM 的开发模型分成 UI 设计和视图逻辑开发。

这些取舍需要从团队的特点、个人技能等等各类因素出发。除去开发工作依照技术栈、项目技术选型可以区分之外，很多软件工程需要完成的工作也可以考虑如何组织、分配和协作——例如 2021 年软工课程的美滋滋甜兮兮队所做的轮值 PM 实践等。请依照课程所学的方法论来谨慎考虑这一问题，同时大家也可以参照近年课程各团队的实践来考虑适合自己团队的结构和管理模式——每年课程的团队人数和选题规模要求都是相近的。

技术选型

课程组发布了关于技术选型的指引，请参照相关文档。

软件架构

软件规模、软件应用的特点，需求特定的软件架构。大家可以阅读这本书：《凤凰架构》来拓展相关的知识。

对于选题而言，我们需要确保团队选题的各项功能需求所带来的对于计算、流量、带宽等资源的要求不会超出我们选择、我们能够选择的运行基础设施的范围。

考虑 「Re: Forum」，如果它真的是一款“云饭堂”社交应用，可以预想它在三餐时间会形成较大的潮汐流量，那么比起使用自搭建的带宽恒定、计算资源恒定的云服务器，使用云函数、云数据库等可伸缩的云计算服务或许会是相对更好的考虑；同样，我们还会在三餐时间迎来大量用以确定用户在哪个食堂的定位请求，这些请求会蜂拥而至我们选用的那家倒霉的第三方位置信息服务商，可能需要考虑相关接口的可调用量是否足够。如果 「Re: Forum」 集成了校内信息服务，需要考虑与校园网服务器的接口对接所带来的带宽压力是否能够和双方服务器相匹配。

一个影响到选题和需求指定的最重要的问题是：我们能够投入来获得的资源该如何配置才能满足所有想法的需求？又或者有多少想法我们现有的资源完全无法满足？

合规

在信息化比例已经足够高的当下，以任何形式开展软件服务，都需要考虑合规性的问题。——最基本的合规性的问题，或许是所有团队如果选用国内云服务开展网络服务都应当会面临的域名备案的问题。

再往前一步，如果我们的 「Re: Forum」 在国内公网发布并开展服务，会需要做出对应的举措适应国内对于社交媒体的内容监管政策；如果对接校内的相关信息接口，则可能适用关于大学校园内信息的国家保密政策相关条例；如果我们想把 「Re: Forum」 做成“云饭堂”，那么对用户位置信息的获取必然涉及到隐私权的问题；构思一个校内基于真实身份的前台匿名论坛，则可能需要与学校合作完成对部分信息的管理——考虑产品的合规性，是产品能够健壮运行的重要基础，也往往有助于产品承担它所需要承担的各项社会责任。这些问题始终应当从产品所在的环境、所影响到的范围出发考虑，并且谨慎和周密地寻找方法解决。

获得资源

在考虑选题所需要的资源时，请清晰地评估获取相关资源的难度。

例如，团队需求接入校园网的统一认证平台，那么请先与校园网办公室取得联络了解获得相关权限所需的要求。更隐性地，例如：我们的 「Re: Forum」 要求用户用校园邮箱注册来确保用户来源于校内，那么一定要首先确保团队用于发验证邮件的邮箱不被校内邮件系统退信。

类似这样的隐忧会潜藏在错误的估计中，为项目的进行带来令人措手不及的阻碍。

分发

冷启动问题

应用的分发往往面临这样的窘境：我们需要用户——用户从哪儿来？——用户会因为有其他用户而纷至沓来——那么我们需要用户！

无数次的循环之后我们发现，盼望已久的第一批用户就是无法到来！团队在项目展示前心灰意冷的周末，终于想到了为自己家的七大姑八大姨兄弟姐妹一个个注册账户的方法来达到大家一开始对于产品的期望。

基于用户生成内容的平台——例如我们的 「Re: Forum」——似乎总是面临这样的窘境，也因此在选题审核阶段就会遭到讨人厌的助教们怀疑的目光和冷酷的否定。团队选择这种类型的题目时，应当尽可能地提前考虑分发的“招数”。

以 「Re: Forum」 为例，我们是否可以通过组织一些话题来增加讨论热度？如果是一款聚焦校内组队的交流平台应用，我们是否可以对准当下即将进行某类比赛或活动的时机？如果是我们设想的“云饭堂”，团队成员是否可以牺牲一下用餐的时间，举着二维码在饭点线下分发这个犹如快闪运动一样的想法？

解决冷启动问题的方式，在没有卧薪尝胆长久蛰伏的时间的情况下，自然是“让它人为地热起来”。选择此类题目的团队，请为了你们的产品（当然也为了课程组能够安心地期待你们的项目能够顺利上线、获得成功、并且获取足够的实践和实绩来支撑团队走完课程流程并取得恰当的课程评价）充分地思考相关对策。

时间上的准备

WebApp 的分发或许最为简单：只需要确保产品能够在展示之前获得一个访问链接即可——虽然，能够及时完成时长大约一周、有时则长达半个月的国内域名备案更好。

或许团队会选择以微信小程序的形式分发产品，在这种情形下请注意：获取微信小程序的发布资质需要审核时间、小程序的初版审核时间也需要考虑，总的时长按照经验大约也为一周。同时，小程序的更新也需要预留三天左右的时间，提交紧急审核则大约一天——但不是每次都能获得批准。

如果团队开发桌面应用或安卓移动应用，则分发的难度会略微下降，大部分情况下只需要分发二进制文件/软件包即可。但请注意特定分发途径可能仍然需要提交应用商店审核来覆盖更多用户，例如采用鸿蒙系统的终端等。

对于 iOS 端的分发，则需要更为复杂的流程来进行软件分发。想在 iOS 端分发应用，请注意提前（付费）申请注册 Apple Developer Program。小范围的测试（需要手动添加用户邮箱、并且步骤繁琐，对于一般用户并不友好）无需审核即可上线，公开测试或上线应用商店则需时长数日到一周的审核时间，并且需要遵守 iOS App 审核的各项规定，请预留足够时间。

对于 iOS 端的分发问题欢迎你联系助教 @KumaXX 获得（力所能及的）协助。

产品的可持续性

构思产品时，应当考虑产品的可持续性。

软工课程的老朋友：校内的航空航天概论刷题平台一波波涌现又一波波消失，留下来继续运营的平台少之又少。最多用户的航概题库微信小程序作者，通过广告收入维持了平台的稳定运行、造福一届届校友，又花费心力去持续更新题库，保证了数据始终具有时效性。

对于作为课设的、自己的劳动成果，大家一定希望尽可能地维持其生命周期。航概题库的例子至少指出了两个方面：持续运营所需要的财务上的考虑、内容平台对内容更新维护的需求。事实上，还有项目代码的可传承性、运维管理等等问题值得考虑和解决。假使我们的 「Re: Forum」 真的成为了校内的爆款应用，我们可能会希望在自己毕业后依然能够持续地存在于校园生活。成立或绑定一个社团或者学生组织维护它？接受来自校友的捐款、或者开发一些主题之类的可付费项目、又或者简单粗暴地引入广告、再或者索性与学校商议搬迁至校内免费服务器来维持项目运营的计算资源需求？会不会几届之后这个学校就不再有使用论坛的文化，又该用什么办法来保证我们产品的市场始终不会被其他的社交形式所挤占最后导致产品本身的消亡？——所有这些问题都与产品的生命息息相关，在最初构思时就应纳入考虑。

最后，祝各位有好的选题和开发体验！想法成真！