怎么定义工作的有效性
前言
很多时候我们在工作中总是忙而无效，多数的时间成本都被浪费，定义程序员的产出并不应该是写代码的效率。而是创造的价值和有效性。
当接到开发功能特性的时候，应该问问产品这些问题：
- 我们为什么要做这个特性，它会给用户或者公司带来怎样的价值？
- 什么样的用户会用到这个特性，他们在什么场景下使用，他们又会怎样使用它？
- 达成这个目的是否有其它手段？是不是一定要开发一个系统？
- 上线后，怎么衡量它的有效性？
如何衡量有效性
衡量有效性，就是要保证我的工作不会被浪费。如果我们的工作总是被浪费，会导致焦虑和负面情绪，我们的挫败感不断累积，而成就感很少。导致最终可能会变成一个没有责任心的任务机器。
衡量有效性主要有四个方面：
- 以终为始
- 任务分解
- 沟通反馈
- 自动化
以终为始
以终为始，就是在做事之前，先想想结果是什么样子的。很多时间，开发人员想的终和产品想的终不一样。终本质上就是和团队所有人一起构建一个集体想象，或者说想象的共同体。
对做软件的人来说，我们应该把终定位成做一个对用户有价值的软件，能够为别人带来价值，自己的价值才能体现出来。
既然是想象就需要实际呈现出来，对于一个需求或者功能需要经过两次创造，第一次是在头脑和纸笔上，也就是产品文档和需求文档，第二次才是付诸实践进行开发。
但是工作中很多都是第一次创造还没有做好，就开始了第二部，相对于第一次创造第二次的成本是很高的，所以需要在第一次创造多下一些功夫，将相关各方的集体想象统一起来。
做事前先考虑到详细的结果或者后果，把终具象化，然后在开始去向着终去实现。在拿到需求后，需要详细的去了解这个需求的的用户故事，以及给用户带的价值，还有就是是否还有其他方法可以带来同样的价值。
任务分解
一个大问题，都很难给出答案，但回答小问题却是每个人都擅长的。譬如假设需要做一个通用的登陆模块，对于一个新手来说可能会分解成。设计数据结构、编写登陆逻辑接口、编写token逻辑、编写注销逻辑、编写修改密码逻辑等等。但是如果是一个老手可能会拆解成、设计数据接口、用户通用功能逻辑编写。
分解任务的重点就是：不同的可执行定义差别在于，你是否能清楚地知道这个问题该如何解决。
在譬如，我们保存用户数据到 Mysql 中，对于大多数人这其实就是一个可执行的任务，但是如果是保存到一个我们没有使用过的新型数据中，那么任务中可能就需要存在去学习这个数据库的任务。
对复杂需求来说，任务分解是巨大的挑战，面对日常工作，我们更容易忽略的是分解的任务要可执行。每个人对可执行的理解不同，只要我们清楚地知道接下来的工作该怎么做，任务分解就可以告一段落。
沟通反馈
沟通中经常出现 X/Y Problem， XY Problem 就是提问者没有向被问者提出问题的本身，而是将提问者自认为的解决方案抛给了被提问者，于是大家在一个错误的方向上浪费了大量的时间和人力物力。
一个有意思的 X/Y Problem 示例： Stack Overflow 上有个问题，问的是“怎么截取一个字符串的最后三位？” 下面有一堆答案。突然有个人问：“你为什么要截取字符串的后三位？”他说：“我要找文件的扩展名”。实际上，文件的扩展名不一定是 3 个字符，而且有专门的函数干这个事儿，不需要自己写。这里，取文件的扩展名，这叫 X，取文件名的最后 3 个字符，这叫 Y。他想知道 X，但不知道该怎么说，于是就说成了 Y，导致别人都去解决一个不存在的问题。
这个世界上到处都是 X/Y 问题。当你了解了 X 问题后，你就要到源头，来质疑或是改良他的 Y 问题，甚至提出 Z 方案，而对方会陷入被动，被你牵着鼻子转。
避免 X/Y Problem 关键在于在提问时，将想要解决的问题以及尝试过的解决方案一并给出，且应该清晰的阐述问题和背景，这样别人才能给出正确的解决方案。
其次是跳出程序员角色思维，扩大自己工作的上下文。虽然我不是项目主力，但不妨碍我去更深入地了解系统全貌，虽然我不是项目负责人，但不妨碍我去了解系统与其他组的接口，同样，虽然我不是项目经理，但我可以去了解一下项目经理是怎样管理项目的，虽然我不是产品经理，但了解一个产品的设计方法对我来说也是有帮助的。
当你对软件开发的全生命周期都有了认识之后，你看到的就不再是一个点了，而是一条线。与别人讨论问题的时候，你就会有更多的底气，与那些只在一个点上思考的人相比，你就拥有了降维攻击的能力。
核心就是扩大自己工作的上下文，别把自己局限在一个程序员的角色上。
自动化
自动化就是将繁琐的工作通过自动化的方式交给机器执行，这应该是我们工作的一部分。打造自动化的服务，减轻自己一些重复性的工作，用这部分时间时间来持续的学习和成长，创造更多的价值。
工作中经常遇到的问题
学会说不
在一些情况下说不，比如一些需求需要在很快时间完成，今天提的需求，恨不得明天就上线。在这种情况下，你要学会对某些事说“不”。
经常会出现上级问你，”这个产品我需要接入，后天能不能上线，“，然后你想了想，如果不写测试不考虑未来的扩展和数据的流向，确实能够节约不少时间，然后你就妥协了，妥协很容易，但再往回扳就不容易了。下次，他还会再进一步压缩，”一天能不能完成“，人的欲望是无限的，所以，就不要让上级有错误的预期。
正常应该告诉上级，这个压缩会影响到什么。比如，要想做这个调整，你需要放弃的内容是什么，或者，可以给出一个快速上线的临时方案，但接下来的几天，需要调整，让代码回到一个正常的状态中。所以，你就不要给我安排新工作了。这个过程，相当于把自己看到的问题暴露给上级，让他选择。他有更多的上下文，他会平衡该做的事情。
当你面对时间完全不够的需求时，你也不要说不。既然对方把压力给你，你要想办法把这个压力还回去，或是让对方来和你一同分担这个压力。我可以加班加点完成，但是我不保证好的质量，有 bug 你得认，而且事后你要给我 1 个月的时间还债。
不能直接说”不“ 是我要有条件地说是。而且，我要把你给我的压力再反过来还给你，看似我给了需求方选择，实际上，掌握了主动。
尽早暴露问题
遇到问题，最好的解决方案是尽早把问题暴露出来。对于程序员来说，在程序中尽早暴露问题是很容易接受的。但在工作中暴露自己的问题，却是很大的挑战，因为这里还面临着一个心理问题，会不会让别人觉得自己不行。
说实话，这种担心是多余的。因为每个人的能力是强是弱，大家看得清清楚楚。只有你能把问题解决了大家才会高看你，而把问题遮盖住，并不能改善你在别人心目中的形象。
既然是问题，藏是藏不住的，问题还是会出来，到那时，别人对你的评价，只会更加糟糕。
情绪控制
工作中动不动就生气或者心怀戒心，通常会令沟通很难进行到导致工作延误甚至停滞。沟通中需要时刻保持清新思考。
交流中不要过早的质疑对方。即使有不同的观点，也不要过早的打断对方，也许等你听完对方完整表述后会改变自己的一些看法。
求同存异，冷静客观。每个人的知识储备不同，生长环境不同，经历和性格等也不同，所以看待和理解问题时，自然会有很大差异。所以，要懂得尊重这些差异，客观公正地思考问题，并给出相应的建议和看法。切莫在冲动之下，说出很多一些过分或过激的话，因为言语的力量是巨大的，杀伤力有时难以预估
学会投资自己
学会规划自己的时间，定义好优先级。无论写不写出来，一定会要有一个自己的 to-do list。有 to-do list 并不是什么高深的事。更重要的是，我们要知道什么事是重要的，什么事是紧急的，什么事重要但不紧急，什么事又重要又紧急。这有利于划分优先级。
对于相同优先级的事，可以使用“最短作业优先”的调度算法。理由是，先把可以快速做完的事做完，看到 to-do list 上划掉一个任务，看到任何的数据在减少，对于我们也好。
关注长期利益规划。要多关注长远可以节省多少时间，而不是当前会花费多少时间。长期成本会比短期成本大得多。所以，宁可在短期延期，也不要透支未来。按季度来规划，这个季度做什么，达到什么目标，一年往前走四步，而不是只考虑眼下
我们的时间就像金钱一样，我们要学会投资时间，把时间投资在有价值有意义的地方，就会有“更多的时间”。花时间在解放自己生产力的事上。在自动化、可配置、可重用、可扩展上要多花时间。
花时间在解放自己的事上是最有意义的了。花时间在让自己成长的事上。成长不应该只看在一个公司内，而是要看在行业内，在行业内的成长才是真正的成长。所以，把时间花在能让自己成长，能让自己有更强的竞争力，能让自己有更大的视野，能让自己有更多可能性的事情上。这样的时间投资才是有价值的。
最后
996 只是手段，而手段必定需要为某个特定目的服务，目的还不明确的时候，手段的有效性是无法评判的，所以工作的有效性也大概率是没有的。不如一起坐下来一起确定我们的目标是什么。