- 项目落地 - 《如何给项目排期》

        本文属于专栏《构建工业级QPS百万级服务》系列简介-CSDN博客

---

          “谋定而后动，知止而有得”

-《孙子兵法》

        软件的生命周期包括【设计-开发-测试-部署-运维-下线】，给软件项目排期是设计阶段所做的事情。 而如何给项目排期，我在刚工作两年时疑惑过，也在之后作为有经验的人给别人解惑过。接下来，我以研发的角度，分享一下我在排期这个事情上的经验。

        作为研发，给软件项目排期。有两类角色：一线开发人员和项目一号位。

1、一线开发人员

        一线开发人员，特别是新入职场的同学，遇到的第一个难题往往不是开发，而是如何回答产品经理或者leader询问的，“这个功能要开发多久”。预估开发时间太长，会受到别人的质疑，另外即使提前开发完了，之前沟通的测试资源也是在几天之后。预估开发时间太短（这也是新人常犯的错误），会导致加班加点地工作，还持续延期，甚至影响上下游。我的经验是：

        小需求：除了修复线上bug和“特别紧急的需求”外，任何开发相关的排期，都需要1天以上。因为，在实际实现之前，很难准每次都确判断是否会遇到问题。另外作为研发人员，除了写代码、自测之外，我们在开发的同时，还承担着参与上下游方案讨论、线上维护、Code Review等责任，而这些责任的履行，很多情况下会比开发优先级更高。所以不要把自己放在一个真空的环境中。让开发的排期在1天以上，因为这个排期的意义不是“写代码需要8个小时”，而是“在履行其他职责的同时，我会在8小时内完成开发和自测”。最后要特别强调一下，何谓“特别紧急的需求”，在实际工作中，我们要先知道，这个需要对谁紧急，是对用户，还是上下游团队，还是提出需求的人，只是习惯性说“越快越好”。比如，产品经理对我说，“有一个页面展示方式更新的需求，很紧急，今天开发上线，越快越好”，那我会如此沟通，来判断是否真的紧急：

• 页面目前展示方式，持续多久了，用户对新展示方式的需求，必须在某个截至日期前吗
• 这个需求是否影响上下游开发、测试联调，截止哪天没开发完，会阻塞他们的进度
• 我这边手里可能会有xx的事情插入，如果明天上线，造成的具体影响是什么

        当然，我们对业务理解得越深刻，我们就越能清晰得知道需求得紧急性。

        周/月级需求：排期本身也需要时间。对于稍复杂的项目，排期本身也是一个工作，在计算排期前，我们需要大体做一个方案设计，梳理链路是否有卡点，对于不熟悉的部分，我们还需要咨询有经验的人或者在网上看看别人怎么做的。所以不要一拍脑门就觉得排期应该xx天。这不仅可能会坑了自己，其他配合的团队也会收到影响。所以先告知，需要x时间，才能给出排期。做完工作内容梳理之后，再给出排期。

 2、项目研发一号位

      作为项目的一号位，一般是在一线开发上有一些经验，且有沟通意愿的同学。而排期的项目一般时间会更长一点，并且这里关注的不止是自己的排期，还是参与项目的人的排期，以及其他参与人有多少比例的精力会放在此项目上。

        季度/年（多人参与）需求：先确认方向，再分阶段排期。这样的项目，部门给很多资源，自然对项目也有期许，做这样的项目，不要急于设计。因为这样的需求，大概率刚开始也是不够清晰，或者需要先结合业务和工程经验才能确定。比如老板让你造一辆好车，于是你努力去造一辆保时捷，可是造到一半，发现老板是需要一辆车来做冰箱运输生意，这时候怪别人为什么不把需求说清楚是没有意义的。现实是，资源是有限的，从结果上，成功落地的事情越少，倾斜的资源就会越少。为了做这件事，我们首先要做的是，具象需求，以造车为例子：

• 造这辆车的目的是什么，预计会有哪些收益，部门的期望是什么样的，其他部门是否有见过类似的车，有什么积累的经验
• 车的这些功能里，优先级是怎么样的。在能跑的前提下，我们是更关注速度，还是安全，或者是舒适度，还是运载能力
• 在阶段性里程碑中，哪些会影响哪些上下游，哪些事情我们需要在部分里程碑完成之后再讨论

        前文强调了确定项目方向的重要性。因为远期的事情更加不确定，所以分阶段排期尤为重要。以作者作为项目一号位，完成的其中一个开发周期半年工业级服务为例，我第一次大概会给出如下排期：

• 截止7日：完成需求沟通
• 截止21日：完成方案设计，核心模块A-D和辅助模块E-H的owner责任划分
• 截止30日：A-B-C-D环节，在一个月之内，给出数据协议和demo数据（小提示：demo数据可大大降低沟通gap的风险）
• 截止45日：确认A-D开发是否有卡点，如顺利E，F，G，H相关同学开始介入开发
• 截止60日：A，B，C，D模块完成开发测试，开始模块间联调
• 截止90日：所有模块开发完成，A-D完成联调，灰度环境上线
• 截止120日：E-H逐步嵌入已有链路灰度环境，A-D完成性能优化、补齐监控、告警等
• 截止150日：完成链路问题修复，准召回评测。基于已有版本的新需求和排期
• 截止180日：完成流量逐步放开，用反收集和小功能迭代。完成第一版收益总结和评估

        这里可以发现，越靠前，里程碑越具体，越靠后，里程碑越模糊。因为长时间项目的排期，不是一次性完成的，我们需要在项目进行的过程中调整排期，比如也需要在60日时，把60-180日的计划做一版迭代，并和部门再次对齐。《计算机程序设计艺术》也说过，“程序的早期优化是所有罪恶的根源”。我认为这个道理也同样适用于项目排期。所以，总的来说，“近具体，远模糊”的分阶段排期是一个能够提高项目落地概率的好办法。