CTO要越过的几道坎儿

本篇文章源自《CTO说》书中本来产品技术本部副总经理钱荣明分享的《技术架构的迭代与锤炼》的解读与感悟。最近工作中遇到的事情与这篇文章中的分享几乎同出一辙，更加有了“感同身受”的共鸣。

书中给这篇文章所写的标题与内容并不十分贴切，反倒是本篇文章通俗的标题更恰当的提炼了本篇文章的内容。

对于技术人员能够上升到的最高高度莫过于CTO，当然像李彦宏那样的程序员就另当别论。技术的锤炼、知识的提升、管理技能的磨炼都是CTO躲不过去的必备素养。但大家往往忽略一项比较重要的使命——决策。跨过技术思维禁锢，站在公司发展的全局层面进行决策（建议），成为公司业务与技术实现的枢纽型角色，也是CTO的重大使命。

重视双向沟通才能共赢

首先，我们都认可的一件事情是：一个产品的成败不完全取决于技术。想必经常听说一个很烂的产品通过运营的手段在市场上广为人知，同样一个很牛的产品却无人问津。CTO往往技术出身，手里有技术这把用惯了的“锤子”，当一个需求过来，第一反应就是用“锤子”去锻造它。其实，当从技术转型到CTO的职位之后，第一个需要面对的决策就是暂时扔掉锤子，判断产品方向是否对公司的发展有利，是否可以用非技术手段解决，然后才去分析怎样用专业的技术手段进行实现。

技术管理者往往会遭遇领导作出某项决策，却没有给技术人员留出足够的准备时间，这是典型的缺乏沟通意识。

我们会经常遇到CEO一个电话就要求某项目一个月上线。或经常听到这样的话“这个功能有很难吗？应该几天就可以完成吧？为什么这个这么慢，两天时间还搞不定吗？”。作者（钱荣明，以下均称作者）认为，不能要求每个老板都懂技术，只能妥协，通过努力达到目标。其实，如果这样做了，反而缺少了CTO的决策作用。

作为承上启下的CTO，首先要搞明白不懂技术的老板的真实意图是什么，按照老板说的那样去技术实现是否能够达到老板想要的目的。如果此决策对公司发展有重大利好，而且必须在规定时间完成，后面的事情才是想尽办法用技术去达成目标。

在这个情景中与CEO的沟通，不仅体现在具体需求的沟通，是否能够达到预期，还体现在CEO与CTO需求沟通的提前量，防止技术实施的被动，造成项目的急迫感。

是否技术至上

企业技术体系的构建，绝对不要坚持“技术至上”原则。因为技术的构建离不开业务的发展，构建的目的也是为了更好地实现业务的升值。

作者举了一个为了达到CEO的要求赶工期将一个项目拷贝成两个项目导致的严重后果：独立的服务器、独立的系统、独立的数据监控，无论从财务层面、报告层面还是公司结构层面都暴露了极大的问题，最终还是需要花费大量的时间将两个系统融合在一起。

个人看来，这个例子并不能很好的说明技术至上的原则性问题，但提出了技术至上这个问题的存在。技术至上的根源是任何问题都想通过技术来解决：当你手里有一把锤子，任何事物看起来都很像钉子。技术离不开业务，业务不一定非要用技术来解决。

要重视数据库

数据库怎么备份都不嫌多。然而，在创业初期往往因为人员配备、资金或资源、项目进度等原因被忽略掉。一旦出现重大问题，都需要用加倍的损失来弥补。

控制技术的求知欲

技术人员天然对新技术有强大的兴趣，在每一个项目中都跃跃欲试的使用一些新的技术。对新技术的选型十分重要，不仅涉及到学习成本、运维成本，还涉及到新技术是否形成相应的生态，比如文档支持、论坛支持、技术更新周期、是否长期有人维护等，不然很可能到最后遇到问题还需要自己研究新技术的源码，自己去修改相应的bug，那就得不偿失了。

在编程语言方面，有两个方向的选择，作者建议尽量统一编程语言，这样在项目初期阶段对资源、运营成本、沟通成本和项目把控度来说都是有利的。同时，针对大的企业，每种语言都有它的优势和特定的业务场景解决方案，不同语言的思想也有不同的优劣之分，保持多种语言也就保持了人员与思路的多样性。有很多选择都是如此，适合的才是最好的。

千万不要选择外包服务

本来生活最初的系统是外包供应商做的，可他们做了一件令我觉得不可思议的事情：为了把核心代码加入系统中，他们把所有的逻辑都写在了同一层里面，不管逻辑是否通顺，甚至也不管该不该写在其中，全部一股脑的写进去，然后把这个包加密了。当我源代码购买来解密之后，那一瞬间我就想把系统推翻重做！

想必经历过外包项目的人都有这样的感受，再好的外包公司都要慎重选择，一旦选择外包就要准备好承担它带来的风险。前些天也写了自己的经历《背锅与填坑的一个月》。在此延伸一下，对于刚入门编程行业的朋友来说，慎重选择就职于外包公司；在招聘的时候对于长期在外包公司工作的应聘者也需要仔细的面试一番，习惯的力量是非常大的。

谈谈招人这件事

有人问我，创业初期，如何解决招人的难题？
我的答案是，去北京各大学的论坛泡，看论坛中的学生，有没有符合要求的人。还可以让这些人推荐他们身边的好友，不管是否毕业的、应届的、没有毕业的，只要是人才，通通招进来。

看到作者的做法首先是眼前一亮，不失是一个好办法。但再一想创业初期哪有那么多时间去各种泡论坛寻找人才。而且在初期阶段，项目进度异常紧张，也没有太多的时间和精力去培养新人。

个人反而觉得，在此阶段需要招聘全能型人才，一个顶两三个普通员工的人才。但这里又形成一个悖论，创业公司无法用工资或品牌效应来吸引人才，前途和“钱途”都无法保证。聪明的老板会用人文关怀和对未来的展望（画大饼）来留住一部分人才，但往往很难奏效，有能力的人很少给老板画饼的机会。

这里感慨一下，如果在创业初期，有那么一帮人愿意跟着你干，那已经是上天的馈赠。经历多次的招聘之后你会发现，在创业初期招聘一个合适的人是多么多么的难。往往是没能力的没办法用，有能力的不屑与你为伍。

如果老板是职业经理出身，能够将员工管理的心服口服还好。反之，CTO的桥梁作用也是创业公司成败的决定性因素。

必须百分之百确保系统可控

这里讲的是组建运维部门和测试部门的重要性。创业初期，运维的工作往往由技术人员身兼，这样的结果往往是一团糟糕。很多大型互联网公司有专门的运维部门还经常出现安全和误操作的事故，试想一下，如果这些事情由身兼百职或不擅长运维工作的技术人员来担任，后果会是什么样子。每个岗位存在即合理，初期无法保障，后期必须跟上。

系统与人员的冗余

作为老板往往希望每一分钱都花在刀刃上，系统资源恰好百分之百利用，人员每天工期排满恰好加班加点能够完成。这难道不是最完美的安排吗？各项资源百分之百利用，不浪费一丁点。创业初期，这往往是不懂技术不懂管理的老板的通病，后果是要用更多的代价来弥补这百分之百的完美。

如果一个产品的服务百分之百的利用着资源，那么当一个促销活动或一个小访问峰值发生时，系统的资源利用呈现百分之二百的状况，系统是否也完美的瘫痪了？没有系统资源的冗余就没有应对突发状况的能力。与系统的瘫痪相比，资源的冗余是最佳的方案。

再说说人员冗余的事，在创业初期往往是身兼百职，如果每个员工都把时间计划排的满满的，这样效果是否最佳？首先不说员工情绪上的反抗（被工期压的喘不过气），与身体上的疲惫，单说如果工期是满的，没有任何机动的应急力量，这时来一个紧急的时间稍长的任务，是不是所有的计划都被打乱，如果原定计划中也有紧急的任务是不是会造成重大损失？另外，如果其中一个员工离职或生病，没有替补人员，紧急任务将如何处理，这将是多么恐怖的一件事？

从那以后，我就知道，系统必须要用冗余，架构的冗余、设备的冗余、技术的冗余，包括人力上都要稍微的冗余，而不是所有的技术人员都投入在业务上。我的方法是分配出20%的人力，在技术架构上实现超前部署。

风控，拒绝“羊毛党”

“薅羊毛”的事件经历的太多，本人也管理过金融风控相关的项目，深知这一块的重要性，也是创业初期最容易被忽略掉的地方（因为它不创造价值，价值的守护者身份又不容易被看到）。薅羊毛只是最简单的风险行为，有的甚至直接导致资金损失、系统安全或生态崩溃等重大问题。

针对羊毛党，简单的可以借鉴腾讯和阿里的系统，它分为两个等级，其中第一个等级就是我们常用的验证码，做一些简单的人工判断、人工学习，例如通过页面拖动的时间、停顿、失误率来判断出这个注册的对象是人还是机器。在这一块，前些时日就遇到被机器刷注册的情况。

另外，就是通过数据分析建立完整的用户安全等级：可信、可疑和严重。针对不同人的行为做出不同的措施，在每个关键节点设置关卡，提高风险抵抗能力。

个人小结

阅读过很多类似的CTO管理的文章，唯独这篇让我产生很多共鸣，只因这篇文章中提到的事项几乎在我最近的工作经历中一一验证。因此花费几个小时的时间写了这篇文章的读后感。虽然经历十分相似，但对作者提出的一些解决方案和认知并不没有完全赞同，也发表了个人的观点和看法。千变万化，适者生存，才是这个世界多彩的呈现。踏上CTO的船，后面要学习和提升的东西是无限多的，但从更长的人生层面来说，每天的学习和提升也是必不可少的。

CTO要越过的几道坎儿插图