今天有点想骂人，是因为我们几乎要犯同一个错误，踩入同一个坑！这次迭代的排期，已经延迟了近10天，还在一本正经的排，估算，砍需求...一年前就因为这种大公司的作风带入创业团队而导致失败，一年后还要这样继续一次吗？！
经过一天的反思，我列出了几个看似无解的问题：
- 我们 vs 你们
- 质量 vs 时效
- 远水 vs 近火
但归根结底，这次主要原因就是产品与开发在设计节奏上的不一致性！
作为一个初创团队，大家虽处于不同的部门，但是在产品设计和开发设计上需要高度的一致，大家不分彼此，互相理解，相互补短。最重要的是：把两个设计过程有效融合并前置！！！
因此，我想到了 结对编程。
结对编程（Pair Programming）是一种敏捷软件开发实践，指两个程序员并排坐在一台电脑前，面对同一个显示器，使用同一个键盘和鼠标一起工作。一个人输入代码，而另一个人审查他输入的每一行代码。输入代码的人称作驾驶员，审查代码的人称作观察员（或导航员）， 两个程序员定期互换角色。他们在一起完成需求分析、系统设计、编码、单元测试、整合测试（Integration Test）、写文档等工作。基本上所有的开发环节都一起肩并肩地、平等地、互补地进行工作。
我一直比较崇尚全栈的能力，不仅限于开发全栈，也包括产品与开发全栈。有人说这个事impossible，但我说nothing impossible。更何况这是一种追求！
回到产品的设计过程，如果能和开发的设计过程做成结对方式，至少有几点好处：
- 产品能从开发那学到系统化的设计过程，能了解开发的顾虑和禁忌
- 开发能从产品那学到用户化的思维逻辑，能了解功能的来龙去脉
- 产品和开发能相互监督，为了一个目标使力，过程中不断的纠正偏差
- 更重要的是，能够把设计工作强制的前置。别再说没时间好吧，你的时间就是大家的时间！
- 最重要的是，大家有个共同的目标，它不是宣讲出来的，也不是日夜唱经式的洗脑，它需要你真正的认同！
同样，我也能想到一些反对的声音：
大家语言不通，沟通太费劲！
语言不通是个回避不了的问题，在排期时也会发生！沟通是PM的强项，只要你不抗拒。全天泡在一块，太浪费时间！
不用每天，不用一整天都在一块。这是个高效合作的方式，一天三小时足以。产品和开发关注的细节不一样，全部讨论太碎了！
无需事无巨细，把握好度，因为你一天只有三小时！对方的细节问题你可以回头自己去理解，也许会有新的收获！
火焰般的PM，你需要海水般的绵柔思路
一滴水并不起眼，数不清的水滴构成了汪洋大海，其精妙之处让你无法想象。开发是个工程学，他讲究精良的设计和严密思维下的取舍进退。
PM同学们，你们也许需要知道：
- 领域模型的构建
- 实体的生命周期
- UML
- 数据模型、对话模型、处理模型
- ...
大楼并非一天筑起，它需要从一砖一瓦开始。
海水般的Dev，你需要火焰般的激情与奉献
火焰看似危险，但它照亮了前路，温软了面颊，也燃烧了自己。产品是个结合感性和理性的产物，也是一种多方利益的博弈学。
Dev同学们，你们也许需要知道：
- 产品的用户模型及画像
- 产品解决的痛点
- 产品的关键核心价值
- 产品的用户体验设计
- 产品的定位与市场契机
- ...
光芒很耀眼，却容易转瞬即逝。
海水不是为了熄灭火焰，火焰也不是为了烤干海水
上周在雾凇岛拍到了惊艳的一棵树，温暖斜阳下的雾凇倚靠着湛蓝的半边天，竟如此和谐，美哉！
