作业2
团队绩效评估计划
一、其他团队的绩效评估方法调研
在制定我们的绩效评估方法之前，我们先调研了其他几个团队的做法规避。
有的团队采用KPI量化法，根据代码行数和功能点数来打分。优点是可量化、容易比较，缺点是会鼓励堆砌代码而不是写出高质量的代码，代码行数多不代表做得好。
有的团队采用360度互评法，每个成员给其他成员打分。优点是评价比较全面，考虑了团队协作的因素，缺点是耗时比较长，而且难免有主观偏见，关系好的打分就高。
有的团队采用OKR目标管理法，把目标分解成关键结果来考核。优点是目标导向明确，与项目进度挂钩紧密，缺点是周期比较长，不太适合我们这种两周的短期项目。
有的团队采用贡献度自评加互评结合的方法。优点是灵活，能考虑个人感受，缺点是主观性太强，可能会不公平。
有的团队采用任务完成率加代码Review的方法。优点是兼顾了数量和质量，缺点是需要有专人做Review，增加了工作量。
综合这些方法的优缺点，我们设计了自己的评估方案。
二、本团队绩效评估方法
我们采用量化指标、互评反馈、项目成果三个维度相结合的评估方法，权重分别是百分之四十、百分之三十、百分之三十。
量化指标部分，占百分之四十
这部分主要看四个方面。任务完成率占百分之十五，按时完成分配的任务就得满分，每延期一天扣两分。代码质量占百分之十，主要看Bug率、是否遵循代码规范、是否通过了Review。功能完成度占百分之十，看完成的功能是否达到预期效果。文档质量占百分之五，看文档是否清晰完整、是否及时更新。
互评反馈部分，占百分之三十
这部分是匿名的，每周五每个成员给其他成员打分，然后取平均分。
主要评估四个方面，每个方面一到五分。团队协作态度，看是否主动帮助他人、是否积极配合团队工作。沟通响应速度，看消息回复是否及时、会议是否准时参加。技术分享意愿，看是否愿意分享技术经验和心得。责任心，看对自己负责的任务是否认真负责到底。
项目成果部分，占百分之三十
这部分由组长和指导老师根据最终产出打分。
核心功能占十五分，看隐患管理、AI分析等主要功能完成得怎么样。创新亮点占十分，看AI思考可视化这种有特色的功能做得好不好。整体质量占五分，看系统稳定性怎么样、用户体验好不好。
三、第一阶段绩效评估结果
根据这个方案，我们对第一阶段的四位成员进行了评估。
前端开发同学的量化指标得了三十五分，任务基本按时完成，代码质量还行，功能都实现了，但文档更新有点不及时。互评反馈得了二十六分，团队协作态度不错，但沟通响应速度一般，技术分享较少。项目成果得了二十六分，核心功能完成了，创新亮点也有贡献，但细节上还有一些bug。总分八十七分，评级为A。
AI模块同学的量化指标得了三十四分，AI核心功能完成了，思考可视化的效果不错，但时间估计不太准。互评反馈得了二十七分，主动性比较强，愿意帮助别人解决问题。项目成果得了二十七分，AI部分是项目的一大亮点。总分八十八分，评级为A。
测试和文档同学量化指标得了三十三分，测试用例写得比较全面，但手机端的bug还是漏掉了一些。互评反馈得了二十五分，工作认真负责，但有时候反馈问题不够及时。项目成果得了二十四分，文档质量还可以，但更新不够及时。总分八十二分，评级为B加。
UI和协作同学量化指标得了三十二分，完成了UI设计，但缺少专业度，手机适配做得不够好。互评反馈得了二十六分，团队协作态度好，会议组织得不错。项目成果得了二十五分，视觉风格统一是加分项，但细节问题较多。总分八十三分，评级为B加。
团队平均分八十五分，整体评级为B加。
四、第一阶段暴露的问题
通过这次绩效评估，我们总结出了几个问题。
首先是需求理解不一致。同样是看需求文档，不同成员理解出来的结果不一样，导致开发出来的功能和预期有偏差。解决的办法是，开发之前先画原型图，大家确认清楚了再动手。
其次是代码整合困难。每个人写的代码风格不一样，合并的时候经常起冲突，要花很多时间解决。以后要统一代码规范，而且频繁提交代码，不要攒很多再一起合并。
第三是手机端测试不足。很多手机上的bug都是在最后才发现，那时候已经来不及改了。以后开发阶段就应该在手机上实时调试，不要等到最后才测试。
第四是时间估计不准。预估一天能完成的功能，最后往往用了两三天。以后要多留一些缓冲时间，而且要把大任务拆解成小任务，每个小任务单独估计时间。
第五是文档更新滞后。代码改了好几版了，文档还是最初的那个版本。以后要边开发边写文档，不要等到最后才补。
第六是代码Review缺失。没有经过Review的代码直接上线，容易出问题。要建立Review机制，每个功能上线前至少被另一个成员看过。
五、后续改进计划
针对这些问题，我们制定了后续改进计划。
最高优先级的是建立代码Review机制，大概需要半天时间，全员参与。同时要统一开发规范，包括命名规范、格式规范等，也需要半天，由前端负责人推动。
中等优先级的是每周开一次同步会，及时对齐进度和问题，每周一个小时，全员参与。还要建立共享知识库，用语雀或者飞书来记录经验和文档，预计一天，由负责文档的同学来做。
较低优先级但长期要做的是增加自动化测试，减少人工回归的工作量，预计两天，由测试同学负责。以及每个阶段结束后的复盘会，总结经验教训，全程参与。
六、个人绩效评估表模板
我们设计了一份个人绩效评估表，供后续阶段使用。
第一部分是自评，占百分之四十，包括任务完成情况、代码或工作质量、功能完成度、文档完善度四个小项，分别占十五分、十分、十分、五分。成员自己给自己打分，并写出说明。
第二部分是互评，占百分之三十，包括团队协作态度、沟通响应速度、技术分享意愿、责任心四个小项，每个项一到五分，取其他成员评分的平均分再乘以六。
第三部分是成果评估，占百分之三十，由组长打分，包括核心功能、创新亮点、整体质量三个小项，分别占十五分、十分、五分。
最后是总分和评级。九十分以上是S级，八十分以上是A级，七十分以上是B级，六十分以上是C级，六十分以下需要改进。
下阶段还要写两到三个改进目标，明确下次评估要达到什么结果。
七、绩效评估总结
回顾第一阶段，做得好的地方有几点。全员都按时完成了基本任务，没有出现掉队的情况。团队协作的态度整体是积极的，没有人推诿扯皮。AI思考可视化这个功能确实有特色，得到了测试同学的认可。
需要改进的地方也不少。时间估计要更准确，不能再把一天能做完的事情估计成半天。沟通效率有待提升，消息回复应该更及时一些。代码质量需要把关，不能因为赶进度就牺牲质量。文档要及时更新，不能代码改了文档还是旧的。
下一阶段的目标是团队平均分达到九十分以上。要重点解决数据安全、防错设计这些核心问题。还要建立起规范化的开发流程，不要让问题重复出现。
博客总结
通过这次项目开发和绩效评估，我们认识到了很多问题。
做一个能用的软件和做一个好用的产品，中间的差距比我们想象的要大得多。数据安全和防错设计是软件的生命线，这两条没做好，其他功能再花哨也没有用。和成熟商业软件的差距是全方位的，从架构到安全到生态，我们要走的路还很长。团队协作需要有规范和流程来保障，不能只靠自觉。
我们会正视这些不足，在后续阶段认真改进。