作为一个敏捷教练，我见证了很多公司无止境地争议同一个话题：比起项目流程，我们应该更加关注项目的产出。
以下是我个人的一些看法。我相信项目流程是一种驱动工具，如果我们勤恳的遵循流程，就可以得到预期的结果，达成既定的目标。
但我注意到，在IT领域中有两个非常常见的反面教材：
1、坚持只关注产出；
2、严格遵循流程规则，即便对于项目成功交付来说没有任何附加价值
就我看来，仅关注项目产出往往会带来重大的失误。如果我们始终只关注产出，那我们只是在思考如何“生存”，这样就会降低团队的活力，并且造成创造性思维缺失、技术债堆积和产品质量降低这些衍生后果。
现在的很多新兴企业都奉行这个观点，只要求团队关注交付产出。当团队被期望增加产出量时，就会去走捷径，到时候就会导致计划外的工作量大幅上升，反过来导致产品最终质量下降。尽管一开始团队往往还是可以完成预期的交付任务，但长此以往团队就得在越来越多的计划外工作和偿还技术债上花费大量成本，而这些最终则会彻底击垮项目。
另一方面，遵循流程不仅能让我们得到预期的结果，也能保证可持续的成功交付。当然，遵循一些过于顽固的项目流程也会阻碍项目的成功交付。毕竟敏捷宣言告诉我们，“个体和交互高于流程和工具”，过于严格、顽固的流程会令团队失去热情和自由，给他们造成压力，从而对交付产生不利影响。
比如我注意到，对于一个成员分布在不同时区的高度分布式团队来说，用视频电话来进行每日站会其实是非常痛苦的。我发现，因为严格要求每一天都要在特定的时段通话，反而降低了这个会议的参会率，项目瓶颈的解决速度也变慢了。所以在我们开回顾会议时，团队开始重新梳理每日站会带来的实际收益。我们都意识到每日站会必须马上做出一些调整，并从失败的经验中总结，想出了一些创新的办法来开这个会，比如通过维护实时的表格来做每日同步，并且每周用视频会议碰头一次。
没有绝对完美的流程—我们都赞成这一点。一个敏捷教练或者管理团队，应该善于对流程做出调整，以求最大程度的适应团队本身以及促进产品的交付。合理的流程应该能提高团队的学习能力，使团队有能力做出改变，从而达成预期的目标。
敏捷过程之所以如此流行，一个很基本的原因是它允许我们围绕12项敏捷原则作出自己的尝试。这种方法有利于我们响应项目需求的任何变更。
尽管项目的成功没有特定的经验法则，但不管是只关注流程还是只关注产出，项目都是不会成功的。只有定期地检查流程，识别影响交付的障碍（如果有的话），优化流程来解决这些障碍，以及快速的响应变化，才能使项目成功。
长按二维码关注