独立开发多人（远程）协作经验分享
有不少人问我和设计师是怎么合作的，我想了一下独立开发的远程协作还真踩了不少坑。所以今天把自己踩过的坑分享一下。
正确的人：建立信任，价值观匹配
一个长期稳定的合作的基础是双赢。
因为合作者的价值观一致，因此才可能双赢。因为双赢才能建立信任。
如果合作的人值得信任，就只要解决决策和信息同步的问题。因为大家都会百分百的执行。大家本来就不在一个地方，如果还要监督执行管理成本就无形增加了很多。
合作的人价值观一定要匹配。我举个例子，有一个人想组队去攀珠峰，于是他找人。有的人觉得我反正闲着也是闲着，想要找点事，一起加入。有的人只是对爬山有点兴趣，刚好有人组爬山就一起去。有的人单纯是想搭一下便车，他只是刚好要去半路上一个地方。因为你不可能一直都是顺风，逆风的时候没有信任团队就散了。 价值观会影响决策，如果价值观不一致，同样的条件，就会做出不一样的决策，就会产生分歧。
如果有过项目决策经验，你就会知道有一些决策 A 和 B 都可以。但是 A 有长期价值，B 有短期价值。这个时候选择长期价值还是短期价值就很考验人性。举个例子，项目进行到一段突然有了 10 万收入，有人觉得 10 万应该扩大投入生产，有人觉得 10 万应该尽早分掉落袋为安。又或者有人出 10 万来买这个项目，有人想要继续做下去有一个自己的产品。有人觉得只是一个生意，赚钱了就完成了。
所以在合作初期，对于合作的预期目标，价值倾向就要先沟通清楚，达成一致。你想长线做一个产品就不能和一个只想着短线利益的人合作。否则越往后越痛苦。
工作流异步协作最大化
在协作之初的工作流就为了能最大程度的异步协作设计。与此同时也要做到同步沟通效率最大化。
独立开发的性价比体现这什么地方呢？同样的钱可以产出更好的工作，或者同样的工作但是更好的体验。同样的一个设计师，他生活在上海市区和他生活这二线城市的郊区所需求的薪水会有所不同（地理套利）。同样的八小时工作量，要你早上 8 点到公司，和弹性 8 小时心情就不一样。因此为了独立开发能达到最大的性价比，最大程度的地点自由、时间自由是一个基础要素。如果你的工作流支撑不了全远程、全异步，你的效率性价比就不会超过公司。
异步协作的重点是：信息透明、流程结果透明。当然也需要定期的同步沟通（对齐颗粒度）。
抽象一下协作无非就是沟通好我想要一个什么东西，然后你什么时候做好给我，最后验收一下。想一下我们网购不就是这样吗，挑好一样东西，下单。你不放心就去看一下物流进度，到货的时候你检查一下质量，确认收货或者退换货。这里面的最后成果质量和客服是否实时回你消息没关系。核心是你是否明确自己想要一个什么东西（需求），商家产品的质量是不是达到预期（实现质量）。
首先在产品需求阶段是需要大量（异步）沟通的。我会在群里提出很多潜在的需求，用户提的、同行做的、自己想到的。这些需求觉得有必要的最后都会记录在项目管理工具上，也可以称为需求池吧。
每个迭代版本要开始前会一起同步讨论要做什么功能。这个时候主要是需求优先级的确认，我们优先解决什么问题。这个时候也是价值观的碰撞。都是有用的功能那先做什么呢。
在沟通好要做的功能后，我会在一个白板工具上做原型。因为是一个白板，所以也会插入思维导图，需求说明文档。同时在原型上标注很多思考的点、用户的需求背景。还会放一些参考设计。这个在线协作的白板相当于是一个 live docment。参与项目的人看到这份原型白板文档都能直观的理解这个需求。在设计开始前会约好一个时间同步讨论原型设计。
设计师做设计也是用的在线设计工具（Figma、MasterGo），所以也可以随时看到设计进度。讨论 UI 的时候语音连着就可以实时看到 UI 的改动。
在 App 开发上，基本上两三天就会打一个测试版本到 TestFlight 上，设计师会自己安排时间看下功能的完成度。
所有的进行中的任务状态都会标注在项目管理工具 linear 上。我们的需求池也记录在 linear 上。未来几个项目的计划也会标在上面。所以我们都知道互相在进行什么任务，状态在哪一步。
需要同步沟通的只有需求原型沟通确认，设计确认。这里可以高效沟通的一个原因是不像传统的那种开会的时候才看到要讨论的东西。以前在公司的时候经常开会的时候才第一次看到需求文档、设计。现场就需要很多思考的时间。我们这种过程、结果的产物都是线上透明，在沟通前要讨论的地方就在图上标注好了，所以就可以马上进入交流，一般一次沟通半个小时就结束了。
有的时候需要开会讨论一些规划也会提前写好会议大纲（在飞书上）。尽量把所有有关线索都提前组织好，这样也是上线后就可以直接讨论焦点部分，不需要再说明方案。
这个流程让我们觉得舒服的还有一个原因是我们没有 deadline。我们是用户体验优先，加上成员的信任，只要沟通好要做的东西就可以了。参与人只要大致估计出下一次完成确认的节点就可以了。一个设计做 3 天还是 5 天都无所谓。其实没人逼你以后，有责任心的人反而会更高效。
草图原型很重要
我们最初协作的时候对一个任务是口头和文字描述的。协作下来发现这样最后会偏差的特别多。可能做出来以后发现有个部分欠考虑了，发现这个方案不行，发现和脑中想的不一样。设计师会跟我抱怨你脑中其实有个更明确的模型，但是你没有尝试表达清楚。 因此前期需求沟通有草图、原型，把一个需求从脑中逻辑化落地可以很大的提高沟通效率。 比如我跟设计师说要一个可爱的小动物形象，这个描述也是很抽象的。但是我找了几个可爱的小动物设计参考，他就知道了我想要的是哪个类型的。插画师画图也会先给到几个草图，我就知道他大概是怎么表现的。在这个草图阶段，我们双方对于内容的大概方向就确定了下来。在草图阶段我们会进行大量的沟通。前期沟通明确后最后的成果交付以后就只需要微调就可以了。
产品细节听谁的
独立开发的产品，每个参与的人都很有积极性，对产品都有主人翁意识。对于产品的形态，实现细节就会有很多意见不统一。这其实也是多人协作会正常遇到的问题。
我的结论：每个人都充分表达意见，不可逆的重要产品决策，最核心的一个人做决策。可逆的非关键决策，谁执行谁决策。
最核心的产品决策权最后由团队里决策质量最高，最有威信的人做。这个决策质量是通过一个个迭代中证明出来的。所以最开始团队可能还有一些 pk，如果某个最初的决策人总是犯错误那么最后的拍板权就给另外一个人做了。 千万不要有我是产品经理，我经验最多就听我的这种思想。优秀的人不吃这一套。应该是最优秀的人做决策。
比如要不要做哪个功能，就是不可逆的关键决策。这个按钮位置在哪里，大一点还是小一点就是执行层面的决策，谁做谁决定。如果某个产品经理、设计师最后的产物上线后用户总是不认可，说明这个人能力就差。自己干这个的都做不好说明就不适合干这个。
这样磨合一段时间以后也能增加独立开发的效率优势：高质量的直觉式决策。
为什么不推荐 A/B test 这种民主式都不得罪的思路呢？因为独立产品一定有一些关键决策会带来重大提升。细节的 5% 提升对于独立产品的基数来讲并不重要。大厂的产品基数大，找到一个最佳参数很有必要。独立产品的用户驱动因素更多是产品定位层面的，细节的优化提升只会捡芝麻丢西瓜（等于过早进行性能优化）。
当然这里的关键核心产品决策，最好是有逻辑支撑的。可以总结出一些大家认可的决策原则。比如先沟通好产品的定位、用户群，产品的价值取向，团队的价值取向。这样就不会在底层逻辑上有分歧。
最后 最开始我对独立开发的想象，是做出一个自己百分百满意的产品。后来和设计师协作推进了一段时间后，我们都发现这是不可能的。我向设计师妥协了一部分决策，设计师也向我妥协了一部分决策。最后的产品可能我们都是 80% 喜欢。但是也许这样的产品是体验更好的。一个纯开发者视角、纯设计师视角的产品未必就会是一个好产品。大家意见充分表达以后有一些新的视角带来融合的产品也许才是更好的。
不得不承认，互联网或者叫泛IT产品的研发成本和人时要比其他领域的产品研发贵的多。此前的逻辑一是：IT产品能更大的提高边际效益，比如一套停车管理系统能取代15个看车大爷，自然就应该贵一些。逻辑二是：互联网领域的投融资相对活跃，很多投入可以在资本市场以估值提升的形式成倍收回来。但当现在随着互联网产品渗透率提高、增长有限，导致边际效益提升减缓，以及资本市场大家都知道的状况的前提下，泛IT产品的研发溢价可能会受到越来越多的挑战，研发预算下降可能是不好完全避免的趋势。
我们最近在跟客户沟通中采用了一种新的报价方式来拟合双方的预期不一致。我们会先对任务做一个估价，在双方都同意这个估价的前提下，将支付分为两部分，一部分是客户可以接受的现金部分，另外一部分变成债，加上一部分利息来支付，而支付来源是客户通过这个产品产生的收入流水的一定比例。比如100000的应付款，作价150000三年，以业务流水的一定比例来支付，由于我们开发的系统自然可以看到流水，所以大家容易对金额达成一致，同时客户也觉得通过这种形式捆绑了双方的责任，我们也会对后续维护更在意，毕竟弄不好损失的是我们的收入。而且不用一下子按市场行情支付现金给我们，自己的财务压力也会降低，而我们也在长期应收款上获得了一定溢价。三年到期或业务终止时，如果分成还没达到预期金额，双方再探讨是一次性还款还是做展期。
当然这个方式有一定局限性：必须是有能产生流水收入的业务，双方有长期合作的基础，对各自的履约能力和意图都放心才行。
现在看这个方案执行的还行，构建了一个缓冲空间，尽力弥合了传统行业对互联网产品研发成本的低估，和研发一侧对自身研发工时的高估。甚至有一些公司开始探索如何交易和转让这个合同，也是很有意思。