管理目标目标管理案例 _云知道

一位X-Developer用户问，最近我们业务和研发都有大量调整，导致团队成员对业务不熟，现在启动和完成指标的对比很难看，怎么办？

我就问：你期望的目标是什么？
用户：当然是真正地完成迭代的任务呀，不要表面的“更新成完成状态”，而是没有剩余工作量。
我接着问：那么，怎么才能“真正的完成”呢？
用户：就是看X-Developer团队报告“产出能力”这个图表上的完成数量呀，我从这上面就可以得到真正的完成的情况了。
我说不对，我们讨论的是“怎么做”才能做到真正地完成迭代任务，而不是“怎么度量”出真正完成的任务数量。
用户：这就是困惑我的地方了，怎么做才能提升完成数量呢？
我说，其实你知道如何提升，但是你的思路被指标困惑住了。
用户：这个怎么讲？
我说，因为你的问题已经包含了原因——团队成员对业务不熟，因为指标的缘故，你没有进一步分析原因寻找解决方案，而是焦虑如何让指标看起来更好一点，所以，反倒得不到想要的结果了。如果先从这个原因着手，在迭代中安排一些业务学习任务，持续地观察启动、完成的情况，就可以验证“业务不熟”是否真正影响团队产出能力的因素，并持续地提升。
用户听了，觉得很有道理，但是依然没有缓解指标带来的焦虑：业务也不是一天两天可以掌握的，还有没有什么短期快速提升的方法？
我说，当然有了，比如现在这个浪费的天数，消除一半，就可以缩短交付周期时间，提升迭代的产出了。

用户说，这我也注意到了，目前我们从故事卡的任务切分，没有对准故事卡的持续交付，而是根据开发人员工作量去分配，没想到一度量，估算3天的故事卡，实际上跨了8天才转测，中间不但测试空了2天等开发，最后测试时发现的一个业务逻辑在设计是忽略了，导致这个故事卡不得不放在下一迭代交付。其实功能挺简单的，如果迭代前期，精力更集中一点，就不会出现这种情况了。看来我们还是先聚焦任务拆分的优化，持续关注改进效果，争取把产出能力提升上来。
这个真实的故事想必也是大多数企业管理者的经历。X-Developer早期试用者也问过类似的问题：你们这个产品是不是要团队有很强的执行力才能用好？我的回答是，X-Developer不是让你来“用好”，而是始终如一地告诉你你的现状是什么，和预期有多少差距。
X-Developer告诉你应该做得更好，如何做得更好，而不是要你来把X-Developer“用好” 。这其中，最核心的就是提升您的团队观察、跟随和适应变化的能力。比如上面的案例，最核心的就是业务的改变，新知识的涌进，导致产出数量的回落，团队需要时间来学习、提升，才能“达成目标” 。
你度量什么，你就“得到”什么许多大组织花费一两年的时间从版本交付到迭代交付，然而迭代之后，发现不但效率没有提升，质量还下降了！最难堪的还是业务部门的反馈：
迭代，不就是把以前一个大需求，写成很多个小需求嘛，这怎么提升了产出？不是忽悠我们嘛。关键是因为需求变小变多了，我们要不停地提、不停地跟踪、不停地验收，研发可能效率是提升了，但我们业务的效率下降了，我们的感觉很不好。