【CodingNoBorder - 03】无际软工队 - 求职岛：功能规格说明书-CSDN博客

本文链接：https://blog.csdn.net/CodingNoBorder/article/details/124286739

无际软工队 - 求职岛：功能规格说明书

项目	内容
这个作业属于哪个课程	2022年北航敏捷软件工程
这个作业的要求在哪里	团队项目-计划阶段要求
我们在这个课程的目标是	熟悉敏捷开发的方法论，并通过实际开发产品进行实践。
这个作业在哪个具体方面帮助我实现目标	熟悉敏捷开发的方法论：学习考量产品功能的思维模式、定义并规范产品功能的方法。通过实际开发产品进行实践：结合开发项目需求，说明用户故事，为项目定义明确的功能规范。：

Author: 无际软工队

Date: 2022.04.18

引言

产品介绍

本团队，针对当前就业形势复杂化、社会企业对毕业生提出越来越多样化需求的现状，意图开发一款聚焦校内科研实习及内推信息聚合的综合求职平台。我们希望聚焦校园细分领域，立足校内特有的资源优势，建立便于双向选择、减少沟通成本和信息流动阻力的一站式实习、求职信息聚合平台，为抱有各种志向——无论是科研还是工作——的同学们提供支持，帮助他们更好地触及走出校园之后的未来。

典型用户与场景

在读本科学生

姓名	王隽
身份	大二，本科在读学生，初步决定了专业方向，但是没有明确的研究方向
使用动机	希望能了解所在学校的实验室及其研究方向，抱着试一试的心态参与实验室工作，从而确定自己的兴趣所在。积累科研经历，丰富个人履历，为将来做准备。并且希望与实验室同学一同参加科研竞赛，力争获奖。
使用场景	搜索和筛选校内实验室信息，关注心仪的实验室近期科研动向，获得与实验室老师、学长学姐沟通和交流的渠道。重点关注可以接收短期实习的实验室。同时，这部分同学对未来会有所迷茫，希望能够获得老师和学长学姐的指引。
用户痛点	对相关领域虽然有所初探，但终究了解尚浅，希望老师或学长学姐能从更加专业的角度去分析相关领域的前景和发展状况，这些往往不是实验室网站上简短的项目介绍所能完成的。同时，即将步入人生的重要选择阶段，需要考虑升学或就业问题，希望能直白地和老师交流相关意向。
用户偏好	希望能对某一领域的实验室与项目信息有深入了解，并希望能和老师或学长学姐直观交流升学规划。
付费接受程度	学生群体付费意愿低，且对于信息的计费较为不易
用户比例	50%

姓名	朱韵
身份	大四，本科应届生，有一定技术能力，想要利用应届生身份毕业找个工作。
使用动机	希望能够了解和自己处境相近的同学的面试经验；联系到本校学长学姐这类相对更可靠的信息源；获得知识与技术水平相近同学简历撰写的经验和技巧；整合并方便检索本校学长学姐发布的各种内推机会。
使用场景	搜索和了解企业招聘信息，获得与手握内推机会的学长学姐沟通和交流的渠道，关注与自身技能相适应的职业机会。
用户痛点	手握技能，但欠缺发挥的渠道和通路。招聘信息琳琅满目，无从下手。即将步入社会的他们迫切需要得到前辈的经验和机会，以免在茫茫求职之海中迷失方向。同时，他们也需要成体系地展示自身能力的方法。
用户偏好	获得求职方面的技能支持，希望得到针对性更强的求职经验与更可靠的内推机会。
付费接受程度	由于先一步迈出象牙塔，需要面对比在校学生更多样的挑战，愿意接受用金钱换取经历和支持。
用户比例	30%

握有内推资源的已就业毕业生

姓名	金凡
身份	在企业团队中担任一定职位，有内推资格，有一定内推指标需要完成。
使用动机	希望能从相关专业的同学中为企业输送有能力的同学进行实习。
使用场景	为特定技术团队挖掘高校人才。
用户痛点	内推的窗口时间长而时效性要求不高。目前主要招收渠道是通过高校群，高校群里的通知消息时效性强但是持续性差，因此需要长期定期地发通知；高效群聊翻阅内推消息太麻烦了；只希望招收特定院校且和自己有一定关联的同学，不希望招收范围过于广泛；公司内部会有关于内推的竞争，因此希望能招到的同学越多越好；总是有海投党或是来白嫖简历修改建议的同学。
用户偏好	能够招收到和自己有一定联系的高校同学；相关招收通知能够具有尽可能长的持久性；能够发布实习通知和相关工作描述；能够在一定程度上提前筛选掉申请意愿不真实的同学。
付费接受程度	不大喜欢付费；但是如果公司内部有相关内推补贴，会考虑分一部分支付给平台。
用户比例	10%

高校实验室导师

姓名	高森
身份	实验室导师，独立带领一个研究团队，同时进行不同课题的研究，在学院内担任某课程讲师。
使用动机	希望能展示实验室的研究方向与课题，吸引感兴趣的同学，积累团队后继力量；新的课题带来新的需求，与当前研究团队的技术栈有一定差异，需要招收有特定技术能力的同学来辅助工作；行政上有竞赛需求，需要召集能力突出的同学组成团队代表学院参与竞赛。
使用场景	展示实验室研究方向和现有课题；长期招收对研究方向感兴趣的实习生；有新的技术需求时招收有特殊技术能力的同学；发布竞赛指导与招收通知。
用户痛点	实验室现有的主页访问量很低，而且平台老旧，信息更新起来很麻烦，亟需新的更有效的展示平台；招收需求基本只能通过导员和同学转发到学生群聊中，效率低而且留存时间短；不了解同学们情况，导致实际招收的很多同学由于考研或工作不能长期参与；不知道同学的科研经历，导致招收到在多个实验室之间反复横跳的同学。
用户偏好	能够展示实验室的研究方向与课题，且很方便编辑与修改；能够轻松地发布招收需求并设置门槛要求，并及时传播开来；能够了解同学们的具体情况，包括技术栈、项目经历、科研经历等基础信息，以及是否需要准备考研、是否已有实习、是否出国深造等详细信息；能够与报名的同学进行一些基础的交流。
付费接受程度	如果能够持续提供高质量的生源，愿意长期付费使用。
用户比例	10%

产品功能设计

产品的主要功能可以被划分为三大模块：

个人控制台：个人信息管理，查看已申请/发布信息等
- 对企业管理员和实验室导师，可以在此修改团队信息与介绍
主功能页：主要功能页面，支持发布者/求职者的角色切换
- 对发布者：发布与管理招聘信息、管理候选人
- 对求职者：设置求职取向，查看推荐，对招聘信息进行筛选与搜索
通知与消息页：申请结果通知、发布者与求职者消息交流、其他系统通知等

个人控制台

个人控制台是每个用户的私人管理空间，主要负责个人信息的编辑以及相对应团体的信息编辑，还集成了对个人申请与发布历史的查询功能。

个人信息：每个用户均可编辑自己的信息
- 个人基础信息：头像、姓名、年龄、所在院校、自我介绍
- 展示信息：项目经历、科研经历、教育经历、专业技能
- 隐私信息：联系电话、邮箱
- 求职生类似：
  - 基本信息：头像、姓名、年龄、性别、所在城市、联系电话、邮箱
  - 教育经历：学校、专业、学历、在校时间、GPA、排名、成绩排名、主修课程
  - 经历：团队名称、时间（开始与结束）、描述文本
    - 企业实习
    - 科研实习
    - 社团与组织
  - 获奖经历：获奖名称、获奖时间
团队信息：当用户被指定为团队管理员时，可在个人控制台修改团队的展示信息：
- 团队基础信息：LOGO、名称、所属院校、团队简介、团队管理员
- 团队招收信息：当前团队已发布的招聘信息页面入口
已申请职位：对求职者而言，查看现已申请的职位
- 查看申请职位的通过状态，点击可直接跳转至主功能界面的招聘信息展示页
已收藏职位：对求职者而言，查看现已收藏的职位
已发布职位：对发布者而言，直接跳转至主功能页面的招聘信息发布页
设置：查看与设置个人的账号信息，管理通知设置，查看隐私协议等

主功能页

主功能页是大部分业务功能的根节点，主要负责承载招聘信息发布、招聘信息管理、招聘信息查询、招聘信息展示等功能。

由于同时存在两种用户，因此需要支持用户一键切换，以下对不同角色场景下的功能进行介绍。

对求职者：
- 职位推荐：
  - 根据求职者设定的求职意向进行职位推荐
- 职位查询：
  - 可以根据院校名称、实验室名称、企业名称、岗位名称等进行搜索
  - 提供过滤功能:
    - 是否仅搜索职位/科研
    - 是否长期招收
    - 是否针对技术能力设限
    - 是否针对特定院校设限
    - 是否针对特定专业设限
- 求职意向设置：设置个人的求职意向，分为院校科研与企业岗位两类
  - 院校科研：专业方向、所属院校、是否长期参与
  - 企业岗位：职位、所在地区、所属行业
- 招聘信息展示：查看特定职位的招聘信息
  - 职位信息
    - 基本信息：职位名称、所属团体名称、工作地点、发布时间、职位介绍
    - 门槛要求：技能要求、长期招收、针对特定院校
    - 关键词标签
    - 职位对应于一个课题
  - 交互按钮
    - 投递申请按钮：求职者点击后自动发送求职申请
    - 咨询沟通按钮：打开私聊消息窗口，向发布者咨询具体情况
    - 收藏按钮：收藏该条招聘信息到收藏夹，可在个人控制台查看
对招聘者：
- 招聘信息发布
  - 发布招聘信息需要通过招聘身份认证
    - 身份认证流程包括：
      1. 认证者填写身份信息与联系方式，上传自证信息
      2. 团队身份认证请求被发送给团队管理员
      3. 团队管理员核实认证者身份后通过其身份认证申请
      4. 认证者获准以该团队名义发布招聘信息
  - 从发布者已受认证的团队列表中选择一个团队作为招聘信息的发布主体
  - 填写职位名称、工作地点、职位介绍、简历投递的目标邮箱等基础信息
  - 设置技能要求、设置是否长期招收、设置是否针对特定院校、设置是否针对特定专业
- 招聘信息管理
  - 支持对已经发布的招聘信息进行修改
  - 支持对已经发布的招聘信息进行撤销
    - 撤销前将进行再次确认
    - 撤销后将向所有投递过简历但未通过的求职者以及已收藏该招聘信息的求职者发布通知，已通过的求职者则不受影响
  - 支持查看每条招聘信息目前已收到的候选人列表
    - 可从列表中点击进入候选人主页，并查看被候选人授权查看的内容
    - 可从列表中直接点击候选人进行私聊，进入消息窗口进行简单交流。
      - 该私聊消息窗口对应于当前职位实例，即由（发布者、申请者、职位）三元组决定

通知与消息

通知与消息页主要展示系统通知和私聊消息

通知主要为系统通知，系统通知主要包括：

当有新的系统全服通知
对求职者，当有新职位申请通过
对团队管理员，当有新的认证请求
对招聘发布者，当有新的求职者向已发布的职位投递申请

消息主要为发布者与求职者构建沟通桥梁，每条消息由（发布者、申请者、职位）三元组决定，整体形式类似于闲鱼的买卖窗口，包含双方互发的消息和系统插入的流程通知。

文字消息：双方互发的消息
流程通知：系统根据当前双方就当前岗位达成的操作插入提示卡片，比如‘’申请已通过/拒绝‘’、“检测到可疑信息，请注意个人隐私保护”等

功能阶段划分及计划

结合具体的课程要求，团队将上一节中涉及的产品功能进行 $\alpha$ 阶段与 $\beta$ 阶段的划分，并各自设定任务计划。

由于每次任务划分均会单列文档描述，此处列出各阶段的分工说明：

$\alpha$ 阶段的分工说明：【CodingNoBorder - 05】无际软工队 - 求职岛：Alpha 阶段初始任务分配

$\beta$ 阶段的分工说明：【CodingNoBorder - 11】无际软工队 - 求职岛：Beta 阶段初始任务分配

产品期望

用户活跃度的定义

作为一款面向全体北航学生与北航实验室的 专用软件 ，我们在用户量上一定存在客观的上限。

一种合理的评判我们的应用是否成功的方式可以定义为 所有用户查看招聘条目的数量之和（称为摘要访问量），和 所有用户点击招聘条目详情页的次数之和 （称为详情访问量）。为了达成这个目标，我们既需要良好的内容量，又需要向用户宣传到位，同时还要保证应用界面的美观和方便使用。

产品的预期用户量

我们希望在Alpha阶段可以达到总的摘要访问量能达到1000人·次，详情访问量达到100人·次。

在Beta阶段持续增加访问量，希望摘要访问量可以达到5000人·次，详情访问量达到500人·次。

潜在的问题与对策

系统容载量问题

关于本部分内容，请参考我们团队的技术规格说明书。

信息鉴别与防滥用

本平台为防止滥用，保证平台的信息真实性，设计了完备的身份认证机制。

对于 C 端，我们采用校园邮箱认证、学生卡等信息提交认证的方式验证求职者的校园身份，采用工作邮箱、工作证、入驻团体邀请码等方式验证招聘者的工作身份。

对于 B 端，团队内部对企业方、实验室方的接入准备了完善的预案和流程，同时依靠联运方北航职协提供公共关系方面的支援。

用户信息存储及保护

本团队，通过与北航职协的合作运营，获得了用户隐私权方面的法务支持，能够解决法律方面的疑虑。