在技术同学与产品同学的双方交涉过程中，一次、两次的需求变化还可以接受，但频繁需求变化之后，产品同学表示他的权限不够，如果还需要进行变化需要上报负责人审批，由于过于频繁的变化，一级 Lead 权限也有限，需要更上级的 Lead 同意，总结审批，产品同学便发现自己这么频繁需求的变化可能会导致上级领导误会他是名不靠谱的员工，因此产品同学不得不在需求初期便想得更清楚，避免后期又出现这种状况。

产品同学在调研、绘图、写文章、评审的几个过程之后才完成一份完整的文档；而技术同学也有设计、评审、工作任务分解的过程。每个团队都有自己的工作，不可能产品同学需要技术同学的帮忙，技术同学便可以马上拿出时间来。他们都需要提前安排时间。因此时间第一，控制需求变化频率不变要有代价。除了需要改进需求、需求评审，还有设计和设计评审环节，这样的方案才更靠谱。但尤其注意的是，工作任务分解，其现阶段要求分解到半天级别，这样即使分解出现不准确时间也不会有特别大的差距。

4、质量篇

1 数据说话、数据收集、bug 收集与分类

线上 bug 多，便投入大量的时间修改 bug。大多数公司表示线上 bug 是最高优先级的，用户反馈需要修改 bug，公司会优先解决，这也是个高优选择。线上出现 bug 需要修复，在很多情况下，该临时状况并未考虑在项目排期过程中，因此经过多次的经验总结，需要保留 10%-15% 的空间安排修改 bug，否则项目上线、bug 修改，两件事的冲突最终结果仍然是加班完成任务。需求原因、项目流程原因、线上质量原因等各种因素都会导致加班结果，因此也需要不断进行技术改进，减少线上 bug 问题，做更靠谱的未来排期。

数据说话解决主要矛盾。项目出现问题需要数据证实，但是项目的初期不存在数据，因此不得不花费一两个月的时间做数据的总结和收集，并得出该期结论。比如，运营产品团队的后台配置失误、优惠券的打折出错等需调整数据的问题也属于 bug；你作为新用户用手机号注册 58 到家，但是过一段时间之后，你换了手机号码，但发现没有这个功能，于是提交订单请求修改数据。

然而并不是所有类型的 bug 都需要第一时间接入进行修复。用户侧影响较大的需要第一时间解决，但后台侧、体验侧、优先级低的问题不需要立马解决，可采取一些措施。首先进行 1 至 2 个月的数据收集，进行问题分类，对每类问题进行针对性地解决。第一类，难以避免的配置错误，被提供的系统运营和产品配置之间存在错误，但是犯错是存在代价的。需求变化是正常的，第一次错误帮忙解决，第二次犯错经理审批。多次的犯错需要从自身找出原因，知识缺乏、技术缺乏、态度不端正等因素，任何的犯错都需要代价。

举个例子，技术同学抱怨自己的工作没有技术含量，因为他日常的事情都在接受修改用户手机号的需求，在数据库中修改数据，并且日复一日地做这乏味的事情。产品反馈功能优先值较低，每个月只有一两次帮忙修改，但是大家都不会设想未来随着人数的增多，流量的增多，业务的发展，此类情况可能会变成高频发事件。对于低频的事件，RD 需要手动修复数据做成功能。Bug 不分优先级，但需要 RD 第一时间介入修复，规范流程。

2 bug 修复流程

如上图，Bug 修复流程。Bug 解决也是一个流程，研发团队需要和产品、运营团队、PMO 沟通、讨论、确定线上 bug 解决流程。而在 bug 处理流程中，大多数是用户侧提出来的 bug，并且确定其确实为 bug，而不是功能和策略，且该部分的 50% 已被 down。达到研发团队的 bug，评判优先级较低，且需要一个复现的过程，请求 QA 确认过程。优先级是依靠产品的方案进行快速判定，发现不能跟踪的第一时间必定通知了研发团队。然而并不是所有问题都是有技术团队面向客户群体，高优 bug 在当天晚上 24 点下班之前必须解决；次有问题 48 小时必须解决；之后便是两周之内，最后影响不大的未来在考虑。

5、技术含量篇

1 深刻思考的重要性