/**

* 版权所有(C) 猪八戒网保留所有权利

* Author: 玉华王

* Timeline: 2021/4/24

* Description: 很荣幸收到八戒技术公众号的邀请，今年是我在猪八戒『混日子』的第

* 10个年头了，其实有不少心得体会想说，来不及整理，想到什么写什么

**/

01

在自己的作品上签名

在文章开头先装逼写一段注释，这其实是我想说的第一点。

过去时代的手艺人，为能在他们的作品上签名而自豪。你也应该如此。『这是我编写的，我对自己的工作负责』。

当同事在一段代码上看到你的名字时，他们对这段代码的预期应该是可靠的，测试过的和有文档的。有签名，也是对自己的鞭策，其他人也更容易找到你咨询问题。

就像喜欢车的人，看到奔驰AMG发动机上的铭牌，多半是会『高潮』的吧。这块由AMG工程师亲手签名的铭牌，象征品质与责任，确保每一台发动机都能达到完美水平。

02

程序员都是吃青春饭的

前两天部门里来了个实习生，我让他每周在部门群里公开提出他对工作的疑问。

他问，为什么都说程序员的职业寿命短？

业界对程序员的看法，总是带有调侃和偏见的成分的。

他们觉得这群穿格子衫的人荷尔蒙分泌失调，找不到女朋友，以为弄几个『程序员鼓励师』来，就能忽悠这群人疯狂工作；

他们觉得花2w找一个老油条程序员，又贵又难管，不如花5000找4个应届程序员，又愿意996，又听话肯干，『反正活儿都一样』。

我也曾经历这样的困扰和焦虑，现在看来，所谓的『技术转产品、技术转管理才有出路』，只是结果而已。要达成这个结果，要么你不断练习技术过硬无法取代；要么你能跳出具体的实现，建立更体系化的全局认知。

所以我现在的观点是，能说出『程序员都是吃青春饭』这样话的人，他自己所做的一定也只能是低附加价值的重复体力劳作。其实任何行业都一样，真正有经验的老手所能带来的附加价值，往往是新手的10倍以上。

03

对你的boss说不

先看一段我们日常工作中经常发生的对话场景：

boss：『这个功能明天上线，今天务必准备好』

你：『明天就要？那我尽量吧』

boss：『好的』（愉快的回家）

这段对话看似和谐，实则出现了严重的问题。

当你说『我尽量』的时候，可能想说的是『我不一定明天可以交付，但我会努力试试』；

而你的boss会怎么理解呢？单纯一点会觉得明天可以上线，然后愉快的回家。复杂一点呢？会觉得你未尽全力，有所保留。然后养成『倒排时间』的习惯。

再看一段对话：

boss：『这个功能明天上线，今天务必准备好』

你：『明天？这不可能，这至少需要3天』

boss：『不行，已经做了运营铺垫，也发了通告，明天我们必须上线，想想办法吧』

你：『这样吧，我提供一个最小化的登陆页面，但至少可以让客户登陆』

boss：『你确定？客户明天可以正常登陆吗？』

你：『是的，虽然界面比较简陋』

boss：『太好了』

你不妨大胆说『不』。与其保持的虚伪的和谐，PK之后达成一致，才是解决问题的唯一途径。

04

理解向上管理

还是上边那个对话的例子，我们可以抛出一些问题。要不要给boss解释『为什么要3天』呢？告诉他不做review和测试？减少xx步骤？少建立两个数据表？

多数情况下，给你的boss提供更多细节，只会招致更多的微观管理。事实是『需要3天』，而『为什么』只是细节。

那么如何合理的向你的boss传递信息？这里就有个方式非常管用，叫金字塔原则。是一个脖子里戴大金链子的金发美国老太太发明的。

用一句话说，金字塔原则就是，任何事情都可以归纳出一个中心论点，而此中心论点可由三至七个论据支持，这些一级论据本身也可以是个论点，被二级的三至七个论据支持，如此延伸，状如金字塔。

对于金字塔每一层的支持论据，有个极高的要求：MECE（Mutually exclusive and collectively exhaustive），即彼此相互独立不重叠，但是合在一起完全穷尽不遗漏。不遗漏才能不误事，不重叠才能不做无用功。

电梯里遇到boss，给你三十秒，你就只说中心论点和一级的论据；若你的boss像刘备一样臀大肉沉，三顾茅庐搬空你家冰箱，你就汇报到第十八级论据，为什么三分天下，得蜀而能有其一。掌握了这个，沟通起来最有效。

05

不懂沟通，工作等于白做

——很多时候，沟通就是工作本身的一部分，而且还是很重要的一部分。

任何事情都有需要沟通的部分，工作也不例外。不到位的沟通，可能你做了9分的工作，最后却只得了5分；但如果沟通有效，7分的工作能变成10分。

很多人，暗地里做事做的要死要活，但少了明面上的沟通和汇报，导致很多同事和领导都抱怨，『这人不靠谱』。

在职场上，你善于沟通汇报以及跟进吗？还是，boss不问，你就不说？

我遇到过多个同事，都有这样的问题，不会做跟进和沟通。当事情交给他以后，过了很久都不会有声音。

过了几周，我突然想起来，问他事情怎么样了，他说，『早就完成了』。

他可能还以为有分加，其实，倒扣2分，1分因为没汇报同步，1分因为事情还在我手上没移交出去。如果我在其他渠道得知他已经把事情完成了，而我这个直属上司还傻傻搞不清楚状况，再扣1分。

5.1、主动性

其实主动性，是个伪命题。

借用丁表哥的话来说，『公司不是学校，培养员工的自主性绝无可能』。

你是否愿意主动学习，是否愿意主动跟进、沟通汇报，一定会体现在你所交付的工作成果上（这个成果绝不仅仅是你交付的工程代码）。缺少这样素质的人，做不了任何一种需要承担责任的工作。

5.2、重复一遍对方的话

很多时候你会觉得你的boss自己没交代清楚，而反过来怪你做事不到位吧？你怎么办？

这里也有一个方法，叫做SMART原则，建议做为你之后的反馈工具。SMART中，S指的是Specific（具体的），M指的是Measurable（可衡量的），A指的是Achievable（可行的），R指的是Relevant（相关的），而T指的是Time（时限）。

直接看一个例子吧。

boss：『blah  blah blah blah.....』

你：『老板，要求我明白了，但为了不出偏差，还是重复一次让你确认一下，blah blah blah.... ，您是否确认』（S）

boss：『确认』

你：『这个事情是否结项，是否以一月内产品上线，并通过客户验收为准？』（M）

boss：『是的，一月内上线，通过客户验收』

你：『以目前的资源来看，要在一月内完成，我手上正在进行的XX项目需要暂停，您看是否可行？』（A、R）

boss：『XX项目也不能丢下，我会协调额外的研发资源给你』

你：『好的，那我下周一着手开始跟进新的项目，预计三周完成研发上线，最后一周通过客户验收，期间我每周会给您一个进度汇报』（T）

boss：『好的』

老板心里很满意，他知道每周会收到进度汇报，这件事他就算彻底移交了。

5.3、In fact，not judge

随便judge别人往往是一切撕逼的开端。

你一周因为重庆操蛋的交通迟到三次，boss说，『你最近工作不怎么上心，早上床都不想起了吧』。

卧槽？劳资哪里不上心？劳资起床的时候鸡都没开始叫好吧？

然后你推诿狡辩，怒火中烧，辞职看世界。

换一种说法，in fact，『小王，你这周迟到了3次，是怎么了呢』。这样是不是你更容易接受呢，因为boss说的本来就是无懈可击的事实。

多来几组对比：

『我不喜欢ta的设计』or 『这个设计师不行』

『那组人有两次延期交付』 or 『那组人不靠谱』

『那个妹子对我没吸引力』  or『那个妹子真丑』

相信你很容易辨别哪个是in fact，哪个是judge吧。辨别容易，做到却很难。我自己也在修炼之中。

『不参杂评论的观察，是人类智慧的最高形式』—— Jiddu Krishnamurti

06

所谓软件架构

——系统架构的目标是解决所有利益相关者的关注点（不仅仅是软件架构）。

我面试过不少简历光鲜的『架构师』，他们都落地了各种『最新XX技术、最新XX全家桶』。我会问他们『你设计或选用这个系统的时候，你的用户都是谁，你跟他们沟通的时候，他们分别关注什么？你的架构怎么解决他们的什么问题？不同的用户之间有冲突吗』；

让人失望的是，能真正在系统设计之前找到所有的利益相关者，并与他们充分沟通的『架构师』，少之又少。

比如我们在进行系统设计时，产品经理、运营人员、客户、开发TL、工程师、项目管理、测试、销售等等，都可能是利益相关者。他们都有不同的关注点，运营在乎ROI，开发TL在乎性能和稳定性，销售说流程太繁琐，法务和审计只要安全合规，工程师说我不想写文档。

很多时候，不同的利益相关者之间的关注点，是有直接冲突的。能够无遗漏的找到所有利益相关者的关注点，系统设计能力才叫入了门；更重要的是能协调和解决好他们之间的冲突。这些关注点和冲突解决的程度，体现了设计者的水平和价值。

另外，你需要构建一个从收集到测量，到调整的闭环，用于架构演进。

推荐一本书，叫《软件架构师的12项修炼》。这本书更关注叫做『软技能』的东西。

07

练习、思考

——Care About Your Craft & Think! About Your Work.

早些年，我看到一篇这样『没有干货』的文章（对，就是你现在看到的这一篇，感谢你看到这里），是不屑一顾的。不就是一些鸡汤么，看一眼就懂了。

其实，（长期的）真理往往都是非常简单通俗易懂的；而（短期内的）真相，却是一件非常复杂的事情。很多人以为懂得了真理，却选择性忽视眼前的真相。

很多之前我以为我懂了的道理，在真正动手练习之后再去总结反思，往往会得到一些新的理解。

上边说的都比较浅，没有非常细致深刻的去讲，但每一条却都是肺腑之言，与诸君共勉。想说的其实还有很多，未完待续......

--------  以上所有内容可能来自我自己踩过的坑，也可能来自各种书籍和其他人写的文章中深得我心的部分，如有雷同，纯属认同作者。-------

骆俊武：五年了，我的技术管理成长之路

2021-06-21

程超：突破瓶颈！如何不断的提高自己

2021-06-17

亚马逊首席科学家李沐：工作5年反思！

2021-06-03

刘朋：从技术到管理 - 团队制胜六步工作法（开篇）

2021-02-08

Netstars CTO 陈斌：技术管理的两种思路

2021-01-26

儒枭：我看技术人的成长路径

2020-12-16

阿里高级技术专家宋意：平凡人在阿里十年的成长之旅

2020-12-14

漫画：下辈子你还当程序员么？

2020-12-01