本日志是作为邹欣老师在中关村学院开设的《软件工程》课程的团队编程项目开发记录。邹欣老师关于软件开发和其中团队合作的管理有很多经验和独到看法。
在我们学院中,有一部分同学是非计算机背景来做AI或AI交叉项目,没有编程经验,但可能有更好的市场需求远见,因此这种希望带有商业目的团队编程作业可能很好得发挥不同同学的优势,同时加速跨专业编程知识的学习。
1、需求与商业分析
1.1NABCD
1.1.1 N-Need
本人参与过学校的很多宣传工作,对于一些重视宣传工作的单位或组织(特别是有微信抖快红全媒体矩阵)每天有大量的照片需要管理和媒体分发。在最常见的工作场景中,照片由负责摄影的人员拍摄并通过微信提交给负责推送编辑的人员,这个过程会有多个问题,以下是两个核心问题:
1️⃣在一些摄影师比较多的大型活动,或者是长期接收照片稿件的项目,负责接收照片的人的消息会非常混乱。
2️⃣在后续需要调用以前照片的时候(例如年终总结)会很难检索
3️⃣一些组织会通过推送或新闻稿仅用来活动留痕,完成这个项目或许可以避免劳动力浪费(做一些无意义的文字撰写和排版)
简而言之就是优化照片的:
上传—>管理—>下载使用
流程
1.1.2 A-Approach
我们的成员都不是很专业的软件开发者,甚至有些刚接触代码,对于软件该有的架构规范都不太了解,因此vibecoding是最适合我们的。
在前期也可以先调研是否有开源的图库软件可以直接使用修改,如果不能商用,我们至少可以先通过它们学习图库的软件架构大概应该是什么样的。
1.1.3 B-Benefit
我预期希望用户得到的好处是确确实实优化了集体的照片管理。
1.1.4 C-Competitors
事实上类似的竞品有很多,比如百度网盘也可以实现图片管理,但我作为一个摄影爱好者兼校宣传工作者,发现我所了解的组织完全没有使用他们的,无一不使用微信或钉钉工作流。这其中的原因很明显,因为微信钉钉本来就是最常用,几乎没有学习成本,特别是遇到一些比较紧急的情况,一般人能想到的肯定只有把照片直接拖到微信钉钉发给需要的人,这在临时情况非常无脑快捷(即便很不方便后续管理,但这就和很多人还是会建立名称为"111111"的文件夹一样)。
所以我们要做的产品需要有两个竞争优势:
1️⃣学习成本够低,在使用过程中尽量无感
2️⃣有明显好用的功能,让大家不得不使用它
问题1️⃣可以有很多角度来优化,如使用微信小程序的形式,毕竟大家本来就乐意用微信……
还要做好一个设计师,让上传、阅览、搜索等常用的界面做的尽量显著和快捷。
问题2️⃣很难想,我并不认为我的核心Benefit是一个用户极度需要的功能,解决问题1️⃣是首要。
1.1.5 D-Delivery
因为这个软件需求场景就在身边,我认为初期推广还是比较简单的。直接把这个产品丢给社团或者学校去用,听听反馈,然后优化。这个产品如果能够真正解决组织工作者的核心痛点,自然会在“牛马”之间口口相传。
后期可以通过小红书去推广,特别是高校辅导员最钟爱小红书,他们是核心用户之一。
2. 项目的新闻稿和FAQ
新闻稿草案:
标题:“智能照片管理,让团队协作更简单——全新照片管理软件助力宣传工作者”
正文:在全媒体时代,组织和企业每天面临海量照片管理挑战。传统微信/钉钉传输方式导致照片混乱和后期检索效率低下。我们团队基于实际需求,开发了一款专注于照片上传、管理和下载的软件。通过微信小程序和智能分类,用户可轻松管理照片,提升工作效率。alpha版本已在校内测试,获得积极反馈。预计发布后三个月内活跃用户达500人,覆盖高校和中小企业。
FAQ:
-
Q: 软件是否免费?
A: 初期测试版本完全免费,未来可能针对高级功能(如云存储扩展)推出付费计划,政企单位认证需直接购买。 -
Q: 如何上传照片?
A: 支持微信小程序直接上传,也可通过Web端拖拽操作,简单快捷。 -
Q: 照片存储安全吗?
A: 照片加密存储于云端,仅用户和授权组织内部可访问,确保隐私。 -
Q: 如何检索照片?
A: 支持关键词标签、时间筛选和AI基于内容的智能搜索,AI内容于Beta版本开发。 -
预计活跃用户:
-
发布后第一个月:30人(某宣传部内测试)。
-
第三个月:200人(扩展至校内多个宣传部)。
-
第六个月:1000人(拓展至全校)。
-
3. 软件的典型用户
-
高校宣传工作者:如学生会宣传部门成员,负责活动拍照和推送编辑。
-
社团摄影人员:经常拍摄活动照片,需共享和管理大量图片。
-
企业宣传员工:管理公司社交媒体账号的照片内容。
-
非技术背景的组织管理者:注重效率,希望减少工作流程复杂度。
4. 典型用户使用软件的典型场景
场景:学校社团举办大型活动后,领导通过小程序派发摄影任务,摄影师通过微信小程序派发链接上传数百张照片至系统。系统自动添加活动标签(如“2024迎新晚会”)和时间戳。负责推送编辑的同学登录Web端,输入关键词(如“舞台照”)快速检索到所需照片,通过快捷键一键实现照片到推送的粘贴制作。整个过程无需多次微信传输,避免消息混乱,节省30%以上时间。
5. 你们团队是用什么样的方法来发现用户需求的?
我们希望结合多种方法确保需求准确:
-
(已有)解决自己的痛点:团队成员参与学校宣传工作,亲身体验照片管理问题(“吃自己的狗食”)。
-
深入面谈:与10+名同学和老师交流,了解他们的工作流程和痛点。
-
可用性研究:在alpha版本中观察用户操作,记录难点。
6. 项目的团队、估计和设计
6.1 团队成员的角色和团队模型
-
角色分配:
-
前端开发(1人):负责微信小程序和Web界面,使用JavaScript/React。
-
后端开发(2人):处理服务器、API和业务逻辑,使用Python/Flask。
-
数据库管理(1人):设计MySQL数据库结构,优化查询。
-
AI助手:全员使用GitHub Copilot和ChatGPT辅助编码,提高效率。
-
-
团队模型:采用敏捷开发中的SCRUM模型,迭代周期为2周。
-
SCRUM master:由项目带头人(我)担任,负责组织站会和任务协调。
-
协作方式:避免“一窝蜂编程”,通过分工和每日同步确保进度。
6.2 第一版(alpha)发布时,能支持的功能
alpha版本仅开发微信小程序端,聚焦核心功能,确保解决用户必要需求:
-
照片上传功能:
-
分类:核心功能
-
必要需求:是(解决上传混乱问题)
-
卫生属性:必须稳定易用
-
-
照片分类和标签功能:
-
分类:核心功能
-
必要需求:是(优化管理)
-
杀手功能:提供AI接口供beta版接入
-
-
照片检索和下载功能:
-
分类:核心功能
-
必要需求:是(解决检索困难)
-
让人惊喜的功能:智能搜索支持自然语言查询
-
-
用户管理功能:
-
分类:外围功能
-
辅助需求:是(支持多级组织内部管理)
-
卫生属性:确保权限和安全
-
6.3 对于工作的估计
-
估计方法:采用故事点估计法(基于复杂度,1点=1天工作量),结合团队速度调整。例如:
-
照片上传功能:3点(前端1点 + 后端2点)。
-
-
典型功能的Work Breakdown Structure (WBS):
以“照片上传功能”为例:-
需求分析(0.5天)
-
UI设计(1天)
-
后端API开发(2天)
-
测试与调试(0.5天)
-
总估计:4天
-
6.4 如何收集用户对你们产品的NPS?
-
在软件中直接提问:用户完成关键操作(如首次检索)后,弹出NPS调查(“从0-10分,你多大可能推荐本产品?”)。
-
事后用户调查:通过邮件或微信发送问卷,附加奖励(如免费存储空间)提高回复率。
-
定期分析:每月计算NPS分数,结合用户反馈优化产品。
7. 项目的具体开发和推进
7.1 代码仓库如何保证代码质量?
-
Git Flow工作流:
-
分支模型:master(稳定版)、develop(开发版)、feature/xxx(功能分支)。
-
所有功能通过Pull Request合并,需至少1人代码审查。
-
-
代码规范:
-
前端:ESLint + Prettier强制规范。
-
后端:PEP8规范,使用Black格式化。
-
数据库:SQL规范,避免冗余。
-
-
持续集成:使用GitHub Actions自动化测试和部署,确保代码质量。
7.2 在研发过程中,如何运用AI coding工具?
-
作为积极贡献者:全员使用ChatGPT和Claude Code生成代码片段、文档和测试用例。
-
确保正确性:
-
采用TDD(测试驱动开发):先写单元测试,再用AI生成代码通过测试。
-
每一步验证:AI生成的代码需通过手动审查和测试覆盖率检查(目标>80%)。
-
-
一致性维护:AI工具用于辅助,但最终决策由团队成员负责,避免过度依赖。
7.3 如何推动开发进展?
-
Weekly SCRUM:每周例会(线上/线下),每个成员汇报:
-
进展
-
计划
-
遇到的障碍
-
-
记录方式:在团队博客中每日更新站会摘要,参考要求。
7.4 参考福州大学本科生团队的博客
-
-
强调用户反馈循环:定期发布beta版本收集意见。
-
博客记录详细:每日站会和反思公开透明,增强团队 accountability。
-
-
借鉴他们的做法,我们也将博客作为主要沟通平台,确保进度可视。
8. 个人在团队中的贡献,个人和团队的关系
8.1 你们团队如何决定每一个人的团队贡献分?
参考邹欣老师的文章,我们采用多维评估:
-
评估因素:
-
工作量(30%):完成任务数和代码提交量。
-
代码质量(30%):通过代码审查、测试覆盖率和Bug数量衡量。
-
成员互打分(20%):参与讨论、帮助队友、文档贡献。
-
带头人评估创新与主动性(20%):提出改进建议或解决关键技术问题。
-
8.2 在alpha阶段后,如何决定离开团队的成员?
-
决策方式:结合贡献分和团队投票,确保公平。
-
贡献分最低的成员进入候选名单。
-
团队投票(匿名)决定去留,考虑个人意愿和技能匹配。
-
如果多数成员同意,该成员需离开并加入其他团队。
-
-
目标:激励每个人积极参与,同时保持团队活力。
9. 项目的总结
9.1 预先总结(pre-mortem)
如果项目在八周后失败,直觉原因可能包括:
-
时间管理不当:团队成员跨专业,课程负担重,导致进度延迟。
-
技术挑战:缺乏经验,在AI集成或云端存储上遇到瓶颈。
-
用户需求偏差:产品未切中痛点,用户拒绝切换 from 微信。
-
团队协作问题:沟通不足,任务分配不合理。
-
推广失败:未有效触达目标用户,缺乏持续反馈。
我们将定期复盘, mitigate 这些风险。
9.2 事后诸葛亮会议(postmortem)
-
在alpha阶段后,我们将召开postmortem会议,总结成功与失败,具体内容在团队博客4中详细记录。
结束语:作为项目带头人,我将确保团队每周回顾此博客,对齐目标。我们欢迎反馈,共同迭代产品!
755

被折叠的 条评论
为什么被折叠?



