在问题发生之初，产品经理和李就应该将开发团队面临的来自客的扰，及时引导到自己上。对于待开发项目变更，也应该由产品经理与客负责人详细沟通。

只能暂时好客安抚，“董哥，你说的况我明白了，如果是这样，那么这一开发确实是现了不可控的问题。这样，我现在就在回玫城的路上，明天到公司我就召集这个项目负责人明确好问题和对策，晚上给你回电，你看怎么样？”

结果，实际上我是满意的，待改项目所占比例并不，属于正常平。但就在刚刚结束的第二个月预演会上，不仅仅上次的待改项一个都没解决，这一个月迭代周期的待改开发项，经过讨论和验证，达到了40%。同启，不用我和你再多说，你也应该知这个数字意味着什么。现在，我认为，这样去，第三个月本无法完成我们的一期开发任务。”

“没问题，董哥，现问题了，我们必然要拿解决方案来，这你放心。”

“……”李一时卡壳，他不是没发现，只是他和产品经理刚好都松懈了，发现时已经又过去一周了。但他还是说，“有发现，所以一发现我们就立刻在第二天的站会后组织了简短的分析会，理问题。”

许同启听完，一时也有些震惊，40%的开发项目都需要划待改列表，确实比例太了，基本上意味着这一个月的开发迭代周期是失败的。

“有，这是咱们最基本要求。”

两人落座不久，略寒暄后，许同启也直接切了主题，“大李，玫城科技产业园的智慧园区项目，执行况怎么样？”

问题主要在这个开发项目的产品经理上，李有疏忽也有行动，但很明显这个项目的产品经理是完全缺位的。

刚接到电话知许同启刚到玫城就约他来吃饭，李就料到了必然是产业园项目他已经知了，来的路上就提前整理了一番思路，还临时打电话给这个项目的产品经理和开发团队了解更的况。

所以，他周日晚上一到玫城，没有先回家，直接电话了公司ICT项目负责人李，约他来吃饭，先听听他对这个项目况的说明。

“许总，是这样的，这个真不怪我们。我们在第二迭代开始前，就和客负责人确认好了这一的待开发项，但执行期，客频繁要求更改待开发项目，所以我们的开发团队不断受到扰，才影响了速度和质量。”

那么这一迭代必然现了严重的问题，是什么，他次时尚未掌握况，无法置评。

“那燃尽图上度明显滞后时，你和产品经理有看到吗？”

本章尚未读完,请击一页继续阅读---->>>

许同启听完，给他添了菜，才继续问，“这个项目公示度的燃尽图有吗？”

每一迭代一经开始，就要尽量避免变更。产品经理完全可以有更多的方式来理这个问题，比如在本接受少量审议充分的变更项，其他

“好，同启，那就这样。”说完那就挂了电话。

“有的，会议一结束我就找董明了，但他还是要求更改和添加新的开发项，我也同他了折中，临时更改了几项容。但这几项临时添加的没通过审议和详细的用故事编写，问题频，最后影响了整个第二个月的迭代开发。”

“行，同启，我是信任你才给你打的这个电话，要不然我就不是找你，而是找我们产业园在区里的领导了。那我等你电话，咱们力争把项目挽救回来。”

听到这里，许同启基本明白了。

“会上开发团队有和你们提受到客扰的事吗？”