编者按：在作者的理解中，产品的开发模式不是最重要的，人——才是最重要的！每个人的思维方式决定了团队合作的效率和结果，而每个人的协作理念合在一起就是开发模式稳固的基石。本文作者点融技术高级开发主管 Landon，写下几个提高开发效率的协作理念，跟大家分享，首发公众账号“点融黑帮”。
1.做产品的主人
因为团队职责的划分，PO/PM 是容易被大家认为是产品的主人，是他或者她的项目，工程师只是实现一下而已。如果对产品没有归属意识，这是个很要命的问题，接下来就是责任心的缺失，各种懈怠和对立。这里希望 PO/PM 也能意识到这个问题，鼓励每个人对产品发声，一定程度的参与设计和讨论。
对开发来说，如果对产品没有理解，不能形成自己的体验见解，说明根本没吃透设计文档，只是按图索骥，小心画虎不成反成猫；对决策者来说吸收产品建议的确需要综合考量，但工程师并不笨，相反他们是最聪明的一帮人，我就不信整个产品里面连一个由工程师发起设计或者优化的点都没有。
如果团队里有对产品理解深刻的工程师，请珍惜。
2.拥抱队友
拥抱你的队友，站在队方（不是错别字，的确不是对方）的立场思考问题。工程师可能经常会听到 “不是吧，你竟然这么做了，我有个方法比你好 XX 倍！” 或者是 “你这么写有问题的，应该这样 blablabla”。第一反应绝对是不爽到爆，很明显，除非团队里混进了竞争对手的内奸，那么大家都是一条绳上的蚂蚱，明确一点，那就是除了你之外，其他人也都是希望产品好少出 bug 效率高。
不妨先静心听一听队友的方法，如果合理，那两个人一起比较一下差别在哪里，如果自己的里面隐藏了一个很深的 bug，那你得感谢你的队友；如果队友的方法只是效率更好，那么再评估一下修改的时间开销，问问负责的 PM，看看把优化插在哪个节点比较好，然后代码里写个 TODO 注释，结束。程序员大多数不重视沟通方式，但技术牛掰加上一点点沟通技巧，那么恭喜你会立即脱颖而出！
这个问题可以这么说 “昨天咱们做的那个模块，功能 OK，就是效率稍低了一点，我另外又做了一个修正版，这里是测试运行效率的数据...不用谢了...请叫我雷锋”，对，是 “咱们” 不是 “你”！
3.打破开发的职责边界
打破开发的职责边界，只需要多延伸一步而已。Richard Clayton 在 Failing at Microservices 一文中提到了他的困惑，“服务由不同的人来负责，工程师开始抱怨服务 A 被服务 B 的任务挡住了。尽管服务和服务之间不会有编译时间依赖，但还是会抱怨。没有人去帮助服务 B 的工程师，或者是把与其他服务相关的任务从清单里分担掉，而是升起了他们所属服务的吊桥，就好像他们是城堡一样，然后就等着这一轮冲刺结束”。相信每个团队都会遇上这样的事，就连 Debug 也会听到推诿的声音，前端与后端联调时，先是测试者 “前端显示不对哦”，然后是前端应声而起 “不会吧，是后端协议数据给的不对吧”，后端也按捺不住了 “另一个应用也在用这条协议，没有问题啊”。
工程师 Debug 有三重境界，第一重初级水平 “找到并解决自己的模块的问题”，第二重高级水平 “找到队友负责模块的问题并帮他解决”，第三重专家水平 “设计一种方法，让以后再写类似模块的人不可能犯这样的错误”。
团队管理者应该鼓励工程师在搞定自己事情的前提下，发挥更大的作用，去帮助团队解决问题，本帮正是发扬这种超越自己职责的 “狼性文化”，能延伸多少看个人能力，但哪怕只从自己的领地向外延伸一步，也会给团队合作带来巨大的改变，所以前面那种情况你听到应该会是：测试者 “前端显示不对哦，但抓了包看可能是后端给的数据不对”，前端 “另一个应用也用这条协议没问题，我去查一下配置”，策划 “不用看了，我配的数值有问题，马上更新一版”，后端笑笑继续思考怎么改善体验。
4.活用结对
活用结对攻克问题，开拓思路，提高效率，降低学习成本。结对是敏捷最佳实践里面的一个小方法，但我并不认为他只属于敏捷，在某些关键时刻使用非常有效，比如开发非常精细的功能、复杂算法、寻找重现机制复杂的 bug。
这时1+1 的作用远大于 2，首先结对的专注度更高，心情也更放松，好基友的效果不一定比鼓励师的效果差，不容易受 QQ邮件电话的各种打断，结果就是代码质量高，生产速度快；俗话说 3 分开发 7 分测试，用在测试和 bug 修复的时间会少很多，把多投入一个人力的成本给追回来，更不用谈一些边际效应带来的成本。在 debug 非常难的问题上，当陷入困境，队友可以帮助查疑补缺开拓思路，甚至有时只需要把思路讲一遍给队友听，自己立刻就知道问题出在哪里了。另外结对的一个非常好的副作用就是降低学习成本，这个功能点你的好基友下次在你请假的时候也可以来维护。
5.从用户身上寻找信心和动力
加班和赶时间节点是大部分工程师反感和造成效率低下的事情，但是 PO/PM 非常清楚，如果不踩准这个节点，那么会导致 XX 天之后的某个版本不能按时交付，造成市场上一系列的被动局面。
有一次为了踩准一个热点事件的推广，我们团队的工程师们连续作战 16 个小时，完全没有怨言，反而干劲十足。其实那是我们第一次做这样的应用，时间非常苛刻，从决定做开始，设计、美术、编码实现，测试部署上线只有 1 天时间，分摊到每个环节其实只有两三个小时，但竟然没有人质疑这样的决定。原因就是每个人都清楚，热点事件转瞬即逝，工作的成果将直接由用户来考评，这并不是 PO/PM 贴在墙上的冲刺清单。
“产品唯快不破”，所以如果你想快，请让工程师直面市场和用户，同样重要的是，根据时间点来匹配开发内容，用最小化的产品上线，接着持续迭代，并持续部署交付。
结语——写给工程师的
最后还想提醒诸位，人是团队最宝贵的财富，以上几点的领悟和运用，纵然需要团队管理者意识的转变，但最终能走到哪一步，还是要依靠高素质的团队成员。
