今年我们有几个较大的客户，有可能年收入可以过千万，Menards是其中之一。但在很长一段时间里，Menards在我印象中，甚至算不上一个目标客户。直到我有机会和参与项目的同事沟通客户情况。张旭和我谈起Menards的时候，已经与客户一同工作了两年多，其间还去过客户办公室，几个月时间onsite工作。

Menards项目一直进展非常不顺利，两年时间我们不断调整，还是难以适应。团队从二十多人的规模，一路缩减到两个人，张旭是其中之一，合作模式也从ODC转为固定价格。但在之后不到一年时间里，客户满意度反而提升了，2017年底，John告诉我，客户计划在2018年扩大与盛安德的合作。

张旭告诉我Menards内部的项目井井有条，问题出在我们自己身上。客户把合作模式从ODC转为固定价格，一定是发现ODC的效率存在问题，采用固定价格模式，客户就不用再担心效率问题。两种模式最终客户要的都是结果，既不是时间，也不是工作量。有很多人认为ODC合作中，我们只要交付每天八小时时间，固定价格才交付结果；也有同事认为ODC交付工作量，每天完成一定量的工作，不能少，但也不能多很多。客户选ODC，是因为ODC应该有更好的性价比，更好的性价比从对效率的不断追求中来，效率的提升带来更多、更高质量的“工作量”。如果工作量是距离，效率是速度，效率的提升就是加速度。ODC交付的是不断提升的效率。从对团队的要求上讲，ODC比固定价格更高。

Menards发现我们的效率有问题，又没办法单方面改善，只好把合作模式改为固定价格。有些客户可能因此就终止合作了，我们很多项目都遇到过类似的问题。

关注程序员效率的是PO这个角色，Manards项目初期阶段，PO是客户方的，他们把这个角色称作“Tech Lead”。客户方PO的关注，并不能直接提升程序员效率，提升效率要靠我们自己。客户将合作模式改为固定价格模式，我们还没有意识问题在哪里，甚至靠加班去完成我们认为的“工作量”。

Menards很早就意识到，客户方的PO不如我们自己派PO效率高。他们提出过要我们派人去做”Tech Lead”，但我相信即使派人的事情成功，如果Tech Lead不清楚自己的职责，还是难以维持ODC合作。后来John把Cornwall唯一的准技术人员Ajay派到客户办公室，合作模式改为固定价格，在大连交付团队张旭的努力下，重新赢得了客户的信任。

回顾与Menardsd的合作过程，我发现客户自始至终对于合作模式的想法是清晰、一致的，ODC必须配备PO角色，如果我们的程序员足够敏捷，客户PO加我们的程序员，应该可以顺利开展工作；如果程序员还不够敏捷，我们需要先解决程序员的问题，敏捷意味着程序员开始追求效率。在2018年，我们会派出更多PO（Tech lead）到美国，解决客户面临的业务问题，将会有更多敏捷程序员参与，合作也将达到新的高度。

PO这个角色应该由成熟的敏捷工程师担任，Account Owner由有经验的PO担任。最好的情况，初期客户方提供PO，我们提供敏捷工程师，在Account Owner（最好和客户在同一时区）的协助下，项目能够顺利开展，之后加入逐步用我们的PO替换客户PO，我们的PO可以是本地招聘的敏捷工程师。

PO和咨询师很像，但职责并不相同。PO对项目负直接责任，对客户的项目整体预算负责，他也是项目团队成员。咨询师提供咨询服务，对自己的付费负责，咨询师的产出可以是项目需求，项目交给开发团队开发，咨询师并不对开发团队的产出负直接责任，咨询师的付费可以独立于开发预算。PO这个角色不能独立于开发团队。两个角色同样关注客户业务，咨询师利用自己在行业中积累的经验，根据客户业务确定（固化）需求；PO对客户业务的了解程度可能不如咨询师，但通过与客户协同，不断完善和优化需求，程序员也要充分参与这个过程，在不断探索与优化中，达成客户满意度。程序员思考问题的出发点与PO完全相同，这将不断提升程序员解决问题的能力，而不仅仅是技术能力。目标放在解决问题上，是让程序员效率/能力得以不断提升最佳途径。

要实现盛安德的使命，PO加敏捷工程师比咨询师加开发团队有大得多的优势，因为前者要想走通，依赖于工程师自身能力的提升和不断发展，而工程师（员工）的发展是一个企业长期可持续发展的基石。