你可以单干么？
我们是否经常在工作时经过艰难的沟通后发出一声长长感叹：
有这个时间，我是不是还不如自己就做了算了？
作为程序员我们是不是可以一个人莽完所有的代码，并发布上线一个程序呢？如果我都能搞掂客户，我还需要老板干什么？
我是不是可以自己开一家公司了？
当你有这样的想法时，让我们稍微较真一下，你真的能单干吗？
当这个问题只聚焦于一件事的时候，这种语境下，正常人通常是具备完成能力的：吃饭、洗碗、编程...但这样看起来不够复杂有趣，让我们把事情变得有趣一点...
当我们需要通过一组能力来达成一个目标时，我们能不能做到增强意义上的单干？例如独立完成一款游戏？
事情开始变得有趣了，一部分同学觉得社会是靠分工完成的，术业有专攻就好。另一部分同学则认为，干完一整个流程也没什么难度，为什么不自己一次性干完就好...于是我找了若干个案例来验证这个念头的可行性。
如图所示，TapTap游戏市场上经常能看到的情景就是一位独立游戏开发者，花了一年多的时间，独自开发了一款游戏，并得到了良好的反馈评价。
当你认真思考这个问题后，你就会发现，如果只是回答能不能单干的话，答案似乎是肯定的。
我们似乎在努力证明自己真的是可以通过单干来完成一个项目的，并且看起来效率更快，质量更好，更不需要与人沟通协作。
那么让我们再较真的问一句意犹未尽的话.....
单干的动机是什么？
我们常听到一些关于组织内“协作”时带来的吐槽:
“这个会跟我只有10%的关系，但却拉着我开了1个多小时了“
背后诉求：我只想好好码代码，不要开那么多会好不好？
“公司想出了各种指标，如果这就是他们想要的，我总有办法给他们”
背后诉求：减少花里胡哨的指标，最好不要瞎搞管理技术实践耽误进度好不好？
从积极意图的角度来看，单干的出发点是：
在自己能力所及的范围内，尽可能减少沟通的节点
尽量一次性沟通，高质量的沟通减少沟通的信息损耗
提升单个工作的流转效率，并使得他人瓶颈不影响个人下班时间或绩效
单干背后的假设：
只要个人能力充分（但通常无法定义什么是充分）
上下游来的信息质量过关（但无通常法定义什么是质量过关）
已知时间范围内的问题理论上可解的（但通常无法定义未完成后果）
当我们把单干理念极致的推向公司软件研发过程的语境中，你就会发现
它具象成为了瀑布开发的部门协作模式，而这种模式隐含了一种勤奋的战术假设：
详尽的计划 + 到位的工作 + 里程碑倒排期 = 顺利的交付
即假设：
只要只要前期做了周密准确的计划和排期（但通常无法定义什么是周密）
同时我们每个阶段的工作是到位的（但通常无法定义什么是到位）
那么：
交付应该会在准确的里程碑节点顺利交付（但通常无法定义远期风险，尤其是人的）
至于产生延期或返工、测不完等问题，那都是不可抗力（但通常无法定义不可抗力）
我们不关心最终的结果，但我们需要瀑布（但通常瀑布也并没有做好，例如延期）
一旦你相信一个事实，就会下意识地去寻找支持自己观点的证据，选择性的注意和搜集信息，并且排斥那些和你观点相悖的现象，从而得出一个符合自己意愿的事实或真相。-- 证实性偏差
能单干意味着零协作么？
要弄清楚这个问题，我们需要
重新理解协作是什么？
当我们将“独立游戏开发故事”的视角再次扩展，更多的组合能力和反馈角色出现在了我们的视野里，我们的单干能力被更多的外部底层能力所支撑，我们的产品改进被更多的外部角色所影响，这种基于平台能力依赖和用户反馈的能力组成了更大的协作图景。
这也意味着，在更大的视角里，协作是最小不可被分割的与世界交互的工作形式。
当我们谈论协作的时候，我们在谈论什么？
让我们以羽毛球这项体育运动为例：羽毛球区分了单打、双打、混双几类竞技模式，单打，相对来说，就是运动员在一个时段里相对呈现个体的状态，好坏结果确实是由其直接掌握的。在最极限的情况下，你却至少需要一个对手，否则你甚至无法独立完成一场比赛。那么也就是说，即使是对手也是在这个竞技的过程中与你协作的必要存在，即——把球打回来（反馈）
所以，协作不仅是事实上无可避免的最小工作组织形式，同时也是回答做一件事的意义的探索形式。有且不仅限于：
- 完成这件事而已（TODO-DOING | 做完）
- 获取进行下一步的信息输入或共识（WHY-TODO | 提出假设）
- 获取产品完成后的商业价值（DONE->HOW MUCH | 验证假设）
然而真实的协作更为复杂，角色、部门、职能、利益边界，加速了部门筒仓的形成，这也进一步削弱了协作本身所带来的直接价值反馈。
如果让我们重新编写一条简单的交付公式，也许他是这样的：
能力分 * 协作率 > 阻碍分
由公式可知绝非强化单干能力一条路径可以破除阻碍达成交付。更低的协作率，削弱了能力所带来的基本面，而良好的协作率则更利于分担过程中产生的不确定风险，甚至可以弥补单点能力上的不足，从而更丝滑地在心理和结果两方面作用于交付。
多人协作所带来的更多思考
在双打中，会在基本走位的基础上，延展出，补位、节奏、过渡、战术等关注点，是帮助竞技中的双方能够以更严格的规范，更好的默契实现拿分制胜的关键。
在野球场上，一个大神带一个新人打双打，很多时候容易被技术远不如大神的对手球员得分，导致丧失斗志，消极应战，乃至输掉比赛，也就是说双打并不完全看重个体绝对技术的高低。积极主动的状态，更易通过沟通配合，提高竞技中的赢面。但仅仅只是积极主动仍旧是不够的...
协作的背后意味着规则
我在百度文库中检索到了国际羽联关于羽毛球比赛的10个领域的112条规则，实话说我的第一感受是，太多了看不下去，真的犯规了再学习就好了。但我认为规则的基本盘也正在于此，它是一个领域中的基本规则的约束，让我们不至于在球场上，因为一个球是否出界或得分而停止比赛开始争执，它让一个事物的运行有法可依，避免了重复争执所带来的浪费，但同样需要警惕的是
规则的生长绝不意味着成为我们前进的阻碍。
规则：守护跑的慢的
试想一下。每天研发早会的时候，每个人因为交通工具、起床时间、加班后状态、家庭动态、规矩解读等原因等导致无法准时启动早会时，每个会议在主题和结果都不明确的陷入无目的头脑风暴时，每次对接在因为立场和视角冲突而无法推进时，因为没有规则的支持，我们甚至需要不停的在解释、惩罚、安抚、调整、怒斥、辩驳、博弈中度过。难以想象每天因为琐碎而耗去各种精力的我们，究竟能凭借什么东西，专注于知识与价值的创造。故，规则是守护我们秩序的底线。
当对规则的了解不够充分的时候，我们不知道该启用什么样的机制去了解和熟悉。
当组织分工不明确的时候，我们不知道做出什么行动是安全，不背锅的。
当规则过于冗余时，我们不知道该如何及时做出调整来应对变化。
规则：支撑跑的快的
如果说组织级的规则如同世界羽联制定的112条规范是为了让这项体育运动可以正常开展的话，那么建立团队协作规则便是真正意义上从技术角度体现团队的协作能力。
一个组织是否是面向未来，要看他是否更多的鼓励了主动进攻的人，还是只关注了破坏规则的人。
一人防守时，队友会补到什么样的站位能让攻守平衡，一人接过渡球的时候，该打到什么位置，才能让回球能够被队友更好的承接。
就如同，当我们传递一个需求的时候，它的风险和可测试性是否真的在有限的资源下得到了梳理，亦或是直接将不确定风险的需求传递至下游，尽可能晚的打开代码黑盒，直到整个团队开始疲惫于八面漏风的情形，再也无法处理新的挑战。
因此探索进攻型协作的内核就是探索我们传递工作成果标准线，这条基线之所以难以建立，最主要的阻碍来自于各自视角于全局结果的不共识。
因此，我们需要找到...
共识：关键杠杆点的视角
我们没有时间去评估需求，编写代码，进行测试
我们无法拒绝没有被认可的需求
我们的时间紧、任务重、质量要求高、预算非常低
这种协作的现状成为了一种进一步拒绝协作的理由，进一步撕裂彼此的关系，团队从疼痛中想找寻方案，期待寄情于能够有一种灵丹妙药，不经历阵痛，就能够让彼此的争执停止，让软件的质量显著提升，让结果皆大欢喜。但这真的可能吗？
然而不看到全貌，不清理容量，我们便无法真正拥有进攻的选择。因此..
建立全局视角是组织进攻的必要条件
就如同医生常说却又被我们习惯性无视的一句话：给你开点感冒药，但主要是你得多运动，强健身体，才能更快康复。
当你待在一间着火的屋子里，你会做一些什么？是寻找灭火器？是拨打119寻求帮助，亦或是马上逃跑，还是坐在原地继续码字？我们感受的到房间里的烟雾么？我们会提醒大家危险么？我们能对疼痛做出响应吗？
探索到这里，我们已经能够形成一些思路。
所谓协作：
就是我们与世界进行交互的无可避免的最小单位；
就是在建立规则，守护底线，支撑奔跑，提升协作率，给予团队能力的发挥空间；
就是在建立组织级、团队级，全局与局部愿景及视角的共识，使得着火被看见；
重新定义协作：
如果说单干意味着，你能完成一件事，那么协作就意味着我们让这件事意义浮现。
沟通，一阶的协作技术，强调对话的发生，但没有严格的定义产出及损耗（UDP）
协作，二阶的协作技术，强调对话的有效发生，让双方对结果有共识（TCP）
协作，不只是沟通，而是不断明确需求的过程。
协作，不只是移交，而是在重复的过程中明确可以形成的规则。
协作，不存在单干，只存在看不到的视角。
共舞，三阶的协作技术，强悍的纪律性使得我们不需要为一般重复问题困扰，彼此充分信任无需额外关照，感知流动并做出当下最好的选择（心流）
最后的话：
细细想来，敏捷思考的是人与自己、人与人、人与团队、团队与市场的协作反馈关系。从这个点来思考，协作将成为我们讨论敏捷的永恒话题。另外我深深相信，没有所谓的敏捷专家之说，敏捷教练其实是协作专家。这背后的思考需要用年为单位来进行沉淀。到底什么是协作？我们的组织形态如何强化新型的协作模式？我们不是因为工具和结构才产生了协作，而是因为协作才产生了工具和结构。它值得你的持续性的思考，并期待各位的分享 - 王宇
附录：协助印刷案例分享
盛夏的某一天，葱头接到了一个协助设计与印刷的案子，这对经常做活动的她来说可谓是家常便饭了，葱头决定接到需求后，先晾几天，因为手上也还有点别的事要处理，因为经验丰富，所以交付应该是不太成问题的。闷头几天后，甲方感觉有些焦虑，经常问进度怎么样了，有没时间一起看下进展，不顺利也没关系，一起解决。葱头内心席卷了一股不被信任的感觉，这么简单的事，其实不劳烦甲方您天天那么关心吧，我也没时间没精力跟您透明过程，到期给你便是...
此时甲方的内心里是这样想的，我对我自己的需求有很多不确定，葱头是怎么能保证做出来的就是我想要的东西呢？但可能这就是专业吧，安心等待吧。
项目推进事实
项目最终卡时间点交付（略有延期）
项目最后加班至凌晨完成物料交接（因为次日要使用，此时没有了任何修改的空间）
案例回顾
需求是在一周的时间里完成两套引导卡牌的定制与印刷，该需求隐含了以下内容
卡片内容的校对和补充（非终稿版本需校对）
卡片内容的中英文翻译（翻译细节及样式）
印刷尺寸的确定（未知合适尺寸）
印刷材料的确定（未知合适材料）
印刷克数的确定（未知克数手感）
印刷工艺的确定（未知工艺学名）
供应商的报价确定（未知不同制法的报价差异）
供应商印刷周期及物流
业务协作过程的关键问题
需求提出时的隐含需求，是如何被识别和确认的？
双方协作习惯不一致时，如何保障交付结果的可用？
当我们延后协作校准时，将面临什么样的风险？
协作应用提示：
需求的提出者，并非通过明确待办和拿到待办成果，就能获得成果满意，即：需求的提出者也需要更多的过程信息来校准决策 。
不是所有的工作过程都得引用高阶的协作技术，多数时候用钱包说话，用生命践行，避免彼此强拉共识。
协作并非不制造浪费，而是相对局部最优，选择全局最优的解题方法。
如果这个协作不是一个长期的状态，也不必强行拉齐共识。
如果协作是一个常态，那么强悍的纪律就是怎么用都不会错的切入点。