Whwhorere 是美团提出的一个适用于产品规划和思考的方法论，其构成为 Why, What, Object, Resource, Roadmap, Evaluation，其实和我们经常提到的 5W1H 比较类似，但是更加适合用于产品规划方面。
使用这个方法论，可以让我们对于产品的思考更加的清晰明确，建立起一个更加直观的框架结构，也便于我们将自己的产品规划讲述给他人。
今天看到了一篇文章，讲的是一个团队指定了 A 作为 B 的上级，但是 A 却没有批复 B 的申请，给 B 打绩效的权利，B 的绩效好坏也不影响 A，久而久之 B 不再听从 A 的安排，A 也不去管 B，导致 AB 虽然是一个团队，却没有团队的合作。这个就是团队管理中常见的权责利不统一而导致的问题。
三者之间的关系是缺一不可，相互制约又共同生效的，缺少了权就像指挥家缺少了手，无法顺畅的指挥交响乐，缺少了责容易成为“渣男”，只分派任务却不用担责，导致人心不平衡，缺少了利就是“想让马儿跑，却不给马儿吃草”，三者任缺其一都会导致管理出现问题，要做到权责利平衡，需要先做到薪资等利益和岗位责任对等，其次对应的岗位责任需要赋予对应的权利，岗位责任最大，工作难度越高，赋予的权力也需要越大，成功获取的利益大，失败承受的后果也更严重，三者相互制约，可以理清工作的边界，让我们认清工作的本质，知道什么是我需要做的，做成功能获得什么收益，这样我们工作的积极性也就提升起来了。
这周看到一篇 不错的文章， 大致讲的是我们要有一个认知，即决定成功的往往是学习习惯与思维习惯，而非天赋。
举个例子，在面对同样一个问题时，有的人能看得全面深入，有的人却只能单一角度看问题或无法深入。再比如一件事情需要我们进行 7 层的逻辑判断，一部分人由于长期以来的好习惯将思维锻炼到了直接就可以达到 4-5 层，而另一部分人缺少锻炼只能直接看到 1-2 层，面对这个问题的时候就会发现前者往往可以很容易的解决问题，让人觉得他们有天赋，这看起来是天赋，但一些精准的判断与独特的视角却是在过往的习惯中不断积累下来的，因此会给人一种有天赋的感觉。
而形成这些习惯的本质原因，是我们从小的教育与成长环境。有的人过往环境让他更倾向于做能获得短期刺激的事情（如上课开小差、想学习时却被抖音/剧集吸引等）；有的人从小培养了专注的习惯，会对于刺激来的更长期的读书、或深挖一个问题找到背后原因的快感更加倾向。其实所谓天赋，不过是过往的长期原始习惯积累带来的能力差异，并非真的不可逾越。
因此，在这个认知基础上，我们可以刻意训练自己的学习习惯与思维习惯。比如看书时远离手机，给自己创造一个安静的沉浸式的环境，培养专注的习惯。比如在遇到困难时，首先不是畏难，而是尝试找到角度深挖下去，长此以往在遇到困难时的第一反应不是害怕而是快速反应应对。当然除了这些还有其他一些习惯是可以养成的，意识到习惯的差异并建立正确认知，通过刻意练习，是能够逐渐弥补大家普遍认知的“天赋”差距的。
昨天和朋友讨论了一下关于工作总结应该如何去做的问题，他提出了一个观点我觉得十分正确，就是在总结中我们需要增加我们对于中观层面的思考，而不是仅仅罗列我们做了那些事情和达到了哪些效果。这让我想起了一个之前听到的一个做事情的方法论，叫做「以终为始」，在我们分析问题的时候应该从想要达到的最终效果开始思考，以此为起点，反推出我们需要做到哪些事情。比如我们要实现一个需求来达到某个目标，我们需要思考的不应该仅仅是如何完成这个需求，而是要去想为什么要达到这个目标需要做这个需求，而不是其他需求，有没有什么更好的解决方案，每种解决方案都有哪些优劣之处，为了更好的达到这个目标应该以什么样的优先级来完成不同的小步骤等等。这样的思考方式最开始会花费我们更多的时间和精力，但是一旦养成习惯之后，可以大大的增加我们思考的深度和广度，并且这种思考方式不仅仅可以运用在工作中，生活中也可以使用这种思考方式来达成更好的效果，比如参加一场重要的聚会，先思考想要在聚会上想要达到的状态，然后以终为始选择自己的装扮等等。
首先，我们需要明确的一点是，用户也无法清晰的知道自己的需求是什么。所以我们在跟用户讨论需求的时候，不要去问用户想要什么功能，否则往往会陷入细节却无法得出真正想要的结果，更好的方式是去引导用户讲述自己的使用场景，以及为什么会有这样的使用场景，自己的痛点是什么。收集过后，使用 MECE 法则，针对用户的场景和痛点穷举出可能的需求及其解决方案，列在白板上，然后对这些列举出来的方案进行抽象归类，这样就形成了一个一个的模块，然后对各个模块进行去重和提炼，提取出各个模块的核心，建立他们之间的关联，然后形成文档之后，与用户再进行多次沟通和交流，多次完善需求和方案，最终达成一致。
在完成需求的时候，需要对各个模块进行充分的评估，然后确定出各个模块的优先级和大致的实现顺序，然后再对各个模块进行更细粒度的拆分，建立起相关的任务，与相关方一起评估实现的难度和方案，讨论得出实现的时间节点（一定要预留足够的 buffer），对于那种有依赖方的需求一定要提前进行沟通，保证正式开发之前依赖已经准备就绪，而不是等做完了某些需求，等要做有依赖的需求才发现依赖方还未准备就绪，这样会有极大的延期风险。实现需求的之后最好能够用 TDD 的方式进行开发，这样可以更明确的了解到需要实现到什么程度，也能在一定程度上保证和提升开发的质量。
有时候会听到一些同学的吐槽，说自己遭受了上级的不公正待遇，把更好的机会给了另一位同学而不是自己，导致自己的绩效不出彩，甚至会心生怨怼。其实我们可以设身处地的从两个方面来考虑这个问题：
今天在发布上线的时候，CI 突然报错没有通过编译，打开一看，惊了，之前依赖的公司内部的一个组件库的 tag 删除了😂，oncall 问了原因，告知是有两个连续的版本 1.0.2 和 1.0.3 有个比较严重的问题所以删掉了。由此，我不禁思考：如何发布版本才能更少的影响用户
从我开始用「不背单词」APP 背单词和「多邻国」APP 学日语已经 50 天了，以前都说 21 天养成一个习惯，那我这个习惯也算是养成了，但是其实能够坚持下来也是有一些条件的，这也和《掌控习惯》里面提到的一些方法不谋而合–让习惯简单易行和让习惯令人愉悦，其中我背单词的时候没有每天背非常多的单词个数，因为那样复习的时候会让自己产生压力，让坚持变的困难，而「多邻国」每个单元的学习比较简短，并且在每次学习之后给出一个及时反馈，给一些奖励，并且有学习排名，让我更有动力继续学习下去。
反映到我们生活中的其他方面，其实我们也可以使用类似的方法让自己能够更长久的坚持下来
平常在设计系统时，会基于现有的条件进行系统架构的设计，满足当前用户的需求，以最小的代价完成系统设计和实现。这样的设计在无法完全确定当前业务能否“活下来”的情况下是比较适用的，因为成本较低，可以快速试错，但是带来的缺点是总以最小代价来进行设计，可能会导致设计能力的原地踏步。因此，我们应该在成本可控的基础上再多进行一层抽象的思考，当用户量级或者请求量级提升上来之后应该如何进行设计以保证系统的可靠性，或者如何提升设计的通用性，减少以后的修改成本。
最近学习了一个与人 one on one 的方法论模型，总结起来主要有两步：第一步是「建立信任打开心扉」，第二步是「解决问题」，切记在对方打开心扉之前，不要抛出问题，并且整个谈话应该是以被交谈者为中心，因为谈话主要是为了解决被交谈者的问题。两个部分又分为两个不同的模型
「建立信任」使用 PLASS 模型（praise listen ask share support），praise 表示以肯定和赞许开头，用「事实+评价」的方式肯定对方，打开对方心扉，listen 表示在整个谈话过程中要以倾听为主，给对方足够的时间和空间来表达，并在倾听过程中表示理解，ask 表示用询问和引导的方式获取对方的意见和想法，切记不要过分表达自己的想法，share 表示在谈话过程中还应当分享自己的意见和经验，表露自己的感受和想法，给对方提供「参考」而不是「指导」，support 表示在对方提出需要帮助时，尽自己的努力为对方提供尽量多的支持和帮助，切记不要越俎代庖。
通过上面的方式建立起信任，让对方能够真正的打开心扉，才能开始「解决问题」，这个阶段可以使用 GROW 模型（goal reality options way-forward），首先要对齐目标 goal，包括短期和长期目标，让谈话双方能够在一开始就谈论问题的重要性达成一致，然后需要分析现状 reality，抛出遇到问题的难点和原因，充分交换上下文信息，接着一起讨论方案 option，提出一些可供选择的策略或者行动方案，讨论需要哪些支持和资源，最后需要确认行动计划 way-forward，拆分达成目标的步骤，并且设立具体的实施方案。