为什么写代码是一件很酷的事情？我的看法是：反馈及时——超级无敌及时反馈确定性强——处理代码，确定性强的成就感——解决问题或克服困难的成就感。被需要感——如果自己的创作能为他人服务就更好了（被需要感）。因为这些感受/感受，写代码成了一件很酷，甚至会让人上瘾的事情。事实上，令人上瘾的东西通常具有这些品质。在软件交付的上游和下游编写代码是整个软件交付过程的一部分。当然，软件交付是整个产品的一部分，产品可能是公司战略的一部分。我们只会将上下文限制在软件交付过程中。稍微抽象一点，软件交付就是解决问题，用一定的技术（代码）为一定的人解决一定的问题。从定义问题，到找到解决方案，再到实现，很可能会出现“上下游”的概念。从问题顺流而下，到解决方案，再到实现，如果我们从以下几个维度观察：不确定性反馈循环无形/有形的人性问题/程序性问题，我们会发现趋势：(1)不确定性——从高到low：不确定性是由变化引起的，是不规则的变化（如果变化是有规律的，是可以预见的，不确定性就大大降低了。）我们常说，市场是变化的，需要变化，甚至人也在变化，并且这些变化导致了很多不确定性。从发现/定义问题，到制定解决方案，再到实现，不确定性的趋势是从高到低。(2)反馈周期——由长到短：在提问阶段，客户/用户提出一个问题/要求，需要一段时间才能得到具有合理可验证性的回答；而且现阶段的很多问题，都只能给出假设性的答案，或者没有答案，有的要等产品上线后才能知道。到了最后的实现阶段，不断拆解Release->Feature->Story->AC->Task->TDD，TDD的反馈回路不言而喻。(3)从无形到有形：在物理世界中，软件当然??也是无形的；但在数字世界中，可以工作和运行的软件是有形的。将某个问题、某种想法和感受通过文字或图片表达出来寻找解决方案，然后通过计算机编程语言变成一个可以工作的软件。这个过程就是从无形到有形的转变。(4)从人的问题到程序的问题：Ta有什么期待？目前的体验如何？还有什么没说出口的要求吗？会不会受到什么影响而改变决策？这些典型的问题，别人的问题可能都没有确定的答案，有的时候连Ta自己都不知道。程序的问题是不同的。这个地方出问题肯定是有原因的。一定是哪里的逻辑有问题。我会找到原因的。所以，从问题到实现，我们一开始关注的是人的问题，最后逐渐转化为解决程序问题。上游蝴蝶上游对下游的影响是显着的，而且数量级越来越大，就像“蝴蝶效应”一样。一只蝴蝶在上游拍打翅膀会对下游产生戏剧性的影响。不过，也不用太担心，因为软件交付对下游的影响比蝴蝶效应更可控和可预测。(1)上游问题：通常涉及的人数相对较少；它通常在各种会议或一对一对话中被识别、分析和定义。需要在一定程度上定义问题：问题是什么（期望是什么？目前的经验是什么），是谁的问题？(2)MidstreamSolution：通常参与人数不多（会比下游Implementation低很多）是基于给定的问题或上下文；如果给定的问题或上下文是错误的，那么解决方案就会有问题；解决阶段还将确认问题/上下文。通常离线工作，但需要在各种会议或一对一对话中反复修正（技术实现视角、安全视角、一致性约束等），更“纸上谈兵”，实证（3）下游实现：交付团队正在工作。大部分团队成员直接面对各种Feature/Story卡日常交付工作（Release/Sprint/Story,Tech,Bug）《战场秋兵》——安排合适的人解决合适的问题工作会追溯到上游Solution,Problemstage(4)上游“蝴蝶”很重要通过上面的分析可以看出，上游“蝴蝶”很重要，它扇动翅膀的力量是巨大的。我们自然希望更有经验的人做上游的“蝴蝶”：可以在各种会议上和客户“谈笑风生”，在需要的时候（扯皮）为团队打拼，客户可以给下游信息，这就是简单而不复杂。谁适合简单的项目？经验丰富的PM、BA、TL被选中！如果客户有技术/架构师参与项目交付，TL不会逃避。为什么不写代码是一件“不愉快”的事情。所以如果不写代码，就会失去写代码能得到的快乐：及时反馈-超级无敌及时反馈（删除强确定性-处理代码，确定性和成就感强-解决问题，或者克服困难的成就感和被需要的感觉——如果自己的创作能为他人服务，就会更愉快（被需要的感觉），及时的反馈&强烈的确定性，这两者一定是没有的（或者大大降低了））。成就感和被需要感呢？既然加了“感觉”二字，说明这个东西是“主观的”。去发现、去创造，记得往外看（可以参考上一篇博文：《努力工作是有人教的，工作快乐是没人教的》）那我不写代码能得到什么？是开会、PPT还是扯皮？这个？【本文】原稿为专栏作者“ThoughtWorks”，微信公众号：Thinkworker，p转载请联系原作者】点此阅读该作者更多好文
