前言

聊聊成为初创公司CTO的那些事儿

每一位程序员都有一个成为CTO的梦想。CTO稀缺、高薪，工作兼具深度和广度，还能保持极长的职业生命。

不管是跳槽到中小企业负责技术，还是在现有企业“被逼上位”做管理，或者要做创业公司的技术合伙人：你准备好了吗？

技术好就足以成为合格的CTO吗？是否还要考虑招聘、架构、沟通、管理、研发、个人发展？

在不同规模、不同业务、不同性质的公司和团队，到底应该如何因地制宜，去做好工作，实现全局目标？

在这里，我们聊聊如何成为CTO，尤其是一个互联网初创企业或小型企业中，CTO工作的方方面面。也就是“初创”CTO。

COPYRIGHT

韩锐 han@learning-tech.com

为什么要做CTO？

“The U.S. Bureau of Labor Statistics predicts that job openings for CTOs are expected to increase between 2012 and 2022. The continued growth of business conducted over information systems is the main cause of employment growth in this role. Rapid advancements in business solutions, and growth in mobile device usage and cloud computing usage, have also contributed to the expected increase in job openings.“

Technology is moving away from physical assets and moving toward virtual assets using cloud technology, big data and the internet of things. Technology is focusing more on integrating applications, processes and data. To become innovative and stay competitive, CTOs must keep abreast of big data, streaming analytics and cloud technology.

100Offer 知乎我们接触了 20+ 位年薪百万的技术人，得出了以下结论…

小型技术创业市场很大，依赖技术人员，人力成本占比高，需要管理经验/可以锻炼管理经验（拿出数据）

程序员的职业焦虑

程序员这个岗最需要年轻了
- 35岁肯定不招基层了
- 事实上所有工程师岗，守着多年，都是上升途径比较窄的岗。这可以说是不正常的，但我们如果挑战这个不正常，损失的更多。
- 在中国，大环境是不上升管理能力，就完蛋
  - 中国行业不要特别特别深入沉淀
  - 中国大龄程序员优势不一定大
    
    *　要年轻人的原因（尤其在中国）
- 2016年，亚马逊员工平均31岁，谷歌员工均龄30岁，脸书员工均龄28岁（查平均年龄）
那么，既不要年轻人，暴富又不可能，怎么办？

CTO有啥好处

职业生命长
不靠拼时间、拼重复工作上升
工作兼具深度和外延
流水的公司，铁打的CTO（市场总监这种职位不好跳断崖下跌的都很多，但CTO基本公司一倒就能找到下家）

从程序员到CTO

CTO是程序员职业规划和发展路径的必然
跳小机构或创小机构也是程序员的路径
- 大机构坑不够
- 大厂不适合老人
- 小机构百花齐放
- 抗衰老
  - 靠管理，经验
这条路径是需要积累的（可能出现的问题）
- 要全不要专，知识并不能完美迁移
- 管理岗位工作多

技术是无法垄断的：硅谷贵族可以垄断资本，但无法垄断技术，尤其是贵族对技术的天生鄙视。硅谷的成功人士，有很多草根，他们知道他们需要什么样的人才，这种草根成功人士，也更愿意提拔能力相当而出身更差的人。

这本书写给谁？

这个专栏写给谁？

欢迎这些读者关注本专栏的更新：

想成为初创CTO的人
想从工程师/组长升职为技术主管和CTO，需要在技术、管理、意识上有全面提高的人。
在公司内被从技术岗推上管理岗，需要快速从技术专家走向管理专家的人。
正在做技术负责人但技术和管理上力不从心的人，需要驱动自己和组织有变革的人。
想转型初创CTO的人
来自大型IT企业，想跳槽创业公司负责技术，但对创业公司的技术需求和打法不了解的人。
刚从其它管理岗位转岗为CTO，需要更清晰理解CTO这一岗位的管理特点、风格、方法的人。
在大公司中接手创新型独立项目团队，需要跳出原有体系，打造小快灵团队的人。
想了解初创CTO的人
一直找不到满意CTO，或与CTO共事有困难的初创企业负责人。
需要与CTO合作进行科研产品化、工程化的的科学家和科研人员。

谈什么？怎么谈？

谈什么？

在《初创CTO》中，我们将谈什么？

前文已经聊过，成为创业公司CTO，是技术人员快速上升来实现个人价值的好路子。然而CTO这个职位并没有没有固定的职业培养路径，很难通过循规蹈矩的上升自然胜任。甚至我们常常发现，一个高水平的程序员或研究人员，大多数情况下都天然不是合格的CTO。毕竟这项工作综合性强，既涉及到了大量的知识、经验、技巧，又要同时承担技术和管理的双重职能，必须跳出技术人员的固有思路，还得针对初创公司特点、行业性质、国情，做非常具体细致的调整。所以，我就试着把这些综合性问题一个个拿出来，与大家交流经验、感受和思考结果。

视角上，我既会谈宏观的企业战略和技术前瞻问题，也会谈微观的执行方式和案例故事。既会讲方向性的“大问题”，也会提供关键的技术操作准则和步骤。总之，凡是有助于创造一位合格CTO，创造一位初创机构CTO的主题，都会写出来分享。这也是本专栏的初衷。

内容组织上，职务定位(Positioning)，技术工作战略战术(Technical Strategy & Tactics)，团队建设管理(Team)，协作和影响力(Communication & Influence)，职业发展(Career)这五个方面，可以较好地定位初创CTO的主要工作。因此所有文章都会围绕这五个方面展开。

具体而言，大概准备谈谈这些事情：

定位CTO：CTO是什么？为什么要做？什么人适合做？CTO的能力模型是什么？如何成为CTO？
战略能力：战略制定，“野路子”和“制度化”，技术视野和前瞻，整体思维，关注业务和运营，业务数据化。
战术能力-项目：项目管理，项目掌控，采购外包，需求管理，敏捷/精益方法，项目管理工具。
战术能力-技术和架构：最小可用原型，技术架构，组件化和重用，优化和迭代，调用和自研，技术演进，服务器开发，网页和移动端开发，测试，部署、运维、监控。
团队-组建：技术团队架构，招聘，面试，发展节奏。
团队-领导：团队管理，薪酬考核，加班，员工类型，实习生培养。
协作和影响力-沟通：向上管理，团队协作，其它部门沟通。
协作和影响力-影响力：技术交流，资源和运用，跳出技术圈，对CTO的常见误解。
职业发展：职业生命和职业危机，持续自我学习，求职和跳槽，成为CXO。

随后陆续发布的文章不拘顺序，哪篇感觉积累到了可以拿出来的程度，就会写出来分享给大家。

怎么谈？

一个有关科技和创业的专栏应该以什么样的形式谈问题？

在这一点上，我非常认同PayPal创始人Peter Thiel在他的科技畅销书《从0到1》中的写作风格。作者围绕全文主题，用了14个章节去对应14个应该思考清楚的问题，每章内只讲两三个核心观点，每个观点文风都类似于：

“在这种情况下，这样做是对的，那样做是错的，原因是怎样怎样；当然也要考虑哪些例外情况。”
“在什么情况下，应该怎么做，原因是什么；等遇到什么新情况，应该怎么改变，原因是什么。”
“这样的思考是常见的误区，原因是什么；应该如何思考，而这种反常识的思考为什么能解决问题。”

我会尝试以这种风格谈问题。首先要讲干货，也就是专注于正确的道理和正确的方法，不留模棱两可的说法。因为初创和技术管理这些工作，乍看似乎有不少难言对错的模糊地带，其实在进一步细分情况、除掉错误信息后，最终得到的结论往往是非分明，非黑即白的。模糊和注水的方法论是不具体的方法论，是无法实行的方法论，是我要尽力避免的。

其次，我会“用脑”写这个专栏。我将讲的内容虽然来源不同，有自己的经历、有书本的知识、有错误的教训、也有同行的经验：不管来自何处，一定不会是拼凑的陈词滥调，而是经过实践和思考、结合初创公司情况、结合国内CTO发展的具体情况和环境，去粗取精思考，跳出人云亦云的固有框架后分享给大家的。

CTO是什么？

CTO是什么？初创企业CTO是什么？

CTO， Chief Technology Officer，是首席技术官。一般而言是一家公司技术方面的最高负责人。

CTO这一头衔最早出现在二战后期，当时的知名大型企业对科研越来越重视，开始成立独立的技术研究部门，来聘请科学家和技术专家来领导，负责科研到产品的转化。这些独立部门的负责人头衔就是CTO。随后数十年，随着技术在企业发展中的重要程度和规模的不断上升，越来越多的企业设立了CTO这个岗位，用以称呼企业内技术最高负责人。

过去二十年，随着互联网产业的爆发，各行业的发展变得更加依赖于信息技术————软件、App、数据、智能硬件等产品取代了传统概念上的产品，也因此使得研究人员、程序员和工程师代替了传统的工人，成为了产品的生产者，这也使得各行业对技术负责人的需求激增。

而在国内，大批的初创公司和新业务团队不断涌现，其中大多需要通过核心产品的研发来验证商业模式，就更需要聘任一位CTO。

这样的初创公司CTO，头衔虽高，工作要求虽根据公司情况各不相同，但共同点是工作很杂很宽泛。在创业初期，CTO就是一个技术大总管，应担负起和技术有关的全部工作，包括组织研发生产，拟定技术战略，管理技术团队等等。根据公司的具体情况，还可能向上下游拓展，同时照顾产品，IT设施，数据，设计，增长等方方面面工作。成为一个通过经验、资源、创造性手段、管理能力来解决初创公司技术和技术衍生问题的杂家。

共同点

负全责，本质是个C
懂技术，本质是个T
懂管理，本质是个O

不同点

大小公司区别很大
不同性质的公司区别很大
不同阶段的公司区别也很大

（稍后会讲）

初创呢？顺势简单提一点儿

“As a startup CTO I wore the following hats; Enterprise architect, SCRUM master, developer, lead quality assurer, social media manager, blogger, [and so forth].”

(当然创业公司干得更多更粗放)，初创公司，当公司里没有人比你懂技术时，任何与技术有关系的问题，你都是最终解决人。

“An executive-level position in a company or other entity whose occupation is focused on scientific and technological issues within an organization.” --Roger D. Smith

CTO干什么？

管理部分

Managing Roadmaps, Tasks & Deadlines: The strategy and design that a CTO develops with his team often becomes little more than a huge to-do list. A good CTO will have the product and project management skills to attack that list.

Getting Your Hands Dirty: A competent CTO rises to challenges and gets his or her hands dirty, proving that they can contribute as well as dish out orders. Speaking of which...

Delegation: As mentioned in the previous point, a CTO should be working on the frontlines — however, it still holds true that the only way all of that listed work will get done is if the people beneath the CTO pull their weight. To make sure that happens, a CTO needs to know when to hand something off to a colleague.

“Delegation [is definitely part of the job], and it’s a personal challenge for me. For example, I can spend a whole weekend just making sure some specific UX is seamless, although that’s not the most valuable thing I could spend my time on.”

技术部分

Getting Your Hands Dirty: A competent CTO rises to challenges and gets his or her hands dirty, proving that they can contribute as well as dish out orders. Speaking of which...

Technology Strategy: Contemporary companies work in a digitally volatile space, and it’s the CTO’s job to ensure that the company has the best technology for the job(s) at hand. That includes recommending the right CMS to handle content distribution across existing and emerging channels.

Business Strategy: A CTO needs to have a voice in the company strategy — especially since most (if not all) business strategies today rely heavily upon technology to exist, reach consumers and scale. More specifically, it’s upon the CTO to think up ways for his CEO and stakeholders to fulfil their goals. If they can do that well, the CTO ends up at the forefront of innovative projects.

Evangelism: Finally, the CTO is also a public face of technology for the company. They need to tend to the internal wellbeing of the company’s tech and be the driving force behind the brand’s technical prowess and insight. The CTO needs to represent that prowess in public appearances, in front of the press, and at conferences.

“I believe that CTO should be involved in business development in a technical way. It means CTO should always think not only about how to develop a certain product but also about how certain technologies can gain additional profits, and/or reduce costs.”

趋势

眼下和未来的趋势

公司越来越偏需要技术产品，越来越偏研发
纯技术公司越来越多
大规模产品铺开需要
O2O趋势不变

CTO的别名

CTO/CIO/VP/Chief Scientist/技术总监

技术部分、产品研发、技术战略、工程实施、信息数据、科学研究、IT基础设施

CTO / Chief Scientist / VP Engineering 区别
算法和工程化的关系
IT基础设施=软硬件支持和管理，数据、安全、设备维护、网络、技术采购、安装

CTO和技术合伙人

CTO要不要写代码

要不要写代码，你是控制项目，管理需求，防坑，派任务的。这些不需要时间么？然后才是写代码。

什么人适合做CTO？

钻一个技术问题，钻的进去，懂得彻底的。眼睛里容不下不会的东西。
三教九流，各层级各行业，谁都能和你都聊得来的。

（此处参考CTO书）

~~~

初创企业CTO的能力模型

核心工作

初创企业的CTO，所处的环境有什么特点，需要进行怎样的针对性工作？

初创企业的目标是建立商业模式，因此，初创企业的CTO的核心工作就是运用技术和管理手段，在不确定性中支撑企业来快速建立商业模式，并提升企业的综合研发实力。

快速建立商业模式，是为了在资源有限的情况下，通过产品的研发，赌公司能走出一条路来；而提升企业的综合研发实力，则决定了一旦企业走出了一条路时，整个技术和相关部分的实力和潜力，能否支撑公司在后面轮次愈发激烈的竞争中持续保持领先，直到最终走向行业顶尖地位。

环境和工作特性

下面分项简要谈谈初创企业CTO角色所面临的环境和工作特性。在本专栏随后的文章中，所有内容都会针对初创企业的特点来对症抓药。

主题	面临的环境特点	工作特点和应对
战略方向	实现目标的资源总量有限，资源变化大，时间紧张。	需要在人、事、钱三方面，保证技术决策与公司初创期的长短期目标一致，同时留有适应变化的弹性。
制度建设	保障研发和IT顺利开展的制度不够完备，员工无章可循	需要建立简洁可行的研发规则和IT制度，并逐步根据发展阶段细化制度。
技术规划	技术的规划在覆盖面和精细度上，都无法满足业务需求	需要根据总体目标不断拆解需求，进行技术选型，准确估计按期实现的可能性，在诸多不确定技术因素中，提前识别出关键风险并排除。
需求方	需求方多是非技术出身的CEO，或身兼数职的产品经理	需要安排大量时间理解、细化、核定需求。
需求调整	需求不细致，变更需求前，需求方不一定会和技术团队协商完善，对解决需求需要的时间没有概念	综合考虑细化需求、持续沟通、技术预研、最小可用原型、可行性分析、资源调配、文档撰写等手段，来在变化中固定需求。
需求优先级	需求变化频繁，容易因优先级规划模糊导致并行多任务	需要在全部需求中，确定最关键的20%任务，并投入80%资源。
文档维护	各类文档不明确，没有足够时间完善和回顾	需要平衡文档沟通和当面沟通的诸多利弊，结合团队协作特点和质量控制目的，找出最佳的书面沟通形式。
架构有效期	架构能够支撑到业务被验证即可	根据需求情形，保证半年到一年内不需重构即可，但需要保证各组件间的解耦，为架构的扩展留有可能性。
技术选型	技术选择的灵活性大，但员工驾驭技术能力差，也没有完备、长期可靠的工具链	选择成熟的第三方组件代替自研；选择公有云服务代替自建；选择易于招聘和分工的编程语言和框架。
可靠性	优先保证核心功能可靠性	以稳定支持业务的合理增长预期为可靠性目标的上限，在此之外无需进一步准备。
系统冗余	无充足的人力和精力保障系统的备份和恢复能力	需要优先考虑核心数据安全，同时考虑满足总体崩溃的恢复时间要求。
部门结构	人员总数有限，业务总体复杂度不足	简单的部门划分，或分为多个敏捷团队。
跨部门沟通	部门数量较少，跨部门沟通总体上更容易；一段发展期内经常偏重一个部门	需要在正确的阶段需要为研发部门争取最大化的资源，实现关键研发目标。
流程分工	研发工作上下游分界不明确，，研发人员容易在兼顾上下游工作过程中浪费大量时间和精力	需要保持不断分工、不断流程化的意识，逐步补齐团队。
人员招募	没有完整的招聘体系，公司人才吸引力不足	需要运用社会关系，并综合多种策略招人，辅以使用互联网招聘平台和猎头。
人员配备	人员岗位不完整，尤其缺乏研发之外的岗位，如架构、运维、测试、设计、交互	需要负责人亲自处理，按需补齐，或者考虑外包。
团队文化	没有长期积累的机构文化可依赖	一定程度靠个人的影响力带动塑造工程师团队文化，来保证小而专业。

总而言之，初创CTO的工作，就是需要在变化的环境正中找到确定性，通过对公司方向的感知、IT战略的制定、资源的创造性运用、制度人员团队的建设、技术的架构选型等，来快速验证商业模式，并提升企业的综合研发实力。

能力模型

参考：robbin回答

要对企业有巨大的放大器，加速器作用。

能让别人干得起来（组织生产，争取资源)
能让别人干得好（控制质量，且参加生产，解决关键技术攻关问题）小公司cto需要负责像部门经理一样抢不靠谱项目可能性小
能让上面知道你的情况，能知道上面要你干啥

在调配资源时要脑子活，在规划需求时要扎实细致，在服务业务时要跳脱。

技术不如情商重要为什么国内 IT 公司 leader 以上就不怎么写代码，而据说 Google 的 Jeff Dean 还写代码？到底哪种情况好呢？ - jason wang的回答 - 知乎

https://www.zhihu.com/question/23321862/answer/463542279

cto风格：team leader型，project manager型，（buy buy buy型一般初创公司不存在）

什么是项目？

理解项目，就能把握和理解研发的全程

项目

项目的生命周期

Coding.net 首页的定义

产品：策划，研发，运营
研发（项目）：立项，执行，完工
执行：需求，设计，开发，构建，测试，部署
这六项中，前三项考虑敏捷，后三项考虑持续集成和持续部署，部署前的更新工作考虑持续交付

GitLab ConvDev 的定义

Idea-Issue-Plan-Code-Commit-Test-Review-Staging-Production-Feedback

以上已经讲的很清楚了，现代，简单，随意另创的算是邪教了。

文档的重要性：磨刀不误砍柴工。

制造MVP

先解决有没有，再解决好不好。
避免无限追求完美，MVP期的信息、资源、反馈本身就不可能做到完美，目的只是验证。
外包和自建的权衡
采购：消除信息不对称，并应付老板（hfjy货买三家的例子——CTO就是做对方向） 参见专门章节
驻场和雇佣的权衡
实现网

采购和外包

买还是造，It is a question

工具性的内容可以通过外包服务实现，如旁支的检测、安全检查，但是系统层面的构建千万不要选择外包服务。

实现网

需求先行

时间付费和项目付费

对接才是问题

需求管理

早期/中期需求的区别
提炼核心需求，避免过大量工作
提前架构与过度架构：以网站建设为例
确认需求的重要性
控制头脑风暴别成愿望大会，或者如果已经成了愿望大会就别纠结可能性
如果连需求分主次都不懂，就换产品经理吧
任务在深度和广度上必须二选一，除非接任务的是高手或做过高度重合项目的熟练工
做事务必从需求出发，而不是会啥/做啥出发

项目规划

注重可行性
排期
避免深入细节
做项目一定要先核定需求，再说做事。这样做的意义是（需要细谈）
- 核定工作量
- 明确分工边界
- 向上确定交付内容和不交付内容
- 时间管理
- 资源和人管理
- 为进一步估计交付时间做基础
持续评估

真需要科研的量和人很少，绝大多数是工程。科研需要的头脑更多，工程需要的经验更多。软件工程大部分原理是通用的

延期

分析延期的原因

工作安排验收

项目人员安排分配

对于新组，要反复明确交付/负责的边界，在此基础上还要做好对接浪费时间的准备。
上层设计压力太大可以下移，但要确保承接人员综合素质足够，且（有明确的需求）能明确理解需求。
先搭架子挖坑，不着急先做具体细节，以后可能delegate
人做不完工作就拆分，再拆一层还搞不定就炒了吧

每月

每周

晨会

提前准备
站立
限时
主要目的

项目过程控制

项目管理

过程驱动和结果驱动：过程驱动看专业性，但归根结底，尤其初创公司是结果驱动
软件：软件的选择；看板是方式，目标是完成目标
排期和延期
平衡项目进度是走钢丝的艺术

项目文档

目的：把各个岗的最终目的写下来，把缺岗的地方自己补上
构成

Always have a backup plan

经验

确定未来三天完成的版本号(如0.0.2）和目标。主要目标应该是固定一个供测试部署的版本，且完成一些一定能三天完成的小工作，在周四下午前提交固定。为此，应该在Gitlab开一个Milestone，开Issue，必须_仅_包含这三天的目标，并且提前通知郜来安排时间整合。
确定未来一个月的版本号(如0.1.0）和目标，开Milestone，开Issue，从粗到细规划，下班前讨论，并争取用未来四天细化规划，并跟韩锐沟通找出可能出问题的地方，跟天阳沟通核定最终交付和不交付的东西准确，核定到需求可操作，资源可提前安排，完成时间误差正负不超过50% 的地步。
确定未来一个月内，以上任务的初步分工方法，然后按照任务分配的人员开始沟通目标，保证每人对目标有准备，对时间和结果负责任。
能避免的全员讨论就避免，大家都去研究一件事的效率是很低的，会影响手头的工作，真正下手做事的人了解细节即可。一个基层人，深度和广度不可兼得，管理者需要帮助整合。

进度拆分

项目不能按上周，本周，今日分。得按idea，预研/需求，确定需求，研发，集成/测试，灰度发布，最终上线这样分。否则根本不知道时间哪去了。这样还有个好处是能直观表明需求和测试发布这些环节的重要性，让人无法忽视。

Milestone

一个Milestone里，很容易看出进度问题（红色就是到期的）。这时候一般有几种情况：

没做完的（需要根据情况催进度，找原因，或者追责）
做完了，但需要交下个阶段的其它人（需要延长Deadline，催转交，催沟通，并反思沟通准备问题，反思Deadline是否少考虑了要指示的转交步骤）
做完了，但没有Close（需要催Close，做完的标准是交付并Close Issue）

一般按照上面的办法每天盯一次，Milestone内完成比例就会明显上升，进度也会推进。关键是能找出慢的原因并修补。

避免假努力和假deadline

项目管理工具

意义

让研发制度和流程，固化到工具中。
Manage-Plan-Create-Verify-Package-Release-Configure-Monitor-Secure

核心优势

大量商用，功能通用，这满足了选型的评价出发点。
功能完备，涉及研发流程完整：对于绝大多数常用需求，包括代码管理、版本控制、项目管理、任务追踪、Bug追踪、持续交付、自动化测试、持续集成、自动部署、资料分享、服务监控都有满足初创公司适用的解决方案。
扩展性强：极强的扩展能力，对接大多数更复杂的专门软件。账号方面支持LDAP。
扩容便宜。
数据自有可控。
价格免费版无硬伤。
一般研发层面的需求和细化讨论，都能在上面有效进行和分享。

Git flow / Gitlab flow

分支问题处理
Git flow的核心概念————适合哪个阶段
Gitlab的重要功能
客户端的使用，如 Sourcetree
Git issues 沟通本质是个平等化分配任务的过程
受保护的Master分支

敏捷和精益方法

精益和敏捷是思想，不是教条
参考腾讯方法和敏捷书
实用化的开始方法：条线式敏捷分工小组

技术架构

初创公司的架构与战略是一致对：是一个设计150%，做100%，拼命做出80%的工作。

需求确定的情况下，绝大多数大块时间的浪费，来源于架构。

调研的重要性：可以不知道实现细节，但必须知道别人怎么实现，至少知道用什么实现

选轮子和造轮子

组件化

微服务

微服务解决了什么问题？

优化和过度优化

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

--Donald Knuth, 1974

先实现需求，避免滥用技术
优化要有证据：避免熟悉的领域优化太过
架构要预感需求变化：避免架构设计太超前（并发）

新版本：可以考虑做个replace list

DevOps

DevOps的目的是创造开发和运维通力协作，优化交付的文化。

开发和部署的固有不一致

持续交付

开启DevOps本身是个过程

成说的apache跳板机

guacamole 远程桌面协议
jumpserver/jumpserver 堡垒机

测试

项目总体Review

你的测试是否真的跟上

进入时机晚不晚？
测试能力搭设是否很需要时间？
测试面扩大是否很需要时间？
如果不自动化，持续测试时，效率是否严重衰减？

最后时刻的需求变更

不能有改bug冲动，要排期

测试

单元测试

测试环境

测试要点

测试报告

持续测试

运行监控

先分解什么需要监控，分哪几个层次

服务器端开发

Web端开发

移动端开发

不能只讲后端，讲讲前端开发和移动端开发的坑

战略的制定

战略最大的困难是传导深远，修改不易
核心功能全力保
先挖坑搭架子到战略（阶段目标的）150%，然后砍到100%，然后实行80%，就成功了。
研发战略，核心是找到关键，找到优先级。从这个角度讲，mindmap是没用的，铺开再多不如抓住关键。
每个需求都是有巨大成本的，哪个做，哪个不做，哪个拼命也要做出来，是最重要的工作

技术的演进

业务数据化

什么时候需要数据

内部使用（收集分析测试预测监控）和外部使用（数据平台）

数据系统包含什么？

数据系统设计

架构

组成

收集-传输-清洗-存储-查询-分析-可视化-使用

性能

很多时候，新业务早期就需要存储大量数据用于产品、业务和市场的认知分析，所以数据系统往往从一开始就需要关注性能。

单位时间吞吐
- 数据库写性能
- 负载均衡
实时性
- 采集到展现的时间差
查询性能
- 能否满足查询总量
- 查询延迟业务端能否接受

容量

总量

可靠性

网络可靠性
- 动态DNS
- 分布式队列
系统高可用
- 主要时队列、数据库的多点、容错
- 大型全球项目才考虑网络问题

采集和传输

filebeat
Log还是直接写？
Log格式
队列

清洗和存储

消息队列选型：吞吐，持久化，集群，通用性
做清洗时的边界。
预处理和分析。

做存储设计时，首先要关心存储形态的问题，一般是三种：SQL，NoSQL，Key-Value。

SQL 优点：将复杂的数据逻辑简化为了SQL语句；容量易扩展，性能易调优。缺点：业务新增和修改时，各环节都要变动，工作链条长，不适应业务的快速变化。
NoSQL 优点：灵活，最容易适应业务需求变化；缺点：数据结构确定性差，天然容易造成数据呈现时的故障。
Key-Value 优点：容易追求性能极限。因此可以做为大型系统中，结构简单但需要最高吞吐的局部。缺点：仅适合简单场景，扩展性差。

分析和展现

查询
- SQL/NoSQL语法
展现
- Kibana, Superset, Grafana

注意事项

本质上需求是来源于业务的，不能脑补需求做设计。

视野和前瞻性

关注业务和运营

cto在大家各就各位，一切理顺后，到底做什么？

注意vipabc

业务和运营工具

野路子与制度化

优劣

技术团队架构

敏捷团队

非敏捷团队

招聘

TOPIC

一切问题都是人的问题

有些人的水平低，是救不了的，不要指望招进来改变

厉害人的标准 在意自我实现，在意工作的意义和严肃性的是好员工

如何搞定知名高手：慢慢来，享受过程（找国外例子）；一起做一点儿上船工作（我的例子）

面试前看简历，避免脑补谁都能干，避免脑补谁都是垃圾
什么样的简历一看就是垃圾？
是否避开Java：IEEE Spectrum 统计python持续第一大语言
高级人才水货也有，但推荐渠道可靠的水货少；没有水，只有不匹配
招聘非特殊岗，岁数小优秀。很常见

新人入职

来的时候得有人
照顾吃饭
加班和时间政策

面试

Delegate

面试如何delegate

面试者类型

假的，混型

水平

不同能力级别人的指标特征

最后

不管怎么面试，人好用不好用也得用了才知道

团队发展变革

团队管理

解决人的问题避免技术思维

你如果是太理性、太讲逻辑的人，要求助于不理性、不讲逻辑的人帮助解决团队问题

10%人占用了90%的精力，为什么，怎么办？

要通过性格的简单归纳，以对和自己性格不同的人的性格做一基本把握(MBTI)

创造良性的竞争氛围

遏制不良风气

跟踪结果

太多经理呵护少数需要帮忙的人不好，也别冷落不用操心的人
研发有默契型和分工型
磨合期：技术岗不同工种磨合期>同工种合作期>非技术

带人的方法：激发自我进步动力，把动力align到公司目标

如何服众：经验正确预测正确，自己向上按期交付。就够了
用人要激发使命感。驱动人只有两种：任务驱动和使命驱动，后者比前者高级
团队改变：改变不是凭空来的，是思路、影响力、沟通的结果

员工的类型

文化对团队的影响高于工具

自己不懂的领域怎么管？

中级人才在乎什么，高级人才在乎什么

技术分块最终负责怎么逐步delegate

cto从基层做起才好，知道这一行的轻重难易

对于熟练员工而言，造成的时间浪费最多的，一般是方向性把握的问题

薪酬和考核

根源是懂得什么人好，招到对的人

Google Snippets

薪酬

初创公司钱要花在增长上，薪酬高低取决于帮助增长速度和质量的程度
这个时代还要克扣成本来做的科技公司，本身就没有竞争力
不同岁数程序员激励方法不一样

定期考评

考评跟KPI是两回事儿

我们进行月度考评，只关注两个目的：

回顾和评价个人过去一个月的表现
跟踪工作情况，保持上下级间的信息透明，消除信息差。

KPI

研发人员的天职是解决问题，要解决的问题层面是复杂、多样、变化的。KPI的负面意义在于，把重点从解决问题本身，改变成追求固定维度的工作了。

什么是考核好的工程师

不同级别的考核要点

技术人员的利益

经常受侵犯
“说了不算”怎么办？
“卸磨杀驴”怎么办？

加班

人月神话是否管用

什么情况加班有用，什么情况没用？
什么情况应该加班？
什么人需要加班？
996员工一定偷时间
调休和报酬
加班会造成核心人员离职

一般而言，这一行需要的是聪明的、能解决问题的人，勤奋不勤奋不是需要关心的、勤奋只是解决问题路上的常见手段

千万别用叮叮（问问yangwei意见）

加班时间大排名：鼓励

技术团队培养

新人和新团队的融合期

综合培养

做完事情，做好事情，是培养的第一位
卡住的原因总可以归纳为功底不牢
一个基层人，深度和广度不可兼得

高手的培养

拉高追求
解决盲点
带动性格

code review

是个培养人的事情
是个控制质量的事情
尤其是个控制完成度，需求理解的事情

应届生培养

新手管理

手下技术人员不开心的原因
技术人员的沟通方式：只考虑实现；利益上宁折不弯
新手工程师需要注意的问题
知识面不够，有些问题想不到
不知道什么叫做完，交付的边际在哪里
手里拿着锤子，看什么都像钉子
要不要用实习生？

新人可能的问题

分工授权问题(Delegate)：一个人不能干所有的工种，这样干是浪费而不是节省，会明显影响进度。比如一会儿部署测试，一会儿开发，一会儿对Log。他们不觉得这有问题，其实这很浪费核心开发人员。这些都是简单的分工就能解决得很好的。应该有不断分工的意识。
测试问题(Test)。他们不重视测试。其实测试可以由咱的核心人员确定方法和流水线，然后及早分给非核心人员重写补完测试，既能熟悉代码，又赶上了单元测试的进度。剩下跑测试、存日志、自动化的事情给DevOps。等再招一两个研发就能做这件事，永远不需要咱的人来做。
总体意识(Whole picture)。做到哪儿算哪儿，没有总体项目节奏意识，没法预计接下来需要做啥，没有提前申请资源的意识。

实习生灵性很好，需要加把劲快速培养出来。

新员工要从微观（项目规划，管理）开始，逐步建立总体意识

向上管理

程序员必须会说，否则别人真不知道时间花到哪里去了
要随时了解CEO心里缺啥需要啥
主动参加重要决策会议
沟通意愿问题需要解决（cc例子，e例子）
老板不告诉战略怎么办？
有的老板抱着发展的诉求，却在传统习性的干扰下，白花钱（周黑鸭）
老板有没有接受更高层次价值观念、引入更加专业管理团队的准备
不重视信息化、不投入信息化，但却又受累于信息化，最终带来更高的成本支出

和老板沟通

问项目完成预期时间，必须先说要问需求，需求不明确可以拆解，不可以猜解。
如果老板提出优先级不高的开发事项反复强调怎么办？（追究这样提的原因，是不了解技术重点，是有什么担忧根源，还是忘了这块儿已经解决了：要记得追究这些是CTO的工作之一）。
要强调，你干的必然是别人干不了的，有前瞻性的，最终解决问题不返工的，要懂得强调这种价值，而不是和别人比高效、比

沟通

沟通意愿是沟通能力的一部分
老板出发的不合理需求处理
外行低估需求时如何处理

身份的焦虑

是否合伙人身份的定位区别
老板：不管型和micromanage型

向上管理

时间和预期的向上管理
资源不足问题的向上管理
向上沟通，自己说了老板不信的，就再找一个最适合的人一起说。
老板不相信时间的，就拆解，先做简单的看效果。
让老板做选择题不一定对，因为不懂技术细节的话，老板还是没有足够的信息决定，需要让老板做修改题————先独断，提出方案，但只是需求型、未落地执行的方案，然后和老板修改，讨论修改部分的可行性、必要性和成本。这一点尤其适合想法多，又没有实际操作过流程，但还追求细节的老板。

团队内沟通协作

需要规定沟通方法
搞技术的常常以为自己懂，需要确认是真懂，还是需求不明情况下沿用旧经验/受限的知识。
好cto是擅长对下沟通的，技术人员是一个对工作内容意义有一堆疑惑的群体，有可能是因为技术人员站得不够高，也有可能是cto想错了，需要沟通

跨部门沟通协作

技术人员一辈子改不了不善沟通的问题，又过于讲究可行性，其实过于讲究落地可行性是短视的，人类就别发展了。（举例） 全能、比拼命。

只守着自己的边界最不利于做高管，但不受边界，又容易累死或者完不成核心目标。

不能假设别人懂专业语言：比如冻结需求，

和CXO沟通

和客户沟通

CTO的核心技能就是和所有角色合作

程序员注意，我干多了开发也会不理需求，不爱沟通，忙着做事，不善交际。这是种影响big pic的事情

别的部门找你怎么办

别的部门小员工找你修电脑怎么办

技术交流

周末交流

论文和学术

科研和文档类研究和专利

开源和社区

开源两种项目：不靠谱的和靠谱的
初创企业能开源的东西：大家都用得着的小改进，核心领域核心组件，需要共同研发的
没有社区/无需社区的公司，开源没有回报，不要轻易开始
开源项目的模块署名制度

每个模块，哪些人有贡献，就署哪些人的名字；谁最终负责，谁名字就放第一。   毕竟未来代码是 *要给别人用，要见人* 的。 

- 容易更快培养成熟的开发者，做事通盘考虑，也不敢没想好就乱提交，拿产品当试验品。
- 给开发者荣誉性质的激励，“开源的牛逼BitLoop项目的XXX模块是我做的”，而且开源项目本来就应该这样。
- 个人对内部调用和外部调用的需求负责到底。这样就有自然有了文档意识和对接意识了。
- 更快意识到产品级别的东西（给别人用的），和实验级别的东西的大鸿沟，以后做事脑子就更清楚了。

技术资源运用

边缘角色，紧急角色的来源

外部资源合作

什么样的合作是好合作

资源置换

跳出技术圈

沉浸在代码不跟资本结盟不行

资本的力量非常大，技术驱动的项目，如果背后忽视资本驱动，很难生存

对CTO的常见误解

职业生命和职业危机

个人发展（40岁）

程序员能纯靠技术渡过中年危机吗？ - 接地气的陈老师的回答 - 知乎（软实力和项目管理）

https://www.zhihu.com/question/264237428/answer/320325900
程序员能纯靠技术渡过中年危机吗？ - 北冥乘海生的回答 - 知乎（路线/速度）

https://www.zhihu.com/question/264237428/answer/482762867

持续学习

E:只输出顾不上输入

写作

求职和跳槽

求职有啥坑
一个公司需要招一个CTO，这件事本身就有可能可疑，尤其是一个正常运行的公司。
要不要碰金融
谁来面试你(CEO？怎么应对)
有些行业全行业供不起一个cto
目前经济趋势，低水平科技企业必然不好活，所以创业去低水平基本等于死
CTO求职，要考虑机会也是一种稀缺资源。正经大点儿的CTO自己去面试也挺奇怪的。基本不缺工作。
选老板：成功者一般是优点突出而不是全强，成功越快反而性格缺陷越多。性格决定合作顺利，优点决定是否能成功，这中间的度需要权衡。

要不找通过规模挣过钱的老板，要不找通过高利润挣过钱的老板，否则盈利路线不对，技术研发什么作用都不会有

不要迷信大厂，尤其是没有生命力的，口碑差价值观有问题压榨人的，以及养老的

求职和行业周期规律

成为CXO

统一账号

统一账号/统一认证系统的引入和搭建(LDAP)

本期我们谈一项有关企业IT基础设施的实操性话题：如何为初创企业引入并搭建自有的统一账号系统。

为什么需要统一账号/统一认证？

没人喜欢记忆一大堆混乱的账号和密码，员工不喜欢，企业更不喜欢。

企业要高效解决业务和研发问题，必须在初创期规划搭建必要的企业软件和研发工具，也就是进行IT基础设施中软件部分的选型、配置和部署。在大型企业，这样的工作会有专门的IT基础设施部门和内部工具部门负责，而在初创企业，这类工作往往需要由CTO布置，甚至亲自完成。当然，这一过程也是CTO对研发部门贯彻管理和研发思路，同时对企业总体提供IT支持设施的过程。

在公司软件基础设施中，最基础的部分就是统一账号和统一认证，这一体系相当于一张访问软件系统的“员工卡”。它能基于对每个员工的唯一账号、密码、以及其它信息的管理，简化和串联不同软件系统的身份管理、统一登录和权限控制，让员工方便地通过同一套用户名密码登录公司的大部分系统完成工作，也让行政和IT人员一站式地管理任何员工的账号和权限。

为什么选择LDAP？

初创公司选择统一账号的方案只需要考虑两个问题：广泛兼容和自有可控。

广泛兼容指应该选择有最多的软件和工具支持的统一账号方案：应选取不论是哪种操作系统下的软件、不论是云端还是本地部署、不论是开源产品还是收费软件、不论是研发用工具还是其它部门常用软件，都应能顺利接入的方案。

自有可控指这样的方案应该有可靠的私有部署和本地存储方案：无需向第三方长期采购，且随着公司规模的扩大，支持灵活的功能增加、字段增加、组织结构修改、以及复杂权限管控。

因为以上两个考虑，我不建议初创公司选用知名云办公套件或大型OA自行设计提供的统一账户管理接口，原因是兼容软件不全，迁移成本高。也不建议选择不成熟、不可控的LDAP-as-a-service类云服务产品。OpenID和Oauth与本文的目的不符，也不应选用。

满足以上两个需求且最适合初创企业的，是LDAP(Light Directory Access Protocol)这项被广泛支持的协议。这是一个轻量、灵活、通用、长期可靠、可自有部署的目录服务协议。所谓目录服务，本质上是一个适合规划组织和账户结构的数据库标准和实现。各类软件可以通过类似数据库查询的形式，统一存取LDAP内的数据，以实现账号管理和登录认证的统一。

软件选型方面，目前兼容LDAP协议的最主流实现方案有二：Linux操作系统下开源的OpenLDAP，以及Windows Server操作系统下闭源的Active Directory。我们将以OpenLDAP为例讲解，在实际选型中，只要按照操作系统的熟悉程度两者择一即可。

哪些软件和工具可以和统一账号/认证集成？

下面列出一些常用的支持LDAP作为统一登录认证后端数据库的软件和工具。CTO在为公司建设软件工具体系时，可以直接参照下表选型。事实上，大多数包含账号体系的企业级软件，尤其是技术研发相关的软件，都支持LDAP账号。

支持LDAP协议进行统一登录的软件和工具

类型	典型产品
电子邮件服务	大多数主流邮件服务软件，以及全球市场销售的绝大多数云端邮件服务
企业通信录和日历	大多数兼容 CardDav 和 CalDav 协议的通信录和日历协作产品
研发综合管理	Gitlab, Github Enterprise, Phabricator 等
知识管理	Confluence, MediaWiki 等大多数知识管理、知识库、知识协作产品
企业网盘	OwnCloud, NextCloud 等
项目/错误/集成管理	JIRA, Trello, Bugzilla, Redmine, Jenkins
数据看板	Grafana, Apache Superset
实时通信	Slack, Mattermost, IBM Sametime 等
Wifi接入	部分企业级路由器，大部分路由器网关软件，OpenWRT
虚拟专线	OpenVPN
证书管理	OpenSSH

实施要点

我们的专栏不会讲具体的部署配置细节。但会介绍实施的关键步骤以及需关注思考的重点。

1. 搭建和配置LDAP服务

应优先考虑选择使用OpenLDAP或Microsoft Active Directory作为服务端软件。
对于域名是ctoabc.xyz的公司，LDAP服务名称和接入名称应设置为dc=ctoabc, dc=xyz，管理员访问名称一般为cn=admin, dc=ctoabc, dc=xyz
应保证搭建完成的服务拥有独立的公有IP，便于内外网访问；应保证服务器的访问安全，并使用加密通信(LDAP over SSL)。

2. 建立组织结构和人员数据

选择安装一个LDAP管理客户端软件，可以是基于网页的OpenLDAP, Web2LDAP, LAM，也可以是本地运行的jxplorer。
最简单的组织结构搭建方法应先配置用户类型/用户部门，然后配置用户。
- 配置用户类型/部门：新建一个organizationalUnit，名为ou=groups或ou=departments，然后在其下按需创建posixGroup，如按账户类型区分cn=employees，cn=admins，或按部门区分cn=product，cn=marketing。
- 配置员工。新建一个organizationalUnit，名为ou=users，然后创建用户cn=username，如cn=zhang.san，并把用户的GID关联到上一步建立的用户类型/用户部门中。随后填写该用户的必要信息，如Email，Full name，Password初始密码等。还可以按需增加字段，甚至增加个人照片。
撰写一篇统一账号操作文档，记录以上配置/删除一名员工统一账号的标准操作方法，并移交给相关的IT/HR负责人。

3. 与各软件工具集成

需要注意各系统中Bind DN项目应配置为dc=ctoabc, dc=xyz ，访问LDAP目录的用户名则应配置为有最高权限的账户，如cn=admin, dc=ctoabc, dc=xyz。
需要注意配置好各系统中用户名、密码、全名等字段，与LDAP目录中字段的匹配关系。也就是配置好从LDAP中查询到各相应字段的方法。

4. 解决日常使用问题

配置一个自助密码修改Self-service Password Change系统，方便员工修改密码。
为统一账号系统起一个明确好记的名字，如CompanyName ID。
撰写并发布面向公司全员的CompanyName ID使用介绍文档。

这样基于LDAP的统一账号体系就搭建完成了，员工可以用一个账号和密码来访问和对接全部软件和研发工具，公司的也开始能够从账户层面管理众多软件基础设施了。

IT使用手册

https://git.blockinc.cn/docs/it-guidelines-for-employees/wikis/home

云存储和云文档

设计和推动企业云存储和云文档

初创公司的技术负责人，难免需要照顾传统上应该由IT部门完成的工作。在这一篇中，我们聊聊IT管理中最基本的一项工作：建设云存储和云文档系统，支撑公司初创期全部文件和知识的电子化保存和分享，为文档和资料的创建、管理、分享和使用，提供最优的解决方案。

谁会用？怎么用？

几乎所有部门都有保存和分享文档的需求：技术部门要存储设计资料，技术约定，公私钥，密码，还可能需要快速传输大文件；行政部门要发布手册、表格、文档，还要收集申请、报告；市场部门要保证全部门能随时访问最新的产品和服务资料；售前售后部门则有大量的用户数据记录；设计部门要公布公司形象识别手册等。

作为云存储和云文档的架构者，我们应选用合适的工具统筹这些资料的存储保管。在此之外，还应该从公司全局角度，分析考虑到以下相关问题的解决：

易于访问：应提供易于桌面和移动设备访问的界面和客户端。基本使用的学习成本尽可能低。
所有权：文档资料应最终归公司所有，公司可以最终控制、转移、恢复文件；
分享：文档资料应能快速分享给需要的内外人员直接访问；
传输：支持大文件的传输，尤其是公司局域网和专线内的快速传输；
外部访问：可以按需支持或禁止从公开网络访问和分享；公开访问的文件应有固定的URL地址。
权限：支持收于不同级别用户不同的访问、修改、协作权限；
历史版本：同一份文档资料的任何历史版本和历史修改，都可以跟踪并还原；
备份：支持自动备份，异地备份，以及出现故障时的快速恢复；
协议兼容：支持主流文件协议的访问，便于不同系统、设备的访问和打通；
上传：有便于用户上传文件的投递箱功能，用于收集公司内外提交的资料。

如何选择？

一般来讲，一套企业网盘，加上一套知识管理系统，足够解决初创公司全员的云存储和云文档需求。这样的产品市面上选择非常多。比如，云存储可以考虑开源的企业私有云盘如OwnCloud及NextCloud，也可以选用软硬结合的NAS系统如Synology；文档和知识协作可以根据需求，考虑Confluence，WikiMedia等知识库、维基系统、和内容管理系统。还可以考虑采购可供私有部署的各类云文档产品。

在具体选择产品时，还需要关注部署和整合问题，包括：