最近陆续出现过好几次，团队迭代交付的时候，出现的信息不对称的问题，直到迭代评审验收的时候才发现？原来这个迭代我们还被安排了这样的事情？或者，原来这个事情怎么和我们做的事情是两个事情？
原因有几个，迭代的输入没有统一起来，类似这样改进类的任务，也需要纳入到PO Meeting有统一的入口，因为团队最主要还是要承担业务需求，之余才是各种改进task，由统一的PO入口并根据优先级排序，PO会权衡团队在业务和改进上的权衡，我们似乎也也样尝试了，可为什么会出现改进task和实际团队做的事情是两件事情的问题？
原因有二:
- 团队的BA统一规划团队本迭代要完成的各项任务，包括业务需求，改进任务。如果改进任务是直接下发到个人，而不是经统一入口BA下到团队，当BA根据团队优先级给队员下发的任务和项目下发到个人的任务发生冲突的时候，必然有一方的任务无法完成。
- 改进任务的AC是由项目来写的，就像业务需求一样，用户只知道最终想要达到什么效果，却因为对团队很多细节不清楚，无法把握住细节，改进类的TASK和STORY的拆分一样，必须满足SMART原则，否则就会出现一个任务很多个迭代都完不成，外部客户看来一直进展缓慢，完成风险很大。这跟需求的跟踪管理是一个道理。
究竟应该怎么做？
*改进类的任务，应该和业务需求走相同的流程。小妹儿和范范，在TFS上拆分出feature，写feature的AC，PO Meeting上，和PO一起，跟团队澄清想要团队承担哪些改进事项，三方一起权衡协商后，讨论出下迭代要做的事情的范围。圈定后，下来由团队BA拆分task并写AC，并在计划会上就业务需求和改进TASK和团队一起澄清，并向PO反馈最终的承诺。这样一个过程，才能保证，入和出，以及要做的事情的范围都是几方协定并共同给出的，且已经被拆分成适合的粒度，更容易在迭代内完成，也让外部更容易看到进展。
图片发自简书App
