项目开发接近尾声了。

PO提交了一版变更需求，以及一些零零碎碎的问题。

团队评估了一个工期，但PO将其中两个复杂模块的工期减了一半。

团队和PO无法达成一致。

团队负责人向我和开发方的职能领导提出这个问题来。

我们先与团队进行沟通，了解具体情况。

沟通过程中，职能领导询问开发负责人一些技术细节的东西，但他自己从大学校门出来，几乎未再接触代码，也没有带过一个项目，因此我感觉再交流这些细节的东西不会有什么效果，而我的做法是选择相信开发负责人对工期的估算。因此我催促职能领导联系PO及其上级尽快沟通。职能领导说约第二天，我催他立即，现在开发团队只有两个成员，进度以天计，交付节点就在眼前，协调的事情不适宜再拖。

于是，在我的“逼迫”下，职能领导立即联系了PO方，召开了电话会议。

PO的问题是，她拿到了团队反馈的进度安排，觉得“没办法”去和用户沟通。对于变更很大的两个需求，她根据以前的经验，觉得不需要那么大的工作量。

我可能急性子了点，也为了“将军”，提出了一个解决方案，让PO那边找几个人，去完成这个进度争议比较大的模块，她们那边也有熟悉这个平台和项目的人，其余的这边的开发团队继续往前赶。要不然双方在进度上都按自己的理解，没法往下走。

PO的部门主管赶紧说，他们以前的经验也是基于另外一个开发平台的，在现在这个平台上可能也不一定适用。

PO的部门主任赶紧说，现在主要考虑的是用户那边的想法，我们分节点给用户提交，态度好点，在过程中获得用户的理解。

我又附和部门主任说，对，我们要围绕怎么在用户那能获得个好结果讨论，不要聚焦在双方工作量估算的焦点上。实际上PO方是需要在本月在用户方获得一个验收签字，以便收款，用户方虽然提出了一些修改意见，但并没有表示这些内容不在本月改完就不给签字，在这种内部兄弟单位更多的是如何与其沟通，用积极的行动获得用户的理解。

因此最后的结论是将报给用户的工期分为几个阶段，最长的那部分比开发团队原先报的提前了，但估计不能按期交付，指望着在过程中通过前几次积极的交付去打动用户，然后在过程中将最后的期限往后延。

其实这种模式又回到了传统的项目模式上，要PO脸皮“厚”一些，明知道有个可能完不成的节点，也事先给用户一个希望，在过程中或者临近节点了再告诉用户需要后延。违背了“透明”原则。但没有办法，PO总是觉得她“没有办法”去和用户沟通，只希望团队能按照她理想的模式完成所有任务。