以人为本做技术

最近写博客有些怠惰，不如偶尔写一写杂谈。

小时候刚开始接触电子产品的时候，折服于这种智慧的结晶，“人类工业的桂冠”。彼时，大家刚刚用上诺基亚的智能机，没有安卓，仅仅可以拍出勉强能辨出我是雌雄的照片。当初看到人们根本不懂如何真正的用好电子产品，能写文字的非要浪费存储用图片，拍照用的太差而太模糊时，总觉得“这么高精尖的技术给一群五大三粗的人用，真是暴殄天物”。

随着年龄增长，愈发发现这种思路的幼稚，但这种思路的变种却经常在工作中见到。如果总结到知乎常见问题“什么是学生思维”的话，这种思维绝对可以说是技术工作者的通病了，包括我自己。

简单来说，做技术，要以人为本。因为，

决定技术的是人；

使用技术的是人；

为技术付钱的，也是人。

只要你的“技术”需要人与你协作才能成功——需要人实现，需要人宣传，需要人付钱——就一定要记住技术要以人为本。

决定技术的是人，意味着技术路线的选择上要与人达成共识，技术决策者不和技术实现者达成共识，下属会觉得你这架构师毫无眼光，应付了事；与技术决策者提出建议，无论想法再怎么精妙，如果leader不能get到，那也很难帮助你进行投入。

使用技术的是人，意味着你的设计无论如何精妙，总是要其他人来使用的：或许是一段与人协作的代码，那你就要定义好接口，并且让人理解你为何如此设定，而不是洋洋洒洒讲你的实现方式，然后试图让他基于此理解你的接口；或许是一个用户界面，你不要教育用户先学习你的设计，才能用好你的软件。

为技术付钱的，也是人，意味着真正掏钱给你开工资让你写代码的人，是最后产品的使用者。他不喜欢你的设计，你就是失败的。而不是你的设计有如何精妙，用到了如何高级和高深的算法。

这里有一个经典案例，当初某司一个浏览器退出账号会使得整个手机的账号退出，并且退出时问是否清空记录，选择同意会把整个手机账号的包括记事本等全部清空，不少人损失惨重。结果程序员们在论坛里吵得不可开交，很多开发者认为，浏览器是手机默认的，账号就是手机账号非常合理，退出时候也警告了会删除数据，那么整个行为就是合理的。——这种思路的人绝对不适合做产品，只能完成一个个独立的需求。如果独立来看虽然每一步都合理，那么结果就合理了嘛？这个逻辑，且不论正确与否。事实上是，你根本没有机会跟你的用户去讲。逻辑的“对不对”和技术设计上的“对不对”并不等价。如果逻辑上是对的，设计上就是正确的，那么这个世界上不应该需要rust，不应该有漏洞扫描工具，不应该有回收站的恢复功能。所以，一个好的设计要铭记的是：人的精力是有限的，人的知识是有限的，人的耐心是有限的，人是会犯错的。回到案例中，一个人觉得“浏览器中的账号不应该影响外面”，是一个符合直觉的感觉么？很明显是。“浏览器的账号和手机账号是同步的”，是一个你的设计选择，用户不会去如此考虑，“我弹出过警告了”，这也只是个无力的免责声明而已，并改变不了你的设计与用户的直觉不符的问题。

当然，这个反向的理解，也会引出很有趣的例子。例如之前听到的一个，一个软件客户要求运行速度提升，本来是很难达成的目标，但是实际上程序员只是把显示时间乘以一个系数就让客户满意了。另外，国内某安全大大也提过，安全公司内组建了“安全感”部门，主要负责提高安全产品的用户感受，而非真正研究安全技术本身，这个部门“很不技术”，但是客户满意。这也反向说明了，技术其实在现实中是向“人”妥协的。

讲到这里，有些人会认为这是跟客户打交道，而非程序员自身的设计问题。这就些许狭隘了，因为广义上，跟你的代码对接的人，前端之于后端，应用之于框架，都是“客户”。非常常见的怪象就是一些非常有经验的技术大佬却做不出来一个大型的技术项目，他们精通背后的技术细节，但是永远无法应用这些能力去支撑一个需要多人协作的工程，问题就在这里。只要不是每行代码都是大佬自己做，不是每个使用这些代码的地方都是大佬亲自写，你就无法避免要把思路讲给他人理解，无法避免其他人会写错，其他人需要解决错误的方案。很多大佬这时候就开始给人将内部细节，然后陷入到无穷的细节中。这就是忽略了“人”这个客观存在，而头脑中只有技术的后果。如果把你的技术设计用几分钟讲清楚，几张Slide讲清楚，而不是需要你给人开一个学期的课才能上手，这才能够把“人”利用起来，否则给你再多的人力也于事无补。

稍微发散一点，有非常多的人把“技术”和“管理”二元对立开来，例如认为在职业规划中，做技术到一定年限后一定要转行管理。在我看来这是一个非常扯淡的观点。因为，技术和管理从来不是二元对立的，一个“技术”做的非常顶尖的人不一定会管理，而管理者不精通技术也是致命伤。有这种想法的原因也非常简单，对于多数“开发者”和“管理者”来说，他们的关系和“临时工”和“包工头”并没有太大区别，可替代性非常强。这写开发者只负责把一个个分解的简单的逻辑写成代码（而不是思考所实现的逻辑背后的意义），而管理者只负责从更高层把需求转达下来然后列个时间表（而不是分析隐藏在表面需求的背后的真实诉求，并且设计整体架构）。这也就造成了浏览器案例里面最终呈现的问题。技术方向的管理，应该是结合对技术的理解和对“人”的理解，去找到其中的平衡，即干涉“技术”也干涉“人”。

总而言之，面向“人”做技术，而不要把技术和“人”割裂开来。写代码，拉项目，做框架，处处看不不到“人”，但是处处都是“人”。