閱讀本文約花費: 10 (分鐘)

英文：http://www.startuplessonslearned.com/2008/09/what-does-startup-cto-actually-do.html

你的首席技术官（CTO）整天都在做什么？很多时候，在一般人眼里的 CTO 形象等同于“那个拿着高薪坐在角落里，对‘技术’进行深层次思考的家伙” 或者 “那个在最后一刻突然一时兴起，跳起来重新安排我的项目的家伙”。我已经努力不让人产生这种印象，但这不容易做到。我们缺乏一个对 CTO 的一致而明确的角色定位。

当我问起我那些曾在大公司任 CTO 的导师们如何看待这一角色，他们通常会谈起 CTO 应该成为公司技术平台的对外形象，对开发者、客户（尤其是技术型产品）、员工来说，CTO 是布道者。毫无疑问，技术布道是一项非常重要的工作，我总是被要求做这件事。然而，我不认为大多数初创公司真正需要某人来做全职的布道者。

所以 CTO 意味着什么，除了只是 “不负责直接管理任何人的技术合伙人？”。

我一直认为我不会管理任何人。我打心底认为成为一个经理一点也不好玩，谁会真的想对别人的行为负责？我的意思是，公司大了，什么人都有（不好管理）！所以我被 CTO 的职位吸引，而不愿意成为分管工程师的 VP。我认为公司会招一个专业的家伙来专门负责管理和安排日常事务，而我只要将精力集中于确保我们的技术确实很牛逼。然而，一路走过来，一些奇怪的事情发生了。我发现软件的研发过程和软件的架构变得越来越难以分离。如果你尝试设计一个架构来最大化软件的灵活度，在没法保证所有的开发者都采用 TDD 时，事情是推动不下去的。如果在推动决策时，一部分人采用“预先筹划” 而另一部分人使用 “5 个为什么”，事情也会一团糟。如果每次产品发布都需要手工部署怎么办？一些做法可以改进软件的性能，但要牺牲可读性、部署能力或可扩展性，你会去做吗？这对我来说像是技术问题，但是当你深入分析问题的本质时，你会发现它们实际上是人的问题。而人的问题真的没有办法以一个旁观者的立场来解决。

所以我学习了如何管理他人。还好，我并没有太不擅长管理，而且我发现原来它可以带来很大的回报。但尽管我在 CTO/VP 的混合角色上经历了很长时间，我仍然有这一挥之不去的困惑，即究竟 CTO 应该做些什么？

以下是我的观点。我认为 CTO 的主要工作是确保公司的技术策略服务于它的商业策略。如果这听起来太简单或者太泛泛了，思考一秒钟，是否有你所知道的公司做的正好相反，是否你有听说过有所谓的“砖家”把技术的繁文缛节当做经营理念来坑老板和投资人？这正是我们要极力避免的。

我会将它分解为五个特定的技能：

• 平台选择与技术方案设计 —— 如果你的商业策略是创建一个低消耗、快速迭代高效率的创新产品，你最好使用基础工具让它变得简单而不是变得复杂。大规模专用数据库？我不认为在这里适用。公司的技术支持团队是否能够深入他们开发的工具，在有问题时解决和修复？如果不能，谁能主张并坚持切换到免费和开源的软件？当产品想法变得越来越天马行空，谁能检查并确保整个计划可行？新上线项目对整个平台造成影响应当追究谁的责任？
• 把控全局（包括一些关键细节）—— CTO 是整个项目中能够了解整套技术方案能做什么不能做什么的人。这意味着了解什么可行，什么不可行，当前架构能支持什么，做不到什么，以及构建一个新功能在先有架构下要多长时间。这可不是简单画一个架构图就完事的。能够同时看清整体和细节是所有我有幸与之共事的真正优秀的技术人员的共同特质。
• 提供选择 —— 另一个好 CTO 的标志是他们从不说 “这是不可能的” 或 “我们永远别这样做”。相反，他们找到可选方案并且能够就这些方案与其他人沟通。如果 CEO 想要完全改变一个产品来服务于新客户群体，需要找一个能扛起新业务需求的人，并制定出每种可能的方法所需耗费的成本。一些技术人员有一种倾向，只是“为你决定”并给你一个“最好的”选择，但这是危险的。如果一方宣称他知道所有的答案，你们之间就不是一个可信的对话。
• 80/20原则 —— 这是我最喜欢的一部分工作。有时候，你在一个会议中，有人会提出一个新功能。在他们脑海里，他们灵光一现，加这个功能，加那个功能，最好再加一堆。在我看来，他们在增加成本（实现这个部分要一个月，那个部门要两个月，……）。有时候，我会给他们泼一桶冷水。而有时候，一旦我理解了他们要添加的功能的目的是什么，我可以找到一个获得 80% 好处而只要消耗 20% 成本的折衷方案。我一直很惊讶我经常会听到“什么？原来这个功能实现起来很难？！我还以为只要加一两行代码就搞定了呢！”
• 培养技术 leader —— 我将这个职责定义为培养工程师成为“技术经理”并授权他们指导更多项目的技术方向。一个人的能力是有限的。为了做到这个，我也必须要清楚公司哪方面的技术方向是真正重要的，而哪些只是我们为了达到目的的过度方案。为了让多人以同样的标准工作，我们必须在我们的定义中增加一些保障。比如我们必须要采用 PHP，还是我们能加入一些用别的语言写的工具？是否需要保证所有的网页代码都用面向过程风格？如果有人想要把他们的模块用面向对象风格来写行不行？通过授权和培训，我们培养了一些 leader，他们能够分担 CTO 的工作。而通过一起工作，我们创建了一个团队，通过合作，让一加一大于二。

我想加最后一个想法，尽管我知道它是有争议的，介于 CTO 和技术 VP 的职责之间。我不知道我被同时履行两个角色的职责影响了多久，但我认为它是重要的，足以让我决定冒着被喷的风险将它列出来。

• 拥有开发方法论 —— 在传统的产品开发配置中，技术 VP 或者类似的管理角色全权负责确保工程师写的代码足够规范，接口有质量保证，并有节奏地发版。但是我想在一个精益的初创团队，开发方法论比只是单纯管理要重要多了。例如，一个团队是否使用 TDD 或者实时可扩展，对架构会有很大的影响。最起码，我认为 CTO 和技术主管对缺陷和问题要能够找到和分析根本原因。否则他们如何能够找到什么是他们的盲点并确保团队和架构能得到及时调整？这项工作要求具备全局视野。

你的 CTO 可能是一个好的架构师、布道师、接口设计师或调试 bug 的天才。这些都是非常好的能力，我很好奇你是否在你们的 CTO 身上见过这些能力。我承认我的经验是有限的，所以我在收集案例。你是否与一个很棒的 CTO 共事？是什么使得他们让你觉得很棒？一个新任命的CTO，你能从他身上学到什么？