从零开始搭建的意思，就是从需求分析，系统规划，设计分析和落地实践几个步骤，从无到有的过程。考虑左右，为了个人学习和提升，选型基于流行的springboot+springcloud，从零开始搭建一套自己用于学习的研发平台。

整体平台的流程，从管理、开发、测试、运维、生产几条线，实现整体平台的落地和管理，下面是整体研发平台架构。

整个研发平台架构设计

整个研发平台产物：https://gitee.com/landonniao

整体研发平台使用的基线规划如下

平台所有基线及所有项目目录结构，整体从零开始进行平台基线搭建及规划，多个基线的规划，考虑更合适多个岗位角色的管理

序号	基线说明	基线地址	维护人员	状态	备注
1	平台整体文档目录	alinesno-cloud-document		集成中
2	平台环境搭建文档记录文档基线	alinesno-cloud-evn		集成中
3	平台前端规划及页面基础页面设计基线	alinesno-cloud-pages		集成中
4	平台所有服务列表代码基线	alinesno-cloud-service		集成中
5	平台前端应用和手机应用代码基线	alinesno-cloud-application
6	平台自动化测试基线	alinesno-cloud-test
7	平台运维脚本过程产物基线	alinesno-cloud-operation
8	平台搭建过程中常见问题基线	alinesno-cloud-question
9	开发人员使用平台指引	alinesno-cloud-guide			略

一、个人为什么要搭建一个统一研发平台

1、为了有方向感，不迷茫，不浪费时间，有可行的学习计划

上大学的时候，就开始学习计算机，从基础的Java到Java web，再到框架，再到在学校接一些小项目，如企业网站，兼职网，报名网站等，这几步路大概走了2年左右，而在学完两年之后，人还是很迷茫，方向感还不是特别强，而在找方向和突破迷茫上面，走过了很多弯路，终于找到点方向。后来才发现，很多这个专业的同学，可能毕业几年之后，依然还找不到方向和定位，东学一点西学一点，很浪费时间，可能醒悟的时候，已经过了3~5年，很难再转回头。

2、为了在工作和学习过得中不断积累和提高学习效率

学习和工作的几年里，几乎每个项目，资料，文档，规范都是有共性的，而由于各个项目的不统一，在接收新项目的，几乎都从零开始，一些非功能性需求的建设已经占去了实际项目的很多时间，投入需求建设的时间其实没多少，最简单的，代码的CURD都是一样，自己在做的时候，针对每个项目都有改进，比如这个项目统一了CURD，那个项目梳理出了公共代码，但是项目是分开的，最终新的项目，也是从零开始或者复制，再加上人工，手工，人肉运维，不断的繁琐而简单的工作的学习中无法脱身，影响进入下一步学习。这类似于温水煮青蛙，没有感觉，可能慢慢拖死自己，特别是做项目的前两年，除了数据的添加删除，还是这些。重复开发，无法共用这些都消耗了很长的时间。比如一直想学大数据，但是由于没有好的平台依托，目前还是无法投入学习。

3、为了可以总结和反思，可以不断的打磨出一个平台，一个产品或者一个精品

这几年的工作和学习中，有很多都是在学习，在努力，也很上进，资料有不计其数，但是却在用的时候，没有深入或者精通某一个模块，最常见的，连自己精通的模块都无法界定，不自信，没有自己的深入心得，比较浮在表面上。自己近乎有两年的状态如此，一直在努力，但是却一直没有达到预期的，别人认可的效果，接触的面好像很多，但是却没有哪一样是完全吃透的。最终发现的原因是没有做好总结和复习，反思，一个知识点以为看过了就懂，但是没有结合实际进行提炼与打磨，没有吃透，就往下一个模块，最终导致好像不断的在捡东西，但最终这些东西都不是自己的。所以需要打磨自己的东西，能谈出自己心得，这就是自己的产品，就是自己的精品，或者自己就一个精品。

4、为了扩大自己的视野和学习心态，开放心态

学习中最怕和就是无沟通与交流，没有他人的指点和自己的固步自封，坐井观天等心态，在学得一些技术之后，开始自以为自，然后偏向于安逸。明显，这种心态自己曾经有过，而且持续很长一段时间。这间接造成不管是沟通、技术方面都慢慢出现问题。自己一直相信，心态有多开放，有多宽容，帮助的人越多，自己也才更好的成长，不管是技术还是管理，包括生活等。

 二、个人需要搭建怎么样的研发平台来学习

1、可以随时随地的学习，只要有网络和电脑，就可以学习

闲碎的时间常常存在，比如学校上机，看手机，还有一些无聊的聚会，甚至上厕所，这些都要能可以用来学习，网络现在无处不在，有个手机就可以上网，所以这些时间要能充分利用起来。

2、可以好的工具和学习环境

学习过程，工具的成熟度和熟练程度很多时间影响到自己的学习效率。比如vim的配置使用，熟练之后，不管在编辑和代码方面，速度都比一般的操作快得多。还有jenkins，在这个工具上不断的学习和积累，不管是配置和权限，发布，运维，分布式都能很大的帮助，同时节省很多时间。

3、可以不断的学习目标，最好从基础程序员到总监

学习有一个从零开始，到不断往上的过程，并且有目标，知道每个目标阶段需要什么样的技术，能力，成长时间等，做到心知肚明，不浪费多余时间 。可以不断的有学习积累，在积累上由量变到质变

5、可以不断的跟外界沟通交流，避免闭门造车，固步自封

需要不断的与外部学习，获取到外部的建议，看到自己的不足，同时也看到自己的优点。在自己不断学习的过程中，同时不断的成果，并让别人看到，给自己提建议，在自己把自己的思路成果对外贡献的同时，别人也一样帮自己提升。

 三、研发平台怎么搭建，搭建到什么样的程度

搭建的思路都是先有一稿，然后再后期慢慢在这一稿上面做好优化，同时参考当前社会主流技术，便于学习。

1、制定整体学习规划和学习路线，技术路线和成长规划

平台构建过程中，产生大量的技术产物和管理产物，而在大量的项目过程中，同时也会产生大量的问题导致过程中细节的不完善，人为的不完善及限制，导致平台无法正常管理和运维，开发平台的管理规划即针对整体平台的运维管理进行的建议，以达到管理统一有序，过程明确，产物明确，目标明确等

从需求->准备->组织->开发<->内部测试<->用户测试<->自动测试->生产(试运行)->生产->运维整个流程完善，每个流程中又包括多个工作，如需求管理，同时每个工具必然有一定的产物，如需求管理的产物是需求管理基线和需求文档。

序号	模块	功能	产物	备注
1	需求	需求管理	管理基线
2	需求	组织分工	需求人员管理表
3	需求	需求变更
4	需求	需求确认	需求文档
5	需求	需求分配
6	准备	工具准备	工具管理文档
7	准备	组织结构	人员资源清单
8	准备	环境准备	开发基线/文档管理基线
9	准备	资源准备
10	准备	基线准备
11	组织	人员资源	人员资源准备
12	组织	开发管理
13	组织	沟通管理
14	组织	角色分工	角色分工及联系沟通表
15	组织	版本管理
16	开发	开发培训
17	开发	开发管理
18	开发	单元测试
19	开发	开发流程
20	开发	部署管理
21	开发	问题处理
22	测试(内部)	内部测试
23	测试(内部)	组织机构
24	测试(内部)	问题反馈
25	测试(内部)	Bug管理
26	测试(内部)	接口测试
27	测试(内部)	功能测试
28	测试(内部)	集成测试
29	测试(用户)	业务测试
30	测试(用户)	问题反馈
31	测试(用户)	Bug管理
32	测试(用户)	问题反馈
33	测试(用户)	测试报告
34	测试(用户)	版本管理
35	测试(自动)	测试配置
36	测试(自动)	压力测试
37	测试(自动)	安全扫描
38	测试(自动)	功能测试	测试报告
39	测试(自动)	安全测试	安全报告
40	测试(自动)	压力测试	压力报告
41	生产(试运行)	切换计划
42	生产(试运行)	工单管理
43	生产(试运行)	账号管理
44	生产(试运行)	安全管理
45	生产(正式)	运维监控
46	生产(正式)	工单管理
47	生产(正式)	日志管理

为达到以上的要求，也为了过程有记录和沉淀，考虑一些必要性的管理工具，暂时考虑以下几个工具：

序号	说明	技术	版本	备注
1	文档管理	GitBook		企业内部做好考虑，团队未必每个人都能接受markdown
2	Wiki管理	GitBook		企业内部做好考虑，团队未必每个人都能接受markdown
3	开发过程管理	Jira
4	开发工具管理	百度网盘		公司内部建议使用FTP或者内部文件系统
5	邮件通知	163邮箱		建议使用企业内部邮箱

以下为文档管理基线示例

2、制定持续集成环境，为学习提供基础的准备和提升效率

持续集成他一套比较成熟的自动化研发解决方案，使用也有几年时间，不同的人有不同的设计，有些可能只是发布工程，这里针对于需求、开发、测试、文档、运维几个维度，进行了整合，同时也制定和管理方案，以达到基础规范 – 组织结构 – 基础架构 – 业务开发 – 持续集成– 自动化部署 – 自动化测试 – 生产运维监控 – 在线升级 几个方向自动化，这里不得不提一下Jenkins+git，确实是整个自动化的核心。目前考虑了一下这些工具，针对于开发的：

序号	说明	技术	版本	备注
1	代码管理	Git(gitee)	2.17.1	企业内部建议使用gitlab(更能满足需求)
5	代码管理客户端	SourceTree	2.7.6
2	自动部署工具	Jenkins	2.107.1	不建议使用太新版本
3	私服库	Nexus	2.14.1	不建议使用3.x版本
3	构建工具	Maven	3.6.0
4	代码检测	Sonar	5.x	不建议使用太新版本
5	镜像管理	Harbor	1.5.2
6	镜像容器	Docker	1.12.1
7	容器管理	Kubernetes	1.10	不建议使用太高版本,跟着社区走

自动化持续集成的效果如下：

文档持续集成效果如下:

3、下载和整理软件工具，整理软件工具版本

基础环境完善及配置，为整个开发平台做基础，以环境搭建为主,为本地开发环境。

使用的阿里云服务器规划如下：

序号	作用	服务器资源(系统/内存/硬盘)	IP规划	备注
1	开发服务器_master	CentOS7.4_x64_4G_40G	192.168.1.110
2	开发服务器_slave	CentOS7.4_x64_2G_40G	192.168.1.111
3	开发服务器_slave	CentOS7.4_x64_1G_40G	192.168.1.112

规划的使用工具如下：

序号	说明	工具	IP	是否集群	文档完善进度	备注
1	基础环境	JDK	172.18.11.17	单点	已完善
8	反向代理	Nginx	172.18.11.17	单点	已完善
11	自动部署工具	Jenkins	172.18.11.17	单点	完善中
12	私服库	Nexus	172.18.11.17	单点	已完善
17	链接跟踪	skywalking	172.18.11.17	单点
13	代码检测	Sonar	172.18.11.17	单点
2	缓存工具	Redis	172.18.11.17	单点	已完善
4	消息列表	Kafka	172.18.11.17	单点	已完善
10	分布式注册中心	zeekeeper	172.18.11.17	单点	完善中
6	分布式注册中心	Eurake	172.18.11.139	单点
10	分页式配置中心	Apollo	172.18.11.139	单点
6	数据库	MySQL	172.18.11.139	单点	已完善
1	开发过程管理	Jira	192.168.1.120	集群
3	Redis监控工具	Redmon	192.168.1.119	单点
5	消息管理工具	Kafka-Manager	192.168.1.119	单点
7	数据库主从	MyCAT	192.168.1.111/112	集群
7	容器管理	Kubernetes	192.168.1.1110/111/112	集群
9	高可用	KeepAlived	192.168.1.110/111/112	集群
14	镜像管理	Harbor	192.168.1.110	单点
15	自动部署	Ansible	192.168.1.119	单点
16	自动部署管理	Ansible Tower	192.168.1.119	单点
17	链接跟踪	pinpoint	192.168.1.119	单点
18	日志监控	elk	192.168.1.119	集群
19	服务器监控	Zabbix	192.168.1.119	单点

工具的保存是放在百度云上面：

4、规划平台非功能性需求组件，包括基础组件等

功能重用，组件重用，目前最好的技术承载就是微服务了，这也是这几年才出现，这样规划研发平台构架，对我而言，微服务架构自然成为不二的选择（后面的中台业务也是在微服务上进行进程创建）

服务设计原则

服务单库设计,以减少迁移，服务之前影响等；
基础服务只为调用设计，位于服务的底层或者中间层，基础服务禁止调用业务服务；
业务服务调用基础服务，或者其它服务，业务服务为服务的顶层，用于定制化业务；
同一级服务之间可以互相调用，只能自下往下调用，平级调用，禁止自下往上调用，以避免服务混乱及维护混乱。
每种服务目录按999个服务规划

服务设计规划

类型	目录名称	说明	备注
教程	示例服务	做示例工程，包含有所有服务调用示例
前端应用	门户服务	与中台服务同级，用于统一门户服务
前端应用	应用服务	前端应用或者手机应用
网关应用	网关服务	对外网关服务,与平台组件同级，但仅做为网关部分
中台服务	中台服务	服务于前端应用，处理业务，可以服务之间互相调用，或者调用基础服务
基础服务	基础服务	公用基础组件，只能被调用或者调用公共或者组件包,不能主动调用其它服务
基础服务	公共服务	基础公共包,所有工程的基础，包括配置，页面，核心包等
基础服务	组件服务	基础组件包，用于第三方等，组件包不能单独运行，只能被依赖
运维环境	监控服务	监控平台，用于运维平台，目前仅规划,有可能与平台服务合并一起
运维环境	平台服务	包括注册中心，配置中心等

工程目录规划

关于命名方向，一直不知道用什么名字比较合适，所以使用自己网站的域名。

序号	目录名称	目录规划	端口规划	权限	备注
1	公共服务	alinesno-cloud-common		研发
2	组件服务	alinesno-cloud-component		研发
3	平台服务	alinesno-cloud-platform	24000+	研发
4	基础服务	alinesno-cloud-base	25000+	研发
5	业务服务	alinesno-cloud-business	26000+	开发
6	门户服务	alinesno-cloud-portal	27000+	研发
7	网关服务	alinesno-cloud-gate	28000+	开发
8	应用服务	alinesno-cloud-web	34000+	开发
9	监控服务	alinesno-cloud-monitor	35000+	研发
10	示例服务	alinesno-cloud-demo	30000+	研发	置于guide基线

5、提取出业务中台规划，并完善组件，打磨中台业务产品

上面也提到，业务中台也是在微服务上面构建，设计原则加上了几个点，分别如下：

按“重中台”+”轻应用”设计，业务应用逻辑思路放在前端应用，推荐是尽量减少或不拆分前端服务;
重中台的建设，在于前端应用共性部分的抽取和后期的沉淀，形成中台业务服务;
中台服务调用基础服务，或者其它同级服务，中台服务为服务的中层，用于业务共性(共享)抽取；

整体中台的业务架构如下：

中台业务建设目标如下

6、统一和通用的权限配置系统和界面设计

这个就是通用的，只需要在配置平台添加好菜单，分配好账号权限，本地开发只需要账户就可以进行本地开发，配置平台包括的一些功能规划如下：

应用管理：用于配置系统应用，添加和删除管理。
用户管理：用户是系统操作者，该功能主要完成系统用户配置。
部门管理：配置系统组织机构（公司、部门、小组），树结构展现支持数据权限。
岗位管理：配置系统用户所属担任职务。
菜单管理：配置系统菜单，操作权限，按钮权限标识等。
角色管理：角色菜单权限分配、设置角色按机构进行数据范围权限划分。
字典管理：对系统中经常使用的一些较为固定的数据进行维护。
参数管理：对系统动态配置常用参数。
通知公告：系统通知公告信息发布维护。
操作日志：系统正常操作日志记录和查询；系统异常信息日志记录和查询。
登录日志：系统登录日志记录查询包含登录异常。
在线用户：当前系统中活跃用户状态监控。
定时任务：在线（添加、修改、删除)任务调度包含执行结果日志。
代码生成：前后端代码的生成（java、html、xml、sql)支持CRUD下载 。

然后大概的设计如下：

开发人员的开发流程如下：

7、完善软件组件辅助，包括测试、运维、环境管理

以上组件的搭建过程，如果一个人管理，会产生很多问题，同时延伸出其它方向的建设，其中包括最基础的服务器管理和服务预警方向，安全策略管理，平台整体入口和常用文档，功能，平台组件的质量保证，即运维、机房环境，测试这几块。在建设统一研发平台的同时，也自然包括建设这些内容，大概做了一些建设工作，以下为一些设计的示例。

机房服务器管理系统

平台统一门户管理

• 

其它的建议，如包括人才培养，大数据，人工智能，项目管理，都是在研发平台中慢慢积累和培养的产物，而最终的结果是为了整理出一套完整的企业统一研发平台。

四、总结

以上为目前搭建整体个人整体研发平台的思路和设计，一个优秀的研发人员的工作并非只是编制代码，更多的是自己能做什么，完成什么，有什么价值，能帮别人做什么。

1558 1547 column count of mysql.proc is wrong. expected 20,found 16. the table is probably corruptd.
在用navicat连接时发生了一个错误：
1558 column count of mysql.proc is wrong.Expected20,found 16.created with mysql 50091,now running 50528.please use mysql_upgrade to fix this error。

其实这个错误如果不是用客户端工具的话是发现不了的，因为我远程控制时操作是没有这个问题的。
查了下说是这个是由于升级后未使用mysql_upgrade升级数据结构或用不同版本进行备份迁移恢复造成的。
用Navicat for mysql会有此错误提示：

解决方法：
最后是通过”mysql_upgrade -uroot -p”

命令解决的。
直接用cmd命令执行这个，然后输入密码就好了。会自动升级mysql里的数据结构。
如:

mysql_upgrade -u root -pjoy

mysql_upgrade -u root -pjoy –datadir=/var/lib/mysql/ –basedir=/usr/

关于管理这件事，千人千面，我尽量把我这几年在管理上遇到的困惑和思考按照以下四点罗列出来，多多指教。

注：文章约12000字，信息量较大，故列出文章大体框架，供参考整理思路。

一、团队搭建5大步骤

早在《圣经》中就写过“凡自高的，必降为卑；自卑的，必升为高。”谁想要居首位，就必须甘居众人的末位，当大众的仆人。团队管理就是如此。

特别是现在的互联网团队基本是同龄人，最忌讳权力崇拜。坦诚和尊重，足以解决大多问题。

1、部门章程

不以规矩，不成方圆。或许在团队建立之初，大多是专业人士，能主动担责各尽其职，但随着发展壮大，新人涌现，靠自觉和人情管理就显得脆弱，这时就有必要和所有成员议定“部门章程”。

这东西相当于新人指导手册，告诉他这个部门日常是如何运作，哪儿有雷，哪儿可以撒欢。其中常见的章程条例有这些：

（1）部门架构

1. 小组概要（图左上）
2. 人员编制（图左下）
3. 岗位职责（图右侧）

在部门章程里，部门架构这块内容变得越来越尴尬，大多条例都因为各种各样的原因沦为“面子工程”。但对于管理者而言，一定要清楚每个岗位最重要的职责，想让一个人承担大部分工作成为“全才”，最后不过是庸才而已。

（2）立项流程

不同小组提出需求开展某项活动时，应由管理组议定项目负责人，专项负责人和管理组拥有共同决策权，部门其他成员具有审议权。具体流程如下：

1. 启动：由部门某成员提出创意或点子，在小组内部过审，并知会管理组，授权或承认该项目的存在并制定项目负责人（默认为主管）；
2. 计划：由项目负责人确定小组分工并制定验收标准，在正常情况下，面对项目负责人提出的合理要求，部门全组必须全力支持，如有意见可以直接向项目负责人或管理组反应；
3. 执行：确定项目的分工及完成标准后，安排各小组按步骤执行；
4. 监控：在项目推进过程中评估项目的发展是否按照正常计划在推进，如果不是，则寻找问题点，将问题点反馈给项目负责人记录解决；
5. 总结：完成项目后，对项目的实际完成情况进行评估，项目是否按时完成？是否在预算内完成？是否达到预计完成效果？形成文档留存。

（3）会议制度

1. 部门例会：部门定期开展例会，频率为每周一次，时间固定在每周第一天（默认周一）的 14 : 30 ，时长控制在 20 分钟以内。所有成员必须提前到会议室准备，如有无故迟到行为，乐捐 5 元。周会内容就是让明星个人讲经验，后进个人谈改进。
2. 普通会议：当部门成员确定发起部门会议时，一般情况下需要至少提前 30 分钟通知，并注明会议主题、时长、参与小组/成员。

（4）工作汇报

每天 9 : 10 开始分小组在会议区站立汇报当日重点工作，部门所有成员项目同步。下班前 17 : 30 填写 Excel 日报提交到 SVN ，方便主管汇总制作当日简报。

部门所有文档的提交参考时间为：

日报告（全员）

日汇总（管理）因作者公司隐私，故模糊处理

周简报（管理）因作者公司隐私，故模糊处理

月报表（主管）

制定部门报表规范的初衷很简单，一是规范工作内容，存档记录，二是便于领导查阅汇报。但由于我的性格，吃亏太多了。

以上表格图是我当初给团队制定的部分报表模板，最早日汇总由全员填写提交管理查阅，日报告由管理查阅后综合提交方便领导查阅，周简报由管理汇总提交领导，月报表由主管填写留底。

但现在只留下了日汇报、日汇总、周简报三张表，其他全砍掉了。

为什么？因为我太苛求了！！我注重规范不仅要求正确填表，甚至是控制单元格长宽，为了在日汇总中方便统计同一项目的参与人数，要求全员统一工作名称，还列出了一长串日常规范项目名。

起初同事就颇有微词，我力排众议推行了近三个月，终于后知后觉这是个多么反人类的工作！

在推行过程中我发现，表格失去了它原有的作用，越来越多同事因为反感，每天只是当做完成任务，完成结果和完成时间全凭感觉而非实际情况；领导层也由于事务繁忙，基本没时间看这些规范的报表。

也就是说不管表格多么漂亮，终究是流于形式。我意识到我可能是“没有大公司的命，却犯了大公司的病。”

砍掉大多“形式报表”后，同事们面上写着的都是“早该这样了啊！！”只保留了日报的原因是因为日报是所有汇报的基础，而简报的形式是“项目进度 + 本/下周重点事项 + 个人汇总”，用 word ，不论格式，只要把问题说清楚就行。

“重形不重意”，是所有管理者需要避开的陷阱。每天面对大量繁杂的报表时，一定要想方设法去简化，不要为了报表做报表，只会浪费时间。

文字传达的信息永远不比口头快，多和部门成员交流，了解情况，文字和表述结合，才是正道。

最后，不少企业已经开始使用更高效的解决方案，比如 Teambition 、 Tower 、钉钉等，但是公司内部一定要有创新者和领导的极力推动，毕竟多数人还很“传统”。

（5）文档规范

• 文档存放：管理者分配好文件夹，制定不同类型文件的存放位置，告知团队成员
• 文件命名：姓名 + 标题 + 日期，例如“涂俊杰-如何管理团队 2016-11-15.doc”

（6）培训计划

为提高部门人员专业素养并持续提高团队业务能力，运营部组织每两周开展一次内部培训会，时间一般安排在每周五下午，时长控制在1小时以内。

会议流程：

• 培训会议召开通知：确定时间、地点、参与人员、会议主题
• 参考资料的准备：幻灯片、板书、文印资料等
• 会议环节：分段讲述、随时提问
• 会后资料共享：会议后整理所有会议资料，将资料上传到云盘

（7）乐捐事宜

本着“乐捐不是目的，改进才是”的理念，部门推出乐捐制度，希望所有同事在工作中能遵守部门规章制度。所有乐捐金额将存入部门基金池，用于部门活动的开展。

乐捐条件参考：

• 上班迟到：除不可抗力，每月迟到一次乐捐 5 元
• 会议迟到：无故迟到一次乐捐 5 元
• 工作汇报超时：每日/周/月/季工作汇报未按照要求时间提交，一次乐捐 5 元

注：主管层以上乐捐金额*2

（8）部门活动

部门每月会举办 1 次部门活动，公司提供活动经费XX元/每人。

活动举办流程：

• 部门选举娱乐委员：选举方式视情况分为推荐、自荐和抽签，暂定为每月更换一次。
• 游玩项目议定：由娱乐委员收集全员意见，并作出整理，娱乐委员具有最终决定权。
• 游玩费用：在公司活动中，费用由管理组垫付，回到公司后由文娱委员负责整理发票并申请报销，活动结束后多余金额存入部门基金池，缺少金额继续由所有同事均摊收取。

以上，大概就是一个部门章程中经常会涉及到的条例。

肯定会有人说这些条条框框真是麻烦，做人不能简单点？其实在实际推行过程中，会简单很多，比如大家聊天时提到有家餐馆味道不错，这个月想去搓一顿，那就定好时间，没有什么委员选举，说走就走。

规则的存在不是为了约束主动的人，而是少部分不够主动的人。

最后要给到管理者的经验是，管理者一定要分清楚原则问题和行政问题（原则问题诸如项目责任人的确立、管理者的授权等；行政问题诸如一次迟到或着装休闲等），不要在行政问题上死抠，视公司环境和成员主动性调整规范，规矩是死的，人是活的。

2、奖惩机制

在“部门章程”中的“乐捐事宜”就属于奖惩机制的一种。而奖惩的关键在于当你罚了同事 10 块钱，今后要找理由奖励他 30 块。

在奖励和惩罚两种方法中，我始终推崇奖励，惩罚只是作为辅助。千万不能让同事在潜意识里产生负反馈。

比如我曾经会叫几位最近业务成绩不太好的同事去会议室聊天，聊天过程中指出他的问题并适当引导。但是你不能只因为同事“业绩不好”就让他去会议室“聊天”。

久而久之，所有同事都会默认为“被叫去会议室=业绩不好”，这样的后果就是所有人都害怕我叫他，害怕去会议室。

当我意识到这个问题，首先换了一个轻松的聊天地点，比如休息区（会议室自带严肃属性），然后不只因为业务下滑才聊天，也在同事业务超额完成的时候单独鼓励，并申请一些实质性的奖励发放。

说了“惩罚”，再聊奖励。新来的管理，想要尽快和同事打成一片，除了专业能力突出之外，就是多请客，多在容易带来好感的事情上曝光，带来好感的事情最常见的的就是请客吃饭（下午茶）。但是你以为突然在群里说“今天下午我请客下午茶”就是好方法么？

心理学有个经典条件反射，刚才在“惩罚”里提到“被叫去会议室=业绩不好”就算一种，对于惩罚我们需要避免条件反射，做到无规可循，但是对于奖励我们反而要利用条件反射，让其他人一有好事就想到你，占领好感高地。

那么这个下午茶该怎么请呢？回答是，在团队完成了某个小目标的时候，或者在团队测试出一条可行性方法的时候。成员目标达成，会自带成就感，这时候如果你能锦上添花，在大家心情好的时候请个下午茶，好感度 double 。(土豪随意)

3、KPI ？ KPI ！

KPI（Key Performance Indicator：关键绩效指标），大部分同事对 KPI 厌恶至极。追溯根源不难发现这个矛盾在设立 KPI 之初就已经埋下。

领导层希望最大限度的激发员工积极性推动目标，所以设定高 KPI ，但是高 KPI 带来的刺激程度并不是所有人都能接受，特别是当 KPI 挂钩工资，一旦员工受罚，必然怨声载道。

这次，我们不聊 KPI 到底要不要，好不好，我们来聊设定一个合格的 KPI 有哪些方法？

（1）定值 KPI

有些领导人深陷“年度目标”无法自拔，关键是领导如果执意要非常清晰业务指标，例如“一年后微信粉丝XXX”，“微信头条均阅读量XXX”之类。那么结果就是在分解月指标时只能按照月份均分，得出一条稳步上升的曲线。

这就意味着 KPI 值的容错率非常低，因为市场不可预测，可能第一季度平稳上升，第二季度突然来个幺蛾子大幅下降呢？如果挂钩工资奖惩，是不是意味着员工在第二季度只能喝稀饭呢？

所以，短期的定值 KPI ，或许可以适当刺激，长期的定值 KPI ，就是藐视市场。

定值 KPI – 理想曲线

（2）浮动 KPI

什么是浮动 KPI ？就是环比统计，本月成绩与上月对比，把时间粒度切分，风险分散，指标多为百分比制。

例如“获客单价较上月降低 5% ”，“咨询量较上月提高 10% ”之类。这样做的结果是，把超额完成和未完成分布均衡，这个月出了幺蛾子， KPI 值突然下降，被罚，那下个月最少会回升正常值，对比之下上个月罚的钱这个月就能赚回来，出了黑天鹅，也是同理。

浮动 KPI 最大的特点就是跟随市场的变动而变动，在员工的赏罚之间快速制衡。当然，浮动 KPI 也不是没有缺陷，因为是以上月值为基数，容易“小富则安”，大方向感缺失。

所以目前比较普遍的解决办法是使用“浮动 + 基准值”的 KPI 形式，如“获客单价较上月降低 5% ，达成得 10 分，低至 50 元 / 人，额外得 5 分”之类。

浮动KPI – 现实曲线

管理者如何制定 KPI 是一门艺术。

不仅要设定奖罚力度（奖励金额>惩罚金额），还需要在同事和领导之间找到平衡；不仅要视企业发展阶段使用不同的 KPI 方法，还要深入了解业务找到关键指标和基准值；不仅要思考客观分数和主观分数的配比，还要琢磨表格的展现形式…可能千辛万苦制定出的 KPI ，还没经过测试就被喷成狗。

小事情，大智慧。

因作者隐私，故做模糊处理

4、招聘 / 离职

任何一个团队，都无法避免老成员流失和新成员的进入。团队成员是我们每天都会接触面对的人，所以招任何一个人，不论职位都要谨慎；辞退任何一位同事，都要三思后行。

（1）招聘

团队正值用人之际，向人事提出需求申请，在此之前，管理者必须非常清楚需要招揽一个什么样的人，要找执行人才还是战略人才？需要他哪方面能力突出？希望这个人入职后给团队带来哪些改变？

经过几次面试之后，对应聘者的言谈举止应该有了大致的了解，应聘者的面试作品也能反映出部分业务能力。但是真正的考验一定是入职之后。

一般来说，在面试者入职的前三天是第一道坎（熟悉部门规范），一周是第二道坎（熟悉业务流程），一月是第三道坎（是否能优秀完成任务），结束面试期之前一定要有明确结果（是否有优化工作的意识），决定去留。

说个关于我的反面例子。

我所在部门需要扩招，有两名面试者同时通过人事一面，但是两个人都有些缺点， A 对业务的熟悉度较差， B 态度有些高傲。在两人入职的第三天，我决定放弃 B ，留用 A 。

理由是一个人的业务能力可以逐渐提高，但是态度品性却难以改变。所以哪怕最后 B 写出来的业务方案明显比 A 专业。

在 A 入职后，我安排了大量执行性工作，忽略了新员工在试用期的多维度测试环节，这些执行性的工作掩盖了 A 对一些开放问题的思路和能力局限。两个月后， A 通过试用期，等到业务量增多，我不得不交付一些开放工作（没有具体的步骤，需要自己试水总结）给 A 。

但是 A 面对这些问题的处理方式很迷茫，在没有具体指导的情况下难以开展，必须要我手把手教，我一边工作，一边培训。

A 最大的问题就是缺乏思考的主动性，习惯被动接受执行性的工作。这样的性格或许不太适合开拓团队，特别是在名额有限的情况下。

上面这些问题都是我的反思，但是我发现我最大的错误在于我定错了招人的标准，我错误的把标准放在 A 和 B 之间，潜意识认为一定要从这两人中选出一个，反而忘记了招聘岗位的准绳。这件事情一直提醒我，招人必须谨慎，否则受累的还是自己。

（2）离职

天下无不散宴席，总会有同事因为某些事情离职。管理者获知该同事提出离职申请后，就需要去了解员工离职原因。

一般来说不外乎有更好的去处，主动请辞；对团队或个人不满；被动离职；希望通过离职向领导申请加薪，威胁离职；业务能力不够，公司辞退。

先说主动请辞。如果是同事找到更好的去处，管理者可以和他聊聊对未来的打算，帮他分析一下新职位合不合适，提点一些新入职后要注意的地方。

同时，在营造一个友好的沟通氛围后，可以问一些他本人对于团队的建议。这时候，他可能会因为即将离职，说一些在职时不会透露的内容，一定要仔细留意。如果同事确定要离开，那么嘱咐他做好工作交接，祝他事业顺利就好。

其次被动离职。如果团队出现了“有你没我”这种极端情况，管理者必须反思，为什么会允许这种情况的存在？

先找到症结点，人 VS 人的问题，就衡量两人的价值情况，决定去留（到了这种程度，一般无法和解）；人 VS 环境，小团队的环境问题可以努力改变，但是大环境只能婉言相劝并向领导反馈，实在无法留住，后续依然好聚好散。

再说威胁离职。先给结论，所有拿离职来威胁领导希望加薪的行为都是下下策。正常的申请加薪流程应该是：整理业绩→拿着业绩向领导提出加薪→得到答复→加则留不加再提出离职。

最后是公司辞退。如果因为员工长期业务不达标，能力不足，那么管理者应当至少提前一个月给该员工敲警钟，严肃的指出业务问题并给出可行建议，如果该员工仍然无法提升业绩，那么向人事申请辞退并提交业务成绩证明。

另外，还有一种极端情况，那就是公司无理由辞退。如果企业提前一个月告知，然后按照《劳动法》支付工资，当然没事。但是企业既不想支付补偿，又想要强制辞退。管理者先要意识到，东家非常“不厚道”。

这时候切记，管理者需要站在被辞退员工的角度出面和人事及领导谈判，商量补偿，并且为同事提供切实可行的自保方法（劳动法）。而不是代表人事出面辞退员工，这样你不仅会被喷死，还会在团队中威信全无。对于这样一家企业来说，今天他能无理由辞退其他同事，明天就能无理由辞退你。

5、团队氛围

所谓团队氛围，不仅是团队内部营造的，更建立在整个企业文化之上。如果整个企业是狼性文化，你想把团队打造成温和派，怕是行不通。企业文化的改变绝非一人之力，而最需要注意的团队氛围管理是以下几点：

（1）负面控制

团队难免遇到困难时期，在困难时期管理者除了要向团队灌输正能量，还要做好负面控制。有不满是难免的，但是绝对不能出现推卸责任或边缘化同事的情况。

负面控制有个前提，首先是管理者不能说丧气话！面对某个小组的失利，千万不能说像“领导更加重视XX组，所以我们这边难过是正常的”这种话，一旦管理者说出这种话，那么被轻视的小组就等于是打入冷宫，哪儿还来奋斗的激情？

另外，要给团队合理吐槽的机会。可以设置“吐槽会”，比如每周五上午有半个小时的吐槽时间，任何人都可以被吐槽，合理吐槽（提出问题并给出个人建议和解决方案）+1 分。

当同一个人因为同一件事被吐槽超过 3 次，那么被吐槽者需要完成某个特定的惩罚，如当着团队的面表演节目之类（最好别光罚钱，大庭广众的羞耻感可比钱来的刺激）。

一定要注意维护好吐槽会的平等。不论参与者职务高低，一旦触发惩罚，必须受罚。

（2）成就感管理

团队最大的成就感当然来自业务指标的突破。管理者必须清晰的向所有团队成员解释完成某个指标所带来的意义，让团队意识到具体的场景并兴奋起来。

例如，管理者说“今天我们的日均访客目标突破了 2000 ”就不比“今天我们的日均访客目标突破了 2000 ，比之前1500的成绩提高了 33.3% ，帮公司多赚了 5000 块”来得好。

把关键指标通过统计出的数据描述为真金白银，不仅能让团队成就感爆棚，也能让团队成员知道自己的工作价值。

还有一项常常被忽略的成就感来源，那就是生活成就感。

管理者可以把自己或其他人的优秀习惯进行提炼，比如我曾经在团队组织过 15 天读完一本书行动，向公司提出购书申请，每人读完书本后写一篇读书笔记，相互传阅并口头讲述给他人。生活和工作，其实不一定要完全分开。

（3）管理者的绝对权力

虽说任何团队都是公司的财产，但是我认为团队管理者在充当团队保护伞的同时，要始终掌握团队内的“绝对权力”。

比如可能会出现的“越权行为”，当有其他团队管理者甚至领导人直接越过我向我下辖的某位同事下达命令时，我会在大群马上接过话题，重新按照我的想法进行任务分配，并委婉表示下次有需要支持的地方请@我就好。

再就是“分权行为”，管理者在内部培养接班人时不要犯懒，避免贸然让接班人迅速对外以求减轻工作。

关于“分权”这件事，其实就是要掌握一个度，这个“度”，对我来说就是管理者必须主导所有外部联系，控制接班人直接和其他部门领导沟通，如果认为时机到了，那么第一次也必须是在你的协助下沟通，并向其他部门同事表示今后部分工作会委派他来跟进，规范授权。

二、Leader需要培养的9种能力

关于优秀的管理者需要有哪些个人能力，我觉得可以分为专业能力、培养接班人能力、系统思考能力、优先级能力、沟通能力、认识自己能力、时间管理能力、个人素养，八个方面。

1、专业能力

管理者本职岗位的专业能力是所有能力之首，在团队中不要妄图以人情、素养服人，这些永远是加分项，不是必须项。

项目之初，管理者须亲自参与到项目中来，明确项目每一个节点及步骤。鞭策团队，带团队走一次完整的流程，项目完成后辅以数据证明，让每个环节的同事知道自己的付出得到了什么回报，哪些流程可以优化改进。

一般来说在管理者亲自主导完成 1 – 2 个项目之后，就可以开始由主导角色转变为辅助角色，从前更多的是监控项目进度，现在更多为整个团队提供弹药和资源。（切忌下属做事做得好，管理认为自己能做的比他更好这种竞争心理）

管理者的“贡献力”由直接业绩转换为团队业绩，开始更加关注团队成长，这是个人能力转化为团队领导力的特征。同时引出第二个能力，培养接班人。

2、培养接班人

不知道现在团队管理者还有没有“教会徒弟饿死师傅”这种思想，我的人生准则就是提倡分享。没有先贤的分享就没有后辈的进步，想要整个团队大步提升，就把你的优秀经验共享出来，分享过程中优秀的思考者会冒头，这些优秀的善于思考的同事就是你将来的左右手。

当下属能完成你做的绝大部分工作，甚至整个团队缺了你也不会翻车的时候，我认为管理者在培养团队这方面是合格的。

事实上，我通过这段时间的输出分享，收获巨大。在分享的过程中，我必须琢磨透每一个关联知识点，打通知识树的上下层。

这样来说，你教给别人的只是一杯水，但是自己先灌了一桶水。在教授的同时，自己也能加深记忆，遇到不清晰的问题还可以帮助你反思，这么好的机会，你要选择浪费敝帚自珍？

不要害怕暴露实力，你的杀手锏总有一天会被时代抛弃。始终记住“学不如教”！

3、系统思考能力

刚才提到分享，在分享过程中，爱思考的同事可能会问一些上下文联系的问题。

比如你正在向同事讲解“ 404 ”的问题，说到“出现死链要设置返回 404 状态码”，同事好奇再问，那还有哪些常见的状态码，常听别人的 301 、 302 又是什么意思呢？

如果你对“ HTTP 状态码”这个知识点没有深入了解，那肯定是懵逼的，你更不会知道顶级域名使用 301 （永久跳转）和 302 （暂时转向）到主域带来的影响。

现在是碎片化时代，太多短篇文章会分散我们的注意力，没事刷刷微博、微信，几分钟几十分钟的碎片时间就这样被消耗。

所以我规定自己每周读一本书，关注书籍中的系统思考以及作者成书的逻辑。包括我所有的文章输出，全都是按照我的逻辑框架在走，虽然很长，但是我要告诉读者，我学到这一步所有的逻辑线在哪里。

关注自身系统思考的能力，不仅有利于项目的复盘总结，也有利于个人的迅速成长。

4、优先级能力

分清楚待办事项的优先级，一定是管理者必备的能力。很多文章里有写，我就不多重复。

一般情况下，都是按照“时间——紧急程度”四象限划分。通常，领导任务 > 团队任务 > 个人任务，如图示：

图片来自网络

5、沟通能力

如果我设定了某个其他团队提交的支援需求优先级为“紧急但不重要”，但在其他团队看来，或许这件事是“紧急且重要”。如何解决？这就体现出管理者的沟通/谈判能力。

沟通的过程中，先说清楚你的想法，为什么会这么安排，为什么有这样的决定。双方进行信息共享，然后判定是否需要修改优先级。

如果确实是管理者的疏忽，那么调整后修改优先级即可。如果只是对方的“伪需求”那么也适当安抚，表示已经受到重视，完成手头重要的工作后会马上跟进，向对方表态，你已经重视了该问题。一般来说，对方其实要的也就是你的“重视”而已。

在沟通中，难免会出现摩擦。管理者的沟通能力最好同时包括“情绪管理能力”，任何时候都不要在公共场合口出恶言，情绪失控。

始终牢记双方沟通的目的，不要中途被情绪绑架，偏离了初衷。例如我曾经在和其他部门沟通“网站客服系统更换”问题时，提出把XX为XX软件，结果客服部的同事以“学习成本”为由，表示反对。我说明新系统上手快，界面更美观。

但最后因为情绪激动，导致双方的话题偏移，爆发了一些旧问题，比如“客服每天接到的咨询量下降”之类完全和初衷无关的东西，由商量变成了纯吐槽，沟通失败。

良好的沟通方法是所有人都需要好好学习的地方，怎么说话，怎么维持气氛，都已经有很好的借鉴。有心学习，推荐大家看《关键对话》这本书。

6、认识自己的能力

文章开头提到，我发现管理其实是一个“重拾自我”的过程，更多的是管理自己，而不是他人。他人的秉性很难改变，也不要奢求改变，我能做的就是改变自己，通过改变自己的过程去影响他人。

怎样才叫认识自己呢？有几个很简单的测试问题，这些测试问题大多面试时就会提到，但这时候它们不再是面试技巧，更多的是为了看清自己。

• 我的优缺点有哪些？
• 我做事的原则有哪些？
• 我有哪方面的兴趣爱好？
• 其他同事眼中的我是怎样的？

能尽量详细地回答出这几个问题，代表你对自己有基本的认知度，认识自己，才能更好的改变自己。人活在世，最大的对手，永远不是别人。

7、时间管理能力

管理者时间宝贵，务必力求尽早跳出执行层，以更高的战略眼光去看问题。这就是为什么这么多大牛乐于分享自己的知识还能保证自己立于不败之地的精髓所在。

看待问题的“大局观”就是一个人的不可替代性。而培养这种“大局观”的前提，必须是能够合理安排工作，腾出完整的时间块，供自己学习思考。

关于时间管理，展开来说也是个大话题，有兴趣的朋友可以看一看我之前的文章《数据人生丨如何进行高效的目标管理？》，里详细记录了我的时间/目标的管理方法。

实践中对我的影响巨大，让我更深刻的从时间角度认识自己，发现平时不被注意的问题，在潜意识里种下的时间节奏的种子。

8、个人素质

传说中的个人魅力大多体现在一些细节上，管理者对待这些细节的处理方式就是个人的行为名片，常见的需要注意的个人素质行为有：

• 会议时电话静音
• 进办公室前敲门
• 有同事在开会时注视，以表尊重
• 用过饮水机后关门
• 离开工位时熄/锁屏
• 下班离开时把椅子推进桌下
• 多说请，并看着同事说辛苦/谢谢
• 保证桌面整洁
• 不在公司吃有味道的食物
• 知人不评人

最后，需要强调一点，个人的素质行为不应该成为工作中的主导，也就是说领导者不该试图在业绩不好的时候拿素质说话，也不要标榜哪些行为很好，这些只是加分项。

9、隐性经验

在职场中，始终牢记“没有人应该帮助你”这个观点，会让你减少很多没用的抱怨。聊到这里，再说两条职场隐性经验（潜规则）。

• 注重穿着打扮，越职业越让人觉得你的能力强
• 工作区说话/曝光次数越多，职务越高

三、5个管理痛点的分享

这部分纯属私货，只是写下我的想法和思考，不接受喷子，友好交流。

1、管理者应该是温和派还是严厉派？

管理之初，这个问题一直困扰着我。我不喜欢批评，更不喜欢厉声呵斥，妥妥的温和派。为此我一直担心同事不服。

那段时间，一直是“每一种性格都能成功”这样一句类似鸡汤的话在支撑着我。一年多后，我和同事闲聊时，听闻他说我为人太严肃。我才突然恍惚，所谓温和派严厉派只是你的一部分标签而已。

成熟的过程是慢慢意识到，这个世界并不是非黑即白。你可以一面严肃、一面温柔，只是这些需要时间。

如果你和我当初有一样困惑，也请你和我一起干了“每一种性格都能成功”这碗鸡汤。因为成功最关键的因素，不在于你是什么派，而是你能不能把事情做好，做得漂亮。

2、管理层能不能和下属做好朋友？

如果没有中间答案的话，我更倾向于不能。管理者和同事之间只要处理好公事，把团队的业绩做好，那就是合格的。

当然，我也见过能和下属公事公办，私下里关系不错的领导。但是有个有趣的现象，那就是当管理和下属玩儿得很嗨的时候，下属内心是希望领导不在场的，所以私下里关系虽然好，但是朋友圈有些话题仍会屏蔽。

不同职位等级的人之间确实是有一条线存在，不论你认同不认同。

在工作中打理好团队，做好自己的事情就足够，有适当的“权力距离”，方便工作推行也挺好的，至于能不能做好朋友，不必强求。

3、遇见能力强但不服管的员工该怎么办？

首先证实是员工能力确实强，还是员工自以为是。如果是员工自以为是，果断辞退，不要有任何犹豫。虽然可以耐心指导纠正，但是耗不起。

如果确实是员工业务能力强，那么你就要适当的反省，管理者对于这些业务能力强的人最大的帮助就是声明边界，边界以内让他们放手去闯，不要设立一些常规的条条框框阻碍他们。真的是天才，你迟早会让路，虚心学习，别端架子。

还有一种极端情况，那就是员工的能力确实强，但同时又很自负，会当面质疑并顶撞你。我曾经面对过这样的问题。解决办法就是辞退，你这里装不下他。

“当面顶撞你”这种事次数多了必然有损你的威信和自信心，如果任由他继续在团队中行走，不仅不会帮你博得“宽容大度”的美名，还可能让你越来越烦躁，影响判断力。顶撞你事小，破坏团队气氛绝不容许。与其这样，不如辞退得个清净。

4、规则在一个团队中好还是不好？

创业前期的默契小团队，没规则可以让大家撸起袖子大干一场，可是团队要壮大必须有规则。就像上文提到日/周/月报表的例子。

当管理者试行观察下属和上级对规则的反应后，就要马上做出对比结论，千万别“折中”一半老规矩，一半新规矩，最后没什么卵用。

任何一个规则的制定，都不能凭着之前的经验照搬，不同的公司有不同的文化和氛围，发现规则水土不服时就要果断舍弃，寻找更高效的解决办法。

没人喜欢冗长业余的会议，也没人喜欢看着就头大的报表。管理者不该以“我原来用这一套管理得挺好”的借口来麻痹自己，规则因人而异。

5、如何应对不同团队“踢皮球”行为？

因为我本人处在运营岗，可能沟通部门及杂事较多，不少其他部门的人会以各种各样的要求提出“支援”。

管理者首先要明确部门的职责范围和界限，千万不能因为是小事就随便接别人的猴子。这种小事能接一次，永远会有第二次。

如果其他团队说不会，你就教到他们会；如果领导的意思也是这个活儿你先接，那么管理者必须要向领导传达这件事情只是暂时接手的严肃性，一旦其他部门可以接回，必须马上移交。事情要在开始就说清楚，不然就是“管闲事”。

最后，“踢皮球”在现实中可是个危险信号。凡是其他部门以不懂互联网、不懂 Excel 、不会操作后台等借口撂挑子，坚决当面指出。你是来做大事，不是来当助理的。

四、3本书、6篇文章、1点感悟

1、这3本书值得一看，思维导图已做

《卓有成效的管理者》思维导图

《关键对话》思维导图

《精益创业》思维导图

2、自己的一点感慨

我始终忘不了两年前主管对我说“俊杰，周总结会你一起参加吧。”那是我第一次面对公司的管理层，虽然不必汇报，但仍然紧张得不知道手该往哪里放。这几年时间里，我在迅速成长，可成长道路上总会有困苦。

我为每一次唐突处理的人情世故都交了学费。

当我带的第一个下属被公司辞退，主管说，你要想清楚这个人她为什么会被辞退，这个人是被你带“死”的；

当我第一次面试应聘者，面上谈笑风生，桌子下双腿其实在发抖；

当我第一次面对同事质疑，她当面怒怼说“你不就是因为我不服你所以针对我吗？”

当我第一次辞退业务不达标的同事……往事历历在目，恍如昨日。

感谢这一路曾经提携我帮助我指导我的人，我站在巨人的肩膀上看世界，同时也希望能言传身教，把这份精神传递给所有人。

整个学习计划时间预计为5个月，其中时间安排如下：知识点学习（2个月），练习和复习（3个月），预留15个工作日为报考准备

整个计划实施起止日期：2019年5月5日~2019年11月5日

项目知识点学习计划

序号	学习模板	学习目标	工作日（天）	备注
1	项目基础知识和概念	精通	3	此为长期，后期可慢慢学习
2	项目立项	精通	7
3	项目整体学习	精通	7
4	项目范围	精通	7
5	项目进度	精通	7
6	项目成本管理	精通	7
7	项目质量管理	精通	7
8	人力资源管理	精通	7
9	沟通管理	精通	7
10	风险管理	精通	7
11	采购管理	精通	7
12	合同管理	精通	7
13	信息文档和配置管理	精通	7
14	知识管理	精通	3
15	项目变更管理	精通	7
16	项目战略管理	精通	3
17	项目组织结构管理	精通	3
18	项目流程管理	精通	7
19	项目集管理	精通	3
20	项目组合管理	精通	3
21	信息安全管理	精通	7
22	信息系统综合测试和管理	精通	7
23	项目成熟度管理	精通	3
24	量化项目管理	精通	3
25	知识产权与标准规范	精通	7
26	管理科学基础知识	精通	3

基础知识复习管理

序号	学习内容	学习目标	工作日	备注
1	习题练习	针对于每个点的习题练习，每个知识点过一次	20
2	案例练习	针对于项目案例进行习惯，并结合前面的知识点过一次	10
3	论文练习	针对于习题和案例整合，进行论文编写和练习	20
4	真题练习	针对于历年的真题，题目进行练习，并按考虑要求得分数	30

写在前面
天天喊着要当CTO，现在真的当上了，才觉得自己资历太浅，可谓举步维艰。趁着春节几天休息，看了不少文章和书籍，借鉴前人的一些经验，也算是给自己补充点CTO的理论知识。

CTO五种基本的必备素质
本节选自《我也能做CTO之程序员职业规划 》一书

（1）超强的学习能力和对技术有浓厚的兴趣和广泛的涉猎。注重软件前沿最新技术潮流，与时消息、与时偕行，与时俱进的方法来提高自身的技术战略眼光与水平。涉猎的领域不仅涉及.NET和Java技术，还包括IBM、HP3000等大型系统设计和开发，并对界面设计、驱动开发、图像及媒体技术，中间件、ERP、CRM等都较熟悉，掌握时代新技术的潮流，这就需要获得知识的能力：具有很强的摘要及分析大量信息的能力和超强的学习能力。

（2）丰富的工作经历。

（3）很好的沟通能力和强大的推动力。有了这种能力，才能使团队成员接受自己的想法，而团队的成功协作才是软件成功的基本保障。

（4）对市场的敏锐嗅觉。CTO的首要工作就是要提出公司未来两三年内的产品和服务的技术发展方向。

（5）把IT技术与自己产品和项目结合的能力。技术并不是越先进越好，而是越能满足客户的需求越好。选择技术要和公司可以投入的资源相适应，选择合适的技术、产品与市场定位，开发效率便会提高，风险相应降低。CTO必须要拿捏这个度，新技术应用与产品和项目有力地结合，令其各自发挥特长，使得新技术的应用不会碰到太大的障碍。对于程序员来说，新技术创新能够大大地激发自主自发的工作热情。

国内外差异
在一些国外的跨国软件公司，企业文化与制度相对完善，CTO的主要职责就是设计公司的未来，即“技术战略规划”。其从某种意义上说，CTO的首要工作是提出公司未来两三年内的产品和服务的技术发展方向。更多的工作是前瞻性地制定下一代产品的策略和进行研究工作，属于技术战略的重要执行者。有的国外大型公司的CTO也会带领一个精小的团队对下一代产品进行框架设计和实验性短期的编码工作。另外还有对公司知识产权管理保护等职责。

而在国内软件公司企业文化与制度相对不很完善，CTO的主要职责就是企业文化、制度建设、资源整合、技术战略，当然其中不可缺少的就是很强的领导艺术能力，整体构成“CTO之能力沉淀模型”。

国内公司CTO发展现状是职责含糊不清，没有统一的职能界定，属于自由散打阶段，其更偏重研发管理，所做的工作内容比国外层次较低。

CTO并不一定是一个技术超强的技术牛人，这是很多国内公司的一个误区。它们把技术总监与CTO工作职责相混淆，经常看到一些挂着CTO头衔去从事技术总监或者技术总工的职责，往往自己从事项目中具体的事情，经常看到其亲自带领团队去负责从事某个具体项目工作。

在国内往往是“杀鸡用牛刀”的做法，这对公司的整体发展规划是个严重的浪费，使CTO在公司的战略发展上的作用大打折扣，很难发挥出企业“技术战略”的更深远作用。造成这种现状的原因之一就是企业没有对公司战略进行长远规划，没有明晰的战略发展目标，目光相对较短浅，不重视企业文化。另外，还有CTO职能界定模糊，业界群体对这一职能的思想素质能力和意识不高等多方面原因。

衡量CTO的工作质量的七个基本要素
（1）建立公司主营业务中记述框架和实施模式。
（2）建立高效的技术团队。
（3）有效地建立与运行健全的项目管理体系。
（4）有效地建立与运行公司的知识库管理体系。
（5）有效地为公司商业营销管理、人力资源管理、财务管理等提供了良好的技术接口。
（6）在公司范围内建立并有效运行评估新技术引进及风险管理制度。
（7）有效地引导企业建立企业技术文化，并对软件产品及软件项目进行技术的规划。

梦想每个人都有，或者每个人都曾经拥有；目标并不是每个人都很清晰，实现梦想是人生追求的最高境界；而清晰的个人目标与组织目标的一致、阶段性目标与人生梦想方向的一致、个人能力和资源整合与目标达成的一致，是梦想达成的方向性和资源能力组合的必然选择。坚守简单快乐生活原则，注重职业价值贡献。

CTO成长路径：读万卷书，行万里路。

技术管理的通用职责
管理者的通用职责是两个：建设团队、完成任务。但作为企业的技术负责人，需要增加一项技术技能：技术选型。

完成任务这一说法偏被动，我更喜欢完成目标（G）。

建设团队T1、技术选型T2、完成目标G三者构成了技术负责人的三项基本职能，而创业的不同阶段，技术负责人的角色不同不过是这三项职能的偏重点不同罢了。

上述三者，建设团队、技术选型T是基础，目的还是为了实现企业的目标，所以完成目标G是目的。

完成目标G的分析完全可以套用项目管理三角形：时间、范围、资源。公司对时间和范围的要求决定了资源的投入与组成。即完成目标本身又会对团队和技术有自己的特别需求，也就是反作用于T。这三者的关系关系是分类便于理解，但实质你中有我，我中有你，不可分割。请自行理解，我就不用图来表示了。

建设团队有非常丰富的内涵，一种分解方式是以人为中心的，比较好记：选用育留。即选人、用人、育人、留人。另一种分解方式是以管理职能为维度的，更细致，包括：组织设计、人才的计划、招聘、任用、培训、考核与激励、领导与控制、团队文化建设等。

技术负责人的三项基本职能也可以用另外一种方式来表述，即技术负责人眼里的三件事：产品、技术、人。创业的不同阶段，技术负责人的角色不同不过是这三件事的偏重点不同。不详细展开。

创业不同阶段的CTO技术划分
创业的起步阶段S1的技术管理
这个阶段的技术负责人的角色可以叫CTO，也可以叫技术总监，但实际上的职责更偏向于Technical Leader (TL)，技术领头人。

G在这个阶段最重要，几乎可以说是TL的唯一目标。这个不是由技术决定的，而是由创业企业本身的特点来决定了。要么生存要么死，企业生存就是完成企业经营目标，相应的技术团队就得全力以赴完成技术目标，毫无疑问。

T1则可以最简化为招人，人招进来往需要的坑里扔就行，因人设岗也成为一种实用的方式。所以，比较常见的错误或者是误区是因为没有做好人力资源规划，常招进来不合适的人，或者需要人的时候没有。所以，在这个阶段TL是个多面能手就显得非常重要。简单来说，就是公司技术缺什么，CTO得自己冲上去做。换句话说，成功度过此阶段的创业企业通常都因为有一个万金油CTO。

这个阶段TL怎么招人，又招了什么样的人进公司，看起来都是为了完成目标，却间接奠定了一家公司的技术文化。这是很多起步阶段的CTO和CEO容易忽略的问题。

在这个阶段，风险比较高的其实是技术选型T2。一方面CTO在此事要全副精力来完成目标G，给技术选型的时间和精力比较少，另一方面，此时的技术选型，奠定了一家企业未来的技术方向，也就奠定了技术团队的组成，可以说其实T2才应该是CTO的唯一目标。

总结一下，在起步阶段(S1)，企业需要CTO的角色是完成技术目标G，技术工作的特点需要CTO的角色是技术选型T2。

平衡这两者成为衡量一个CTO是否成功的标志。

技术选型怎么选，国内各路大牛有很多成熟的经验，也能给你整出很多论文来。但在创业企业，简化为两个结果：
1）TL自己会什么选什么；
2）业界流行什么选什么。前者还是回到前面黑体字，不用管什么技术合适，公司只有他最懂，就他合适。但是，如果CTO不是企业创始人，这对公司的风险就非常高：CTO技术很牛，但不合适公司怎么办，换还是不换？后者则相对保险一点儿，但业界到底流行什么？

所以，一种技术选型的方式是看人才市场行上有什么人，公司能找到什么人，看团队的能力来定技术。

创业型企业内充满了草莽做法，还都能行，这也算是创业企业有活力的一个侧面吧。

这么说吧，这个阶段完成目标G的质量决定了企业是否能生存，团队建设T1技术选型T2则决定了企业生存下来后是否能顺利的度过下一个发展阶段。

注：上文中一会儿使用TL，一会儿使用CTO，希望由此标明角色内涵的变化。TL是带着团队完成目标，CTO则要偏宏观技术管理。

创业的发展阶段S2的技术管理
这个阶段的技术负责人的角色应该是技术总监，职责上准确定义应该是研发总监。在技术管理的三项基本职能里，TD的主要精力应该在T1，建设团队。

TD必须及时转变自己的职业定位，从冲在前列的TL，改为在后面指挥的TD。很多技术负责人在这个阶段无法及时调整自己的角色，成为了技术团队发展的拌脚石。市面上有很多针对TL转型为管理岗的培训，适合于大企业里TL的成长课程，对创业企业来说，其实也需要。

相对T1，T2这个阶段的重要性也许没有变化，紧急程度则大幅度降低，基本上保持应需而变即可。即，TD需要根据公司业务的发展，实时的监测技术，确保技术没有成为瓶颈。

在这个阶段技术选型应该充分认证，需要根据公司的业务方向来确定，而绝对不可以再根据TD的技术能力或者团队的技术能力来选型，而是根据业务决定技术，由技术决定团队。

在此阶段，G并非就可以忽略，而是说，TD如果能做好团队建设T1，G就是水到渠成的事情。技术目标达成应该是TD的间接任务，而非直接任务。TD是依靠他的团队来完成技术目标，而非自己。

创业的稳定阶段S3的技术管理
所谓稳定阶段，不过是相对稳定罢了。这个阶段的技术负责人可以勉强成为CTO了，或者企业对技术负责人的角色定义是CTO还是TD，体现了对技术负责人的不同定位。

如果是TD，技术负责人的角色和发展阶段S2类似。差别在于在S2，TD眼里的团队应该是所有人，而在S3，TD眼里的团队更多的是团队里的中坚力量，而无法兼顾所有人了。

如果是CTO，在这个阶段，他的角色的主要职责应该回到G，此时的G已经不仅仅是完成目标G，而是开发目标G：这家企业未来的技术目标是什么？技术目标由业界的技术发展和企业自身的产品目标综合决定，背后是企业的经营目标。所以，实际上此时的CTO和CPO、CEO、CFO等关心的问题应该是一致的，不过是不同职能关注的角度不同罢了。

一些CTO在这个阶段还沉迷于技术，无法关注到企业的经营目标，就不合适了。

回到技术本身，这个阶段CTO如果是企业从起步阶段就在职的，那么他应该也必须去参加一些管理课程，改变自己依靠经验做事也能成功的习惯。这种管理培训，并非一定要学习一些管理理论工具意识，而是时刻警惕自己思维固化。另一方面，他应该尽量接触更多的同行业不同行业的人，开拓思路，协助企业更好的发展。

CTO名义上有T，但实际上随着团队的增加，角色偏重的不同，CTO并不能很好的掌控T了。此时，前两个阶段打下来的技术文化才真的决定这家企业的技术、技术氛围。

团队建设之技术团队的人员比例
技术团队简单粗暴的划分由三类人组成：领导者/管理者、中坚力量、普通工程师

所谓中坚力量有很多定义，我喜欢的是这种：具备自管理能力的员工，只需要管理者给出方向就可以高质完成任务的员工。

这三者的比例，更重视中坚还是更重视普通工程师，反应了技术负责人的管理风格，企业的技术文化，企业文化的一部分。

虽然从理论上讲，随着公司的发展，技术负责人肯定也只能更重视中坚。但我接触到的创业企业的技术负责人常常更偏重普通工程师，这是一个非常有趣的现象。我猜测大概他们中大部分都是由小团队TL长起来CTO。所以，能看到的团队的组成大部分是这种树形结构的：

管理者：中坚：员工=1:1:8

管理者把中坚当成自己的副手，认为自己对他不薄，寄希望于他能够尽心尽力协助自己。但作为副手的中坚则往往不甘于此，觉得自己遇到了瓶颈。结果就是中坚不稳，管理者CTO永远摆脱不了TL的身份。

当然这种团队组织方式也是最通常的方式，很容易得到人力资源部门和更高级领导的认可，这大概也是大部分技术团队采用树形结构的原因。

我自己理想的团队则是1:4:5的，甚至我自己的1应该排除在外完成是一直扁平团队，团队依靠强大的中坚力量成为一直自组织的团队。作为技术负责人才可以真的关心他那个阶段该关心的事情：目标、团队组织、技术方向等。这种团队本身并不意味着人力资源成本的增加，完全可以通过缩减人数来控制成本。当然，截至到目前为止，我只遇到过一个与我有相同观点的CTO。

创业阶段划分
上述S1，S2，S3，业界应该有标准分法，我则喜欢用技术团队的人数来大概划分：

S1 < 20 // 第一阶段 20 < S2 < 100 // 第二阶段 S3 > 100 // 第三阶段
这里的20是个概数，我通常以CTO本身能直接管理的团队成员数量的上限来表示，即这20个人都是直接向CTO汇报工作的。