01 | 10x程序员是如何思考的？

这个方法论恐怕要建立在开发和产品双方地位比较平等的基础上。 以我们目前的现状，很多时候产品要做这需求的理由就一个：老板要的！

思考框架是道，原则是演化下的术，我们从 A → B，有无穷无尽的路径，最有效的唯有那条直线。本质上，各个维度、原则（不限于作者提到的四项原则）都是帮助我们更好地定位 A 在哪里，B 在哪里，那条直线在哪里。 这个思考工具算是吸收了，四项原则也是有借鉴意义，谢谢

我们的产品经理的回答是：“你是在拷问我吗？这个你不需要知道，做出来就好了。”或者:“先做出来上线看看用户的反馈，不行了再下掉。”又或者：“这个是老板提的需求，优先级最高”

想起吴军老师讲的三条边，组成的“工”，上面是目标或者行业边界，下面是自己的现状，中间的边就是实现路径，人生主要就是要找到这条路径，下面的一条边代表基础和能力，越粗越好

以终为始的理念还是非常有启发的，具体工作中往往会陷入细节中而看不到目标或者忽视目标，例如把实现路径当成了目标。同时，有了目标还需要不断的反思，孔子日三省吾身，我们起码按季度需要重新总结和考虑一下目标和路径的合理性。另外，文中讲到的沟通和自动化如果更加深入些就好了

说真的，真羡慕年轻人更早得到看到这些文章，本人马上进入不惑之年，已是走在讨探的边缘。因为过于平凡没有走出人生华丽的线条，学专栏是希望给职业续续命。 在职业中如果能持续地解决几个问题，会有不错的机会，正如人生走对几个关键点。此专栏分享的一套行之有效的方法论，职场中是很少有人提点的。 人的思想很难改变的，文中提到的原则都听过，缺少有系统地使用过。希望接下来的学习可以深化成自己的行事原则，和思考模式。 这个思考框架很有意思，像极了哲学的三个终极问题：我是谁？我从哪里来？我要到哪里去？ 思考模型不局限于特定问题，而是通过这套模型去解决现实中的实际问题。作者说这套框架只是工具箱里的一件，不知道还有哪些好用的工具，期待分享。 不说了去看下一遍了

老师的建议和指导都是非常有效，而且“感觉非常可行”，可是实际现实的情况，却有太多意外，我个人曾经在某银行的外包团队中，协同开发一个商户-收银以及集成了各种第三方的团队的接口等等，这个大项目大概有300人以上，由此我得leader不在，我代表开会，足足开了3-4个小时(约30个leader)。杂乱无章，从我个人开发角度无法去高屋建瓴的把握全局应用场景，使用价值之类的。但是每个模块之间互相调用联系，系统升级需要协作。首先，这里沟通成本很高，最要命的是需求变动，无法预测，有的时候新增需求，技术leader直接告诉我在什么地方写一个action，调用一个方法之类的。基本就是码农搬砖之类的，我想提的建议是：希望老师在有丰富理论知识，能给我们有一些实践中的例子，或者列举一些举一反三的例子，理论+实践，我觉得才是最佳法则(没有说老师只是有实际，没有实践，莫怪)，第一次这么长的留言，望采纳，谢谢您了

解决问题的思考框架的四大要点。以终为始，任务分解，沟通反馈，自动化。 （其实我觉得自己当前在哪里有时并不明晰，人总是存在各种偏见傲慢不理性。） x-y问题描述的就是错把手段当目的的没有以终为始的一个典型反例。 解决问题第一步就是定义问题，知道自己要解决的问题的实质。爱因斯坦的名言说要解决问题的大部分时间应该拿来弄清问题本质。不过他指的解决问题应该只包含找到解决方案这部分，不包含具体实施。知道了问题的实质之后开始拆解问题，进行任务分解。通常，弄清问题本质和任务拆解是一体的，分不太开。 关于任务分解，也就是找出解决方案，学问就大了。其中涉及各种思考框架，包括通用的如金字塔原理，各种领域套路，4c3p。这部分就需要学习工作中常常总结了。 沟通反馈透露出控制论的思想。在行动中根据反馈不断调整自己的行动。 自动化，在程序员这一职业中更加长见，程序员本身做的事情就是在帮助别人自动化。而自己的工作也不能忘了自动化。从软件的整个生命周期中，大量存在各种使用的工具。不过不能停留在学习这些工具的使用上，而是应该追问这些工具出现的原因，而自己的工作中有哪些工作是可以使用工具帮忙完成的。

很多团队的问题是人的问题，那些小公司的团队，收入不高，生活压力大，本身就生活在焦虑和恐惧中，哪有心情讨论需求的背景，要解决的问题，解决方案，非功能需求......。最后就是程序员看需求人员2，需求看程序员无法进行人类沟通。

这让我想起了金字塔原理。在解决问题领域可能是这样的： 1. 目标导向，在这里也就是以始为终。思考自己的目标 2. 分类，也就是思考从当前位置到目标有哪些影响因子 3. 优先级，在这里其实是选择适合的方法 4. 解决问题 解决问题的具体方法那就该是： 1. 任务分解 2. 自动化 3. 沟通反馈