我会按照项目核心信息的逻辑顺序,将内容整理为通顺的正常文本格式,去除所有加粗符号,同时保留各部分关键信息和结构,确保信息完整且易于阅读。
租易 - 快捷租房管理小程序:项目核心信息
- 项目的需求分析和商业前景
a. NABCD
- N (Need 需求):
管理者(物业/托管公司):需要高效管理分散的房源、收取租金、处理报修,目前依赖Excel和微信群,效率低下,对账困难。
房东:特别是拥有多套房产的房东,缺乏便捷的工具来管理租约、收租和了解物业状态。
租客:希望有稳定的线上渠道支付租金、一键报修、查看账单,并与管理方/房东便捷沟通。 - A (Approach 做法):开发一个微信小程序,提供三个不同权限的入口:
管理者端:仪表盘总览、房源管理、租约管理、财务统计、工单分配。
房东端:我的房源、租约查看、租金收入查看。
租客端:我的账单、在线支付、一键报修、联系房东/管理方。 - B (Benefit 好处):
为管理者提供数字化管理工具,提升效率,降低沟通成本。
为房东提供透明的资产管理和收益查看。
为租客提供便捷的“支付-报修”一站式服务,提升租住体验。 - C (Competitors 竞争):竞争对手有“贝壳找房”“自如”等大型平台,但它们更侧重于交易前。我们专注于交易后的管理、支付与维护轻量化工具,切入细分市场,降低使用门槛。
- D (Delivery 交付):通过微信小程序直接推广,初期与本地小型房产托管公司合作,让他们引导其管理的房东和租客使用。通过校园周边租房市场进行地推。
b. 项目的新闻稿和FAQ
- 新闻稿标题:《“租易”小程序正式上线,致力成为租房管理领域的“轻骑兵”》
- FAQ:
Q: 使用“租易”收费吗?
A: 租客端完全免费。管理者/房东端的基础功能免费,高级数据分析功能未来考虑采用订阅制。
Q: 发布后预计的活跃用户数?
A: 我们预计在发布后3个月内,通过与2-3家本地托管公司合作,实现约500名月活跃用户(MAU)。
c. 软件的典型用户
- 王经理(物业管理者):35岁,负责管理一个拥有200套分散式公寓的托管公司,追求效率。
- 李女士(多套房房东):45岁,职业股民,拥有5套出租房产,关心资产状态和租金准时到账。
- 小张(年轻租客):22岁,大学生/应届生,习惯移动支付,追求生活便利。
d. 典型用户场景
场景:租客小张的卫生间水管漏水。
- 小张打开“租易”小程序,点击“一键报修”,拍照描述问题后提交。
- 王经理的后台立即收到工单通知,并将其分配给合作的维修师傅。
- 维修师傅接单、维修、完成后在小程序内确认。
- 小张收到完成通知,并可以对服务进行评价。整个流程线上化,无需反复打电话催促。
e. 发现用户需求的方法
- 解决自己的痛点:团队成员有租房经历,亲身感受过报修难、沟通不便的痛点。
- 深入面谈:与2位本地房产中介负责人和5位有租房经验的同学进行了半结构化访谈。
- 用户调查问卷:在校园内发放了线上问卷,回收有效问卷120份,量化了用户对在线支付、报修等功能的期待程度。
- 项目的团队、估计和设计
a. 团队成员与团队模型
- 陈鉴祥:全栈开发 & AI助手应用专员
- 张廷智:前端开发 (微信小程序)
- 何绍斌:后端开发 & 数据库设计
- 郑权:项目经理
- 团队模型:我们采用功能团队模型,每位成员在主导自己领域的同时,也参与其他环节的讨论与评审。我们采用敏捷Scrum框架,由陈鉴祥担任SCRUM Master。
b. Alpha版功能列表
- 用户身份认证与多角色登录
i. 必要需求
ii. 卫生属性 - 管理者/房东:房源信息管理(增删改查)
i. 必要需求
ii. 核心功能 - 租客:在线查看账单与支付(模拟支付)
i. 必要需求
ii. 杀手功能 - 租客:一键报修 & 管理者:工单处理
i. 必要需求
ii. 核心功能、让人惊喜的功能(如果流程足够流畅)
c. 工作估计与方法
- 估计方法:采用计划扑克进行故事点估算。参考历史速度(Velocity)来预测每个Sprint能完成的工作量。
- 典型功能(在线支付)的WBS:
- 设计支付界面UI (1天)
- 后端创建支付订单API (1.5天)
- 集成微信支付SDK(或模拟接口)(2天)
- 前端调用支付接口并处理回调 (1.5天)
- 支付状态更新与通知 (1天)
- 单元测试与联调 (1天)
总计预估:8人天
d. 收集NPS(净推荐值)
我们计划在用户完成一次关键操作(如成功报修或支付)后,弹出一个简单的评分框(0-10分),并询问“您有多大可能向您的朋友或同事推荐‘租易’?”。同时,也会在阶段性项目结束后,通过用户问卷进行更深入的NPS调查。
- 项目的具体开发和推进
a. 代码质量保证
- Git Flow: 采用简化的GitHub Flow模型,即main分支为稳定版,所有新功能从main拉取feature/*分支开发,完成后通过Pull Request合并,强制要求至少一名其他成员进行代码审查。
- 代码规范:前端使用ESLint,后端使用Prettier统一代码风格。在PR合并前,必须通过CI流水线(使用GitHub Actions)的自动化测试(包括单元测试)。
b. AI编码工具的应用
我们积极使用GitHub Copilot和Cursor等AI工具,主要用于:
- 生成重复性代码(如CRUD API模板)。
- 编写单元测试用例。
- 辅助代码注释和文档生成。
确保正确性:我们坚持TDD原则。在实现一个支付功能前,先编写该功能的失败单元测试。然后利用AI生成代码草案,并运行测试直至通过。最后进行人工审查,确保代码逻辑与业务需求一致,而不仅仅是测试通过。
c. 推动开发进展
我们通过每日站会同步进度、困难和计划。站会记录(包括成员更新、遇到的阻塞问题)会简洁地发布在团队博客中,作为过程证据。具体格式遵循课程链接中的要求。
d. 参考团队博客
我们已仔细阅读福州大学团队的博客,从中学习了如何有效地进行任务分解、进度可视化和团队协作,特别是在Beta阶段如何根据用户反馈进行快速迭代。他们的经验对我们规划自己的Sprint非常有帮助。
- 个人在团队中的贡献,个人和团队的关系
a. 团队贡献分决定
我们将参考链接中提到的“多种投票法”结合贡献度矩阵来决定。在每个Sprint结束时,我们会从完成的任务量、完成任务的质量、在代码审查和设计讨论中的参与度、以及帮助队友解决问题等多个维度进行匿名互评和自评,综合得出每个人的贡献分。
b. Alpha阶段后成员流动
如果需要有成员离开,我们团队将通过集体投票的方式决定。投票将主要依据两个因素:1)该成员的个人发展意愿;2)其对当前项目核心技术的掌握程度,以确保剩余团队的技术栈平衡。我们会以公开、公正的方式进行沟通和决策。
- 项目的总结
a. 预先总结
如果八周后项目失败,我们直觉上认为最大的可能因素是: - 需求不聚焦,范围蔓延:试图一次实现太多功能,导致每个功能都不完善。
- 技术选型或架构失误:例如数据库设计不合理,导致后期频繁修改,影响进度。
- 团队协作出现问题:沟通不畅,任务分配不均,导致关键任务延迟。
- 低估了微信小程序审核与发布的复杂度:导致最终无法按时上线。
整理后的内容已清晰呈现项目各模块信息,若你需要调整内容顺序、补充细节,或对某些部分进行简化/扩展,都可以随时告诉我。