2020-12-03 ITIL项目跟踪日记（3）

团队经过第二个迭代周期，完成了一版设备台账的功能（第一个迭代因为准备不充分，没有完成既定目标，没有完整的产出）。

我让团队负责人组织一个迭代验收会，除了拉上PO之外，还将系统的两个关键用户拉上，一个角色是用户方负责人——买单的，一个类似于用户方项目经理。

在会上，用户方提出了很多PO没有考虑过的问题，仅仅设备台账的属性就提出了很多新的要求，然后提出了导入台账数据时，要一次性的进行数据的校验，另外为了灵活的应对某些外部检查的场景，能够有隐含的配置功能，可以根据检查时的情况配置能够查看到的数据范围。

会上，用户方负责人明确了优先级，优先将台账搞明白，用户、PO一起去核对台账的属性、字典项等。到12月底，要把台账做完，需求中的流程能完成多少就完成多少。

然后进入了第三个迭代。

在第三个迭代过程中，PO针对台账，提出了一个新的要求，台账列表要将所有字段显示出来。台账的字段很多，所有字段显示出来的话，列表各项宽度会很窄，比较难看，然后再出一个横向的卷滚条。由于开发平台的限制，开发人员不能自由的调整页面的显示样式。开发人员认为这样不合适，但PO只说是用户方负责人提出的，也没说为什么要提这个要求。

于是就为了这个问题，开发负责人十分纠结，感觉之前的需求一直在变，现在还是各种变，觉得迭代目标不够清晰，在微信群里反应这个情况，然后我给出的建议是，开发一定要问PO“为什么”，无论是谁提的，都要弄明白背后的意图。然后开发和PO沟通，PO让开发估算一下新需求的工作量，她再去和用户协商。

我们内部开了个讨论会，包括我，部门负责人，开发负责人。讨论中部门负责人又提出一个解决方案，如果能实现让用户自己配置可以显示哪些列，就将问题解决了。其实这个在另外一个项目中实现过，但使用的不是同一个版本的开发平台。我判断，现在要实现这个功能难度有点大。

我问了开发负责人几个问题：

如果现在按原有方案实现，以后再实现这个显示所有列的功能、甚至可以配置列的功能，会不会导致现在的功能白做？这个工作之间有依赖关系没有？

开发负责人认为不会影响，而且没有依赖关系。

那么，这个需求可以拆分为三个小的故事：第一个故事，完成一个简单的台账列表显示，即原定的方案，这是必须完成的。第二个故事，实现可以显示全部列的功能，这个是可以有的，但优先级没有那么高。第三个故事，实现可以由用户自行配置显示列的功能，这个是可以有的，但优先级最低。

对于12月底目标的问题，我问开发负责人：如果按原计划要求把台账和流程做完，你们能完成吗？她回答说完成不了。然后我又将迭代验收会上用户方负责人提出的目标给她复述了一遍，反复强调“我们12月底要上线的目标从来就没有调整后，我们只是根据团队实际的进展在调整上线的范围”。她说理解了（不知道她是否真的理解了这个目标，以及这么做的意义）。

然后我们就说，让PO去找用户沟通下吧。

会后，部门负责人在微信群里发了一个他在网上去搜索的如何实现自定义显示列的解决方案。开发负责人回应说“明天我们研究一下”。我实在按捺不住了。在群里发了一个MoSCoW的优先级排序方法。但估计大家还是看不明白，于是立即给用户（是自己单位内部的用户，彼此熟悉）打了个电话，询问她提出这个需求的意图。弄明白了她的意图，然后我按照MoSCoW的排序方法给了她一个解决方案，就她这个需求的优先级达成一致（这个需求优先级比较低），然后得出的结论是团队仍然按原有方案工作，在以后的迭代中如果还有必要再实现她这个需求，以及那个列配置的需求。

然后我将得出的结论发到了群里。

我忘记叮嘱开发负责人不要告诉PO，让PO自己去与用户沟通获得结论，开发负责人很快就将我的沟通情况转告了PO。PO说好吧。但这种做法可能会对PO的心理有一定负面影响。