写在前面
天天喊着要当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汇报工作的。

1.springboot项目pom.xml文件下添加如下配置

2.resources目录下创建logback-spring.xml文件

<?xml version="1.0" encoding="UTF-8"?>
<!--该日志将日志级别不同的log信息保存到不同的文件中 -->
<configuration>
    <include resource="org/springframework/boot/logging/logback/defaults.xml"/>

    <springProperty scope="context" name="springAppName"
                    source="spring.application.name"/>

    <!-- 日志在工程中的输出位置 -->
    <property name="LOG_FILE" value="${BUILD_FOLDER:-build}/${springAppName}"/>

    <!-- 控制台的日志输出样式 -->
    <property name="CONSOLE_LOG_PATTERN"
              value="%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} %clr(${LOG_LEVEL_PATTERN:-%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}}"/>

    <!-- 控制台输出 -->
    <appender name="console" class="ch.qos.logback.core.ConsoleAppender">
        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
            <level>INFO</level>
        </filter>
        <!-- 日志输出编码 -->
        <encoder>
            <pattern>${CONSOLE_LOG_PATTERN}</pattern>
            <charset>utf8</charset>
        </encoder>
    </appender>

    <!-- 为logstash输出的JSON格式的Appender -->
    <appender name="logstash"
              class="net.logstash.logback.appender.LogstashTcpSocketAppender">
        <destination>192.168.11.86:9250</destination>
        <!-- 日志输出编码 -->
        <encoder
                class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">
            <providers>
                <timestamp>
                    <timeZone>UTC</timeZone>
                </timestamp>
                <pattern>
                    <pattern>
                        {
                        "severity": "%level",
                        "service": "${springAppName:-}",
                        "trace": "%X{X-B3-TraceId:-}",
                        "span": "%X{X-B3-SpanId:-}",
                        "exportable": "%X{X-Span-Export:-}",
                        "pid": "${PID:-}",
                        "thread": "%thread",
                        "class": "%logger{40}",
                        "rest": "%message"
                        }
                    </pattern>
                </pattern>
            </providers>
        </encoder>
    </appender>

    <!-- 日志输出级别 -->
    <root level="INFO">
        <appender-ref ref="console"/>
        <appender-ref ref="logstash"/>
    </root>
</configuration>

5.31. Spring boot with ELK(Elasticsearch + Logstash + Kibana)

将 Spring boot 日志写入 ELK 有多种实现方式，这里仅提供三种方案：

1. Spring boot -> logback -> Tcp/IP -> logstash -> elasticsearch 这种方式实现非常方便不需要而外包或者软件
2. Spring boot -> logback -> Redis -> logstash -> elasticsearch 利用 Redis 提供的发布订阅功能将日志投递到 elasticsearch
3. Spring boot -> logback -> Kafka -> logstash -> elasticsearch Kafka 方法适合大数据的情况。

5.31.1. TCP 方案

logstash 配置

			input {
  tcp {
    host => "172.16.1.16" 
    port => 9250
    mode => "server"
    tags => ["tags"]
    codec => json_lines  //可能需要更新logstash插件
  }
}

output {
 stdout{codec =>rubydebug}
  elasticsearch {
   hosts => ["localhost:9200"]  //这块配置需要带端口号
    flush_size => 1000

  }
}			

Spring boot logback.xml 配置

			<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <property resource="properties/logback-variables.properties" /> 

    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <encoder charset="UTF-8">
            <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n
            </pattern>
        </encoder>
    </appender>
    <appender name="LOGSTASH" class="net.logstash.logback.appender.LogstashTcpSocketAppender">
        <destination>172.16.1.16:9250</destination>
        <encoder charset="UTF-8" class="net.logstash.logback.encoder.LogstashEncoder" />
    </appender>

    <!--<appender name="async" class="ch.qos.logback.classic.AsyncAppender">-->
        <!--<appender-ref ref="stash" />-->
    <!--</appender>-->
    
    <root level="info">                    <!-- 设置日志级别 -->
        <appender-ref ref="STDOUT" />
        <appender-ref ref="LOGSTASH" />
    </root>
</configuration>			

5.31.2. Redis 方案

Maven pom.xml 增加 Logback Redis 依赖

			<!-- https://mvnrepository.com/artifact/com.cwbase/logback-redis-appender -->
<dependency>
    <groupId>com.cwbase</groupId>
    <artifactId>logback-redis-appender</artifactId>
    <version>1.1.5</version>
</dependency>			

Spring boot logback.xml 配置

			<?xml version="1.0" encoding="UTF-8"?>
<configuration>
	<include resource="org/springframework/boot/logging/logback/defaults.xml" />
	<include resource="org/springframework/boot/logging/logback/file-appender.xml" />
	<property name="type.name" value="test" />
	<appender name="LOGSTASH" class="com.cwbase.logback.RedisAppender">
		<source>spring-application</source>
		<type>${type.name}</type>
		<host>localhost</host>
		<key>logstash:redis</key>
		<tags>test-2</tags>
		<mdc>true</mdc>
		<location>true</location>
		<callerStackIndex>0</callerStackIndex>
		<!--additionalField添加附加字段 用于head插件显示 -->
		<additionalField>
			<key>MyKey</key>
			<value>MyValue</value>
		</additionalField>
		<additionalField>
			<key>MySecondKey</key>
			<value>MyOtherValue</value>
		</additionalField>
	</appender>
	<root level="INFO">
		<appender-ref ref="FILE" />
		<appender-ref ref="LOGSTASH" />
	</root>
</configuration>			

logstash 配置

			input {
    redis {
        host => 'localhost'
        data_type => 'list'
        port => "6379"
        key => 'logstash:redis' #自定义
        type => 'redis-input'   #自定义
    }
}
output {
    elasticsearch {
        host => "localhost" 
        codec => "json"
        protocol => "http"
    }
}			

5.31.3. Kafka 方案

暂时没有机器资源，本章节待续

1.有关ELK

1.1 简介

在之前写过一篇文章介绍ELK日志收集方案，感兴趣的可以去看一看，点击这里—–> 《ELK日志分析方案》。

这里在对ELK做一下简述，ELK是有Elastic公司的三个组件配合进行日志收集，分别是：

• ElasticSearch:用于存储日志信息。
• Logstash:用于收集、处理和转发日志信息。
• Kibana:提供可搜索的Web可视化界面。

当然，现在很多都配合着Beats进行使用，这里不做过多描述，感兴趣的可以查看官网，www.elastic.co/cn/products…，这里有很多对Beats的描述。

1.2 安装

有关ELK安装笔者之前都写过关于Linux环境下的安装，如下：

• 《Linux安装Elasticsearch》
• 《Linux安装Logstash》
• 《Linux安装Kibana》

其他环境安装方式类似，基本上都是下载压缩包解压这一套流程。

2.SpringBoot日志输出到Logstash

这里以logback日志为例，新建项目，在项目中加入logstash-logback-encoder依赖，完整pom如代码清单所示。

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.1.2.RELEASE</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>
    <groupId>com.dalaoyang</groupId>
    <artifactId>springboot_logstash</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>springboot_logstash</name>
    <description>springboot_logstash</description>

    <properties>
        <java.version>1.8</java.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-devtools</artifactId>
            <scope>runtime</scope>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>net.logstash.logback</groupId>
            <artifactId>logstash-logback-encoder</artifactId>
            <version>5.3</version>
        </dependency>

    </dependencies>


    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>

</project>

接下来新建一个logback-spring.xml文件，配置logback日志信息，注意这里配置的destination属性，输出的要和logstash配置的对应上，不然收集不上，内容如下：

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <include resource="org/springframework/boot/logging/logback/base.xml" />

    <appender name="LOGSTASH" class="net.logstash.logback.appender.LogstashTcpSocketAppender">
        <destination>127.0.0.1:4560</destination>
        <!-- 日志输出编码 -->
        <encoder charset="UTF-8"
                class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">
            <providers>
                <timestamp>
                    <timeZone>UTC</timeZone>
                </timestamp>
                <pattern>
                    <pattern>
                        {
                        "logLevel": "%level",
                        "serviceName": "${springAppName:-}",
                        "pid": "${PID:-}",
                        "thread": "%thread",
                        "class": "%logger{40}",
                        "rest": "%message"
                        }
                    </pattern>
                </pattern>
            </providers>
        </encoder>
    </appender>

    <root level="INFO">
        <appender-ref ref="LOGSTASH" />
        <appender-ref ref="CONSOLE" />
    </root>

</configuration>

修改启动类，加入一个mvc方法，主要用于输出日志，如下所示。

package com.dalaoyang;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@SpringBootApplication
@RestController
public class SpringbootLogstashApplication {

    Logger logger = LoggerFactory.getLogger(SpringbootLogstashApplication.class);

    @GetMapping("test")
    public void test(){
        logger.info("测试初始一些日志吧！");
    }

    public static void main(String[] args) {
        SpringApplication.run(SpringbootLogstashApplication.class, args);
    }

}

3.Logstash配置

logstash配置如下，再次提醒一下，输入要与刚刚配置的对应上，输出为本地es：

input {
  tcp {
    mode => "server"
    host => "0.0.0.0"
    port => 4560
    codec => json_lines
  }
}
output {
  elasticsearch {
    hosts => "localhost:9200"
    index => "springboot-logstash-%{+YYYY.MM.dd}"
  }
}

4.测试

打开kibana管理页面，添加刚刚创建的索引，如图所示。

然后进入发现页，选择刚刚的索引，如下所示。

接下来在浏览器多次访问刚刚在项目中输出日志的方法，查询控制台，如下所示。

然后在进入kibana查看，不光是日志内容，还有自定义的属性也显示出来了。

随着互联网金融企业的业务发展，每研发一个新产品（即需求），都会涉及产品、需求、安全、开发、测试、运维等多个部门的共同协作。如何提升跨部门工作的协同和效率，对于一家追求快速创新的互联网金融企业来说显得尤为重要。

当前主流的的管理工具有Redmine、ITSM、TechExcel、JIRA等，除JIRA外都提供统一的标准化流程，无法做到针对不同的组织或团队进行个性化的定制。

早期JIRA在我司仅作为一个专业的Bug管理工具来使用，在逐步摸索的过程中发现JIRA也具备需求管理、敏捷研发管理、流程体系管理
、产品Bug跟踪等功能。JIRA的优势在于可以根据不同的团队和制度流程，从项目、问题类型、工作流、界面、过滤器、分析统计报表、个性化页面导航等维度实现随需定制。

现阶段我司将JIRA作为需求研发的管理工具，实现了需求从提出到分析进而到研发测试的统一管理，并与Confluence对接实现文档流程一体化。让各部门能及时了解需求的排期及研发进度，降低沟通成本，提高沟通效率。

现分享一下JIRA实现需求研发管理的具体配置：

通过JIRA工具，我们实现了需求研发任务的可视化管理。举个简单例子：利用JIRA中的时间跟踪字段，可以对研发任务的进度情况、人力情况进行统计，并以甘特图或燃尽图的形式进行展示，便于管理者了解项目研发的整体进度情况。然而同一个需求下的研发测试任务之间普遍存在互相依赖的关系，我们采用父子任务以及任务状态的强校验形式对这类研发任务进行管理。在前期需求分析时创建子任务，若子任务没有完成，作为父任务的需求工单将无法提交发布，从而避免因模块间依赖关系而导致的发布质量问题。

针对每个公司或者每个项目的不同情况，JIRA的工作流和界面制定都是灵活的。项目经理可以在JIRA中定制出适合本公司项目的流程，各实施人也可以在切身使用过程中提出优化建议，实现流程的不断改进完善。