关于排期的一些思考——技术债咋整

      作为PM，排期属于是非常重要的事项，而今年在排期的过程中确实也趟了一些坑，在此记录一下，权当是个随笔作业。

技术债务的产生：

      今年游戏市场惨淡，公司的业绩下滑，对于各个研发组来说，最直观的表现是KPI变难了，而PM在这个时候承受着巨大的排期压力，在解决技术债务和继续开发产品需求中，如何抉择将十分重要。

      在《重构》这本书中，Martin Fowler针对技术债务从两位维度分成四个象限：即有意的（Deliberate）、无心的（Inadvertent）、谨慎的（prudent）、草率的（Reckless），在本文上述描写的环境下，大多数情况是有意的，即研发团队对于交付压力的人为妥协，系统设计并没有遵循最佳实践，下文的内容也会从有意的这个象限去分析，而至于其他象限，PM也应做到有意识的去预防。

      在每次的排期过程中，如果出现了技术工期的时间被压缩，或者属于技术团队的研发环节缺失，如概要设计、时间评估、环境需求准备等，PM还在对于自己的沟通谈判能力沾沾自喜时，技术债务就产生了。

技术债务的影响：

      技术债务产生的影响颇为直观明了：

1. 需要花费更多的时间处理历史遗留问题

2. 历史代码对新需求研发造成阻碍

3. 发生双高（重要性/紧急性）事故的风险概率上升，且随着时间推移，风险出现的频次变得更为密集。

4. 迭代速度变慢，延期率增高

5. 可能会有需要破釜沉舟，全面重构的一天

其余的团队士气损伤，用户忠诚度降低，机器维护费用上浮等等问题在此先按下不表。

      把我今年的亲身经历在这里写一下，可能会直观。就像前文说的，今年的KPI压力比往年大，往年会专门准备的技术优化周期在今年被遗忘，大家甚至也都不提了。而CTO在跟老板沟通时，也不敢对一个月的技术优化周期，带来的数据下滑买单。上半年大家干劲十足，数据进展的有声有色，而到了Q3，高危事故发生率大幅上涨，线上问题频繁发生，研发部门在当前的迭代周期需要付出更多的时间对上一个迭代周期的遗留问题买单。品质部门在Q3提出的BUG甚至别前两个季度加在一起还要多，运维就更不用说了，黑眼圈又加深了一层。

      下面是一些我负责项目今年的一些数据，更为直观表现技术债务的一些影响

	迭代延期率	双高事故发生次数
Q1	8.30%	0
Q2	3.84%	1
Q3	18.19%	5
Q4	25.00%	3

      所以PM需要明确，技术债务是团队生产力的恶性毒药，也会对排期工作造成巨大的阻碍，甚至会导致人员流失。这个问题是务必需要预防，需要定时拉出来聊，也需要按期处理的，不要等到一坨屎山压在头上积重难返的时候才追悔莫及。（像我们这种一年不把数据做起来，项目就解散的情况除外.......）

PM可以对技术债务做些什么

       首先，PM需要让干系人明白，技术债务的严重性，我们可以提供数据告诉干系人一个可量化的成本增加，无论是迭代延期率或事故带来的损失，亦或是产品质量的下滑。

      其次，PM需要让干系人达成共识，我们的选择是做或者等会再做，而不做，不是一个可选项。

      然后，协助技术Leader，为其扛住技术优化这面大旗提供助力；跟团队共度难关，无论是带着技术债务负重前行，还是攻克技术债务，PM应当做好仆人式领导，在各种情形下维持团队士气，避免人员流失的情况发生。

      最后，做好偿债计划，平衡绩效压力和技术债务，研发团队也要吃饭的，不要因为在技术债务上投入巨量成本而不管绩效导致奖金包缩水甚至罚款。