<问题1> 需求丢失
情况回顾
运营同学OP-A就某产品提出一个改动点REQ-1。
产品同学PD-B响应了该需求，判断该需求比较简单，转交给研发同学RD-C。
RD-C当时有其他任务，计划忙完后实现REQ-1。
—
>RD-C因为忙忘记了修改。
>>PD-B没有关注任务是否已经完成。
>>>OP-A几天后在生产环境部署服务，发现问题并没有修改，给运营工作带来问题。
问题分析
事实上，本次流程还存在以下错误，包括：
1）没有通知测试同学；
2）没有同步产品组长、没有同步研发组长。
解决措施
这类小改动在产研团队比较普遍。我们想找一个简化的流程避免此类问题。
1、所有确定要实现的需求都要记录在“产研工作看板”。
我们之前已经实现了大需求纳入流程化管理，但没有关注这类临时小需求的管理。这类任务很简单，往往几句话就可以说清楚，在工作看板记录一个标题即可。
2、研发同学必须看见“工作看板”有项目才启动工作。
有一些简单的任务不需要复杂的设计、评审流程。我们提出此方式是为了寻求一种灵活性，同时避免过程管理失控。
3、产品、研发、测试同学每日都要关注“工作看板”
我们不能假设产品成员、研发成员都能自发的推动任务，并衔接好上下游。此项职责应该由各线组长负责，由当事成员具体执行。故所有任务进入“看板”，同时上下游岗位都关注看板：可避免再次出现任务遗漏。
<问题2>历史功能上线出现异常
情况描述
产品线C有个功能FEA-1在2个月前就完成开发完成功能测试，但一直未实际使用。该产品在2个月期间经历了若干迭代。近日FEA-1上线使用，运行一段时间发现数据存在异常。
—
我们意外发现看起来在正常工作FEA-1，但后台数据存在问题。
当天晚上4位成员花费总共16小时修复bug，并修正了异常数据。
该问题被意外发现并被及时修复，没有产生更多损失。
问题分析
该问题源于一个长期未用的功能在迭代过程可能被意外影响。
另外该功能也是第一次上线使用，第一次上线建议可以帮助我们发现更多潜在问题。
解决措施
1、一个持续更新的产品中如果打算启动长久未用的功能，需由测试同学重新做一轮测试。
可以说，测试成果具有“保质期”的概念。可由运营同学识别并提醒产品组长即可，是否要做测试由产研团队讨论决定。
2、对于新功能第一次上线运营，产品同学和测试同学需关注上线效果
我们也许无法消除所有影藏的bug，第一次上线运行却是很好的发现错误机会。此项职责由该需求的产品经理负责。
3、产品和运营同步
产品组长有职责了解运营的工作计划，可对这类工作提前做出安排。
