回看在阿里的这几年，乃至追溯到整个毕业后的工作过程，作为一名后端偏向业务向的一线开发，我一直在想，抛开技术栈和方案经验等这些具体的细致内容之外，究竟有什么东西是能够迁移到更多场景乃至生活上的体悟，思索良久，大抵可以此概述。
总会走的“路”
想来，除少数天才外，所有人走进职场的开头，都是从模仿开始的。这一点在工程领域尤甚，跟着前辈、师兄、领导，学习怎么使用开发工具、生产环境，怎么去受理需求，怎么去按照既定的设计实施，最后开发测试完成上线，即便是之后换了新的工作环境，这些流程大致还是需要重走一遍的，当然，这一点我们的术语也称其为“落地”（不排除落地中也包含着文化同化的部分）。
随着在一个领域里了解的越来越多，或者是在一个课题中越做越深、越做越细之后，慢慢的会对现状产生怀疑、产生不满，觉得现有的东西不够完美，还能有进步空间，就开始想办法去找新路子、做优化、搞设计，目标是突破现状得到更好的结果。直到某一个领域完全符合了自己的想法（当然不排除也会走向自我和解），也能预见在未来的一段时间内能够cover掉大多数的变化的时候，就会尝试跳出边界外，再去找一个相关的领域或者干脆找一个完全新的领域去从头开始。
对于一个技术人而言，这种从0到1再到100的过程，真的是会令人上瘾的，毕竟与此相比，在别人成熟的东西上继续添砖加瓦所带来的成就感和获得感会少的多，技术是需要技术热情推动的，所以也就不奇怪为什么很多团队乃至公司在接手现成项目产品的时候，都会选择技术重构、架构升级等，当然最主要的方面还是为了解决技术旧债和统一建设思路的问题，不过，谁敢说这里面完全不存在哪怕一点点私心其实是为了这点子热情呢（手动挽尊~狗头）。
理出来的“核”
无论是刚开始上手的初期，亦或是逐渐轻车熟路的中期，还是历经数次大促不断打磨过的后期，一名开发同学在不同历史阶段做的事情虽然会千差万别，但毕竟还是同一个工种的事情，说的笼统一点无外乎需求、设计和开发，总会存在一些不变的道理。
很多事情，无论具体的细节随着时间怎么变，都会有存在一条很难直接言明的框架和脉络，内涵于这件事情的本质属性，让人即便遇到了一件看似新鲜的工作内容，在了解了变化后还是会说一句“嗨，什么嘛，不还是一回事”。然而，对所见事务按“相似性”进行归纳，是人类天生的一种学习能力，归纳法是人类认世界最简单的实践根本，人类大多数智慧都发生在生活和经历中，是从具体生产、生活事例中归纳出来的通用性的结论，工作基本也是一样，即所谓工作经验。同意了这个观点，再看看遇到新项目、新需求、新题目的时候，我们大多数时候的做法，还是先想想自己是不是曾经做过类似的事情，然后再去问问做过类似事情的人，以及来ATA上查查有没有类似的项目分享学习经验。说白了，只要是能描述清晰的问题，最终结论都是可解的，所有的不可解都是衡量代价后产生的问题。
直到现在，我还是在说具体的事或者同类的事，那么现在跳出这个思考边界，回到框架和脉络这种本质属性上。开发同学最喜欢做的事情之一就是抽象、封装，那么把这种好习惯用在写代码之外，就以开发工作而言，乃至工作而言，这事儿有没有什么东西，是这个领域解题思路的“核”？
在我看来，工作上的事，无非三个方面：做事情、想事情、谈事情。
做事情与想事情比较好理解，为什么我会单独列出来谈事情，下文细聊，不过三者倒也真的算是相辅相成，只做不想谓之码农，只想不做谓之吹牛，至于只谈不想也不做算什么，那不就是个传声筒呗，算什么开发呢。
做事情
“结果利他，过程利己。”
开发都要做些什么事情，一言以蔽之“实现需求”，实现了能发布上线，做出来的东西得好使，这才是硬道理。工程一事，不只是软件工程，都是结果论调，没做出来东西或者东西不好使，只流于表面夸赞思路超前、架构先进，然后讲出来一套一套，这都是花架子，经不住推敲和敲打，常以此自省。
开发完整一些的流程，从收到需求开始，历经分析、设计、实施、实现、验证直到最终交付。但在上述流程之前，有一个易被忽略的环节，是需求调研的过程，目的是为了搞明白这需求是咋来的；而在流程之后，还有一个被忽略的环节，就是总结，这个总结不是为了理清项目成果，而是想清楚除了项目拿了结果，自己从中收获了什么。
大家都是老司机，标准流程怎么干不说了，仅仅聊些小体悟：
调研
调研这件事，我一开始是走偏了的，曾经我试图去自己走一走从用户诉求到产品需求的转换过程，但开发毕竟不是产品，虽然坊间经常说“人人都是产品经理”，但是不可否认的是，产品需要一定的思维和经验，如果这过程这么容易，那么就不需要设置单独的岗位来做这件事了，专业的事还是需要专业的人来干。那如果不去关注这个转换过程，开发同学还关心调研这事干嘛，等着看PRD不就行了？行是行，但是不好。
不知道大家有没有这样一种经历，辛辛苦苦做出来的东西，结果业务方拿到了以后说这个跟他们想的差的比较远，然后产技会劝说先试着用用看，结果用过一段时间就反馈说东西不行用着别扭，渐渐就不用了，长时间后产品落入了不再维护的境地里。可这事，也不能总怪产品同学写PRD不认真，也不能总怪技术同学做的不行，每一个个体由于自身的经验和思考方式的不同，对待同一个场景的理解是不同的，PRD能清晰的描述逻辑，但是未必能描述初衷，尽管PRD的第一小节永远都是项目背景，别人嚼碎的东西咬着是不太费劲，但是就不知道一开始吃的是个啥了。
所以说，开发关注的调研是什么呢？这个核，大概率就是那个初衷，甭管产品写了啥，先去听听业务当初为啥跟你提起这件事、遇到了什么问题，为啥必须系统化的去解决，是因为搞不定、还是费人力、还是为了玩出个花活，有了自己的认知，回头再看看产品同学帮忙嚼碎后写出的PRD，是不是把这个初衷不小心自己给咽下去了（别细想，怪恶心~），这样的PRD评审才有意义。
设计
每个开发都有做架构师的梦想，这没毛病。一开始就是老老实实顺序写，后来就总想着封装、抽象、控制反转多玩点设计模式的花活，再后来就不满足于此了，甭管啥需求，开发过程不沉淀出个框架、工具来就不行，这过程只要是追求成长的开发同学都会经历，可这事吧，不怕不去干，就怕干的太过了，过犹不及。
所以怕的不是不设计，怕的是过度设计。
我超级喜欢辉子老师的CLED的概念，但是一度没有把这几种概念之间的边界搞清楚，想来也有不少相同经历的同学，为了追求无比闪耀的Configuration而做了一堆配置化的组件、工具、平台，动不动就上升到表达式的层面，尝试把所有的业务逻辑以表达式的方式进行表述，然后就导致在工程代码内完全看不懂这个系统到底处理了什么业务逻辑，一扒代码才发现这些逻辑都落在数据库或者Diamond里变成片段化的QLExpress或者SPEL了，再加上没有图形化的用于表述逻辑的配套设施，业务逻辑碎了一地。
回到设计的初衷，设计是为了解决问题存在的，不是为了单纯的秀，简单即好，适度设计。
实施
骄傲是工程师的天性，具体一点，都会有一点设计洁癖和代码洁癖，但是随着工作的进行，总得慢慢的学会认识到一个道理：不是所有的事都能靠自己一个人搞定。所以上图流程里的实施和实现的区别，想说的也是这一点，实现是自己做的过程，实施是与别人与团队一起做的过程，配合与协同，转变思路是第一位的，这是起点。
那么一开始怎么做好配合呢，尤其是跟不熟悉的开发同学，在不熟悉做事风格的时候，怎么来沟通防止彼此掣肘？一个比较好的解题思路就是设定好领域边界，类比DDD里的概念，大家共识上下文，但是彼此靠边界做隔离，这里的边界的表现形式具体到过程里可以是接口范式、可以是排期设定、可以业务逻辑，然后剩下的，因为相信，所以看见就好。
然后协同的问题就在于又怕太相信到完全看不见，“这事反正有人负责了，过程做到什么程度无所谓了，反正最后能交付就好”，这种想法是非常危险的，过程要看得见，不要成了盲人，大家定一些关键节点的同步周期，合理控制下风险即可，当然也有频繁到每日发日报同步项目进度的，大项目人多沟通不便时这么搞比较好，但是人数少周期短的协作项目这样反而就会很占开发时间，还是老话，什么事都要讲究个适度。
总结
这里想谈的总结不是那种项目战报，而是那种给自己看的真总结。
需求项目做了一年又一年，除了产品本身外，有没有给自己留下点能称得上“持续发展”的东西？很多时候，连续时段的忙碌，就把总结与回顾的过程忽略掉了，交付完拍拍屁股进入下一个，偶尔想想得失，也是很碎片的一些想法观点。其实细想想，这些细碎的东西整理整理就是所谓的产品观、架构风格、方法论，或者这些东西才是要比项目的结果对个人的发展来说，重要得多的东西。
另外这些事光想可不行，零散细碎不成系统的东西是不易被记忆的，需要整理、需要写下来。开发同学大多数不愿意在文字上下功夫（Me too），但是多尝试几次就会发现，每次写完总有一种醍醐灌顶、焕然一新的快感，也能在文字书写的过程中重新审视自己的观点，修正、优化、升华，反复捶打，终是精髓。当然每一件事都总结也不现实，没那么多时间，活还是要干的，阶段性的进行，加上定期的回顾，培养自身发展的节奏感就好。
对于一个技术开发人员来说，成长总在反复的经历每一个需求的过程中不断打磨，回到写在做事情开头的一句话上：“结果利他，过程利己”，结果当然重要，拿人钱财替人消灾，拿了薪水就要给出工作的结果，但是对于长线的发展而言，结果只是短暂的喜悦，而过程的体悟才是最该留在手里的东西，这玩意才是实实在在能够带着陪伴一生的东西。开发同学总爱说沉淀，这沉淀也得分两方面，看的见的沉淀是留在工程里的框架、工具，看不见的沉淀都在自己的脑子里，说白了如果干了一件事，没去细想或者想了一圈自己没思考到什么体悟，那么这事基本等于白干，所以对过程的思考这事要重视起来，好的善于做事情的人是耐得住寂寞的，也知道做的每一件事里自己在表面的需求达成过程中还需要追求什么沉淀，借事成己，才能不断到达新的高度。
想事情
“难的不是想解法，难的是想问题。”
开发同学的工程师特性是善于做事情的，但是进到做事情里面去很容易，跳出来却很难。
自驱
跟一个开发同学说，来设计一个用于某项功能的组件、中间件，大部分同学还是很容想到解法去做到的，但是跳出这件事本身，由开发同学自己去发现当前系统架构中应该构建一个具备某项能力的通用部分，而又不陷入“过度设计，空造轮子”的泥潭，确实是需要一定的时间、项目、知识、经验的积累，看看周围师兄前辈的那种游刃有余感，不要慌、不要急、多发掘、多观摩、多尝试，其他的也不用再唠叨，“馒头会有的，面包会有的，经验也会有的”，这件事迟早会做的到并且慢慢老道愈发醇熟。这个过程就是技术层面，开始想问题的过程，换个常听的词就是技术自驱。
但是在另外一个方面，跳出技术实现这件事，一个开发同学需不需要对业务有一定的提问能力？私以为还是要的。
首先，对应到前文说的调研过程里的初衷二字，要想理解业务同学初衷，前提是得懂业务才行，这里的懂不单单是指能听得懂，要想理解初衷，还需要能对现有存在的问题具备“同理心”，就是能确真理解业务提的这个问题的意义乃至情绪在哪。
其次，在此基础上，换个自己的视角去看到业务这些事情还有什么问题，说通俗点就是“眼里得有活儿”，业务同学是业务的专家但不是开发，很难具备开发思维，或许很多时候甚至都不会想到某些日常工作可以应用化或者需要应用化，习惯了模式再加上做的熟练，业务同学都会有自己日常处理事情的SOP，很多事可能用个Excel就把数据都处理了，也就不会想还要什么系统，这些事情放在天生爱偷懒的工程师眼里，标准的流程和重复的工作应该让机器来干，就会有一个系统的雏形出现了，这样做出来的东西又有受众、又能释放人力、又能完成经验的传递（标准化的系统会降低同类工作领域内熟练者和非熟练者之间的差距），实在的很，如果看到业务同学之前总用手动的扳手拧螺丝，那我们就来尝试造一把电动的。
升华点，再来想想终极的问题，那些业务同学告诉你现在他们做不到的事情，是不是技术能做到？很多事做不到，仅仅是因为只有一个理想化的思路，然而非人力不可为，但是，系统的出现或许就能解决的掉。当然要做到这一点，没有长久的业务知识积累和自身对行业的理解是做不到的，也还有很长的路要走，但是要培养开始这样思考的意识，想得多了总会有的，再换个常听的词就是技术赋能。
审视
一开始做事情，在面对需求的时候，很容易就开始直接思考能不能做以及怎么做的问题，但在此之前，其实还缺了问问题的过程，问什么？问那些做事情以外的内容，不敢说自己的问题有多全面，但我更习惯将整个过程称之为审视，我经常问的两个问题，一个是为什么要做，二是为什么要我来做，一问价值，二问站位。
在价值的问题上，区别于调研阶段的明确初衷以外，是要搞清楚这个事是不是个伪命题，以及这事这么干了能不能获得解决问题目标方向上的最大收获。其实，关于怎么评估价值，不同的场景千千万，难的不是如何定义价值，而是想到要先去定义价值，要明白俯首为牛的努力不完全可取。一件事情看不到价值就去做是去做苦功夫，但是苦劳不一定就是功劳，功劳更不一定有用，尽管很多事情在一开始的时候看不到结局，但是总会存在一个可以明确的初衷以及最初的判断，不可能凭借一句“我觉得行，我觉得有搞头”就扎进去做事情的，现在只有自己一个人的时候，可能只是浪费了时间，如果将来有了团队有了伙伴，这种模糊甚至于不过脑子的鲁莽会导致整个团队创造不出应有的价值，苦哈哈忙了一年没个好收成。
在站位的问题上，很多时候我们问的出对价值的拷问，但是却问不出站位的问题，站位和补位是有明显差别的，如果一件事情谁都能做，那为什么不是别人来做，难道仅因为跟我好说话就由我来做？其实并不尽然，一件事需要我做，总有需要我做以及适合我做且能做好的理由，哪怕仅仅是现阶段的，但这却是自身能区别于他人的理由，而这种区别也会体现在最终做事达成的结果上，每一个结果加上这个结果历经的过程都会带上非常浓重的个人或者团队色彩，而这个色彩的积累又会成为一个人或者一个团队区别于其他人或者其他团队独树一帜的东西。
提问和思考总是同步的，把思路开放到编码以外的事情上，看到事情会变得更加丰满，回过头来，再来思考什么是想事情，大概就是对于现有的内容要分析透彻，找到切入点和站位以及在结果表象下的内在价值；对于未来的问题，找到问题发生的可能寻找机会，找到个人和团队适合的发力点和着手点（抓手~）积极布局。
谈事情
“凡人之所在，皆为江湖。”
更何况是我们这个号称江湖的江湖？
其实在此前，我会认为做事情和想事情才是重中之重最核心的内容，对于谈事情并不关注，工程师嘛，不爱整这些虚头巴脑的东西（技术牛逼，天下第一），但是时间长了就发现，很多事情没做成或者没做好，不是硬件能力不行，明明所有的情景看上去都没那么难也想的到明确解法，但是就是不成事。大家不妨回忆下跨领域查线上问题的时候，是不是总有这样一种感觉，明明问题的追查线路明确的很，就是你推他推，或者查着查着不知道在哪就没下文了，到最后拖个两三天甚至一周的时间才找到问题的原因，烂尾的也有不少。经历这种事多了，慢慢开始对一句至理名言产生了认同的情绪：
“所有问题，最终都是人的问题。”
常在管理层的分享中听到一个观点说：“管理就是用人成事”，说到底还是这个观点的延伸，给每一件事放到一个合适的位置上，找一堆合适的人，这件事就成了。但是人和人之间又不会像系统与系统间或者应用与应用间靠MetaQ、HSF就连起来了，还是得回到交流与沟通这些看似琐碎的事情上。
同时，每个人走到后面，总会有自己要做事找资源或者成为PM的时候，对于开发这个领域而言，机器硬件上的事都有的商量，但是找人一起来共同做一件事的时候却可能比要机器都难，总说开发资源，说到底不还是人。
只要是人，就要用人的方式来解决，“江湖不是打打杀杀，江湖是人情世故”。
张嘴
回头看，能围着一件事稳稳当当的做，真的很可以称之为一种幸福，不需要跟任何人扯皮、只用做好自己的事，对于一名开发工程师而言是做舒服的状态。可是，就我的感受而言，当我慢慢走到前台需要用自己的嘴表达想法、推动进展的时候，才发觉这件事情或许会成为我乃至大多数工程师往前再走一步最致命的阻碍，张不开嘴，张嘴以后也不知道从何说起。
很多事情想明白需要做，也设计好了大概的执行思路，关键的问题在于，但凡有大作用的项目都需要有很多人参与，怎么让别人参与进来，让他人接受，给他人阐述清楚能够进场的位置并能共分成果却成了这件事能否做下去的关键。说句不太上台面的话，有没有人像我刚来的时候好奇过这样一个问题，为啥这个环境里再难的事，只要找一位“老阿里”出面，就能解决？按照我粗浅的认识不外乎两个原因：老师傅们能找到更多的资源，多到可能原来都不是干这一摊事情的人都能拉进来一起共担风雨；老师傅们也深切知道别人到底想听到什么、关注什么、担心什么、分享什么，能把这事的前因后果、核心价值、风险回报讲得明明白白，说服他人一起共同富裕。然后长此以往，老师傅们渐渐建立起了个人的品牌效应，大家慢慢就发现跟老师傅们合作有章法、效率高、有结果、不白干、为人靠谱、值得信赖，如果下次还遇到老师傅攒局就值得一起搞，那可不就能达到振臂一呼，勇往无前的效果？从这一点来看一句说“资源的本质就是人情”，也没什么太偏颇的。
除了谈资源外，与业务同学，需要理解需求的远景，再来谈定当前的近景，理想和规划总是宏大，但是怎么落到这一次的交付上；与产品同学，需要明确最终的产品设计方案与业务初衷是否有出入，迭代的分割与逐步推进节奏是否合理，找到一个既具备可行性又足以满足阶段性验证的体量范围，避免一上来大动干戈；与团队内的技术伙伴，对于一大包的需求要素和工时，怎么设定领域边界，让大家都能够更专注于自己的内容去一起把事情做出来；与兄弟团队的合作，怎么商榷交互的边界，团队与团队在某个具体问题上的划分点在哪里，才能既不冲突又无盲区。
相较于事情本身外，谈事情看似杂乱无章，但是开始尝试起来一但时间久了，也会形成自己的谈事情风格和方法论，这种东西大部分只可意会不可言传，重要的是要张嘴的意识，具体到场景和每个人的性格上，话术思路也不尽相同，或许有些事情别人谈不妥，但是你就能有谈妥的方案，最终也会沉淀为自身区别于他人的亮点，能说会道用的恰到好处了就不是贬义。
闭嘴
张嘴好理解，但是闭嘴是什么呢？
该聆听的时候要闭嘴。一旦开始尝试谈事情，开始主导一些事情，这个过程在一段时间内容易上瘾，慢慢就会变得无论什么时候都想谈，有点打开了新世界大门的新奇感。但是，这个时候就需要警惕了，如果开了一场会议，完事以后脑海里只有自己的声音，就需要反思是不是自己开始听不进去事情了，是否忽略了合作人的观点，尽管基层的开发工作没那么官僚，但是还是要避免一言堂的出现。要明白，啥都管就是啥都不管，人的精力有限，不可能每一件事都关注到，总要学着放手与放弃的，学着去交出主动权，多去听别人有什么想法，想怎么搞，只要还在一张桌子上，说话叫谈，听话也叫谈，张嘴用嘴，闭嘴用耳。
有情绪的时候要闭嘴。谈事情的时候切记不要带着怨气和敌意，很多人在谈判的桌子上总强调气场，这点没错，但是气场不是声音大、不是嗓子粗、不是拍桌子。不知道诸位有没有遇到的这样的场子，开会谈边界谈需求的时候，聊着聊着就吵起来了，吵的飞起来，到最后彼此针对的不是这件事，就是针对这个人，“针对”已经不是找关键点了，而是真成了拿针对戳着，会议冗长没准都开过吃饭的时间点，然后会议结束后也没个结论，不仅浪费时间也浪费心情，有这个时间多去食堂干碗饭不比什么都强。己所不欲勿施于人，大家都是来工作的，开会就是开会，谈事情就是事情，没必要争个谁把谁喷赢了，事情能办成就行，再说一句，低头不见抬头见的，总这么呛着跟别人谈事情，谁愿意跟你谈呢。善待周围的同事吧，他们是伙伴，是战友，很多事情都有的谈，无论是工作还是生活上的事都可以聊一聊，互相学习下经验，都是生来第一次做人，谁又敢说比别人活的通透，即便退隐江湖了，也不一定相忘于江湖。
回到“谈事情”这三个字上，这里更想说的是一种意识，一种跳出事情、视人为人的意识，作为开发同学，学着认可说话是编码以外的软实力，慢慢的把自己的思路和做事方式转变起来，把仅以用什么样的代码来解决问题的观点转变下，也开始想想是否可用人来解决问题，不仅仅是团队需要管理，人际关系也是。
在最后的“结”
想法浅薄，行文拙劣，粗陋之谈，个人观点。
若有帮助，荣幸万分，如觉无意，笑谈也罢。
当然还是希望能与感兴趣的同学多多交流~“永无止境，诸君共勉。”
作者｜向知
原文链接
本文为阿里云原创内容，未经允许不得转载。
