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

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

项目与团队亮点

成员与分工

基本原则：并力前行、共识优先

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

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

为实现上述愿景，团队设置了有效的沟通和进度同步机制，除 Scrum Meeting 外，还通过周例会、议题会议、轮值会议纪要等方式，帮助每一位团队成员跟上团队整体的步伐。

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

进度管理：Notion + Github issues

团队活用 Notion 平台进行团队的文档管理、信息聚合和开发以外的任务分配。在 Notion 中，任务分锅到人，设置截止时间，创建看板、时间线视图，帮助大家了解任务的动向和状况。

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

本团队在 Git 仓库管理上有明确且有效的规范和实践，将在接下来的部分中介绍。

特异化的团队分工

对于平台的实际开发，我们采用前后端分离的模式，发挥团队成员的特长，尽力追求工作量的均等和开发进度的统一。

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

• 我们有非典型的“PM”：项目的协调员、团队公用的**“存储器”**。管理进度、总体把握项目、回顾和统一大家之前达成的共识、处理外部合作关系。

• 我们有 “领航员”：灵活补位的开发总领者。具备全栈开发能力，主持架构设计，分担略少的具体开发任务，集中精力处理项目开发的疑难问题。在前后端开发之间游走，帮助解决开发进度上的不协调问题。

• 我们有 “管家”：开发工具的维护者。了解 DevOps 的最佳实践，制定开发规范，帮助团队处理 CI/CD 等自动化工具，解决硬件设备选型、服务器部署和服务上线的具体问题。

典型用户场景

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

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

用户信息	用户情况
姓名	切诺夫
身份	北航职协负责人，正在筹划群面大赛。
用户痛点	1. 需要一个较为正式的平台实现简历编写、浏览需求、简历投递的功能。自行搭建平台成本过高，若无合适平台则只能使用问卷星，信息归并和整理的成本较大。 2. 需要一个结构化的平台对接大赛的具体流程，实现面试信息的反馈、比赛结果的评价等。
预期使用场景	通过「求职岛」举办群面大赛，比赛选手们在小程序上报名并投递简历，相关工作人员收集信息并进行反馈。
实现该用户需求的功能	1. 「求职岛」小程序成功地成为了群面大赛所需的「正式平台」，解决痛点 1。 2. 「求职岛」小程序可以将用户们投递的简历收集，提供给相关招聘团队进行反馈；为参与者建立了统一的档案，便于后续结果反馈和跟进，解决痛点 2。
未解决的痛点	无。

杀手级功能与竞品对比

团队认为，产品的竞争力不只包括功能的全面性，亦包括功能的特异性：求职岛面向校园内部实习信息聚合的细分领域进行需求调研和规划，对接实习需求的两端：学生、导师或内推学长们。针对学生们在机会寻觅、导师和在职校友们在信息发布上的痛点，立足校内信息优势，构建校内私有的资讯领域和交流通路，与现有类似产品进行差异化竞争。

选定以对比的竞品主要包括面向社会的求职类APP（实习僧，Boss直聘）、偏校园向的APP（牛客、力扣）、以及一些现有的校内可行方式（宣讲会、实习群）。

求职岛主打的特色为提供了校内科研实习信息聚合与定向招收过滤的功能，为校内各类实习机会提供统一的流程和模式，并在此基础上补齐主流求职类APP所具备的各项功能（简历存储、一键投递、关注收藏等）。如是，求职岛在打出校内实习领域差异化优势的同时，其用户体验亦不逊于市面上主流的求职APP。

功能	求职岛Alpha	实习僧	Boss直聘	牛客	力扣	宣讲会	实习群
个人简历编辑与存储	✅	✅	✅	✅	✅	⛔	⛔
一键简历投递功能	✅	✅	✅	✅	✅	⛔	⛔
自动通知功能	✅	✅	✅	✅	✅	⛔	⛔
关注特定团队或企业	✅	✅	✅	✅	⛔	⛔	⛔
收藏特定招聘需求	✅	✅	✅	⛔	✅	⛔	⛔
允许指定仅面向特定院校或组织招收	✅	⛔	⛔	⛔	⛔	✅	✅
已申请需求归档	✅	✅	✅	✅	⛔	⛔	⛔
校内实验室相关功能	✅	⛔	⛔	⛔	⛔	✅	✅
内推相关功能	✅	✅	⛔	✅	✅	✅	✅
对举办特定活动的相关支持	✅	⛔	✅	✅	✅	✅	⛔
团队详情页面展示	✅	✅	⛔	✅	✅	⛔	⛔
是否多端支持	✅	✅	✅	✅	⛔	⛔	⛔
支持微信验证	✅	✅	✅	✅	✅	⛔	⛔
友好的招聘者端操作界面（Beta）	⛔	⛔	✅	✅	✅	⛔	⛔
用户自由发布自定义组队需求（Beta）	⛔	⛔	⛔	⛔	✅	⛔	⛔

宣发和发布

宣发努力与取得的实绩

本项目涉及到两种用户角色——需求发布者和求职者。既有 to C 的一面：我们需要对接两类用户，了解他们的需求、解决他们的痛点，为他们提供各类平台机能；也有 to B 的一面：导师、学长们发布的项目需求、招聘信息等，本身来源于实验室或企业实体。在商谈课题或项目入驻时，需要以团体为单位对接相关方，取得他们的认可和背书。

需求发布者侧的推广

从项目调研阶段开始，团队成员就提早布局，与熟识的潜在用户——实验室导师及内推学长学姐们沟通，了解他们发布实习信息、招生、招聘工作的各个环节和需求。

在项目发布阶段，团队成员进一步与意向入驻的需求发布者沟通，邀请他们体验求职者侧的使用流程，解说平台定制的需求发布、求职者申请和信息反馈机制。

即便时间紧、任务重，在团队成员的努力下，目前已与十余位老师达成入驻意向，并已有来自五个大实验室的近十项实验室实习需求在本平台上发布；科研需求之外，我们还积极与手握内推资格的学长学姐们沟通，与来自字节跳动、商汤科技、司索科技等企业的在职校友达成入驻意向，其中字节跳动的实习生内推信息已在本平台上发布。

对于本平台这样“冷启动”、慢热型的信息聚合平台，磋商和推广是长期的过程，达成目前的推广效果，已经基本完成了项目初始时对 ALPHA 阶段发布的预想目标。

求职者侧的推广

虽然由于微信小程序审核、合作方相关要求等不可抗力因素，本周中才得以开始求职者侧的推广，但平台仍吸引到了大量用户的关注和使用。

在推广形式上，团队立足学生对暑期实习的迫切需求，通过朋友圈、学生群聊等方式精确触达产品信息。

从用户实绩上看：平台基于微信小程序发布，每一账户对应一个微信账号，使用校园邮箱、小范围传播的邀请码注册，除去提供给需求发布者的测试账号，已有逾百位实名的北航求职者用户注册。从后台的统计数据来看，已有近三十位同学开始创建简历，其中一半以上同学进行了简历的实际投递。

可以认为，团队精确把握了求职者用户的需求，有望继续在求职者、发布者间实现双向的良性循环。

北航职协合作

平台针对类似项目缺乏背书、缺乏初期用户量的问题，在项目的早期便与北航职协商谈合作，积极争取，得到了对方的认可：即将于五月份进行的华北地区高校模拟群面大赛的申请和报名、信息收集、反馈等全活动流程将在本平台上进行。

在本周末，北航职协会依托“航小职”官方公众号发送活动推送，并通过“北航就业”的数个信息群宣发活动，预期能够吸引百名以上北航同学参加。活动的引入，能够进一步扩大本平台的知名度，充实平台用户量。

软件工程质量

测试

完整的代码测试规范

我们要求所有后端开发者在编写一个API后必须至少编写一个测试正例以证明代码功能的可用性，并由API编写者与测试负责人编写若干测试反例来测试代码的安全性。少量无法自动测试的API（如微信登录）则手动测试。我们的自动测试代码覆盖率达到了93%。

CI自动化代码测试

后端开发者在向开发主分支dev提交PR时将会由CI自动执行测试，并显示代码覆盖率报告，仅当代码通过测试才可以进行合并。使得我们可以试试确保开发主分支的可用性，并在重构时尽快发现所有牵连导致的bug。

压力测试

我们使用JMeter工具对几个主要典型的API进行了压力测试，确保服务器性能可以基本满足我们的并发访问需要。详见测试报告

开发规范

代码开发规范

本项目后端基于Django Rest Framework开发，后端质量控制负责人在完整学习 Framework 的最佳用法之后，创建一个基本的代码框架，定义了统一的API编写格式，统一的错误处理机制以及统一的API文档格式，并在代码开发初期Review其他成员提交的代码以保证编程样式的统一性。

我们要求后端开发者充分利用Framework中的Model-Serializer-View的架构，通过面向对象的思想以及高内聚低耦合的原则利用精简清晰的代码开发高质量高可维护的代码。

前端基于 MVVM 架构开发，一位开发者专司原型设计和视图绘制，其余两位基于 VueX 状态管理框架处理 ViewModel ——事实证明，这一分工极大地降低了前端的耦合程度，便于快速迭代开发和 Bug 修复。

安全规范

通信加密：对所有通信采用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。

项目与团队总结

项目管理

成员与分工

#####　基本原则：并力前行

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

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

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

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

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

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

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

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

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

特异化的团队分工

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

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

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

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

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

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

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

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

燃尽图

贡献分和贡献

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

功能实现

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

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

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

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

用户信息	用户情况
姓名	切诺夫
身份	北航职协负责人，正在筹划群面大赛。
用户痛点	1. 需要一个较为正式的平台实现简历编写、浏览需求、简历投递的功能。自行搭建平台成本过高，若无合适平台则只能使用问卷星，信息归并和整理的成本较大。 2. 需要一个结构化的平台对接大赛的具体流程，实现面试信息的反馈、比赛结果的评价等。
预期使用场景	通过「求职岛」举办群面大赛，比赛选手们在小程序上报名并投递简历，相关工作人员收集信息并进行反馈。
实现该用户需求的功能	1. 「求职岛」小程序成功地成为了群面大赛所需的「正式平台」，解决痛点 1。 2. 「求职岛」小程序可以将用户们投递的简历收集，提供给相关招聘团队进行反馈；为参与者建立了统一的档案，便于后续结果反馈和跟进，解决痛点 2。
未解决的痛点	无。

用户故事

「使用校园邮箱认证校园身份」页面

小水獭是一名大三下的本科生，最近正在为暑期实习而烦恼，根据好友的推荐，他打开了「求职岛」小程序。听说这款小程序上可以为寻找校内实习提供很大便利，小水獭决定按照提示认证校园身份。

该页面引导首次使用「求职岛」的用户进行校园身份认证，填写对应的校园邮箱，系统会向其中发送一个验证码，填写该验证码后就可以完成验证，系统会根据邮箱的后缀确定用户所属机构。

小水獭填写邮箱后，点击「获取验证码」，他的北航邮箱中成功收到了一封邮件：

小水獭根据邮件填写了验证码：

点击确认后，「求职岛」小程序会获取用户的昵称和头像，用于完善个人信息：

至此，小水獭成功认证了校园身份。

「使用邀请码认证校园身份」页面

大水獭是一名硕士研究生，最近同样在为暑期实习而烦恼，根据好友的推荐，他打开了「求职岛」小程序。听说这款小程序上可以很方便联系学长进行内推，大水獭决定按照提示认证校园身份。然而，因为一些特殊的原因，大水獭的校园邮箱无法使用，他向「求职岛」相关负责人说明了情况，通过邀请码成功认证了校园身份：

该页面引导首次使用「求职岛」的用户进行校园身份认证，如果用户因为特殊原因不能提供校园邮箱，可以与相关负责人联系，通过邀请码实现校园身份的认证。

「个人简历概述」页面

小水獭成功认证了校园身份，进入了「个人简历概述」页面，他忽然想起他甚至没写过简历，看到这个功能，他欣喜若狂，赶快去完善简历信息，以便后续进行简历投递。

该页面展示了用户个人简历填写情况的概述，初始为空。用户可以在界面对相关条目进行增加、删除和修改。具体的填写页面会在后续进行介绍。

「修改基本信息」页面

小水獭首先编辑了他简历的基本信息，包括姓名和邮箱：

该页面用于编辑用户简历的基本信息，并会对不合法的字段给出提示。

「新增简历条目」页面

小水獭接着添加了一些简历条目，包括：

• 教育背景：

• 奖项信息：

• 经历信息：

这三个页面用于添加用户简历的条目，同时会对不合法的字段给出提示。

除了上面三个条目外，小水獭又添加了一个奖项，添加完成后，他的「个人简历概述」页面如下：

「修改和删除简历条目」页面

小水獭突然发现，他的教育背景写错了，就读专业怎么能是 codeforces 呢？他赶忙将其修改为 atcoder，并点击了保存：

此外，小水獭觉得 FST 大奖不是一个出彩的奖项，并通过点击删除将这个奖项删去：

这些页面用于修改和删除用户简历的条目，同时会对不合法的字段给出提示。

最终，他的「个人简历概述」页面如下：

「招聘需求列表」页面

小水獭写完了简历，点击下方的切换按钮，成功来到了「招聘需求列表」页面：

在这里，他可以随意搜索他想要的关键字，下面会展示所有相关的招聘需求，小水獭搜索了「酷里成韵」，一个非常知名的视频平台：

此外，对于目前正在进行的活动「第一届华北地区高校模拟群面大会」，也可以点击以进行相关关键字的搜索，小水獭点击了一下试试：

此外，还可以筛选关注团队发布的招聘需求和收藏的招聘需求，因为小水獭还没有仔细看招聘需求，他决定以后再来探索。

该页面会对所有的招聘需求进行罗列，支持搜索、动态下拉加载、查找关注团队发布的招聘需求、查找用户收藏的招聘需求。

「招聘需求详情」页面

小水獭点进了「酷里成韵」的招聘需求详情，可以看到该需求的招聘团队以及全部需求分工：

对于内推类招聘需求，系统会为内推者建立一个独自的团队，而对于实验室团队的招聘需求，则会展示实验室团队，例如：

小水獭发现他可以在这个页面投递简历，但是他还没想好要投哪个，因此他通过收藏功能 (黄色五角星) 将上述两个招聘需求都收藏了起来。

该页面会展示招聘需求的详细信息，并罗列全部需求分工，用户可以在此进行简历的投递。此外，用户也可以在这里收藏招聘需求、或是取消收藏招聘需求。

收藏相应的招聘需求后，可以在「招聘需求列表」页面点击「收藏」来找到它们：

「招聘团队详情」页面

在「招聘需求详情」页面，点击相应的团队就可以进入「招聘团队详情」页面，小水獭进入了「北航软件工程研究院」的详情页：

小水獭非常喜欢这个团队，因此他通过点击黄色五角星关注了这个团队。

该页面会展示招聘团队的详细信息，并罗列团队的项目成果和论文列表，用户也可以在这里收关注招聘团队、或是取消关注招聘团队。

关注相应的招聘团队后，可以在「招聘需求列表」页面点击「关注」来找到它们：

「已投递简历」页面

经过一段时间的纠结，小水獭最终决定投递「软件研究实验室 / 算法研究实习生」，他点击了「投递简历」按钮：

接着，他点击下方的切换按钮，返回到「个人简历概述」页面，并通过点击上方的「申请」按钮查看投递状态：

该页面会展示已投递简历的状态，并展示相关的回复信息。用户可以点击一个已投递简历跳转到对应的招聘需求。
在该页面所查看招聘需求详情和招聘团队详情，与在「需求列表」页所查看的两个需求页面不共享同一页面 (但是内容相同)，用户可以通过底部的切换按钮在反复切换两个详情界面，实现对不同需求和团队的高效对比。

「通知列表」页面

经过漫长的等待，小水獭收到了招聘团队的回复，他通过点击右上角的铃铛切换到了「通知列表」页面：

通知右上角的蓝点表示未读，阅读后再次进入该页面就会消失。

该页面会展示用户收到的通知，并会标注是否已读，避免用户错过重要通知。

当一条简历投递收到回复后，「已投递简历」页面也会对其进行展示：

当然，「招聘需求详情」页面也会对其进行展示：

初审通过的小水獭很高兴，去准备第二天的面试了~

功能特性与竞品分析

杀手级功能

团队认为，产品的竞争力不只包括功能的全面性，亦包括功能的特异性：求职岛面向校园内部实习信息聚合的细分领域进行需求调研和规划，对接实习需求的两端：学生、导师或内推学长们。针对学生们在机会寻觅、导师和在职校友们在信息发布上的痛点，立足校内信息优势，构建校内私有的资讯领域和交流通路，与现有类似产品进行差异化竞争。

平台具备以下能力：

从求职者的角度看，在实验室实习的场合：

聚合校内信息，让学生不再以口口相传的方式了解校内实验室。

在企业实习的场合：

获得针对性更强的求职经验与更可靠的内推机会。

从录用者的角度看，在实验室招募的场合：

拓宽宣传渠道，获得更符合需求的生源，有助于培养长期稳定的科研关系。

在内推求人的场合：

扩大内推覆盖面，有效筛选合适人选，提高内推工作的效率。

竞品对比

选定以对比的竞品主要包括面向社会的求职类APP（实习僧，Boss直聘）、偏校园向的APP（牛客、力扣）、以及一些现有的校内可行方式（宣讲会、实习群）。

求职岛主打的特色为提供了校内科研实习信息聚合与定向招收过滤的功能，为校内各类实习机会提供统一的流程和模式，并在此基础上补齐主流求职类APP所具备的各项功能（简历存储、一键投递、关注收藏等）。如是，求职岛在打出校内实习领域差异化优势的同时，其用户体验亦不逊于市面上主流的求职APP。

功能	求职岛Alpha	实习僧	Boss直聘	牛客	力扣	宣讲会	实习群
个人简历编辑与存储	✅	✅	✅	✅	✅	⛔	⛔
一键简历投递功能	✅	✅	✅	✅	✅	⛔	⛔
自动通知功能	✅	✅	✅	✅	✅	⛔	⛔
关注特定团队或企业	✅	✅	✅	✅	⛔	⛔	⛔
收藏特定招聘需求	✅	✅	✅	⛔	✅	⛔	⛔
允许指定仅面向特定院校或组织招收	✅	⛔	⛔	⛔	⛔	✅	✅
已申请需求归档	✅	✅	✅	✅	⛔	⛔	⛔
校内实验室相关功能	✅	⛔	⛔	⛔	⛔	✅	✅
内推相关功能	✅	✅	⛔	✅	✅	✅	✅
对举办特定活动的相关支持	✅	⛔	✅	✅	✅	✅	⛔
团队详情页面展示	✅	✅	⛔	✅	✅	⛔	⛔
是否多端支持	✅	✅	✅	✅	⛔	⛔	⛔
支持微信验证	✅	✅	✅	✅	✅	⛔	⛔
友好的招聘者端操作界面（Beta）	⛔	⛔	✅	✅	✅	⛔	⛔
用户自由发布自定义组队需求（Beta）	⛔	⛔	⛔	⛔	✅	⛔	⛔

宣发和反馈

宣发努力与取得的实绩

本项目涉及到两种用户角色——需求发布者和求职者。既有 to C 的一面：我们需要对接两类用户，了解他们的需求、解决他们的痛点，为他们提供各类平台机能；也有 to B 的一面：导师、学长们发布的项目需求、招聘信息等，本身来源于实验室或企业实体。在商谈课题或项目入驻时，需要以团体为单位对接相关方，取得他们的认可和背书。

需求发布者侧的推广

从项目调研阶段开始，团队成员就提早布局，与熟识的潜在用户——实验室导师及内推学长学姐们沟通，了解他们发布实习信息、招生、招聘工作的各个环节和需求。

在项目发布阶段，团队成员进一步与意向入驻的需求发布者沟通，邀请他们体验求职者侧的使用流程，解说平台定制的需求发布、求职者申请和信息反馈机制。

即便时间紧、任务重，在团队成员的努力下，目前已与十余位老师达成入驻意向，并已有来自五个大实验室的近十项实验室实习需求在本平台上发布；科研需求之外，我们还积极与手握内推资格的学长学姐们沟通，与来自字节跳动、商汤科技、司索科技等企业的在职校友达成入驻意向，其中字节跳动的实习生内推信息已在本平台上发布。

对于本平台这样“冷启动”、慢热型的信息聚合平台，磋商和推广是长期的过程，达成目前的推广效果，已经基本完成了项目初始时对 ALPHA 阶段发布的预想目标。

求职者侧的推广

虽然由于微信小程序审核、合作方相关要求等不可抗力因素，本周中才得以开始求职者侧的推广，但平台仍吸引到了大量用户的关注和使用。

在推广形式上，团队立足学生对暑期实习的迫切需求，通过朋友圈、学生群聊等方式精确触达产品信息。

从用户实绩上看：平台基于微信小程序发布，每一账户对应一个微信账号，使用校园邮箱、小范围传播的邀请码注册，除去提供给需求发布者的测试账号，已有逾百位实名的北航求职者用户注册。从后台的统计数据来看，已有近三十位同学开始创建简历，其中一半以上同学进行了简历的实际投递。

可以认为，团队精确把握了求职者用户的需求，有望继续在求职者、发布者间实现双向的良性循环。

北航职协合作

平台针对类似项目缺乏背书、缺乏初期用户量的问题，在项目的早期便与北航职协商谈合作，积极争取，得到了对方的认可：即将于五月份进行的华北地区高校模拟群面大赛的申请和报名、信息收集、反馈等全活动流程将在本平台上进行。

在本周末，北航职协会依托“航小职”官方公众号发送活动推送，并通过“北航就业”的数个信息群宣发活动，预期能够吸引百名以上北航同学参加。活动的引入，能够进一步扩大本平台的知名度，充实平台基础用户量。

用户反馈和团队自评

Pros

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

Cons

• 邮箱验证码可能被校园邮箱拦截，部分用户需要通过邀请码注册；
• 前端 UX 方面欠缺打磨，用户反馈投递简历、已读消息等方面均存在过于突然、易误操作的问题；
• 用户反馈搜索略有龃龉，关键字匹配逻辑不太符合操作直觉；
• ALPHA 阶段的开发任务进行了调整，未能完全按计划进行：在微信审核时效不定、网站备案被打回、课程时间轴与合作项目时间轴不一致、合作方需求变更等多种因素的影响下，前端团队由双角色平台并进的预期目标调整为专注开发求职者的小程序平台，以期快速上线和获取用户；
• 目前限于开发能力和工期，平台尚只能提供一个用于管理的后台进行需求发布、申请导出和信息反馈，没有开放自助的入驻和审核机制。需求发布和反馈机制仍需团队高度介入、个性化地对接需求发布者，这制限了平台的进一步发展。

BUGs

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

软件工程质量

开发规范

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

文档管理

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

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

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

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

测试

单元测试

本阶段，我们利用Django的Test框架对代码进行了相对完善的单元测试，整体测试覆盖率达到93%。未覆盖的代码为微信登录验证、管理员界面等一些无法进行单元测试的API。单元测试覆盖率统计如下图。

单元测试共有50组，每组测试包含多个用例，测试代码超过千行。我们针对每一模块，构造了若干合法或非法行为，用以验证服务端是否能正确提供服务或处理异常。单元测试不仅涵盖了各项数据操作，还囊括了各项用户鉴权等众多安全问题，有效保证了系统的安全性和鲁棒性。测试代码的统计情况如下图所示。

每次提交代码都将自动运行单元测试，保证服务端代码的正确性。通过单元测试，我们在进行大规模重构时可以自动的发现大量的由此牵连导致的错误并迅速将其修复，极大地降低了思维负担。

压力测试

为了测试软件的性能，在使用 nginx + uwsgi 部署好服务器之后，我们使用 JMeter 进行了压力测试。测试过程均采用高并发利用全部服务器资源。

在进行压力测试时，我们对典型 API 进行了测试，API的功能以及测试目的如下所示：

API	功能	压测目的
echo	简单地将request的params返回	测试纯网络连接性能
authenticate	验证token是否可用	测试查询数据库获得User信息以及部分加密的性能情况
retrieve info	列出已登录用户的个人信息的API	常用的API，测试其性能
list offers	列出某已登录用户所能查看的所有Offer的详细信息，每次查询列出其中10个	开销最大的API之一，测试其性能
retrieve offer	展示一个Offer的详细信息	与list offer进行比较
search offers	通过关键词搜索offer	开销最大API，测试Postgresql上的jieba插件的分词和全文搜索性能

我们在测试数据库中创建了113个Offer和226个OfferJob，每个Offer和OfferJob均填充了有意义的中文文本。

Alpha最终压力测试结果如下：

测试项目	平均延时 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	4580	2722	1.73	12.9
retrieve offer	1034	596	0.00	58
search offers	3790	3392	0.00	10.3

从压测结果来看，我们认为本软件足以服务现阶段的需求。

经验和教训

开发方面的感想

DevOps 的重要性

由于团队（尤其是后端）在自动化工具上采用了高标准和最优实践，BUG 的出现大大减少，代码统一且高质量，为平台的稳定性提供了充分保障。

工期管理

项目的冲刺阶段，从燃尽图即可看出，进度出现了巨大的落后，最后不得不以通宵加班的方式完成开发。导致这一现象的原因一是微信审核等不确定性的叠加，从根本上来看更是项目分工的估计不足、容错率不高。项目前端的视图层开发与想象中相比花费了两倍以上的时间——这一迟延主要来源于对小程序端开发工具和机制的不熟悉。Beta 阶段，团队的开发重点将转移到更为熟悉的 Web 平台上来，但 ALPHA 阶段这一惨痛的教训仍应铭记在心，应进一步细致化前端的进度管理。

再谈前端开发实践

对于前端，团队基于 MVVM 思想进行开发，两位成员处理 VM、进行简单的原型开发，一位成员负责视图绘制和组装。

理想很美好，现实则不尽如人意。采用这种开发模式是我们做的最好同时也是最坏的决定。一方面，完全解耦的开发分工，不仅（在简陋的微信小程序开发环境下）消除了代码合并的问题，更大大利于调试和协作，为后期并行快速开发提供了条件；另一方面，没有层次化的 VM，搭配上高度层次化的视图层，导致了行为逻辑和数据的龃龉，视图层的组装困难程度大大加深，代码可读性下降——各调各的没问题，视图层和 VM 层之间几乎无法互相 Debug。

团队得到的启示是：除了自以为是的解耦措施之外，前端开发时在层次化、模块化方面也应当预先制定规范，统一架构再行开发。

看向开发之外——

项目合作

与职协的合作磋商和最终达成，是本团队开发之外所做最大的努力。

强有力的合作者，为平台引入了更坚固的背书、更明确的目标，以及在路上的更大声量。

但另一方面，也为平台带来了更多的要求、制限和“不可控”——尤其是在另一侧是无法松动的课程要求、既定安排的情况下。

作为产品的直接负责人——项目的开发者们，在需求和需求缠斗的正中间，面对滚动着压过来的名为工期的巨大落石，需要足够的智慧、足够谨慎的安排、留下足够的余量才能够勉强逃生，去攀登更高的山峰，去成就更为平衡、更为完善的产品。

——又或许，我们只是需要更多的实践，更多的经验，需要练就更好的与合作方沟通、探知和了解其需求的能力。

合作为我们带来了正向的促进和负向的压力。在 Beta 阶段，我们会继续挑战它——一块滚滚如雷的巨石，一方巍巍耀眼的峰顶。

团队氛围

Bravo。

——太棒了，大家！整个 ALPHA 开发过程中，团队的所有人共进退，共同面对挑战、克服困难、消解疑虑、各尽所能。我们会在初夏的阳光下兴奋地讨论产品，也曾在深夜的新主楼 G 座里一人一台电脑啃着麦当当奋战到天明。

十分庆幸，团队的七个人能走到一起，不只是完成一门课，更是完成一款雄心勃勃的产品，留下一段虽有缺憾但仍足以笑出来的回忆。

冒险仍在继续，我们将继续前行。

展望和计划

Beta 阶段，在开发上，团队将依照功能规格说明书的规划，迭代增量开发功能更丰富的求职者客户端，接续开发并完善需求发布者后台。

在宣发上，团队将继续积极对接需求发布者用户，收集、发布和维护需求，保全信息——这一平台的生命之源。

结合用户反馈、团队成员的总结和分析，Beta 阶段还计划额外开发学生组队、比赛等需求的发布渠道，拓展平台的功能和受众。