【CodingNoBorder - 14】无际软工队 - 求职岛：BETA 阶段项目展示

无际软工队 - 求职岛：BETA 阶段项目展示

项目与团队亮点

疫情下的无际软工

在赛博空间里交流和协作

疫情把团队的大家分隔在各处。从一开始的封校停课转线上导致成员被拦在校外，到取消堂食之后连校内的大家也失去了重要的团队交流地点，再到最后大家各回各家，甚至还有成员被集中隔离——疫情打破并强制性地重塑了 ALPHA 阶段团队业已形成的交流模式，需求每一位成员采取行动应对变化。

在 BETA 阶段，由于缺失面对面的交流机会，为更有效率地进行讨论，避免有默契的沉默、抢话等线上会议的弊病，PM 组织 Scrum Meeting 时进行了更细化的流程安排、梳理发言顺序，主持会议进行。

团队成员进一步密切沟通，将 Scrum 揉进整个开发周期中，拓展交流形式，加强了常时的线上沟通，进一步提高讨论频次，降低信息传递受阻带来的影响。

进度管理：Notion + Github issues

对于开发任务，依照课程组的要求，采用 Github 进行代码管理，结合 Issues 进行任务分配。

本团队在 Git 仓库管理上有明确且有效的规范和实践，已在 ALPHA 阶段进行了展示。

典型用户场景

用户信息	用户情况
姓名	LLLeo
身份	计算机学院学生，大三下，还没找好暑期实习，计划寻找校内实习，但没有想好要找的实习类型。
用户痛点	1. 各大微信群内发布的实习招聘信息过于杂乱，种类太少。 2. 现在有很多求职平台，但是缺少一个汇总校内实习信息的平台，寻找寻找校内实习时无从下手。 3. 可能有多个合适的实习岗位，缺少一个工具对合适的实习信息进行收藏。 4. 缺乏简历编写经历，希望寻找高效的方式投递自己的申请。
预期使用场景	通过「求职岛」高效浏览和搜索现有校内实习岗位，并对适合的实习岗位进行收藏，找到合适的实习岗位后，通过给定的模板进行简历的编写后进行投递，之后等待申请结果。
实现该用户需求的功能	1. 汇总校内实习平台的信息，并支持搜索功能，解决痛点 1 和痛点 2。 2. 支持对实习岗位的收藏和一键查询，解决痛点 3。 3. 支持编写简历并一键投递简历，可以随时查看投递状态和申请结果，解决痛点 4。

用户信息	用户情况
姓名	LLJeo
身份	计算机学院学生，大二下，计划寻找校内实习，确定了一些想进的实验室，但还没有确定去哪个实习岗位。
用户痛点	1. 实验室主页分散，甚至主页上可能缺少有效的实习信息，浏览和检索上耗费大量时间。 2. 无法快速获取每个实验室对应实习岗位的最新信息。 3. 无法对不同实习岗位进行高效对比。
预期使用场景	通过「求职岛」关注对应的实验室团队，高效浏览和搜索关注实验室所推出的实验岗位，比较不同岗位之间的优劣，选定合适的岗位后，通过给定的模板进行简历的编写后进行投递，之后等待申请结果。
实现该用户需求的功能	1. 汇总校内各大实验室的信息，并支持搜索功能，避免在实验室主页上低效检索，解决痛点 1。 2. 支持关注团队，可以一键搜索和查询所关注团队所推出的需求岗位，解决痛点 2 和痛点 3。

用户信息	用户情况
姓名	LJJeo
身份	软件学院学生，大三下，希望寻找开发相关校内外实习工作，技术栈明确，但对找实习相关事宜关注较少，比较迷茫。
用户痛点	1. 市面上的招聘平台信息量过大，对于刚接触实习和工作的本科生来说并不友好，很难挑选合适的岗位。 2. 面向北航学生的实习信息分布较为分散，尤其难以寻找和特定技术栈相关的实习岗位。 3. 针对校内和校外岗位可能要编写不同的简历，缺少一个合适的工具进行版本管理。
预期使用场景	通过「求职岛」选定自己技术栈对应的标签，查看推荐岗位，高效获取有效信息。同时在搜索时添加相应的标签，高效过滤适合自己技术栈的岗位。通过「求职岛」简历版本管理功能实现多份简历的高效编写与管理，并在投递时选择对应的简历，针对不同的岗位展现不同的闪光点。
实现该用户需求的功能	1. 汇总校内外各大岗位信息，并支持通过标签搜索岗位和推荐岗位，高效获取有效信息，解决痛点 1 和痛点 2。 2. 平台具备简历克隆、版本管理能力，解决痛点 3。

用户信息	用户情况
姓名	Chernoff
身份	计算机学院教授，课题比较多，有招聘实习生的需求。
用户痛点	1. 所在实验室主页较为古老，翻新成本过高。 2. 缺乏发布招聘实习生需求的途径。
预期使用场景	通过「求职岛」创建实验室团队，并发布实习生招聘需求，查看投递学生的简历并进行反馈，实现实习生的高效招聘。
实现该用户需求的功能	1. 招聘需求详情页会详细展示实习生岗位的具体信息，团队详情页会详细介绍实验室团队的信息，画面简洁精美，可以很好地吸引相关学生，解决痛点 1。 2. 每个发布的招聘需求都会在广场页上被展示，有效拓宽了发布招聘需求的途径，解决痛点 2。

用户信息	用户情况
姓名	切诺夫
身份	北航职协负责人，正在筹划群面大赛。
用户痛点	1. 需要一个较为正式的平台实现简历编写、浏览需求、简历投递的功能。自行搭建平台成本过高，若无合适平台则只能使用问卷星。 2. 需要一个较为正式的平台实现面试信息的反馈。
预期使用场景	通过「求职岛」举办群面大赛，比赛选手们在小程序上报名并投递简历，相关工作人员收集信息并进行反馈。
实现该用户需求的功能	1. 「求职岛」小程序完美充当了群面大赛所需的「正式平台」，解决痛点 1。 2. 「求职岛」小程序可以将用户们投递的简历收集，提供给相关招聘团队进行反馈，解决痛点 2。

用户信息	用户情况
姓名	Hoeffding
身份	软件学院教授，所在实验室定期招收一定数量的研究生。
用户痛点	1. 以往宣传实验室和招收实习生的方式为，编写实验室说明后发布到各大微信群内，感兴趣的同学可以发送简历到对应邮箱以进行筛选。该方法需要频繁查看邮箱，一旦出现遗漏可能会错过同学们的投递请求，投递方也因为收不到回复而迷茫，双方都没有足够好的体验。 2. 微信群内发布的内容很容易被刷上去，无法吸引足够数量的同学们。
预期使用场景	通过「求职岛」招聘者网页端发布实习生招聘需求，详细查看每个投递请求并给予相应的回复，通过平台强大的一体化功能同时提升求职者和招聘者的体验。
实现该用户需求的功能	1. 「求职岛」招聘者网页端解决了传统的发邮件审核简历方式，实现整个招聘流程的一体化，解决痛点 1。 2. 「求职岛」小程序内的主要内容即为招聘需求信息，不会出现信息被刷上去找不到的情况，此外每个招聘信息都会根据求职者所添加的标签进行推荐，大幅提升了招聘需求的宣传力度，解决痛点 2。

杀手级功能与竞品对比

招聘者端

团队认为，招聘者端的设计目的是：减少平台参与、降低操作成本，实现一套用户自治的系统机制。

在 BETA 阶段的招聘者端设计中，团队对招聘流程进行了针对性的建模，并在此基础上设置机制，通过实现：

• 需求建模与分工细分：提供统一的信息展示模板，降低信息的获取成本；
• 标签系统和推荐：聚合用户与需求的特征以进行推荐，提高信息触达的精准度；避免一过性的信息展示，进一步延长需求的触达周期；
• 申请浏览与追踪：为招聘者与求职者提供有效的初步沟通桥梁。
• 团队建模与邀请码机制：适应校内科研实习的课题组形式，为用户提供更高自由度；基于团队管理平台权限，为实现用户自治创造空间。

功能	求职者 Beta	领英（中国版）招聘端	宣讲会	实习群
招聘需求的发布	✅	✅	✅	✅
简历投递汇总	✅	✅	⛔	⛔
招聘岗位的分工细分	✅	⛔	⛔	⛔
招聘分类发布和展示	✅	✅	⛔	⛔
更长的用户触达周期	✅	✅	⛔	⛔
安全可靠的身份认证	✅	✅	⛔	⛔
针对分工的标签功能	✅	⛔	⛔	⛔
实时反馈投递者	✅	✅	⛔	⛔
可编辑可展示的团队介绍页	✅	⛔	⛔	⛔
每个招聘者可以属于多个团队	✅	⛔	⛔	⛔

求职者端

求职岛主打的特色为提供了校内科研实习信息聚合与定向招收过滤的功能，为校内各类实习机会提供统一的流程和模式，BETA 阶段在此基础上进一步补齐了主流求职类APP所具备的各项功能（标签系统、Offer 推荐、简历版本管理等）并进一步优化体验。如是，求职岛在打出校内实习领域差异化优势的同时，其用户体验亦不逊于市面上主流的求职APP。

功能	求职岛 Beta	实习僧	Boss直聘	牛客	力扣	宣讲会	实习群
个人简历编辑与存储	✅	✅	✅	✅	✅	⛔	⛔
一键简历投递功能	✅	✅	✅	✅	✅	⛔	⛔
自动通知功能	✅	✅	✅	✅	✅	⛔	⛔
关注特定团队或企业	✅	✅	✅	✅	⛔	⛔	⛔
收藏特定招聘需求	✅	✅	✅	⛔	✅	⛔	⛔
允许指定仅面向特定院校或组织招收	✅	⛔	⛔	⛔	⛔	✅	✅
已申请需求归档	✅	✅	✅	✅	⛔	⛔	⛔
校内实验室相关功能	✅	⛔	⛔	⛔	⛔	✅	✅
内推相关功能	✅	✅	⛔	✅	✅	✅	✅
对举办特定活动的相关支持	✅	⛔	✅	✅	✅	✅	⛔
团队详情页面展示	✅	✅	⛔	✅	✅	⛔	⛔
是否多端支持	✅	✅	✅	✅	⛔	⛔	⛔
支持微信验证	✅	✅	✅	✅	✅	⛔	⛔
标签检索功能	✅	✅	✅	✅	✅	⛔	⛔
根据个人标签自适应推荐功能	✅	✅	✅	✅	✅	⛔	⛔
简历版本管理	已完成（审核通过后发布）	✅	✅	✅	✅	⛔	⛔
求职者端基于收藏和关注的特定搜索	✅	⛔	⛔	⛔	⛔	⛔	⛔

宣发和发布

宣发努力与取得的实绩

BETA 阶段的分发遇到了意料之外的不可抗力因素，项目策划阶段的重要标的：暑期生产实习因为疫情而取消，求职者用户寻找实习、参与科研等工作的积极性大大降低，更多同学选择全身心准备夏令营或复习考研。

招聘者端

本阶段团队的开发重心为招聘者端，因此在宣发上主要是对接之前沟通过的老师、学长等，帮助他们使用本平台进行需求信息的发布。目前，已有多位招聘者用户在接触和使用本平台，浏览既往的申请情况，准备新需求的自助发布。

合作方

与此情形类似，原定的群面大赛项目转入线上进行重新设计和筹备。团队积极与职协对接和再次商谈合作目标，和对方一起努力适应形势变化。职协方整理已有的活动信息，并进一步归纳了既往活动的分类及特点；团队针对这些信息重新设计了 Offer 的数据模型和展现形式，并和合作方商议以确定活动的机制和流程。接下来，职协的大部分活动信息都会以统一的信息呈现形式，由难以检索、缺失反馈功能的公众号逐步转移到求职岛平台。

求职者端

作为 ALPHA 阶段的后续，求职者端借由团队的持续宣发和用户的自行推广，进一步增加了用户量。从后端用户的注册、简历建档数据来看，平台的用户数量增加逾两成。有用户实际因平台受益，我们来听听他们的好消息：

Mr. W

19 级，软件学院，现在北航虚拟现实国重实习。

你为什么开始寻找实习？

• 学院培养方案的需要，我需要通过实习来获得生产实习的学分。
• 我自己也想通过实习来让自己得到一个锻炼，希望借实习来让自己有一定的工作经验，并学习更多知识，提升自己的专业水平，这对我以后不管是科研还是工作都是很有帮助的。

之前，你打算如何寻找实习？

• 通过各种招聘网站、校内资讯群等渠道获取企业或者实验室的实习信息，然后再去投递简历参加笔试、面试等。
• 通过校内教师的个人主页等，了解校内老师的具体信息，再结合自身想法，如以后想要从事的领域等，单独向老师投递简历，咨询相关的实习信息。

使用本平台的体验如何？

• 一个很明显的感觉就是很便捷，各种实习信息一目了然，也提供了老师的联系方式，这让我很快就了解了具体的实习岗位，并做出了选择。

• 功能也比较完善，给用户提供了对应的简历模板，可以方便地创建简历，我觉得这对于没有什么简历编写经验的用户来说是比较友好的。

现在实习的状况如何？

• 我个人觉得（和老师）配合得还是比较不错的，因为我个人之前没有什么实验室的工作经验，也没有从事过科研相关的工作，所以一开始会有许多不懂的地方。但是实验室老师却是很有耐心的一步步引导我，教我该怎么做，而且还充分考虑到我考期的压力，让我休息两个礼拜专心复习备考。所以总体来说，工作体验还是很愉快的。

希望平台做何改进？

• 首先虽然有自动生成简历的功能，但是对于一些已经编写好简历的用户来说，再重新编写一份会费时费力，所以如果能增加一个简历导入功能，我觉得会大大提升用户友好度。
• 然后就是虽然平台会对实习岗位进行一定的描述，也提供了老师的联系方式，但是若是能够在平台上搭建一个可以和老师或者企业实时交流的系统，我觉得可能会更有利于求职者了解相关岗位的具体职责，可以减少一定的沟通成本。

Mr. H

19 级，自动化学院，现在新体制电磁技术实验室实习。

你为什么开始寻找实习？

• 学院有生产实习要求，实验室实习可能可以替代生产实习。另一方面想接触一下导师，了解一下研究生相关的事情。再有就是可能想确认和检验一下自己的能力。

之前，你打算如何寻找实习？

• 之前缺乏寻找实习的经历，能想到的方式无非：到学院官网上找导师的联系方式，然后咨询情况；以及到一些实习招聘网站上收集信息。

使用本平台的体验如何？

• 当时还在犹豫的时候，就在这个平台上发现了一个近在眼前、而且看上去挺合适的实习。目前至少对于北航的同学来说，上面的信息还是很有价值的。

现在实习的状况如何？

• 得到了老师很热切的回应，已经跟着老师做了若干周的工作了。工作的内容还是比较对口的，暑假里也会继续。

希望平台做何改进？

• 最重要的点大概在于增加实习信息的数量，获得更多的用户。在足够数量的基础上或许可以对实习信息按地区、内容等进行模块划分。

软件工程质量

测试

单元测试

本项目在后端充分利用了单元测试来保证项目在功能、安全性等方面的正确性。在本项目的开发过程中，单元测试的编写和开发工作是同步进行的，保证每个面向用户的功能都有完善的单元测试，并希望尽可能多地覆盖使用场景。最终，我们的单元测试覆盖率达到了92%，基本实现了全覆盖。

此外，单元测试在我们的迭代中也起到了回归测试的作用，并且在一些大型的数据模型改动后的BUG修复中发挥了重要的作用，为我们的代码发现了许多BUG，为我们项目的健壮性发挥了非常重要的作用。

压力测试

在使用 nginx+uwsgi 部署好服务器之后，我们使用了 JMeter 进行压力测试。Beta 阶段额外补充了一个对招聘者端相对更耗费时间的 API.

1. echo: 最简单的一个API，将 request 中的 params 转换成 reponse 中的 body，不访问数据库，用于测试纯网络连接性能作为参考。
2. authenticate: 单纯用于验证token是否可用的API，会查询数据库获得User信息以及部分加密，所有其他API的参考基准
3. retrieve info: 列出已登录用户的个人信息的API。
4. list offers: 列出某已登录用户所能查看的所有Offer的详细信息，最耗费时间的API之一。（测试数据库中一共有113个Offer和226个OfferJob，每个查询会列出其中的10个）
5. retrieve offer: 列出一个用户指定的Offer的详细信息，与list offer进行比较。
6. search offers: 用于测试Postgresql上的jieba插件的分词和全文搜索性能，这是本项目功能最复杂最耗费时间的API。（测试数据为113个Offer和226个OfferJob，里面的内容填充有意义的中文文本）
7. 新增加的测试 - list applications: 列出关于某个招聘需求的全部求职请求，因为相关数据较多所以序列化和传输会比较耗费时间，我们采用分页的方式降低传输上的压力。

测试截图示例

对于新加入的压力测试项，列出求职请求的确会耗费较大资源，不过吞吐量仍在可以接受的范围内，我们采取了合理分页、前端限制访问频率、按需请求的情形下，后端无需再进行更多处理。

错误处理

后端对错误处理机制做了精美的封装。面向后端编程者提供的方式是在任意API函数中都可以允许任意异常被隐式地抛出到函数外，面向前端编程者提供的方式是无论后端发生任何错误都会以一种特定的JSON格式回报到前端，均包含一个识别何种错误的错误码还有一个自然语言的错误描述，方便前端统一处理。

某些API中前端需要依赖后端提供的不同错误进行不同动作。为了表征错误的类别使用了错误码机制，所有错误的错误码统一展示在JSON内部，在编排上采用最小知识原则，所有API所共有的错误如400、403、500将错误码直接编为对应的HTTP状态码，其他的需要前端特别处理的错误按照类别从6XX开始向上依次编写。后端采用抛出框架内置异常类和自定义错误类子类的方式使得Python代码清晰易读，异常会处理机制自动翻译为统一样式。

开发实践

前端架构的再改进

前端仍基于 MVVM 架构开发，但在此基础上，开发团队在 Web 端 VM 层上进一步抽象出网络层，分离 API 交互实现与客户端离线功能，提高 Web-app 的鲁棒性。并且，模块化进行视图层开发，引入中间件等复用代码、为平台逻辑提供统一实现。比照求职者前端的开发，招聘者前端具有更清晰的代码结构、更好的架构、更高的可维护性。

后端开发与协作

在项目开发的前期，项目组成员对于Django框架不够熟悉，因此由对Django比较熟悉的成员负责代码复审工作。当后端的某位成员提交代码后，由复审的组员进行审核，并且为代码提供架构和编写上的建议，并反馈给开发者。经过几次的改进，后端成员基本能够在代码风格等方面进行统一。

在BETA阶段，后端成员在开发上基本不会遇到技术上的问题，因此团队每次会在例会上进行开发工作的分配。在每次的例会上，先由PM确定本阶段的工作需求，然后后端成员对开发需求进行任务划分，并明确为几个细分的小点，最后通过认领的方式分配工作。

在开发的过程中，如果出现了工作量分配不均衡的问题（例如某位成员的工作量分配不合理，导致无法按时完成需求），则可以实时进行灵活的再分配，防止项目进度因工作量安排不周而停滞。

Dev-ops

管理员界面

管理员界面应用了Django框架自带的Admin框架，通过对模型简单的修饰和额外的一些方法实现管理所有模型的功能，非常方便。

中间件和 Mixin

另外在开发过程中我们还多次利用了中间件技术和Mixin技术，在多种层次上设计与构造的通用的代码能大幅提升代码质量，比如我们使用中间件进行日活统计，用Mixin来实现单元测试中用户登录的部分。

安全

通信加密：对所有通信采用TLS加密，并于SSLLAB网站验证安全配置正确。

所有API均后端严格鉴权并验证用户输入：通过统一的架构开发出来的程序会自带鉴权机制与验证输入合法性机制。由专人负责对代码的资源权限进行审计，确保服务器安全与用户信息安全。

Git仓库安全管理：所有的机密信息不得签入代码仓库，CI自动测试时使用GitHub Secret机制传入机密信息，部署时使用读入文件的方式传入机密信息。

高规格代码测试： 代码测试不仅会测试用户可以访问的资源，还会测试用户不应访问的资源是否不能访问。

常见网络攻击手段的防御：使用框架ORM机制防御SQL注入。前端禁止Render as HTML来防御XSS。用户API使用Header Token鉴权而不是Cookie鉴权，管理员面板使用CSRF Token机制来防御CSRF攻击。用户密码强制要求最低强度并高强度加密后存储于数据库中，防御密码暴力破解。

代码风格

团队制定命名规范，为前后端、Commit Message 配置 Lint 工具，并通过 Github Hook 的形式，确保代码风格的统一。

利用 Scrum Meeting 的线下交流机会，交叉进行 Code Review。小组制设计实现机制、确定架构再各自编码，确保项目低耦合、模块化、易读易维护，代码高标准、高质量。

Git 协作

团队制定了行之有效的 Git 协作规范，如提交规范、分支规范、合并规范等。对照团队文档具体介绍：

Demo展示

求职者端

扫码体验，使用邀请码注册：INVITEALPHA。

招聘者端

OfferIsland-Employer，需要邀请码进行注册以避免潜在的滥用问题。

项目与团队总结

项目管理

成员与分工

基本原则：并力前行

作为软件工程课程项目，小型团队的特点决定了全员往往都需同时承担开发工作。

无际软工队由七名成员组成，大家性格各异、技能及对产品的理解亦各不相同。

——在项目开发的每一个阶段，都希望能发挥每个人的技能和才智。

基于这个朴素的愿望，项目开始时团队成员一致同意：我们更进一步，在产品成型的各个流程都打破传统意义上的层级关系，扁平化组织结构，在重视每一个人参与和思考的前提下，完成不只限于开发，更包括调研策划、文档完成、宣发推广等在内的各项任务。

沟通对接与进度同步：共识而非“决断”

选择共同完成每一项任务，意味着每一位成员都得在各个环节持续投入。一方面，这带来了更大的沟通成本，妨害了个人时间安排的灵活性；但另一方面，这一原则保障了每一位成员都能对产品的方向和当前状况有十足的把握。团队设置了有效的沟通和进度同步机制，帮助每一位团队成员跟上团队整体的步伐。

团队除依照课程要求和敏捷开发的方法论，采用约两天一次的 Scrum Meeting 方式同步进展、指定任务外，还另行安排每周末的例会、针对开发之外的各项工作组织议题会议，确保每位成员了解当前产品阶段所需要考虑的问题，并参与到思考和讨论中来。

在团队决策上，由于上述原则和特点，团队避免采用 PM 拍板方式，也不采用简单的多数决方式来完成开发过程中涉及的各项决策。每次团队讨论依照：提出方案——寻找问题——解决问题——确立共识的方式来进行。

在会议纪要上，团队采取会议纪要轮值制，每位成员都参与一次会议纪要的编写，加深对项目进度的把控和了解。可以参照我们的会议纪要博客了解每次记录。

特异化的团队分工

当然，产品的开发过程中涉及到多项无法“均分”的工作。对于这些需要特别处理的议题，团队引入了以下特异化分工，交由专人来统筹和完成。

非典型“PM”：协调员而非决策者

一位成员担任项目 PM，作为项目的协调员。工作主要包括：设置每次讨论的议程、记录团队成员的共识、统筹开发的时间节点、考量课程的各项要求、维护团队博客。

与一般定义里的“决策者”角色不同，“PM” 在本团队更像是一台团队公用的存储器，在开发过程中遇到对需求模糊、实现不详的情况时，会借由 PM 来回顾和统一之前大家达成的共识。

“领航员”：灵活补位的开发总领者

团队内具有全栈开发能力和开发管理特长的一名成员担任“领航员”。从项目的架构设计、到开发流程与规范的制定和管理，团队依靠他来建设项目开发的初期基础。由于技术上的全栈优势，他分担略少的具体开发任务，集中精力处理项目开发的疑难问题，并在前后端开发之间游走，帮助解决开发进度上的不协调。

“管家”：开发工具的维护者。

团队内在 DevOps 方面有较深刻理解的一名成员担任“管家”，同样参与考量开发规范，但主要从工作流的角度出发。他负责处理 CI/CD 等自动化工具，解决硬件设备选型、服务器部署和服务上线的具体问题，完成服务器运维和数据分析与监控的相关工作，帮助产品持续平稳运行。

在赛博空间里交流和协作

疫情把团队的大家分隔在各处。从一开始的封校停课转线上导致成员被拦在校外，到取消堂食之后连校内的大家也失去了重要的团队交流地点，再到最后大家各回各家，甚至还有成员被集中隔离——疫情打破并强制性地重塑了 ALPHA 阶段团队业已形成的交流模式，需求每一位成员采取行动应对变化。

在 BETA 阶段，由于缺失面对面的交流机会，为更有效率地进行讨论，避免有默契的沉默、抢话等线上会议的弊病，PM 组织 Scrum Meeting 时进行了更细化的流程安排、梳理发言顺序，主持会议进行。

团队成员进一步密切沟通，将 Scrum 揉进整个开发周期中，拓展交流形式，加强了常时的线上沟通，进一步提高讨论频次，降低信息传递受阻带来的影响。

燃尽图

贡献分和贡献

成员	基础任务分	成员赠与奖励分	团队奖励分	最终得分	工作叙述
zsm	35	12	6.23	53.23	负责 DevOps，完成项目上线和部署、运维，设计开发规范，参加后端开发，设计、重构后端接口。
wjy	35	13	3.30	51.30	构建项目的架构、代码管理规范和工作流，参加前后端开发，多次“救火”、解决疑难问题。
xx	35	10	5.83	50.83	参加后端开发，积极对接导师、进行用户调研。
zyf	35	8	7.22	50.22	参加前端开发，开发视图模型层、帮助调试视图层。
nym	35	6	8.54	49.54	参加前端开发，对接导师和内推学长学姐。
xaj	35	10	3.37	48.37	参加前端开发，原型设计，担任 PM，进行项目进度管理。
zcx	35	9	4.21	48.21	参加后端开发，设计数据模型。

功能实现

用户场景和对需求的满足情况

用户信息	用户情况
姓名	LLLeo
身份	计算机学院学生，大三下，还没找好暑期实习，计划寻找校内实习，但没有想好要找的实习类型。
用户痛点	1. 各大微信群内发布的实习招聘信息过于杂乱，种类太少。 2. 现在有很多求职平台，但是缺少一个汇总校内实习信息的平台，寻找寻找校内实习时无从下手。 3. 可能有多个合适的实习岗位，缺少一个工具对合适的实习信息进行收藏。 4. 缺乏简历编写经历，希望寻找高效的方式投递自己的申请。
预期使用场景	通过「求职岛」高效浏览和搜索现有校内实习岗位，并对适合的实习岗位进行收藏，找到合适的实习岗位后，通过给定的模板进行简历的编写后进行投递，之后等待申请结果。
实现该用户需求的功能	1. 汇总校内实习平台的信息，并支持搜索功能，解决痛点 1 和痛点 2。 2. 支持对实习岗位的收藏和一键查询，解决痛点 3。 3. 支持编写简历并一键投递简历，可以随时查看投递状态和申请结果，解决痛点 4。

用户信息	用户情况
姓名	LLJeo
身份	计算机学院学生，大二下，计划寻找校内实习，确定了一些想进的实验室，但还没有确定去哪个实习岗位。
用户痛点	1. 实验室主页分散，甚至主页上可能缺少有效的实习信息，浏览和检索上耗费大量时间。 2. 无法快速获取每个实验室对应实习岗位的最新信息。 3. 无法对不同实习岗位进行高效对比。
预期使用场景	通过「求职岛」关注对应的实验室团队，高效浏览和搜索关注实验室所推出的实验岗位，比较不同岗位之间的优劣，选定合适的岗位后，通过给定的模板进行简历的编写后进行投递，之后等待申请结果。
实现该用户需求的功能	1. 汇总校内各大实验室的信息，并支持搜索功能，避免在实验室主页上低效检索，解决痛点 1。 2. 支持关注团队，可以一键搜索和查询所关注团队所推出的需求岗位，解决痛点 2 和痛点 3。

用户信息	用户情况
姓名	LJJeo
身份	软件学院学生，大三下，希望寻找开发相关校内外实习工作，技术栈明确，但对找实习相关事宜关注较少，比较迷茫。
用户痛点	1. 市面上的招聘平台信息量过大，对于刚接触实习和工作的本科生来说并不友好，很难挑选合适的岗位。 2. 面向北航学生的实习信息分布较为分散，尤其难以寻找和特定技术栈相关的实习岗位。 3. 针对校内和校外岗位可能要编写不同的简历，缺少一个合适的工具进行版本管理。
预期使用场景	通过「求职岛」选定自己技术栈对应的标签，查看推荐岗位，高效获取有效信息。同时在搜索时添加相应的标签，高效过滤适合自己技术栈的岗位。通过「求职岛」简历版本管理功能实现多份简历的高效编写与管理，并在投递时选择对应的简历，针对不同的岗位展现不同的闪光点。
实现该用户需求的功能	1. 汇总校内外各大岗位信息，并支持通过标签搜索岗位和推荐岗位，高效获取有效信息，解决痛点 1 和痛点 2。 2. 平台具备简历克隆、版本管理能力，解决痛点 3。

用户信息	用户情况
姓名	Chernoff
身份	计算机学院教授，课题比较多，有招聘实习生的需求。
用户痛点	1. 所在实验室主页较为古老，翻新成本过高。 2. 缺乏发布招聘实习生需求的途径。
预期使用场景	通过「求职岛」创建实验室团队，并发布实习生招聘需求，查看投递学生的简历并进行反馈，实现实习生的高效招聘。
实现该用户需求的功能	1. 招聘需求详情页会详细展示实习生岗位的具体信息，团队详情页会详细介绍实验室团队的信息，画面简洁精美，可以很好地吸引相关学生，解决痛点 1。 2. 每个发布的招聘需求都会在广场页上被展示，有效拓宽了发布招聘需求的途径，解决痛点 2。

用户信息	用户情况
姓名	切诺夫
身份	北航职协负责人，正在筹划群面大赛。
用户痛点	1. 需要一个较为正式的平台实现简历编写、浏览需求、简历投递的功能。自行搭建平台成本过高，若无合适平台则只能使用问卷星。 2. 需要一个较为正式的平台实现面试信息的反馈。
预期使用场景	通过「求职岛」举办群面大赛，比赛选手们在小程序上报名并投递简历，相关工作人员收集信息并进行反馈。
实现该用户需求的功能	1. 「求职岛」小程序完美充当了群面大赛所需的「正式平台」，解决痛点 1。 2. 「求职岛」小程序可以将用户们投递的简历收集，提供给相关招聘团队进行反馈，解决痛点 2。

用户信息	用户情况
姓名	Hoeffding
身份	软件学院教授，所在实验室定期招收一定数量的研究生。
用户痛点	1. 以往宣传实验室和招收实习生的方式为，编写实验室说明后发布到各大微信群内，感兴趣的同学可以发送简历到对应邮箱以进行筛选。该方法需要频繁查看邮箱，一旦出现遗漏可能会错过同学们的投递请求，投递方也因为收不到回复而迷茫，双方都没有足够好的体验。 2. 微信群内发布的内容很容易被刷上去，无法吸引足够数量的同学们。
预期使用场景	通过「求职岛」招聘者网页端发布实习生招聘需求，详细查看每个投递请求并给予相应的回复，通过平台强大的一体化功能同时提升求职者和招聘者的体验。
实现该用户需求的功能	1. 「求职岛」招聘者网页端解决了传统的发邮件审核简历方式，实现整个招聘流程的一体化，解决痛点 1。 2. 「求职岛」小程序内的主要内容即为招聘需求信息，不会出现信息被刷上去找不到的情况，此外每个招聘信息都会根据求职者所添加的标签进行推荐，大幅提升了招聘需求的宣传力度，解决痛点 2。

用户故事

「使用用户名或邮箱与密码登录」页面

达芬奇是一名在企业内实习的高年级学长，最近组里老板给他下发了很多内推指标，而达芬奇也想通过内推奖金在暑假出去旅游旅游。老板给了达芬奇一个邀请码，让他在「求职岛」注册一个账号来发布。于是他打开了「求职岛」的Employer端。

「注册并绑定邀请码」页面

达芬奇点击注册新账号进入注册页面

达芬奇已经有了一个邀请码，于是点击了「我有邀请码」

「选择团体与绑定更多团体」页面

注册并成功登录后，达芬奇进入了团队选择界面。

一个邀请码对应一个组织。达芬奇通过在注册时通过绑定邀请码成为了组里的成员。

同时，如果达芬奇也在校内某实验室负责招收实习生，那么他也能在这里输入点击「我有邀请码」，绑定邀请码加入更多的组织。

「已发布的请求与团队详情」页面

不过达芬奇现时要为所在组织「无际有限公司」发布招收实习生的需求，因此点击相应卡片进入主页

达芬奇点击「添加需求」并填写表单

达芬奇填写完成需求后，点击加号按钮，继续添加相应的具体招收需求入口

达芬奇要为这个需求添加几个标签，他想，财务应该要会算数，那么就添加一个「计算」标签吧！

达芬奇心想，诶，跟计算机也能沾边，那就正好也把「计算机」也加进去吧

不久，达芬奇就迎来了第一个申请者，点击「查看申请列表」

「查看申请者简历并执行处理」页面

达芬奇想继续查看一下申请人的信息，点击「查看简历」

达芬奇一看，嘿，说的清清楚楚只招博士，怎么本科也来凑热闹，拒了拒了。并且达芬奇还写了一段信息回复他。

又过了没多久，达芬奇又收到了一份申请

哇，好优秀的同学呀，达芬奇暗自心惊，达赶紧给小水獭回信，邀请他参与线下面试

于是达芬奇抓紧时间准备线下面试去了，希望他能找到合适的求职者吧。

功能特性与竞品分析

杀手级功能

招聘者端

团队认为，招聘者端的设计目的是：减少平台参与、降低操作成本，实现一套用户自治的系统机制。

在 BETA 阶段的招聘者端设计中，团队对招聘流程进行了针对性的建模，并在此基础上设置机制，通过实现：

• 需求建模与分工细分：提供统一的信息展示模板，降低信息的获取成本；
• 标签系统和推荐：聚合用户与需求的特征以进行推荐，提高信息触达的精准度；避免一过性的信息展示，进一步延长需求的触达周期；
• 申请浏览与追踪：为招聘者与求职者提供有效的初步沟通桥梁。
• 团队建模与邀请码机制：适应校内科研实习的课题组形式，为用户提供更高自由度；基于团队管理平台权限，为实现用户自治创造空间。

功能	求职者 Beta	领英（中国版）招聘端	宣讲会	实习群
招聘需求的发布	✅	✅	✅	✅
简历投递汇总	✅	✅	⛔	⛔
招聘岗位的分工细分	✅	⛔	⛔	⛔
招聘分类发布和展示	✅	✅	⛔	⛔
更长的用户触达周期	✅	✅	⛔	⛔
安全可靠的身份认证	✅	✅	⛔	⛔
针对分工的标签功能	✅	⛔	⛔	⛔
实时反馈投递者	✅	✅	⛔	⛔
可编辑可展示的团队介绍页	✅	⛔	⛔	⛔
每个招聘者可以属于多个团队	✅	⛔	⛔	⛔

求职者端

求职岛主打的特色为提供了校内科研实习信息聚合与定向招收过滤的功能，为校内各类实习机会提供统一的流程和模式，BETA 阶段在此基础上进一步补齐了主流求职类APP所具备的各项功能（标签系统、Offer 推荐、简历版本管理等）并进一步优化体验。如是，求职岛在打出校内实习领域差异化优势的同时，其用户体验亦不逊于市面上主流的求职APP。

功能	求职岛 Beta	实习僧	Boss直聘	牛客	力扣	宣讲会	实习群
个人简历编辑与存储	✅	✅	✅	✅	✅	⛔	⛔
一键简历投递功能	✅	✅	✅	✅	✅	⛔	⛔
自动通知功能	✅	✅	✅	✅	✅	⛔	⛔
关注特定团队或企业	✅	✅	✅	✅	⛔	⛔	⛔
收藏特定招聘需求	✅	✅	✅	⛔	✅	⛔	⛔
允许指定仅面向特定院校或组织招收	✅	⛔	⛔	⛔	⛔	✅	✅
已申请需求归档	✅	✅	✅	✅	⛔	⛔	⛔
校内实验室相关功能	✅	⛔	⛔	⛔	⛔	✅	✅
内推相关功能	✅	✅	⛔	✅	✅	✅	✅
对举办特定活动的相关支持	✅	⛔	✅	✅	✅	✅	⛔
团队详情页面展示	✅	✅	⛔	✅	✅	⛔	⛔
是否多端支持	✅	✅	✅	✅	⛔	⛔	⛔
支持微信验证	✅	✅	✅	✅	✅	⛔	⛔
标签检索功能	✅	✅	✅	✅	✅	⛔	⛔
根据个人标签自适应推荐功能	✅	✅	✅	✅	✅	⛔	⛔
简历版本管理	已完成（审核通过后发布）	✅	✅	✅	✅	⛔	⛔
求职者端基于收藏和关注的特定搜索	✅	⛔	⛔	⛔	⛔	⛔	⛔

宣发和反馈

宣发努力与取得的实绩

BETA 阶段的分发遇到了意料之外的不可抗力因素，项目策划阶段的重要标的：暑期生产实习因为疫情而取消，求职者用户寻找实习、参与科研等工作的积极性大大降低，更多同学选择全身心准备夏令营或复习考研。

招聘者端

本阶段团队的开发重心为招聘者端，因此在宣发上主要是对接之前沟通过的老师、学长等，帮助他们使用本平台进行需求信息的发布。目前，已有多位招聘者用户在接触和使用本平台，浏览既往的申请情况，准备新需求的自助发布。

合作方

与此情形类似，原定的群面大赛项目转入线上进行重新设计和筹备。团队积极与职协对接和再次商谈合作目标，和对方一起努力适应形势变化。职协方整理已有的活动信息，并进一步归纳了既往活动的分类及特点；团队针对这些信息重新设计了 Offer 的数据模型和展现形式，并和合作方商议以确定活动的机制和流程。接下来，职协的大部分活动信息都会以统一的信息呈现形式，由难以检索、缺失反馈功能的公众号逐步转移到求职岛平台。

求职者端

作为 ALPHA 阶段的后续，求职者端借由团队的持续宣发和用户的自行推广，进一步增加了用户量。从后端用户的注册、简历建档数据来看，平台的用户数量增加逾两成。有用户实际因平台受益，我们来听听他们的好消息：

Mr. W

19 级，软件学院，现在北航虚拟现实国重实习。

你为什么开始寻找实习？

• 学院培养方案的需要，我需要通过实习来获得生产实习的学分。
• 我自己也想通过实习来让自己得到一个锻炼，希望借实习来让自己有一定的工作经验，并学习更多知识，提升自己的专业水平，这对我以后不管是科研还是工作都是很有帮助的。

之前，你打算如何寻找实习？

• 通过各种招聘网站、校内资讯群等渠道获取企业或者实验室的实习信息，然后再去投递简历参加笔试、面试等。
• 通过校内教师的个人主页等，了解校内老师的具体信息，再结合自身想法，如以后想要从事的领域等，单独向老师投递简历，咨询相关的实习信息。

使用本平台的体验如何？

• 一个很明显的感觉就是很便捷，各种实习信息一目了然，也提供了老师的联系方式，这让我很快就了解了具体的实习岗位，并做出了选择。

• 功能也比较完善，给用户提供了对应的简历模板，可以方便地创建简历，我觉得这对于没有什么简历编写经验的用户来说是比较友好的。

现在实习的状况如何？

• 我个人觉得（和老师）配合得还是比较不错的，因为我个人之前没有什么实验室的工作经验，也没有从事过科研相关的工作，所以一开始会有许多不懂的地方。但是实验室老师却是很有耐心的一步步引导我，教我该怎么做，而且还充分考虑到我考期的压力，让我休息两个礼拜专心复习备考。所以总体来说，工作体验还是很愉快的。

希望平台做何改进？

• 首先虽然有自动生成简历的功能，但是对于一些已经编写好简历的用户来说，再重新编写一份会费时费力，所以如果能增加一个简历导入功能，我觉得会大大提升用户友好度。
• 然后就是虽然平台会对实习岗位进行一定的描述，也提供了老师的联系方式，但是若是能够在平台上搭建一个可以和老师或者企业实时交流的系统，我觉得可能会更有利于求职者了解相关岗位的具体职责，可以减少一定的沟通成本。

Mr. H

19 级，自动化学院，现在新体制电磁技术实验室实习。

你为什么开始寻找实习？

• 学院有生产实习要求，实验室实习可能可以替代生产实习。另一方面想接触一下导师，了解一下研究生相关的事情。再有就是可能想确认和检验一下自己的能力。

之前，你打算如何寻找实习？

• 之前缺乏寻找实习的经历，能想到的方式无非：到学院官网上找导师的联系方式，然后咨询情况；以及到一些实习招聘网站上收集信息。

使用本平台的体验如何？

• 当时还在犹豫的时候，就在这个平台上发现了一个近在眼前、而且看上去挺合适的实习。目前至少对于北航的同学来说，上面的信息还是很有价值的。

现在实习的状况如何？

• 得到了老师很热切的回应，已经跟着老师做了若干周的工作了。工作的内容还是比较对口的，暑假里也会继续。

希望平台做何改进？

• 最重要的点大概在于增加实习信息的数量，获得更多的用户。在足够数量的基础上或许可以对实习信息按地区、内容等进行模块划分。

用户反馈和团队自评

Pros

• 从同学们的反馈来看，平台精确命中了校内同学的热点需求、痛点问题，尤其是为本科生提供了易用的信息获取渠道，对还未有科研、实习经验，从零开始的同学们帮助很大；
• 从导师的反馈来看，平台提供了统一、反馈明确的科研信息发布渠道，能够帮助导师们更好地触达同学，同时也大大减轻了他们信息发布、主页维护的成本。
• 从在职校友们的反馈上来看，平台提供了触达率更高、留存度更好的实习信息发布渠道。

Cons

• 求职者端小程序的Windows前端布局仍然有一定的适配问题，且有些按钮（比如投递简历）鼠标点击可能会没有反应。
• 前端部分操作（比如标记已读消息、投递简历）容易被误操作。
• tag目前可以由用户自行添加，故不可避免地会出现同义tag的冗余，这会影响用户搜索得到的结果。
• 由于本产品特殊性，招聘者端不能随意注册（需要认证），所以招聘者端需要用户主动联系开发团队才可以去邀请体验。
• 类似Alpha阶段，目前邮箱验证码仍然容易被拦截，所以登录注册仍然主要依靠邀请码来进行。
• 受到疫情与学校政策的影响，同学们的硬性生产实习任务被取消，且实验室实习大多只能远程进行，故求职者积极性明显降低，Beta阶段求职者端的用户量受到一定的冲击。

BUGs

• 前端布局、换行、视图层有一些微小的视图 Bug，略微影响观感；
• 由于微信小程序的 WebView 实现逻辑，平台小程序在桌面端——即便无论从用户调研的角度、还是实际使用数据的角度都不是预期的目标平台——上，存在较为严重的适配问题，少数状况下会干扰到用户的操作逻辑；

软件工程质量

开发规范

前文已经充分地叙述了本团队开发规范上的实践，这里不再赘述。对于代码仓库管理，我们近期会出一篇博客详细地说明，更新在此处。

文档管理

团队采用 Notion 进行文档管理，活用其文档数据库特性，记录并管理团队成员共同完成的工作。

对于策划阶段，我们有成体系、有模板的调研数据库。

对于开发阶段，我们有符合 RESTful 规范的接口定义文档库；有专门的会议纪要数据库。

对于分发阶段，我们有具体到人，带进度管理的用户沟通数据库。

测试

压力测试

在使用 nginx+uwsgi 部署好服务器之后，我们使用了 JMeter 进行压力测试。Beta 阶段额外补充了一个对招聘者端相对更耗费时间的 API.

1. echo: 最简单的一个API，将 request 中的 params 转换成 reponse 中的 body，不访问数据库，用于测试纯网络连接性能作为参考。
2. authenticate: 单纯用于验证token是否可用的API，会查询数据库获得User信息以及部分加密，所有其他API的参考基准
3. retrieve info: 列出已登录用户的个人信息的API。
4. list offers: 列出某已登录用户所能查看的所有Offer的详细信息，最耗费时间的API之一。（测试数据库中一共有113个Offer和226个OfferJob，每个查询会列出其中的10个）
5. retrieve offer: 列出一个用户指定的Offer的详细信息，与list offer进行比较。
6. search offers: 用于测试Postgresql上的jieba插件的分词和全文搜索性能，这是本项目功能最复杂最耗费时间的API。（测试数据为113个Offer和226个OfferJob，里面的内容填充有意义的中文文本）
7. 新增加的测试 - list applications: 列出关于某个招聘需求的全部求职请求，因为相关数据较多所以序列化和传输会比较耗费时间，我们采用分页的方式降低传输上的压力。

测试截图示例

测试结果

测试项目	平均延时 ms	延时标准差 ms	错误率 %	吞吐量 packet/sec
echo	282	53	0.00	215
authenticate	285	32	0.23	223
retrieve info	442	132	0.00	127
list offers	4239	3748	1.73	11.6
retrieve offer	1007	656	0.00	58.2
search offers	3790	3392	0.00	10.3
*list applications	7565	340	0.00	8.1

改进措施

测试结果表明在列表和搜索性能上，基本满足了我们的需要。通过分析，serach offers和list offers性能差距不大，说明在数据库层面搜索没有什么消耗，而主要在于Django对数据的处理的时间或拉取相关数据上。故对该API进行改进，利用prefetch_relate和select_relate方法来提前拉取关联数据避免多次查询数据库，改进后结果如下：

测试项目	平均延时 ms	延时标准差 ms	错误率 %	吞吐量 packet/sec
retrieve offer	1034	596	0.00	58
list offers	4580	2722	1.73	12.9

虽然有改善但是改善并不大，说明性能瓶颈在Python代码执行上，无更多优化空间。

对于新加入的压力测试项，列出求职请求的确会耗费较大资源，不过吞吐量仍在可以接受的范围内，在合理分页、控制访问频率、前端按需请求的情形下，后端无需再进行更多处理。

单元测试

在本项目中，我们基于Django的Test框架对所有的可测的API编写了单元测试。单元测试共有74组，单元测试相关代码达到2300+行。

我们还将自动测试部署到CI，每次合并到开发主分支时会自动进行单元测试与生成覆盖率报告，持续保持代码的正确性。**至 Beta 阶段终点，**下图是自动生成的代码覆盖率报告，可以看出我们的代码总体覆盖率达到了92%。未能覆盖的部分主要包括数据库移植文件、微信登录相关API、对象存储相关API等无法在此处进行自动化单元测试的部分。

经验和教训

在本次项目开发中，我们经历了Alpha、Beta两轮迭代，小组成员分工合作完成了调研与评估、设计与实践、测试与运维等环节，在实践能力、设计能力、分析能力等方面都有提升。下面，我们来展开谈一谈小组在本轮开发中收获的经验与教训。

工欲善其事，必先利其器。 先静下心来深入了解所需要的工具，再进行编码实践，往往要比直接上手实现要更快更好。项目初期，小组成员对RESTful框架了解不足，因而走了很多弯路，后来随着学习的深入，逐渐发现更好的实现方法，轻松解决此前困扰的诸多问题。在敏捷开发中，我们要注重学习和深入了解开发框架的实现细节，仔细研读指导文档，先行熟悉框架特点。

留得五湖明月在,不愁无处下金钩。 再精心的设计也常常有所疏漏，我们总要为可能出现的问题做出准备。再本项目设计的过程中，Alpha阶段后期我们逐渐意识到了小程序很难为招聘者提供良好的用户体验，所以增加web端的设计。而在开发web端时，我们不得不重新设计了一些模块。这一次经验告诉我们，在开发过程中尽可能地为更多可能的拓展留出余地，做出充分的准备。

人有冲天之志，非运不能自通。 努力和谋划固然是重要的，但是有时候我们也需要一点点运气。我们最初的选题主要有两个方向：校内外卖代取和校内求职平台，最终在调研和决策后选择了后者。进入五月，随着疫情形势变化，校园开始了封闭管理，外卖停止入校，那时我们还在庆幸没有选择代取项目，否则要面临破产风险。然而，几周后，外卖逐渐恢复了，但暑期实习却取消了，这对我们后续的推广十分不利。在项目的完成过程中，我们看到了时势对一个项目发展的巨大影响，我们需要有更长远的目光和更敏锐的嗅觉。

展望和计划

站在软件工程课程的终点，回顾两个多月充实而收获颇丰的开发流程，我们相信无论是对于成员自身、还是刚刚萌芽看见阳光的产品，都还刚刚来到漫长旅程的起点。

第一篇团队博客里我们满怀着信心写下：

希望不受拘束地用编程实现想法，完成蕴含无限可能的产品。

今天，我们站在终点——
再出发。