优化重构与业务推进，如何平衡？—— 找CTO圆桌派第二期小记

本文主要是介绍优化重构与业务推进，如何平衡？—— 找CTO圆桌派第二期小记，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

【找CTO圆桌派】第二期圆满收官，有了第一期的经验之后，第二期无论是主讲嘉宾还是受邀嘉宾都更加自如，现场气氛热烈，脑力激荡，不同观点的碰撞，擦出很多火花。

现场提问不断，有互联网创业公司在各个阶段会遇到的实际问题，也有技术人员对未来该如何转型的迷茫，主讲嘉宾和受邀嘉宾各抒己见，干货满满。

我们把这一期圆桌派中大家提出的一些典型问题做了梳理，以下是详细内容。

1、CTO要做系统重构，但CEO要的是业务价值，如何跟CEO争取时间来做系统重构和优化？

杜仲说：

这个问题是技术管理者跟CEO交流中比较常见的问题，CTO一般都会比较理解业务的软件系统，从公司的初创到业务有起色，系统架构不可能一开始就规划得那么完备，特别是刚开始创业的时候，还不知道业务能不能做起来，所以一般都会用一些快速的方法和相对简单的架构来搭建系统，随着业务发展起来后，先前的系统架构可能就满足不了业务发展的需求了，这时候需要对系统进行一些优化甚至是重构，以便能更好地支持业务的发展，但CEO更多考虑的是业务价值，如果不能直接创造价值就不会愿意投入资源去做重构（指的是给半个月甚至一两个月的时间做系统重构而不做能直接来钱的业务开发）。

作为CTO这个时候跟CEO交流，就得将技术语言转化为CEO能听懂的业务语言，这样大家才能在同一频道交流、探讨，并作出决策。而如果双方都是站在自己的立场，各说各的，那肯定是无法达成一致的决定。CEO肯定希望研发资源投入到能直接带来收益的业务开发上去的。所以CTO得转换一种说法，将系统重构的业务价值展现出来，并使用数字化的方式表达价值。

举个例子：当前的系统使用两台服务器能支撑一万人同时在线，平均每个人打开页面的时间差不多是3-5秒。假如不升级系统，按现有业务快速发展，3个月后将有5-10倍的业务量，那时候系统得扩容到6台服务器，而因为压力增大之后每个人打开页面的时间差不多得8-10秒，这样带来的服务器、带宽支出大大增加，并且用户体验要差很多，而且在当前系统的架构下，因为系统的耦合度较高，开发一个普通业务的时间也会越来越长。如果按照我们现有规划做系统架构优化，3个月后同样的用户量，只需要3台服务器，并且可以确保用户打开页面时间仍旧在3-5秒之内，并且可以为未来6-12个月的业务增量保持一定的冗余和支撑能力，而且架构优化后，模块之间的耦合度降低，开发新业务的时间也会大大缩短。而为了让系统达成这个能力，必须进行架构升级，大概需要团队1/3的人半个月左右的时间进行开发和调试。

如果能用上面例子中这样的数据进行描述，相信懂业务和价值判断的CEO，一定会认同CTO做架构优化的规划。

2、能聊一聊技术团队的效能度量指标吗？

哈里森叔叔说：

我们都知道“无度量、不改进”的经典管理理念，在复杂度日益增长的软件开发领域，如何改进团队的研发效能是每个技术团队正在面临的问题，健信科技的咨询专家团队结合近二十年的软件研发领域经典实战案例和理论体系，整理了效率、质量、成本、饱和度四大维度及其内在多个细化指标体系内容。在效率维度，有多个细化指标在日常的管理工作中已经发挥出具体的作用。

这些细分的指标分成两大类，一类是属于相对指标系，另一类是绝对指标系。相对指标系的作用是用来在团队中划定一个参考标准，用来衡量团队的周期变化趋势，和发展趋势情况，引导团队做更好的细节规划；绝对指标系是用来对团队内部研发过程做一个专项问题定性判断使用，帮助团队针对专项问题进行深入分析的必要性做出辅助判断。

相对指标系中，包含“时间折算生产率”和“价值交付生产率”等多个内容。

时间折算生产率是将团队曾经或正在面对的业务领域中，最小独立需求单元进行识别，再根据团队当前的技术能力和生产力条件对该需求进行处理时间的估算，并将该时间作为标准单元的标准时间，结合人员数量，由此可以得出一天内整个团队的标准任务量，以此作为团队参考基准产出量，用当前团队一段时间的工作内容与该基准进行对比，可以得出当前的团队生产力情况，随后观察下个时间段的数据，将两个数据的变化趋势来分析，可以得出团队当前的效率变化趋势情况。

在绝对指标系中，我们特别规划设计了“需求增值速动率”指标，这个指标的核心是为了衡量团队内需求从提出到交付过程中存在的“浪费”问题而提出。内容上，使用团队每个人的实际任务工时总和与需求交付和提出日期的差换算成需求交付总工时之和的比例来进行计算。如果该指标的数据结果低于0.5，说明团队内存在相对较多的浪费情况。我们用这个指标在日常的咨询工作中，获得了比较好的效果，帮助多个团队识别了问题点，帮助团队找到了实际的改进方向。

软件研发是一件非常复杂的工程工作，过程中会有非常多的干扰和调节因素，所以任何针对软件研发工作的度量都不能是站在单一维度、单一指标系的评估，而是用严谨的态度，多方面、多指标综合评估团队情况，并作出一系列持续改进，才能获得良好的收效。

3、我们研发团队之前的考核周期是一个季度，接下来老板要求我们按月进行考核。有没有必要按月进行团队考核？如果实行按月考核，应该如何设定考核指标？

老傅说：

通常来讲，研发工作的特点是高创造性。与常规的固定周期性生产工作不同，它的产出量很难根据经验进行精确测量。与销售等工作更不同，它的成果无法在短期内跟直接收益挂钩。因此，研发团队的考核需要在一个相对较长的周期，以更好的验证团队成员的创造性成果。一般的软件产品，能形成业务闭环项目的研发周期通常在一个月左右，上线经用户使用验证周期在一个月左右，研发的内容是否具有较好的性能、扩展性、复用性等特性需要在下一个研发周期内验证。因此，业界普遍认为研发绩效季度考核是最佳实践。

当然，这也不是说千篇一律。我们在日常工作中也可以根据工作内容固定重复性和研发-验证周期等因素进行灵活调整。例如：有些常规基础增删改查的研发工作，或者实习生在实习期间的学习锻炼等工作，可以考虑设置短周期的考核。通常来讲，这样的考核多以完成率或者变化趋势等作为考核指标。有些行业，一个完整业务目标的项目周期短，上线用户验证时间也短，也可以考虑使用短周期+长周期结合进行考核。考核指标，建议短周期内考虑交付结果为主，长周期考核技术贡献为主。

另外值得注意的是，一般的研发团队管理者在遇到这样的要求时通常是一个危险信号。除了关注考核周期问题本身以外，要多挖掘背后深层次的问题。是研发效率、质量等方面真正出了问题，是公司业务压力大需要更给力的支持，还是与公司管理层沟通不足。找出公司、业务真正对研发团队不满意的原因或诉求到底是什么，做到对症下药才能真正的解决问题。

这篇关于优化重构与业务推进，如何平衡？—— 找CTO圆桌派第二期小记的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！